一、Leaks
打开xcode中的instrument ，打开方式：
选择product -> profile 即可
通过Xcode来启动Instruments（启动前必须停止你当前的执行文件）
选择第一种启动方式，build成功后跳出Instruments工具，选择Leaks选项，工具显示效果如下，解释一下，为什么选择leaks模板，但是默认情况下还是会添加Allocations模板，
点击红色按钮，开始运行，（这里运行了一分钟直到出现内存泄露方可停止）如图所示
通过观察，可以看出红色的柱子表示内存泄露 ，如上图所示，选择leak，点击十字交叉，选择call Tree
选择Call Tree后，右下角勾选住 Invert Call Tree（倒置call tree），Hide System Libraries（隐藏系统工具）
这时候内存泄露的具体代码找到了，在右边的红色框框里指定了哪个方法出现了内存泄露。
你只要在这些方法上双击，就会跳转到具体的代码，方便程序员调试
以此选择leak，点击十字交叉，选择Cycles&roots 如图可以可以看到内存泄露地址：
点击箭头，查看结果，联系开发人员分析结果
Leaks instrument工具检查进程堆泄露的内存。你可以使用该instrument工具配合Allocations instrument工具来获取内存地址的历史记录。该instrument工具要求你加载一个进程以便它可以从进程启动时收集数据。
该instrument工具捕获以下信息：
z内存泄露的数量（The number of leaks）
z每个泄露内存块的大小（The size of each leak）
z泄露内存块的地址（Address of the leaked block）z泄露对象的类型（Type of the
leadked object）
详细面板的每个视图模式以轻微不同的函数显示泄露的数据。在列表模式下，该instrument工具显示每个泄露的百分比，而每个内存泄露有助于发现内存泄露的总数。在大纲模式下，数据被重组以便你可以查看给定的符号有多少内存泄露。对于任何模式的条目，在扩展详细面板显示内存泄露引发的深入栈跟踪信息。
二、Time Profiler
选择Time Profiler启动.
time profile时间分析工具用来检测应用CPU的使用情况.可以看到应用程序中各个方法正在消耗CPU时间.使用大量CPU不一定是个问题.类似我们客户端中不同场景的天气动画[类似大雨]的路径就对CPU依赖就非常高，动画本身也是非常苛刻且耗费资源较多的任务.
点击Record 开始运行.
刚开始我们拿到分析数据时往往是这样的:
这里显示的是执行代码完整路径，其中系统和应用本身一些调用路径完全揉捏在一起.完全看不到我们关心的应用程序中实际代码执行耗时和代码路径实际所在位置.简单的方式可以快速勾选右边Call Tree中Separate Thread和Hide System Libraries两个选项[后面会解释选项作用]:
可以看到直接能够看到应用程序各个方法调用耗时直接路径,剔除掉了系统相关方法和反向调用树路径.清爽很多.如果觉得这还不够直观,选择任意一个耗时方法分支[这里选择WeatherViewController viewDidLoad]双击进入会看到:
可以直接定位到viewDidLoad的代码，也可以直观的看到改方法下调用其他方法耗时的时间.类似[self loadCityWeatherScroollerView]耗时是121x,x既耗时单位这里为ms毫秒.当然如果直接在Instrument找到问题觉得不方便修改,可以直接点击右上方Xcode按钮会直接定位Xcode对应调用方法入口.这样很容易能够快速定位代码占用CPU最多的方法.也可以打开Xcode快速修改并重新运行Profile来看修改后耗时前后对比.简单便捷.
这里对右侧call tree选项有必要做一下说明[官方user guide翻译]:
Separate By Thread:线程分离,只有这样才能在调用路径中能够清晰看到占用CPU最大的线程.
Invert Call Tree:从上到下跟踪堆栈信息.这个选项可以快捷的看到方法调用路径最深方法占用CPU耗时,比如FuncA{FunB{FunC}},勾选后堆栈以C->B->A把调用层级最深的C显示最外面.
Hide Missing Symbols:如果dSYM无法找到你的APP或者调用系统框架的话，那么表中将看到调用方法名只能看到16进制的数值,勾选这个选项则可以隐藏这些符号，便于简化分析数据.
Hide System Libraries:这个就更有用了,勾选后耗时调用路径只会显示app耗时的代码,性能分析普遍我们都比较关系自己代码的耗时而不是系统的.基本是必选项.注意有些代码耗时也会纳入系统层级，可以进行勾选前后前后对执行路径进行比对会非常有用.
关于其他方法不再赘述.
性能分析&代码优化
我们这次性能优化主要针对如下两个使用场景:
A：应用程序第一次启动到进入天气首页的时间.
B：从后台切到前台天气首页占用时间.
在还没有拿到性能分析数据之前,一直认为第一次启动耗时主要浪费AppDelegate中第三方框架初始化上[类似WeiBo&WeChat 相关SDK初始化调用].当我们拿到实际性能数据耗时占用比时发现实际情况并非如此:
如上可以看到应用程序启动初始化工作主要会在MJAppDelegate如下两个方法展开:willFinishLaunchingWithOptions和didFinishLaunchingWithOptions,其中第三方框架初始化工作主要是willFinishLaunchingWithOptions中完成的.而实际情况耗时占比非常小.基本可以忽略不计.
而我们要优化两个启动时间场景,不同在于.第一次进入应用需要经过新手教程、添加城市、请求城市数据、解析数据、初始化天气首页UI元素并加载场景动画. 而从后台进入时则从本地存储DT文件中解析天气数据、初始化天气首页UI元素并加载天气动画.
1.NSDateFormatter问题凸显
针对这点重点分析应用启动&天气首页耗时. 在AB两个场景均发现加载首页元素发现如下问题:
继续跟踪发现:
在AB两个场景里均出现加载MJLineChartView 和 TendencyChartView 时获取时区对应时间上耗时较大.而耗时主要在getDateStrByTimeZone这个方法调用上.
其中创建一个NSDateFormatter对象平均耗时33ms左右 而设置NSDateFormatter的3个属性平均耗时也在30ms左右.因为首页24小时天气和未来几天预报中.需要for循环中遍历数据，导致这个方法别重复调用多次，则消耗时间不断叠加.
针对这个问题:
NSDateFormatter对象本身初始化很慢,同样还有NSCalendar也是如此.然而在一些使用场景中不可避免要使用他们,比如Json数据解析中.使用这个对象同时避免其性能开销带来性能开销,一般比较好的方式是通过添加属性(推荐)或创建静态变量保持该对象只被初始化一次，而被多次复用.不得不值得一提的是设置一个NSDateFormatter属性速度差不多是和创建新的实例对象一样慢！
添加属性方式如下:
针对NSDateFormatter时间开销出了重用对象外，尽量避免采用其处理多个日期格式.当然针对日期格式处理如果需要提高更多速度，可以直接采用C,可以采用第三方库来规避这个问题..
2.UIImage缓存取舍
在项目代码中看到大量使用如下代码:
在Main Thread中发现不同动画场景中Image IO 开销和耗时所占比例均不一,在UIImage元素较多总体叠加耗时也会占用一定比例.内存开销也会明显增高.
UIImage加载图片方式一般有两种:
A：imagedNamed初始化
B：imageWithContentsOfFile初始化
二者不同之处在于,imageNamed默认加载图片成功后会内存中缓存图片,这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象.如果缓存中没有找到相应的图片对象,则从指定地方加载图片然后缓存对象，并返回这个图片对象.
而imageWithContentsOfFile则仅只加载图片,不缓存.
大量使用imageNamed方式会在不需要缓存的地方额外增加开销CPU的时间来做这件事.当应用程序需要加载一张比较大的图片并且使用一次性，那么其实是没有必要去缓存这个图片的，用imageWithContentsOfFile是最为经济的方式,这样不会因为UIImage元素较多情况下，CPU会被逐个分散在不必要缓存上浪费过多时间.
使用场景需要编程时，应该根据实际应用场景加以区分，UIimage虽小，但使用元素较多问题会有所凸显.
3.天气首页加载策略
在AB两种场景把性能数据对比分析发现:
天气首页WeatherView初始化耗时一直300ms-450ms之间,占据首页耗时很大一部分.且一直固定的开销.占据Main Thread3分之一.
而用户进入最先看到是天气首页上半部分:
而下半部分需要滚动才能看到下半部分.且不一定触发:
而现在整个首页View的初始化和更新全部放到主线程来做.其中WeatherInfoView updateAllInfo方法更新耗时最长.更多的view意味着更多的渲染，也就是意味更多的CPU和内存消耗，对于我们天气首页在UIScrollView里边嵌套了很多view更是如此
而针对这种情况不要在主线程承载过多的操作.uikit渲染，用户输入回应都需要主进程上完成.主线程被意外block或者加载响应耗时过多都会影响到用户体验.而针对资源消耗过大操作，处理原则是最小化主线程的CPU占用，将工作“搬离”主线程， 不要阻塞主线程.类似本地一些IO完全移到其他线程来做.
调试time profiler过程中发现,即使占用了很少的CPU时间（如果你在Time Profiler中看到这些的数据），也可能会阻塞主线程。磁盘、网络、Lock、dispatch_sync以及向其它进程/线程发送消息都会阻塞主线 程。Time Profiler只能检测出占用CPU过多的堆栈，但检测不了这些IO的问题.很奇怪.在System Trace里面突然发现了CPU Time很低，但Wait Time很高的调用，说明在主线程处理I/O已经严重损害了app的性能,这个时候考虑把这个操作优化了.
而针对我们应用首页ui中多个view，在加载策略完全可以采用多线程进行同步加载,只把上半部分放在主线程中加载，下班可以同时开一个线程进行同步加载.这样可以大大降低组线程初始化和更新时间，当首页初始化完毕已经呈现是，下半部分其实已经另外一个线程处理完毕.
另外针对单个view 尽量不要在viewWillAppear费时的操作，viewWillAppear在 view 显示之前被调用，出于效率考虑，在这个方法中不要处理复杂费时的事情；只应该在这个方法设置 view 的显示属性之类的简单事情，比如背景色，字体等。不然，用户会明显感觉到 view 显示迟钝.
4：应用首次加载时间
应用首次启动加载操作：
首次加载坐了如下操作：
A: 链接和载入：可以在Time Profile中显示dyld载入库函数，库会被映射到地址空间，同时完成绑定以及静态初始化.
B: UIKit初始化：如果应用的Root View Controller是由XIB实现的，也会在启动时被初始化.
C: 应用回调：调用UIApplicationDeleagte的回调：application:didFinishLaunchingWithOptions.
D: 第一次Core Animation调用：在启动后的方法-[UIApplication _resportAppLaunchFinished]中调用CA::Transaction::commit实现第一帧画面的绘制.
应用程序首次加载中启动方法willFinishLaunchingWithOptions和didFinishLaunchingWithOptions只做应用程序首次启动必须的要操作,而针对_dyid_start在初始化库framework函数的操作.不必要的Framework不要链接，避免首次加载耗时.
Time Profiler功能出处：http://www.jianshu.com/p/9e1f0b44935c。