Crashlytics 如何根治 Android 内存与响应性问题

ANR 和 OOM 的堆栈往往指向无辜的线程或分配点，真正的元凶早已逃之夭夭。Firebase Crashlytics 团队高级软件开发者 Polina 在演讲中，用一个名为 Chroma Clip 的视频调色板提取应用，完整演示了如何借助 Crashlytics 的新工具链，从 ANR 一路追到 native 内存损坏，把“堆栈说谎”的难题逐个击破。

为什么响应性和内存问题最难查

Polina 指出，当你修完 JSON 解析拼写错误、补上漏掉的空指针检查后，剩下的硬骨头就是响应性和内存问题。一个空指针异常的堆栈能精确指向 MainActivity.kt 第 42 行，但 ANR 或 OOM 的堆栈几乎从不指向真凶。最理想的情况，它只告诉你某个无辜线程在应用卡死或内存耗尽时恰好正在运行，而根因可能发生在更早、甚至完全不同的地方。

Chroma Clip 的故事从 1.0 发布前的本地测试开始：用户选择视频、点击提取调色板，熟悉的“应用无响应”对话框弹出。Logcat 显示主线程状态为 S（sleeping），停在 unsafe.park 等待一个未知对象。由于没有使用传统 Java synchronized 锁，Logcat 无法告知主线程在等谁、等哪个后台线程、为什么超过 5 秒。在本地还能手动翻 traces.txt 里几十个休眠线程，但在生产环境中，开发者根本拿不到用户手机上的这个文件。

ANR 破案：Application Exit Info 与 root-blocking 徽章

转机来自 Android 的 Application Exit Info API。从 Android 11 开始，系统在标记 ANR 或终止进程时，会记录丰富的退出元数据，包括确切原因、内存状态和进程内所有线程的完整系统跟踪。只要使用 Crashlytics SDK 18.3.5 或更高版本，无需额外插件或一行代码，SDK 会在应用重启后自动查询这些信息，连同设备遥测数据一起上报。

在 Crashlytics 控制台中，一个名为 Default Dispatcher Worker 1 的线程被标记为 root-blocking，它就是阻塞主线程的瓶颈。Crashlytics 还提供其他智能徽章：卡在读取大文件或慢查询的线程会标记为 IORootblocking，互相等待的线程则被标记为 deadlocked。展开该线程的堆栈，frameDecoder.getUncompressedFrame 卡在 createBitmap 里分配单帧内存。再结合控制台里设备可用内存不足 100 KB 的数据，基本可以断定：进程内存饥饿导致垃圾回收疯狂空转，UI 被饿死超过 5 秒。Polina 给出的经验法则是：ANR 伴随低可用 RAM，就是内存泄漏或膨胀的铁证。

Application Exit Info API 是 Android 11（API 级别 30）引入的系统级诊断接口，通过 ActivityManager.getHistoricalProcessExitReasons() 返回应用近期进程终止的历史记录。每条记录包含终止原因（如 ANR、低内存、用户主动停止）、时间戳、进程名、可读的描述信息，以及可选的系统跟踪文件（trace）。该 API 的价值在于将原本只存在于开发者设备上的 traces.txt 变为生产环境可获取的数据，并且无需特殊权限。Crashlytics 等监控 SDK 可在应用下次启动时静默读取这些历史记录并上报，从而填补了线上 ANR 与 OOM 根因分析的空白。

从 OOM 到堆转储：定位 Java 堆的膨胀点

问题列表里紧挨着 ANR 的还有 OutOfMemoryException，这让 Polina 怀疑两者是同一枚硬币的两面：同样的内存压力，时机不同就表现为 ANR 或 OOM。OOM 的堆栈同样具有欺骗性——它显示 createBitmap 在打开设置页时连 256 字节都分配失败，但设置页只是不幸的调用者，不是元凶。

Crashlytics 此时接入了 Android 的 Profiling Manager API。在 Android 17 上，系统会在应用触发 OOM 或突破内存限制时于后台自动抓取堆快照，Crashlytics SDK 20.1.0 及以上版本开箱即用，并在仪表盘中自动归组 OOM 和内存限制终止事件。用户可以在 Firebase 控制台选择启用堆转储收集。Crashlytics 还会明确标注 OOM 堆栈具有非确定性，避免开发者像刚才那样浪费时间。

下载经反混淆的 Perfetto 堆转储后，可以在 Perfetto UI 的 Heap Dump Explorer 中分析。Chroma Clip 的堆里是贯穿整个 Java 堆的巨大条形——每个像素的颜色和字符串对象都被保留在列表中，数量高达数百万。修复方案很直接：不再为每个像素分配对象，而是对帧降采样并直接统计原始整数。

Profiling Manager API 是 Android 15 引入、并在 Android 17 上扩展的系统性能分析框架，允许应用请求系统在后台生成堆转储、方法追踪等性能数据，而无需用户手动操作或依赖 adb。它通过 ProfilingManager 类注册触发器（如 OOM、内存限制终止），系统在触发时自动抓取数据并存储在应用私有目录，随后 SDK 可在下次启动时读取并上传。相比传统的 Debug.dumpHprofData()，Profiling Manager 的优势在于生产环境可用、对性能影响可控，并且能捕获到 OOM 瞬间的堆状态而非事后快照。

内存限制终止与 native 泄漏

修复 OOM 后，部分设备上的 ANR 依然存在，另一些设备则开始随机崩溃，并出现全新的 memory limiter kill。这是 Android 17 的新机制：Java OOM 只管 Java 堆上限，而应用总内存还包括图形缓冲和 C++ 分配等 native RAM。过去只有全局的 low memory killer，现在内存限制器会为每个应用设定独立上限，超限就终止该应用。

Crashlytics 同样会自动归组这些终止事件，并提供原因解释、排查建议和官方文档链接。在 Perfetto 概览中，进程总内存（unknown RSS 加 swap）达到 4 GB，而托管堆仅 42 MB，10 秒内就排除了 Kotlin/Java 代码，把嫌疑锁定在 native C++ 层。检查 native palette engine process frame 后发现，每帧都在分配临时 scratch buffer 却从不释放。修复后，Android 17 上的内存限制终止消失，旧设备上的 ANR 也一并解决。

memory limiter kill 是 Android 17 引入的进程级内存管控机制，与以往全局的 low memory killer（LMK）不同，它为每个应用设定独立的总内存上限（包括 Java 堆、native 堆、图形缓冲区等所有内存类型），一旦进程总内存超过该阈值，系统会直接终止该进程并记录原因为 REASON_MEMORY_LIMIT。这一机制填补了 Java OOM 只关注托管堆的空白，使 native 内存泄漏也能被系统主动发现。开发者可通过 Application Exit Info API 获取此类终止记录，并结合堆转储分析 native 分配热点。

原生内存损坏：GWP ASAN 与 ARM MTE

应用走红后，之前不起眼的 native 崩溃数量暴涨。堆栈里没有任何自家代码，render thread 在 libc.so 释放内存时崩溃——这是 native 内存损坏的教科书信号：C++ 代码更早地损坏或释放了缓冲区，render thread 只是后来踩了雷。

Crashlytics 开箱支持两种工具。GWP ASAN 是面向生产的轻量安全网，对极小比例的 native 分配进行采样，并用保护页包裹，CPU 和内存开销几乎为零；但它是概率性的，本地调试可能需要长时间运行才能命中。ARM MTE 则利用硬件指针和内存标签检查每次分配，适用于 Pixel 8 及更新等 ARM v9 设备，适合确定性本地调试。两者互补，Crashlytics 会自动为捕获的问题打上徽章，并支持按工具筛选。

在控制台中，GWP ASAN 捕获的崩溃会多出一个 memory stack trace 标签，顶部直接给出 use-after-free 的确切原因，并列出缓冲区的 allocated by 与 deallocated by。Chroma Clip 的 bug 一目了然：后台线程切换滤镜时释放了旧缓冲区，而 render thread 仍在读取它。加上互斥锁后，GWP ASAN 报告和神秘崩溃几乎一夜消失。

GWP ASAN（Google-Wide Profiling AddressSanitizer）是 Google 内部广泛使用的生产级地址消毒器，专为低开销设计。它通过采样方式对少量 native 分配进行监控：每次分配时在前后添加保护页（guard page），释放后使内存不可访问，从而在发生越界读写或 use-after-free 时立即触发崩溃并输出详细报告。其 CPU 和内存开销通常低于 5%，适合线上部署。ARM MTE（Memory Tagging Extension）则是 ARMv9 架构的硬件特性，为每个内存分配附加 4 位标签，指针携带匹配标签，每次访问时由硬件校验标签一致性，能确定性捕获内存错误，但需要设备支持（如 Pixel 8 及更新机型）。两者互补：GWP ASAN 覆盖面广但概率性，MTE 精确但依赖硬件。

工具链速查

演讲最后给出的清单包括：通过 Application Exit Info 获取 ANR 线程洞察及元数据；通过 Profiling Manager 自动收集 OOM 和内存限制终止的触发器；完整的 GWP ASAN 与 ARM MTE 支持用于 native 内存损坏。此外，Android 17 及以上的现场堆转储（field heap dumps）正在私有预览中，可结合 Perfetto 和 Android CLI 分析，感兴趣的开发者可以通过演讲中的链接申请。

Polina 的收尾祝福很贴切：愿你的主线程永不阻塞，堆内存永远干净。对于那些被“堆栈说谎”折磨过的 Android 开发者来说，这套工具链至少让排查不再靠猜。