1.Time Profiler
使用中重要的就是性能测试的时候一定要用发布配置，而不是调试模式，因为当用发布环境打包的时候，编译器会引入一些提高性能的优化，比如：去除调试符号或者移除并重新组织代码，因为可以自己做到这些，比如禁用NSlog、print语句，因为 ，只需要关心发布性能。
time profile时间分析工具用来检测应用CPU的使用情况.可以看到应用程序中各个方法正在消耗CPU时间
关于使用---这里对右侧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耗时的代码,性能分析普遍我们都比较关系自己代码的耗时而不是系统的.基本是必选项.注意有些代码耗时也会纳入系统层级，可以进行勾选前后前后对执行路径进行比对会非常有用.
- 特别注意
NSDateFormatter对象本身初始化很慢,同样还有NSCalendar也是如此.然而在一些使用场景中不可避免要使用他们,比如Json数据解析中.使用这个对象同时避免其性能开销带来性能开销,一般比较好的方式是通过添加属性(推荐)或创建静态变量保持该对象只被初始化一次，而被多次复用.不得不值得一提的是设置一个NSDateFormatter属性速度差不多是和创建新的实例对象一样慢！
- UIImage的初始化方法
二者不同之处在于,imageNamed默认加载图片成功后会内存中缓存图片,这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象.如果缓存中没有找到相应的图片对象,则从指定地方加载图片然后缓存对象，并返回这个图片对象.
而imageWithContentsOfFile则仅只加载图片,不缓存.
大量使用imageNamed方式会在不需要缓存的地方额外增加开销CPU的时间来做这件事.当应用程序需要加载一张比较大的图片并且使用一次性，那么其实是没有必要去缓存这个图片的，用imageWithContentsOfFile是最为经济的方式,这样不会因为UIImage元素较多情况下，CPU会被逐个分散在不必要缓存上浪费过多时间.
使用场景需要编程时，应该根据实际应用场景加以区分，UIimage虽小，但使用元素较多问题会有所凸显.
- 工作搬离主线程
其中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 显示迟钝.
