火山引擎MARS- APMPlus专栏—— iOS Heimdallr 卡死卡顿监控方案与优化之路

关注

VIP免费原创 2022-01-26 15:28:30 3k 阅读 AI 写同款· GEO 优化 ›

使用火山引擎 APMPlus 解决抖音Top 1 Java 崩溃的通用优化方案问题是在 App 进程向 system_server 进程发送 Activity.onSaveInstanceState 保存的 Bundle 数据时，驱动层在 system_server 的 Binder 接收缓冲区（大小上限 1M-8K）中分配不出用于接收 Bundle 大小的内存，导致 Binder 发送失败Bundle 数据用于 Activity 页面销毁重建时恢复页面状态，其来源包含 framework 和 App 层保存的数据。当页面过于复杂或者很重场景下可能会出现超限问题。阅读详情

本文主要介绍Heimdallr对卡死、卡顿异常的监控原理，并结合长时间的业务沉淀发现的问题进行不断迭代和优化，逐步实现全面、稳定、可靠的历程。

作者：字节跳动终端技术——白昆仑

前言

卡死、卡顿作为目前iOS App的重要性能指标，不仅影响着用户体验，更关系到用户留存、DAU等重要产品数据。本文主要介绍Heimdallr对卡死、卡顿异常的监控原理，并结合长时间的业务沉淀发现的问题进行不断迭代和优化，逐步实现全面、稳定、可靠的历程。

一、什么是卡死/卡顿？

卡顿，顾名思义就是在使用过程中出现了一段时间的阻塞，使得用户在这一段时间内无法进行操作，屏幕上的内容也没有任何的变化。Heimdallr在监控指标上，根据阻塞时间的长短进行了3个等级的划分。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EKde0XNN-1642665310081)(https://tech-proxy.bytedance.net/tos/images/1642663790534_36575e5620cc4621d98544f0d1185e13)]

1、流畅性与丢帧：动画、滑动列表不流畅，一般为十几至几十毫秒的级别

2、卡顿：短时间操作无反应，恢复后能继续使用，从几百毫秒至几秒

3、卡死：长时间无反应，直至被系统杀死，通过线上收集数据，最少为5s

可以看到，根据严重性由小至大可将卡顿问题划分为流畅性与丢帧、卡顿、卡死三个不同的等级。卡死的严重程度与Crash是相当的，甚至更为严重。因为卡死不仅仅造成了类似于崩溃的闪退，更使得用户被迫等待了相当长的一段时间，更加损害用户的体验。由于监控方案上的差异，本文主要面向的是后两者卡顿和卡死的监控。

二、卡死/卡顿的原因

iOS开发中，由于UIKit是非线程安全的，因此一切与UI相关的操作都必须放在主线程执行，系统会每16ms（1/60帧）将UI的变化重新绘制，渲染至屏幕上。如果UI刷新的间隔能小于16ms，那么用户是不会感到卡顿的。但是如果在主线程进行了一些耗时的操作，阻碍了UI的刷新，那么就会产生卡顿，甚至是卡死。主线程对于任务的处理是基于Runloop机制，如下图所示。Runloop支持外部注册通知回调，提供了

1、RunloopEntry

2、RunloopBeforeTimers

3、RunloopBeforeSources

4、RunloopBeforeWaiting

5、RunloopAfterWaiting

6、