用户经常评论app的一个用词是“卡顿”，很大的因素是因为主线程被占用了。用户的事件是在主线程被处理的，包括点击、滚动、加速计、Proximity Sensor。
为了保证事件的平滑处理，需要进行如下优化：
最小化主线程的CPU占用
前面两篇文章，我们接触到了Time Profiler。使用它可以剖析不同线程的CPU使用情况，并给出调用堆栈的CPU时间占用百分比。如果app“卡顿”，并且在Time Profiler的结果可以找到明确的高占用堆栈，你需要把它优化掉。
将工作“搬离”主线程 – 隐式并发
为了得到更流畅的交互体验，iOS已经帮我们做了很多事情，Android就没有这么好运了。iOS将以下这些事情搬离了主线程：
注意滚动（Scrolling）不是一个动画，而是在Main Run Loop中不断接收事件并且处理。
将工作“搬离”主线程 – 显式并发
这里是需要开发者们搞定的部分。磁盘、网络等I/O会阻塞线程，不要把它们放到主线程里。常用的技术有：
iOS 4.0后，易用的GCD技术被广泛使用。例如：
GCD的陷阱
GCD其实就是线程，只不过提供了一个更高层次的抽象。过多的线程一定会带来性能损失，因此GCD设计了一个最高允许的线程值（对开发者透明，不用管到底有多少）。那么如何解决这个问题呢？
另外一个陷阱是线程安全：
此外，iOS 4.3添加了DISPATCH_QUEUE_PRIORITY_BACKGROUND，它拥有非常低的优先级。这个优先级只用于不太关心完成时间的真正的后台任务，如果要表示较低的优先级，，你通常需要的是DISPATCH_QUEUE_PRIORITY_LOW。
不要阻塞主线程
即使占用了很少的CPU时间（如果你在Time Profiler中看到这些的数据），也可能会阻塞主线程。磁盘、网络、Lock、dispatch_sync以及向其它进程/线程发送消息都会阻塞主线程。Time Profiler只能检测出占用CPU过多的堆栈，但检测不了这些IO的问题。
大多数的阻塞事件，都会伴随着一个系统调用，如：
System Trace这个Instrumentor，记录了所有的系统调用，以及每次调用的等待时间。如果你在System Trace里面发现了CPU Time很低，但Wait Time很高的调用，说明在主线程处理I/O已经严重损害了app的性能。
保证主线程的低CPU占用，将I/O移至其它线程，可以大大地提高主线程对交互事件的处理能力。我建议开发者朋友们写代码的时候，除非是以前遇到过的问题，都没有必要假设问题存在。80%的优化都是不必要的。
其实，每个人都是幸福的。只是，你的幸福，常常在别人眼里。
