快影iOS端如何实现OOM率下降80%+

线上OOM是快影iOS端稳定性治理的重点和难点。我们实现了一套分析复现线上OOM头部问题的工具，OOM率下降超过80%。本文主要分享快影iOS端系统化治理OOM过程的基本思路和关键案例，希望和大家进行广泛而深入的讨论。

本文共6813字，预计阅读时间25分钟。

背景

快影APP作为一款专业的音视频制作软件，在使用过程可能会占用大量内存。当内存超过系统限制时会触发OOM(Out Of Memory)，表现为APP闪退。

随着快影业务的快速迭代，iOS端线上OOM问题日益严峻。从用户反馈看，OOM是Top1问题。从大盘数据看，OOM率是Crash率的5~6倍。这严重影响了用户体验和产品口碑，需要重点治理。然而，治理iOS端的线上OOM并非易事。难点主要有两方面，一是无法直接捕获线上OOM，二是很难对线上OOM进行归因（尽管业界提出了一些优秀的解决方案，但仍存在一些局限性，详见后文分析）。

1. Jetsam OOM；通过task_terminate_internal -> proc_exit -> SIGKILL来终止进程；

2. EXC_RESOURCE；当应用超过系统资源的消耗限制时会触发此类Mach异常，在满足fatal condition时也会通过SIGKILL来终止进程；

3. EXC_CRASH(SIGKLL)；比如过热保护(0xc00010ff)；

4. 其它情况；比如外挂强杀(kill -9)；

整体方案

考虑到数据完备性，我们补充完善了UI层和系统层的Action。比如编辑器时间轴的滚动Action，打开相册Action，APP前后台切换Action以及3秒内无用户操作的PingAction等。

那如何保证数据正确性呢？比如，我们非常依赖“最后一次Action”的准确记录，所以采用了mmap的方式来存储Action以及对应的QoS，不必担心Crash导致数据丢失。

为了保证复现成功率，我们需要尽可能还原编辑上下文。还原开关/AB实验环境、还原作品及其引用的素材Asset。我们维护了一个本地素材库AssetsLibrary，通过哈希原始素材的meta信息得到一个近似素材。另外一方面，假设我们能分析出一类问题，就意味会有足够多的Context和Action。因此越是头部的问题，复现概率越大。

1、APP内存超限

APP内存超限是指Footprint超出系统设定的阈值。Jetsam reason通常为per-process-limit。

聚合Footprint曲线特征，可以发现4类APP内存超限问题，包括 内存泄漏、内存堆积、资源过大 以及 内存占用高 的问题。

如图1所示，通过二次聚合Action确认了一类“导入贴纸”弹框内存泄漏；

如图2所示，用户在清理磁盘缓存后，打开作品Draft，在“时间轴”进行快速滚动和缩放。由于作品中包含几百个镜头片段，上述Action会创建几千上万个“生成缩略图”的任务造成了内存堆积；

如图3所示，用户使用裁剪Action后，由于程序异常产生了4个16380*3628分辨率的bitmap；

如图4所示，用户作品Draft中存在时长几十几百分钟的长视频，由于音频解码算法空间复杂度过高，导致内存占用高；

以上案例主要是内存超限问题中的bug，比较容易解决。对于结构性问题的治理，往往比较复杂。比如快影的内存容灾方案、解码帧缓存重构方案均涉及架构和算法数据结构的优化。

2、系统可用内存不足

系统可用内存严重不足时也可能会强杀前台APP。Jetsam reason通常为vm-pageshortage。

通过聚合Action栈，我们发现1G内存设备中，存在大量先“打开视频特效弹窗”，然后“在弹窗滚动”的Action引发的OOM。其内存表现如下图所示：Footprint稳定在140M左右，但系统可用内存Free从360M逐渐下降到80M，最终因系统可用不足触发OOM。

在线下复现过程，我们发现特效弹窗中展示的特效示意图均为webp格式的动图，平均帧数约为30。当我们上下左右快速滚动搜寻特效时，会有大量的图片帧需要解码，大量并发解码任务会造成内存堆积。然而，这种画布模式分配的内存CG raster data并没有计算在APP内存Footprint之中。这也是为什么这个问题在测试阶段被忽略的原因——在此之前，我们往往只关心APP内存。

优化这类内存堆积问题并不困难，经典的思路是通过限制解码并发数来降低峰值（还可以使用任务取消机制或拓扑排序来提升用户体验）。最有趣的问题是，APP分配CG raster data类型的内存，是如何不被计算在APP内存Footprint中的？

借助Allocations，我们发现这些CG raster data是通过CGDataProviderCreateWithCopyOfData这个方法进行分配的。如下图所示，方法内部先使用mmap分配出了bitmap所需的内存大小，然后将解码后的数据写入其中。

可见，解码内存并非随意分配的，而是系统通过定义好的标记在特殊地址进行分配的结果。这些被标记的情况在内存分配时不会统计到App内存Footprint中。值得一提的是，另外一种基于文件的MAP_SHARED类型的mmap也有同样的效果。

这个案例启发我们，APP分配的内容是可以被“转移”出去的。那么，能否用来在“APP内存超限”问题上发挥用途呢？答案是肯定的，我们在后续内存优化中就实践了这一思路。

通过聚合最后一个Action，我们发现2G内存以下的设备中，Top1的OOM Action是时间轴“滚动””Action。其线上内存表现如图所示。

经过线下复现分析，该问题集中出现在“多片段+转场”的Draft中。通过Activity分析，mediaserverd进程内存波动巨大，峰值可能超过800M。如下图所示，mediaserverd关联了内核驱动服务，是一个与应用层“通信”的中间进程。iOS设备上全部的音视频编解码最终都将通过这个进程与底层通信，倘若应用层不加限制的使用这个daemon进程，导致其持有大量内存的同时还在不断请求分配内存。最终就会造成系统可用内存不足，触发Jetsam OOM。由于daemon进程的高优先级，系统往往会强杀前台APP。

回到问题本身，为什么mediaserverd会吃掉这么多内存呢？考虑到预览的流畅度，我们会进行prepare预解码。添加转场后会把转场前后视频分成两路，因此正常prepare逻辑会创建2+2=4个解码器，以4K视频为例，每个解码器会造成mediaserverd增长200-250M内存。

解决的思路是在流畅度与内存峰值之间寻找折中。在prepareNextDecode的时候，只创建解码器但不进行预解码，预解码时机避开转场过程从而避免mediaserverd引入的内存堆积问题。

这个案例提示我们，在iOS系统上处理音视频需要格外关注mediaserverd分配的内存，稍有不慎可能会导致系统可用不足，从而触发OOM。

3、捕获Crash过程异常

聚合最后一个Action，发现有14.2%的线上OOM发生在“字幕拖拽”Action之后。

通过工具，我们在线下成功复现这类OOM。令人感到不解的是，这个问题在调试环境表现为Crash，非调试环境却表现为卡死，且无法attach调试。

经过分析，Crash的直接原因是寻址到空指针触发了EXC_BAD_ACCESS类型的Mach异常。那么，为什么这个Crash没有在线下测试阶段被发现呢？这是因为产生空指针的条件需要用户作品满足一定的特征，这些作品中字幕相对时间的计算出现了浮点数精度问题，当字幕拖拽跨越片段时会触发误删，从而产生空指针。那为什么非调试环境下又表现为卡死呢？原来KSCrash监控库在写崩溃日志kscrashreport_writeStandardReport这一步，将非OC对象的地址误当作OC对象进行解析时，再次触发EXC_BAD_ACCESS。此时Mach异常处理线程已经崩溃，无法处理第二次崩溃，而内核会一直等待第一次崩溃处理的消息回复。整个APP处于“僵死”状态，最终发生Watchdog超时被系统强杀。

那么问题来了，为什么这种卡死会被判定为OOM？首先，OOM排除法依赖Crash标记，然而该标记是在CrashReport生成后通过kscm_innerHandleSignal回调生成。既然Mach异常的CrashReport处理过程又发生了Mach异常，自然是无法生成标记了。其次，在Crash处理过程中，我们已经挂起了主线程和卡死监控线程，也无法识别为卡死。

值得一提的是，Bugly监控库在2.5.71版本以前，捕获到SIGABRT信号时，处理线程会发生死循环（如下图所示，控制台不停地打印异常信号日志）。由于Bugly监控库放在最后注册，第一个拿到了异常处理的控制权。这种情况下，OOM排除法所依赖的Crash监控库（比如，Matrix依赖的是KSCrash）就没有机会处理异常。Crash就误判成了OOM。

那么，如何解决呢？

首先，尽量保证排除法所依赖的Crash监控第一个拿到异常处理控制权，比如放在最后注册或只保留这一个Crash监控。

其次，前置生成Crash标记的时机。如下图所示，我们可以在Mach/Signal/C++/OC异常处理线程挂起其他线程之后，新增一个回调来记录Crash标记。线上数据显示，该修改可以多发现50%+的Crash。当然，这样做会产生一类缺少崩溃日志的Crash。这就需要重点修复监控库的bug，把业务Crash暴露出来。

通过这个案例，我们认识到工程上要正确标记Crash并不是一件容易的事情，这要求监控库的实现方和调用方都要清楚其内部工作原理。

4、生成标记过程异常

通过聚合Action栈，我们发现线上存在大量由“导出作品”再“切换APP到后台”的这一操作导致的OOM案例。而且，这些案例中“导出作品”的过程无一例外都出现了导出空间不足的错误。结合SQL查表，我们统计了这类OOM的占比约8.9%。

这是一个特征很明确的头部OOM问题，我们在线下很快就复现了——制造存储空间紧张的设备上下文，在相同软件版本中导出作品，触发空间不足报错，切后台一段时间再切回前台时，发现APP已在后台被杀。那么，为什么在后台被杀还会判为前台OOM呢？调试发现，在切后台过程中，由于设备剩余空间严重不足，排除法依赖的前后台标记写入必现失败。在下次启动时，排除法认为APP是在前台被强杀的，所以判定为OOM。

有意思的是，这是一个版本迭代引入的新问题。我们清理了问题的直接原因后，不禁要问：为什么过去的版本不存在这个问题？分析发现，老版本在导出过程中，如果发生错误会立即删除中间文件，因此很难出现前文所述的“设备剩余空间严重不足”。那是不是新版本中修改了这块逻辑？答案是否定的，新版本同样会删除中间文件——删除接口正确返回，文件也在APP沙盒目录中消失。但奇怪的是系统剩余空间并没有恢复。

如下图所示，调试过程中，我们发现中间文件一直是open状态，这种情况下APFS不会立刻释放空间，除非文件关闭或者进程退出。最终，我们定位到新版本的底层代码有一个严重的外存泄漏：FFmpegMuxer对象在析构函数中没有关闭中间文件。这会导致用户在APP生命周期内每一次导出作品，中间文件都无法删除。

再回顾下这个案例，因为外存泄漏导致存储空间不断变小，再因为存储空间严重不足，导致排除法依赖的前后台标记写入失败，最后发生误判。暂且不讨论外存泄漏问题（外存泄漏对用户是有害的，考虑到文章主题这里不作具体讨论），我们非常好奇的是：因为写标记失败引入的误判到底有多少？

既然我们通过mmap的方式可以记录APP前后台切换的Action（哪怕磁盘空间严重不足），我们放弃了Matrix使用Archive存储标记的方式，统一改为mmap方式。线上数据显示，因为Archive存储标记失败引入的OOM误判率高达37.1%。

从这个案例中可以发现，排除法在工程上的正确实现需要小心谨慎。失之毫厘，谬以千里。

验收

为了验收性能优化效果以及副作用，我们做了大量的AB实验。这里从用户反馈和OOM率两个维度聊一聊验收情况。

如下图所示，我们统计了12周（2021年11月~2022年1月）的数据。从图中可以看出，OOM用户反馈数有了明显下降，最新版本OOM率下降80%+，其中OOM优化上线以来OOM率下降50%+，OOM去误判上线后OOM率再下降60%+。

一些思考

治理线上问题的一般思路是定义问题、分析问题、解决优化、验收以及防劣化。快影治理线上OOM也是依据这个思路进行实践的。

首先是定义问题。一些复杂问题的定义并非一成不变。比如iOS端的线上OOM，我们最初的定义是“APP在前台发生未捕获的SIGKILL”。通过深入分析头部问题，我们发现更准确的定义是“APP在前台发生未捕获的SIGKILL和排除法误判”。

线上问题往往是分布式的，分析的基础是问题上下文数据，分析的目标是找到头部问题。快影充分利用自身架构的特点来采集和还原问题的上下文，实现了一套分析复现线上OOM头部问题的工具。

解决优化需要对具体问题进行溯本追源，做到“透过现象看本质”。举例来说，我们通过一个“字幕拖拽”的线上OOM案例，先是解决业务层的浮点数bug，再是修复KSCrash的二次崩溃。不仅如此，我们意识到排除法存在误判是更深层次的问题——假设OOM率是不可靠的，不能准确反映APP的内存表现；那么内存相关的AB实验就会不置信，业务迭代引入的OOM劣化也可能无法归因；这严重影响我们的技术决策。为此，我们修改了Matrix和KSCrash的源码，极大减少了排除法的误判。

为了确认问题解决或优化的业务价值，我们需要充分验收。比如快影OOM优化，有可能会造成APP流畅度、视频画质和启动时长等Qos的劣化，最终影响产品的留存转化率等QoE。通常情况下，重大的修改都做了AB实验进行全面评估，有些情况还会开启holdout做长期评估。

防劣化是一个值得商榷的命题，因为单一指标的劣化有时是一种业务需要。快影会根据当前业务的复杂度并结合实际情况动态评估一个“合理的”OOM率，再使用OOM率收敛周期来衡量防劣化工作的效果。在未来彻底解决OOM误判的情况下，我们还可以分设备内存定制OOM率红线，甚至对高端机（如内存4G以上的设备）采用“清零”策略。至于具体的防劣化措施，快影分成三个阶段来做——测试灰度阶段，我们通过线下自动化测试和灰度监控来提前发现新增问题。在方案设计阶段，我们依赖技术评审和CheckList来避免引入新问题。最后是意识阶段，主要通过知识分享和性能优化培训来提升团队的防劣化风险意识。

”