使用Time Profiler获取应用程序的运行消耗时间分布和百分比，检测应用CPU的使用情况。可以获取应用程序中各个方法正在消耗的CPU的时间。使用大量的CPU不一定是个问题，比如动画本身就会非常苛刻且消耗资源多的任务。
测试应用拿到分析数据后发现程序第一次启动的时候，didFinishLaunchingWithOptions和viewDidLoad耗时比较长，如下图所示：
程序第一次启动时较耗时的方法
初始化完成后，发现几个问题比较凸显：
1.NSDateFormatter
创建一个NSDateFormatter对象平均耗时33ms左右，而设置NSDateFormatter的3个属性平均耗时也在30ms左右。如果多次调用，耗时也会不断累加。
解决方法：
NSDateFormatter对象本身初始化很慢，同样还有NSCalendar也是如此。然而在一些使用场景中不可避免要使用他们，比如Json数据解析中，使用这个对象同时避免其性能开销，一般比较好的方式是通过添加属性(推荐)或创建静态变量保持该对象只被初始化一次，而被多次复用。不得不值得一提的是设置一个NSDateFormatter属性速度差不多和创建新的实例对象一样慢。因此，尽量避免采用其处理多个日期格式。当然如果需要提高更多速度，可以直接采用C或者第三方库来规避这个问题。
2.UIImage缓存取舍
UIImage加载图片方式一般有两种:
A：imagedNamed初始化
B：imageWithContentsOfFile初始化
二者不同之处在于，imageNamed默认加载图片成功后会内存中缓存图片，这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象。如果缓存中没有找到相应的图片对象，则从指定地方加载图片然后缓存对象，并返回。而imageWithContentsOfFile则仅只加载图片，不缓存。
大量使用imageNamed会在不需要缓存的地方额外增加开销CPU的时间来做这件事。当应用程序需要加载一张比较大的图片并且使用一次性，就没有必要去缓存这个图片，用imageWithContentsOfFile是最为划算的选择，这样不会因为UIImage元素较多情况下，CPU会被逐个分散在不必要缓存上浪费过多时间。
各位请根据具体使用场景来选择A或者B方法。
3.全部任务都放在主线程
view的初始化和更新，updateInfo全部放在主线程，如果view较多意味着更多的渲染，也意味着更多的CPU和内存消耗，针对这种情况不要在主线程承载过多的操作，uikit渲染，用户输入回应都需要主进程上完成，而加载响应耗时过多会影响到用户体验。处理原则是将工作“搬离”主线程，最小化主线程的CPU占用， 不要阻塞主线程。
调试time profiler过程中发现，即使占用了很少的CPU时间，如：磁盘、网络、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.头文件引入
#import比起#include的好处就是不会引起交叉编译，在 Objective-C中，#import 被当成 #include 指令的改良版本来使用。除此之外，#import 确定一个文件只能被导入一次，这使你在递归包含中不会出现问题。@class一般用于头文件中需要声明该类的某个实例变量的时候用到，在.m文件中还是需要使用#import @class就是告诉编译器有这么一个类，至于类的定义是啥不知道 @class一般用于头文件中需要声明该类的某个实例变量的时候用到，在.m文件中还是需要使用#import “”引进自己创建的文件，用这个首先会在当前的目录中寻找，如果找不到就到其他的位置寻找，虽然#import会相对提升性能，但还是要尽量避免不必要的导入。
网友评论