字节跳动如何系统性治理 iOS 稳定性问题

本文是丰亚东讲师在2021 ArchSummit 全球架构师峰会中「如何系统性治理 iOS 稳定性问题」的分享全文。

首先做一下自我介绍：我是丰亚东，2016 年 4 月加入字节跳动，先后负责今日头条 App 的工程架构、基础库和体验优化等基础技术方向。2017 年 12 月至今专注在 APM 方向，从 0 到 1 参与了字节跳动 APM 中台的建设，服务于字节的全系产品，目前主要负责 iOS 端的性能稳定性监控和优化。

本次分享主要分为四大章节，分别是：1.稳定性问题分类；2.稳定性问题治理方法论；3.疑难问题归因；4.总结回顾。其中第三章节「疑难问题归因」是本次分享的重点，大概会占到60%的篇幅。

一、稳定性问题分类

在讲分类之前，我们先了解一下背景：大家都知道对于移动端应用而言，闪退是用户能遇到的最严重的 bug，因为在闪退之后用户无法继续使用产品，那么后续的用户留存以及产品本身的商业价值都无从谈起。
这里有一些数据想和大家分享：有 20% 的用户在使用移动端产品的时候，最无法忍受的问题就是闪退，这个比例仅次于不合时宜的广告；在因为体验问题流失的用户中，有 1/3 的用户会转而使用竞品，由此可见闪退问题是非常糟糕和严重的。

字节跳动作为拥有像抖音、头条等超大量级 App 的公司，对稳定性问题是非常重视的。过去几年，我们在这方面投入了非常多的人力和资源，同时也取得了不错的治理成果。过去两年抖音、头条、飞书等 App 的异常崩溃率都有 30% 以上的优化，个别产品的部分指标甚至有 80% 以上的优化。
通过上图中右侧的饼状图可以看出：我们以 iOS 平台为例，根据稳定性问题不同的原因，将已知稳定性问题分成了这五大类，通过占比从高到低排序：第一大类是 OOM ，就是内存占用过大导致的崩溃，这个比例能占到 50% 以上；其次是 Watchdog，也就是卡死，类比于安卓中的 ANR；再次是普通的 Crash；最后是磁盘 IO 异常和 CPU 异常。
看到这里大家心里可能会有一个疑问：字节跳动究竟做了什么，才取得了这样的成果？接下来我会将我们在稳定性治理方面沉淀的方法论分享给大家。

二、稳定性问题治理的方法论

首先我们认为在稳定性问题治理方面，从监控平台侧视角出发，最重要的就是要有完整的能力覆盖，比如针对上一章节中提到所有类型的稳定性问题，监控平台都应该能及时准确的发现。
另外是从业务研发同学的视角出发：稳定性问题治理这个课题，需要贯穿到软件研发的完整生命周期，包括需求研发、测试、集成、灰度、上线等，在上述每个阶段，研发同学都应该重视稳定性问题的发现和治理。

上图中右侧是我们总结的两条比较重要的治理原则：
第一条是控制新增，治理存量。一般来说新增的稳定性问题可能是一些容易爆发的问题，影响比较严重。存量问题相对来说疑难的问题居多，修复周期较长。
第二条比较容易理解：先急后缓，先易后难。我们应该优先修复那些爆发的问题以及相对容易解决的问题。

如果我们将软件研发周期聚焦在稳定性问题治理这个方向上，又可以抽象出以下几个环节：
首先第一个环节是问题发现：当用户在线上遇到任何类型的闪退，监控平台都应该能及时发现并上报。同时可以通过报警以及问题的自动分发，将这些问题第一时间通知给开发者，确保这些问题能够被及时的修复。
第二个阶段是归因：当开发者拿到一个稳定性问题之后，要做的第一件事情应该是排查这个问题的原因。根据一些不同的场景，我们又可以把归因分为单点归因、共性归因以及爆发问题归因。
当排查到问题的原因之后，下一步就是把这个问题修复掉，也就是问题的治理。在这里我们有一些问题治理的手段：如果是在线上阶段，我们首先可以做一些问题防护，比如网易几年前一篇文章提到的基于 OC Runtime 的线上 Crash 自动修复的方案大白，基于这种方案我们可以直接在线上做 Crash 防护；另外由于后端服务上线导致的稳定性问题爆发，我们可以通过服务的回滚来做到动态止损。除了这两种手段之外，更多的场景还是需要研发在线下修复 native 代码，再通过发版做彻底的修复。
最后一个阶段也是最近几年比较火的一个话题，就是问题的防劣化。指的是需求从研发到上线之间的阶段，可以通过机架的自动化单元测试/UI自动化测试，以及研发可以通过一些系统工具，比如说 Xcode 和 Instruments，包括一些第三方工具，比如微信开源的 MLeaksFinder 去提前发现和解决各类稳定性问题。

如果我们想把稳定性问题治理做好的话，需要所有研发同学关注上述每一个环节，才能达到最终的目标。 可是这么多环节我们的重点究竟在哪里呢？从字节跳动的问题治理经验来看，我们认为最重要的环节是第二个——线上的问题的归因。因为通过内部的统计数据发现：线上之所以存在长期没有结论，没有办法修复的问题，主要还是因为研发并没有定位到这些问题的根本原因。所以下一章节也是本次分享的重点：疑难问题归因。

三、疑难问题归因

我们根据开发者对这些问题的熟悉程度做了一下排序，分别是：Crash、Watchdog、OOM 和 CPU&Disk I/O。每一类疑难问题我都会分享这类问题的背景和对应的解决方案，并且会结合实战案例演示各种归因工具究竟是如何解决这些疑难问题的。

3.1 第一类疑难问题 —— Crash

上图中左侧这张饼状图是我们根据 Crash 不同的原因，把它细分成四大类：包括 Mach 异常、 Unix Signal 异常、OC 和 C++ 语言层面上的异常。其中比例最高的还是 Mach 异常，其次是 Signal 异常，OC 和 C++ 的异常相对比较少。
为什么是这个比例呢？
大家可以看到右上角有两个数据。第一个数据是微软发布的一篇文章，称其发布的 70% 以上的安全补丁都是内存相关的错误，对应到 iOS 平台上就是 Mach 异常中的