iOS性能优化系列三：事件处理-拯救主线程

用户经常评论app的一个用词是“卡顿”，很大的因素是因为主线程被占用了。用户的事件是在主线程被处理的，包括点击、滚动、加速计、Proximity Sensor。

为了保证事件的平滑处理，需要进行如下优化：

  • 最小化主线程的CPU占用
  • 将工作“搬离”主线程
  • 不要阻塞主线程

最小化主线程的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技术被广泛使用。例如：

1
2
3
4
5
6
7
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团队诚招iOS工程师，推荐成功即奖励6000元现金或iPhone 6一部，详见这篇blog。