【老司机精选】理解和消除 App 中的卡死

3,184 阅读18分钟

【WWDC21 10258】.png

作者:Rickey 王小吉,字节跳动直播中台,一个苹果中毒的程序员。欢迎踩踩主页:github.com/RickeyBoy/R…

审核:Damien, 老司机技术周报编辑,TikTok iOS 工程师

WWDC21 - 理解和消除 App 中的卡死

目录

本文将通过四个部分,让开发者理解并消除 App 中的卡死问题。

一、什么是卡死

当用户触摸了屏幕,但几秒钟之后 App 才有响应,那么这种情况就被称作卡死,换句话说也就是未响应、响应迟缓等。任何 App 都不会想给用户卡顿的体验。

为了理解卡死,我们需要先知道什么是主线程 runloop。如下图所示,每一个 App 都会依附一个主线程 runloop,它就是一个不会停止的循环,App 底层会在这个循环里不停地对事件进行响应,处理源源不断的外部事件,从而响应最重要的用户操作。

当用户与 App 进行交互时,App 会经历接收事件、处理事件、(如果有需要的话)更新 UI 这三个阶段,这样三个阶段的事情都发生在主线程 runloop 的一个循环之中,连续响应到每个用户触发的事件。

而如果处理事件的时间过长,那在接收事件和更新 UI 这两个事件直接就会产生延迟,甚至还会造成主线程任务堆积,阻塞后续事件的响应。在卡死阶段触发的后续任务将无法被响应,直到第一个造成卡死的任务结束,与此同时后续任务也将会增加这个卡死的时间,造成恶性循环。

总的来说延迟超过一秒就会让用户感觉到卡死。不过有些情况下一次小延迟相对容易接受,比如对于 0.5 秒的延迟,如果出现在列表滑动阶段那么用户就会觉得异常反感,但如果在页面跳转过程中发生一次,就没那么容易察觉。

二、造成卡死的原因

当主线程上有超出其负荷的任务被执行时,就会发生卡死,此时的卡死可能包含下面两种情况:

  1. 主线程本身处于忙碌状态,而造成卡死,有可能是处理单个长任务,也有可能是多个连续短任务。
  2. 主线程被其他线程的任务阻塞,或是被系统资源阻塞。

接下来让我们分情况来具体讨论。

主线程被卡死

主线程本身处于忙碌状态,而造成卡死

执行多余的前置任务

我们先来举例看下最常见的第一种情况。通常在前置执行任务时,有可能会执行一些多余操作,从而导致主线程卡死。

比如在上面这个官方演示的 App(Deserted) 中,页面只平铺展示 4 张食物配料图片,因此只需要加载四张图片即可,而不是加载全部图片。如果在进入这个页面的时候一次性加载所有图片,每一张图片都会进行消耗大量时间,从而造成主线程卡死,而实际上绝大部分的时间消耗都不会影响页面展示的内容。

执行不相关操作

另一个常见造成卡死的原因,是在主线程执行了其他派发队列中不相关的任务。主线程是串行执行,所以不仅会执行主线程队列里的 block,同时也会执行其他队列里同步执行的 block。所以其他队列中派发到主线程同步执行的 block,就有可能阻塞主线程后续的任务。

而当主线程向存储队列派发了一个同步执行的 block,那么主线程上接下来的操作,就都需要等待存储队列上的任务执行完毕,才能继续执行。这样一来,实际上主线程上大部分的时间都被无谓的浪费了。

如下图所示:App 中一些低优先级的队列,比如一个存储队列(maintenance queue),如果它的任务(maintenance work)被派发到主线程上同步执行,那么这种耗时长却低优先级的维护任务,就会造成主线程卡死。

类似的情况还有:如果存储队列向主线程派发了一个同步执行的 block,那么主线程也必须要等待这个 block 执行完成才能继续。

没有使用合适 API

没有使用合适 API 也是常见造成卡死的原因之一,实现同样的效果有多种不同的路径,所以一定要熟读 API 文档,确保使用合适的 API。

以演示 App Desserted 为例,它给图片加圆角的方式,是通过基于 bitmap 的 UIGraphics 方法,将图片转换为 bitmap 之后,再用圆角矩形的贝塞尔曲线进行裁剪,最后将裁剪后的 bitmap 转换回图片格式。

这一系列的操作会导致 CPU 负载过重,耗时长且消耗大量内存。这是因为使用了错误的系统硬件,这里应该利用 GPU 而不是 CPU:通过使用 CoreAnimation 中 layer.cornerRadius 属性和 masksToBounds 属性,就能轻松且高效地给图片添加圆角。

主线程被阻塞

主线程被其他线程的任务阻塞,或是被系统资源阻塞

错误使用同步 API

使用同步 API 会阻塞线程上后续任务的执行,从调用开始阻塞直到 API 返回结果。如果这类方法内部进行了大量的工作,或者有可能延时返回,那么它们就不应该在主线程上被使用,因为它们可能导致延迟,以及会增加失败的几率。

一个典型的案例是在主线程进行同步的网络请求。对于那些使用 5G 网络的用户,这样可能不会有任何延迟,但是网络条件差一些的话,请求就可能会花更长的时间。对于那些信号很差的用户,有可能就会一直卡死了。谁也不能保证网络请求的耗时长短,所以这类的同步操作都应该避免在主线程执行。

File I/O 受限

另一种主线程阻塞的情况是被系统资源限制了,因为系统资源经常会不够用。File I/O 文件接口又是最常用且最容易资源不足的系统资源,因为文件接口有很多不确定因素,比如系统硬件性能,以及可能其他 App 也同时在进行读写操作。因此 App 需要尽量避免这些影响因素,比如避免在主线程使用 I/O 接口。

不支持并发的数据存储尤其容易产生问题。当主线程读取一个正在进行写操作的数据,由于不支持并发,那么这个读取操作就会被延迟到写操作结束,在写操作以及读操作完成之前,App 都无法响应。

同步操作阻塞

同步原语(synchronization primitive)会阻塞读写任务执行,因此要减少在主线程上进行同步,即使要用也需要非常小心。进行同步操作的线程,通常会加锁后长时间才会将锁释放,不论是隐式锁还是显示锁。

下面有一些常见需要注意的同步原语:

尤其需要注意信号量的使用,因为信号量不使用优先级策略,因此信号量的抢占有可能导致更长时间的卡死。一个常见的错误如下图所示:想通过信号量之间的等待,使异步方法串行执行。一定要在主线程中避免这种操作。

重复获取不变量

还有一种阻塞主线程的原因,是花费大量代价去不断获取一些不经常改变的数据。

比如官方演示 App Desserted 中的这个代表社交功能的按钮,只有当我拥有通信录好友的时候才进行展示。我们可以每次都获取一下通讯录中的联系人,从而判断是否拥有好友。但这样做会增加很多额外开销和延迟,因为主线程调用通讯录的相关框架,会在底层重复大量操作,产生高昂的开销。更何况需要获取的联系人信息并不经常变动,因此没必要频繁的获取联系人,这只会增加系统资源的压力。

系统资源受限

卡死:主线程过度使用,导致系统资源受限。

系统资源包括 CPU、内存、存储空间等的状态都对卡死有较大的影响,现实情况下千差万别的设备硬件情况,和开发时本地测试遇到的零星情况大不相同。所以我们应该尽量去预防这样的情形,比如使用自动化测试,或者以最古老的设备进行压力测试。

总的来说,造成卡死的原因就是主线程被过度使用了。因此为了保证良好的性能体验,我们需要让主线程尽量只去做一些 UI 更新必须的任务。

三、如何分析卡死原因

了解了常见的卡死原因之后,让我们来看看有哪些有用的工具可以对 App 中的卡死来监控和分类。

System Trace

进一步了解:System Trace in depth - WWDC16

为了对卡死进行分类,通常首先要了解 App 正在做的任务。而在 Instrument 中的 Time Profile 这个工具可以清楚地展示当前 App 的调用栈信息,能精准地分析出正在执行的任务信息。而 Instrument 中的 System Trace 工具能够展示更多信息,包含系统调用、分页错误、I/O 接口信息等,甚至包括进程内以及进程间的合作情况。

接下来我将演示使用这两个工具,来分析官方示例 App 中的卡死原因。在使用 System Trace 对 App 进行了分析之后,Instrument 界面大概会这样显示成这样:

  • 标记 1 的地方,system trace 输出的红色细线条代表系统方法的调用
  • 标记 2 的紫色条形图代表虚拟内存的分页错误
  • 标记 3 的水平蓝条,代表主线程在忙碌状态
  • 标记 4 的位置,可以选择想要查看具体的调用信息
  • Instrument 会展示这 4.7s 的卡顿内主线程的调用信息,标记为 5 的这部分内容说明了 loadAllImages() 导致了其中 4.6s 的卡顿。这就是前文所说的问题,实际上官方示例 App 中加载了过多多余的图片,导致了卡死。

MetricKit

进一步了解:What's new in MetricKit - WWDC20

一旦你的 App 发布之后,就可以通过 MetricKit 来收集卡死时的调用栈了,这样能让你发现哪些卡死的调用栈是用户更容易命中的。我们现在来看一个例子:

MetricKit 同样也会统计卡死时的调用栈,呈现出的调用栈和 Time Profile 中的很像。通过分析调用栈,我们发现这个卡死和我们刚才分析的卡死不一样,这个卡死是新加的社交功能导致的,由于一次性获取了所有联系人而阻塞了当前队列。而如果不是使用 MetricKit,我可能永远也不会发现这个卡死问题。

Xcode Organizer

可以通过下面两个 session 来了解 Xcode Organizer 的更多信息:

Diagnose power and performance regressions in your App - WWDC21

Improving battery life and performance - WWDC19

在修复卡死问题时,能够量化 App 的整体性能情况是非常重要的一点。而 Xcode Organizer 工具能够展示性能表现相关的数据,包括能展示各个版本应用的卡死率的图表,这对于我们分析 App 用户流失的原因很有帮助。

四、如何消除卡死

那么现在我们来了解一些常见解决 App 卡死问题的策略。同时需要记住,每一种策略都能解决一些卡死问题,为了找到最合适的解决方案,你必须要了解这些方案的副作用并进行抉择。

减少主线程上的工作

减少主线程上进行的工作总量,能够有效地消除并预防卡死问题。为了达到这个目的,我们通常有两个方法。第一个是优化主线程上任务的效率,从而减少总时间。第二个方法是将一些任务从主线程移除,改用一些不会阻塞主线程的方式进行,从而保证主线程能及时响应。

使用缓存

对于经常使用的资源,采用缓存策略是一种很好的方式。缓存通常是一种存在于内存中的,如果需要多 App 同步的话也可以持久化到硬盘空间。有可能被用到的固定资源很适合使用缓存,比如 Desserted 中的那些配料图片,因为如果每次用到时都去创建就会有大量开销。

通过使用 NSCache 缓存,每次创建图片的大量开销就能被简化为内存的访问,这样就能消除我们之前通过 Instrument 分析出,因为过度加载图片而导致的卡死。

不过重要的是,需要有一个准确的缓存检查机制,在维护缓存的增删,保证缓存内容总量的平衡。这些操作通常会异步地在另一个线程上进行,从而保证主线程能够及时响应其他事件。

添加观察者

添加观察者来监听通知的方案也能减少主线程工作量,这种方法能针对数值或者状态进行监听,从而避免昂贵的计算量。任何类都能够发出通知,甚至是自定义的类,查看某些类的 API 说明文档就可以找到相应的事件通知。可以通过 Apple developer 官方文档中的找到 NSNotification.Name,也就是可监听的系统通知名称。

而 Desserted 中的社交按钮,就是一个很好的应用示例:通过注册对 abDatabaseChangedExternally 通知的监听,主线程不再需要等待获取联系人列表的过程了,只需要等待通知发出、观察者进行响应就行了。而在 Desserted 的例子中,收到通知后将会更新一下缓存的联系人列表。而这些更新操作也需要放在另一个异步线程中,这样保证主线程不被卡死。

转移主线程上的工作

核心:主线程只负责足够重要的任务

将主线程上的工作就行转移,给主线程减负,这也是一个好方法。那究竟哪些工作该在主线程上执行呢?

只有足够重要的任务,也就是为 UI 展示提供支持的任务才应该在主线程上执行。并且所有视图和视图控制器,他们的创建、修改和销毁也都应该在主线程上执行。

而用于更新 UI 元素的计算过程,就可以从主线程转移到其他线程上,只需要在计算结束时在主线程执行真正的 UI 更新操作即可,这种模式非常适合与计算耗时很长的任务。一些不太重要的任务,或是对时间不敏感的任务,都应该像这样转移到其他线程上异步执行。

异步 API

将任务从主线程转移到异步线程,使用异步 API 是最直接的方法。我们以网络请求为例,通过使用 NSURL 类的异步 API,我们就能让主线程在网络请求期间保持可以响应:

通常来讲,异步 API 名字都会包含 "asynchronously" 单词或者其缩写,而 API 的回调方法名通常包括 "completion",非常好辨认。

GCD 方法

进一步了解:Modernizing Grand Central Dispatch - WWDC17

GCD 是一个功能强大的多线程架构,能够方便地实现异步操作。GCD 提供了非常简单的接口,可以将任何 block 从主线程移至子线程,既可以同步执行也可以异步执行。因此,使用 GCD 方法能够有效地解决绝大部分的卡死问题。通过使用 GCD 的异步调用方法,将 block 转移到另一个线程执行,就能保证主线程不被卡死;同时在完成后调用 completion 方法,再回到主线程执行必要的方法即可:

GCD 也能轻松实现预加载逻辑。将预加载逻辑绑定在一个线程(比如 prefetchQueue)上,再异步执行预加载 block,就能在保证主线程不卡顿的情况下执行预加载任务。而当主线程需要预加载任务的结果时,使用 sync 方法在同一个线程(prefetchQueue)上串行执行后续逻辑即可。

理解交换的代价

以上说的这些方法,本质上来讲都是一些交换,能解决卡死问题的同时也有可能导致其他问题。

  • 使用缓存:空间换时间。使用缓存时需要考虑内存的过度增长,必须要保证缓存的清理机制是有效的。
  • 添加观察者:通知可能被频繁触发,因此在监听通知的时候最好先加一些过滤条件,避免额外的操作,减轻 CPU 的负担。
  • 异步 API:必须要理解哪些操作可以异步执行,特别是直接涉及 UI 更新的任务一定不能放到异步线程,因为异步线程的优先级不高,不会优先执行。
  • GCD 方法:使用 GCD 的代价就是你必须要调整代码执行的顺序,因此你需要时刻保持清醒,避免程序出错。使用 sync 方法来保证执行顺序也是一个不错的选择。

不过考虑到这些方法能够有效解决卡死问题,这些交换一定是值得的。

一些其他建议

  1. 尽量使用 Apple 的框架以及接口,因为它们已经针对所有苹果设备都进行了有效地优化,以及会保持不断地更新与优化。
  2. 不断迭代优化代码。可以不断制定小的优化目标,看到每次优化的效果,再积少成多。
  3. 合理地使用系统资源。过度使用资源会不仅仅降低 App 的性能体验,也会导致整个系统的卡顿。

五、总结

卡死问题是导致用户体验的最大问题之一,当用户遭遇卡死时很可能就退后台杀进程了,这会导致非常高的用户流失率。所以一旦涉及到卡死,一定是需要较高优先级解决的。

通过本文的学习,在我们知道理解原理、善用工具的情况下,分析并解决卡死问题就变得容易起来。同时希望本文也能起到抛砖引玉的作用,毕竟真实的卡死情况更加复杂,还有很多需要进一步探索的地方。最重要的是能理解导致卡死的原理,以及学会解决卡死问题的基本思路,遇到问题才能迎刃而解。

关注我们

我们是「老司机技术周报」,一个持续追求精品 iOS 内容的技术公众号。欢迎关注。

关注有礼,关注【老司机技术周报】,回复「2021」,领取 2017/2018/2019/2020 内参

支持作者

在这里给大家推荐一下 《WWDC21 内参》 这个专栏,一共有 102 篇关于 WWDC21 的内容,本文的内容也来源于此。如果对其余内容感兴趣,欢迎戳链接阅读更多 ~

WWDC 内参 系列是由老司机牵头组织的精品原创内容系列。 已经做了几年了,口碑一直不错。 主要是针对每年的 WWDC 的内容,做一次精选,并号召一群一线互联网的 iOS 开发者,结合自己的实际开发经验、苹果文档和视频内容做二次创作。