三：事件处理-拯救主线程
用户经常评论app的一个用词是“卡顿”，很大的因素是因为主线程被占用了。用户的事件是在主线程被处理的，包括点击、滚动、加速计、Proximity Sensor。
为了保证事件的平滑处理，需要进行如下优化：
最小化主线程的CPU占用，将工作“搬离”主线程，不要阻塞主线程
前面两篇文章，我们接触到了Time Profiler。使用它可以剖析不同线程的CPU使用情况，并给出调用堆栈的CPU时间占用百分比。如果app“卡顿”，并且在Time Profiler的结果可以找到明确的高占用堆栈，你需要把它优化掉。
将工作“搬离”主线程 - 隐式并发
为了得到更流畅的交互体验，iOS已经帮我们做了很多事情，Android就没有这么好运了。iOS将以下这些事情搬离了主线程：
View和layer的动画（动画绘制前的计算，而不是drawing过程）
Layer的组合计算（drawing后的叠加）
PNG的解码（是的，你没看错；而且利用了CPU的多核心）
注意滚动（Scrolling）不是一个动画，而是在Main Run Loop中不断接收事件并且处理。
将工作“搬离”主线程 - 显式并发
这里是需要开发者们搞定的部分。磁盘、网络等I/O会阻塞线程，不要把它们放到主线程里。常用的技术有：
Grand Central Dispatch(GCD)
NSOperationQueue
NSThread
iOS 4.0后，易用的GCD技术被广泛使用。例如：
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),
^{
// do something in background dispatch_async(dispatch_get_main_queue(), ^{
// do something on main thread
}); });
GCD的陷阱
GCD其实就是线程，只不过提供了一个更高层次的抽象。过多的线程一定会带来性能损失，因此GCD设计了一个最高允许的线程值（对开发者透明，不用管到底有多少）。那么如何解决这个问题呢？
将队列串行化
使用Dispatch sources
使用带有限制的NSOperationQueue
使用Cocoa Touch提供的异步方法
另外一个陷阱是线程安全：
UIKit必须要在主线程使用，除了UIGraphics，UIBezierPath，UIImage
大多数CG、CA、Foundation的类，不是线程安全的
如果你使用了ojbc runtime来进行introspection，由于它是thread safe的，可能会导致竞争
此外，iOS 4.3添加了DISPATCH_QUEUE_PRIORITY_BACKGROUND，它拥有非常低的优先级。这个优先级只用于不太关心完成时间的真正的后台任务，如果要表示较低的优先级，你通常需要的是DISPATCH_QUEUE_PRIORITY_LOW。
不要阻塞主线程
即使占用了很少的CPU时间（如果你在Time Profiler中看到这些的数据），也可能会阻塞主线程。磁盘、网络、Lock、dispatch_sync以及向其它进程/线程发送消息都会阻塞主线 程。Time Profiler只能检测出占用CPU过多的堆栈，但检测不了这些IO的问题。
大多数的阻塞事件，都会伴随着一个系统调用，如：
read/write - 读写文件
send/recv - 收发网络数据
psynch_mutex_wait - 获得锁
mach_msg - IPC
System Trace这个Instrumentor，记录了所有的系统调用，以及每次调用的等待时间。如果你在System Trace里面发现了CPU Time很低，但Wait Time很高的调用，说明在主线程处理I/O已经严重损害了app的性能。
保证主线程的低CPU占用，将I/O移至其它线程，可以大大地提高主线程对交互事件的处理能力。我建议开发者朋友们写代码的时候，除非是以前遇到过的问题，都没有必要假设问题存在。80%的优化都是不必要的。
更多:三屏电脑显示器iOS性能优化技巧
https://www.002pc.com/diannaojichu/477.html
你可能感兴趣的iOS,技巧,优化,性能