Android 17 新特性：ProfilingManager 新触发器

大家好，我是拭心。

线上性能问题有一个共同的难点：问题发生的那一刻，你往往不在现场。冷启动慢、线上 OOM、偶发 ANR，这些问题在开发机上复现困难，等你接到报警再去分析，现场已经消失了。

Android 17 对 ProfilingManager 做了一次重要升级------引入了系统级触发器（System Triggers）。你只需要提前注册，系统会在冷启动、OOM、ANR 等关键事件发生时自动采集性能数据，回调给你。

这篇文章我们来了解下这套新 API。

一、从主动采集到被动触发

ProfilingManager（android.os.ProfilingManager）在 Android 15 首次引入，允许应用在运行时主动请求系统级性能数据，包括 Java 堆转储（heap dump）、系统 trace、调用栈采样。

但 Android 15/16 的用法是主动调用 ：你得自己判断时机，手动调 requestProfiling()，适合开发阶段的定向排查。

Android 17 的变化是从主动请求到被动触发：

scss 复制代码

Android 15/16：开发者判断时机 → 主动调用 requestProfiling()

Android 17：系统检测到事件 → 自动触发 → 回调数据给开发者

这个差别很关键。主动采集依赖你能预判问题，而触发器不需要------系统帮你守着，问题一发生就留证。

二、新增的触发器类型

Android 17 新增的触发器覆盖了几类最难排查的线上场景：

触发器	触发时机	采集内容
`TRIGGER_TYPE_COLD_START`	冷启动，尽可能早触发	调用栈 + 系统 trace
`TRIGGER_TYPE_OOM`	应用抛出 `OutOfMemoryError`	Java 堆转储
`TRIGGER_TYPE_ANR`	ANR 被识别后、kill 前	系统 trace 快照
`TRIGGER_TYPE_EXCESSIVE_CPU`	因 CPU 过度使用被 kill	性能数据
`TRIGGER_TYPE_ANOMALY`	系统检测到异常行为	因异常类型而异
`TRIGGER_TYPE_APP_FULLY_DRAWN`	`reportFullyDrawn()` 调用后	系统 trace 快照
`TRIGGER_TYPE_APP_COMPAT`	检测到未来版本不兼容行为	兼容性信息

接下来重点看三个最实用的触发器，其余触发器（TRIGGER_TYPE_EXCESSIVE_CPU、TRIGGER_TYPE_APP_FULLY_DRAWN、TRIGGER_TYPE_APP_COMPAT、TRIGGER_TYPE_ANOMALY）我们在第四节一并说明适用场景。

三、核心触发器详解

3.1 冷启动触发器

冷启动慢是最常见的性能投诉，但也是最难定位的------开发机上快、用户设备上慢，差异原因五花八门。

TRIGGER_TYPE_COLD_START 会在冷启动尽可能早的时机触发，自动采集启动过程的调用栈和系统 trace。注册时机要尽早，放在 Application.onCreate() 里即可：

kotlin 复制代码

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()

        val profilingManager = getSystemService(ProfilingManager::class.java)

        profilingManager.registerForSystemTriggeredProfiling(
            ProfilingTrigger.Builder()
                .setTriggerType(ProfilingTrigger.TRIGGER_TYPE_COLD_START)
                .build()，
            mainExecutor
        ) { result ->
            val traceFile = result.traceFile
            // 上传到你的性能监控平台，分析哪个初始化操作拖慢了启动
            uploadToAnalytics(traceFile)
        }
    }
}

这样一来，线上用户每次冷启动，你都能拿到真实设备上的启动 trace，而不是只能靠 CI 机器的数据推断。

3.2 OOM 触发器

过去遇到线上 OOM，开发者拿到的只有崩溃日志------知道崩了，但不知道内存里究竟装了什么。

TRIGGER_TYPE_OOM 在应用抛出 OutOfMemoryError 时触发，自动采集 Java 堆转储（heap dump），可以直接用 Android Studio Memory Profiler 分析：

kotlin 复制代码

profilingManager.registerForSystemTriggeredProfiling(
    ProfilingTrigger.Builder()
        .setTriggerType(ProfilingTrigger.TRIGGER_TYPE_OOM)
        .build()，
    Executors.newSingleThreadExecutor() // heap dump 较大，用独立线程处理
) { result ->
    val heapDumpFile = result.traceFile
    // 注意：heap dump 文件可能达到几十 MB，建议压缩后异步上传
    uploadHeapDump(heapDumpFile)
}

OOM 发生 → 触发器回调 → 自动拿到内存快照，"OOM 黑盒"就变成了"可诊断的白盒"。

以前遇到线上 OOM，你拿到的只有一行崩溃日志：java.lang.OutOfMemoryError: Failed to allocate，知道崩了，但不知道内存里装了什么。现在可以直接用 Android Studio Memory Profiler 加载触发器采集的 heap dump，看清楚是哪类对象把内存撑爆的。

有一点需要注意：heap dump 包含内存中的所有数据，可能涉及用户隐私。上传前需要脱敏处理，或者仅在用户同意的前提下上传。Google 在 API 设计上保留了开发者的完全控制权------数据不会自动上传，由你决定怎么处理。

3.3 ANR 触发器

ANR 发生时，系统会记录一份 traces.txt，但开发者拿到的通常只是用户反馈或 Google Play Console 上滞后的汇总数据，缺少第一现场的上下文。

TRIGGER_TYPE_ANR 在 ANR 被系统识别后、尝试 kill 应用之前触发，此时线程堆栈还完整保留着：

kotlin 复制代码

profilingManager.registerForSystemTriggeredProfiling(
    ProfilingTrigger.Builder()
        .setTriggerType(ProfilingTrigger.TRIGGER_TYPE_ANR)
        .build()，
    mainExecutor
) { result ->
    val traceFile = result.traceFile
    reportAnrTrace(traceFile)
}

需要说明的是：触发不代表应用一定被 kill，只是 ANR 被检测到。系统会先给你回调数据，再决定后续处理。

四、使用注意事项

注册时机要尽早。 冷启动触发器尤其如此------注册得越晚，启动早期的数据就越容易丢失。建议统一在 Application.onCreate() 里完成所有触发器的注册。

其余触发器的适用场景。 上面详解了三个最常用的触发器，另外几个也各有用武之地：

TRIGGER_TYPE_APP_FULLY_DRAWN：配合 Activity.reportFullyDrawn() 使用，在页面完全展示后采集 trace，适合监控"界面可见但内容还没加载完"这段时间的性能
TRIGGER_TYPE_EXCESSIVE_CPU：应用因 CPU 过度使用被系统 kill 时触发，适合排查后台服务持续占用 CPU 的问题
TRIGGER_TYPE_ANOMALY：系统检测到应用的异常行为时触发，采集内容因异常类型而异，适合作为兜底监控
TRIGGER_TYPE_APP_COMPAT：检测到未来版本不兼容行为时触发，适合在升级 targetSdk 前的兼容性排查

与现有工具互补，而不是替代。 Firebase Crashlytics 捕获崩溃日志，ProfilingManager 触发器捕获性能快照，两者各有侧重。OOM 触发器采集的 heap dump 还可以直接在 Android Studio Panda 的 Profiler 中打开分析，与 IDE 工具链深度集成。

总结

Android 17 的 ProfilingManager 触发器，核心价值是让性能问题在发生的那一刻自动留证，填补了 Android 线上性能监控长期以来的一块空白。几个使用场景总结如下：

冷启动慢 ：注册 TRIGGER_TYPE_COLD_START，采集线上真实设备的启动 trace
线上 OOM ：注册 TRIGGER_TYPE_OOM，自动拿到 heap dump，直接分析内存构成
偶发 ANR ：注册 TRIGGER_TYPE_ANR，在问题发生时自动捕获线程快照
异常行为 ：注册 TRIGGER_TYPE_ANOMALY，应对系统检测到的各类异常

统一在 Application.onCreate() 注册，不需要任何埋点，系统替你守着现场。

好了，这篇文章到这里就结束了，感谢你的阅读，愿你平安顺遂。

如果对你有帮助，欢迎评论点赞转发，你的支持是我最大的动力❤️