Android 15 新 API：内存追踪利器 ProfilingManager

本文为稀土掘金技术社区首发签约文章，30天内禁止转载，30天后未获授权禁止转载，侵权必究！

前言

我们都知道 Android Studio 里内置了 Profiler tool 供大家对 App 在 Memory、CPU、Network、Power 等角度进行 dump 和分析。

但如果一个内存相关的 bug 是运行时发生的，而且很难复现，那么后期就很难准确定位发生时的具体状况。

值得兴奋的是 Android 15 将直面这个痛点：引入了 ProfilingManager API，允许 app 对 Memory 进行动态的、随时随地的 dump。

生成的文件默认存在本地，也可以通过网络传递到 offboard，方便开发者事后回溯。

API 说明

ProfilingManager 主要提供了 3 个方法。

registerForAllProfilingResults

注册 profiling 请求的回调和执行的线程，需要如下两个参数：

unregisterForAllProfilingResults

注销 profiling 请求的回调，如果没有指定 listener 参数的话，将移除所有 callback。

requestProfiling

请求进行一次 profiling 操作，有非常详细的参数可供设置：

需要说明的是：

• 很多时候，并不推荐直接使用该 API 进行 dump，相反可以采用 androidx 中封装好的高层级接口进行请求。该接口内部会依据可用选项和简化的参数进行正确地请求。
• 并非所有情况都会得到响应
• 需要同时考虑 result 的监听和执行它的线程池两个参数，要么都设置，要么都不设置交给 registerForAllProfilingResults() 一起设置

ProfilingResult

在上述提到的 registerForAllProfilingResults() 里会回调 ProfilingResult 参数过来，它用来封装单次请求 profiling 操作的结果。

主要提供了这几个方法来获得信息：

• getErrorCode()：获取 profiling 请求失败的原因，如果成功的话，值为 ERROR_NONE 即 0，其他的还有 ERROR_FAILED_RATE_LIMIT_SYSTEM 等值
• getErrorMessage()：获取额外的失败信息
• getTag()：请求时传入的参数 tag，方便回溯
• getResultFilePath()：获取 profiling 结果文件的路径

实战

留意一下，需要将 Android 15 的 SDK 升级到 revision 3 才可以看到该 API。

     class ProfilingActivity : AppCompatActivity() {
         private val singleThreadExecutor = Executors.newSingleThreadExecutor()
     ​
         private val profilingResultConsumer = Consumer<ProfilingResult> {
             Log.d(TAG_PROFILING, "accept profilingResult:${it.printProfilingResult()}")
         }
     ​
         private val profilingManager by lazy {
             getSystemService(ProfilingManager::class.java)
         }
     ​
         override fun onCreate(savedInstanceState: Bundle?) {
             ...
             binding.dump.setOnClickListener {
                 Log.d(TAG_PROFILING, "button dump tapped")
     ​
                 profilingManager.registerForAllProfilingResults(
                     singleThreadExecutor,
                     profilingResultConsumer
                 )
             }
     ​
             binding.request.setOnClickListener {
                 Log.d(TAG_PROFILING, "button request tapped")
     ​
                 profilingManager.requestProfiling(
                     // ProfilingManager.PROFILING_TYPE_SYSTEM_TRACE,
                     // ProfilingManager.PROFILING_TYPE_JAVA_HEAP_DUMP,
                     // ProfilingManager.PROFILING_TYPE_STACK_SAMPLING,
                     ProfilingManager.PROFILING_TYPE_HEAP_PROFILE,
                     null,
                     "TEST_FOR_PROFILING_MANAGER",
                     null,
                     singleThreadExecutor,
                     profilingResultConsumer
                 )
             }
     ​
             binding.stop.setOnClickListener {
                 Log.d(TAG_PROFILING, "button stop tapped")
     ​
                 profilingManager.unregisterForAllProfilingResults(profilingResultConsumer)
             }
         }
     }

可以看到我们在代码里设置的 tag 为 "TEST_FOR_PROFILING_MANAGER" 。

我们点击 “register dump profile” button 开始注册回调，然后点击 “request dump profile” button 开始请求。

看下 Profiling 的 log 输出。

点击完 request 之后需要等待一段时间（系统默认的 dump 超时为 120s 左右）才会看到 dump 结果。

注意，不要重复点击，否则会收到如下错误的 callback。其中 3 对应的是 ERROR_FAILED_PROFILING_IN_PROGRESS，表示仍在 dump 中，该重复请求被拒绝。

ProfilingResult{errorCode:3 errorMessage:null resultFilePath:null tag:TEST_FOR_PROFILING_MANAGER}

下面我们以如下 4 种 dump 类型看下具体的 ProfilingResult 输出内容。

PROFILING_TYPE_JAVA_HEAP_DUMP

04-21 19:37:32.220  7184  7270 D Profiling: accept profilingResult:ProfilingResult{errorCode:0 errorMessage:null resultFilePath:/data/user/0/com.ellison.osvdemo/files/profiling/profile_testforprofilingmana_2024-04-21-19-37-26.perfetto-java-heap-dump tag:TEST_FOR_PROFILING_MANAGER}

可以看到成功输出了 Java heap 的 dump 文件，并且咱们的 tag 被拼接到了文件名中，而且将_删除并限制了 20 的长度。

所以咱们设置的 tag 最好不要包含字母以外的字符，并且不要过长，不然不方便定位 tag。

PROFILING_TYPE_HEAP_PROFILE

04-21 19:47:16.810  7474  7552 D Profiling: accept profilingResult:ProfilingResult{errorCode:0 errorMessage:null resultFilePath:/data/user/0/com.ellison.osvdemo/files/profiling/profile_testforprofilingmana_2024-04-21-19-45-11.perfetto-heap-profile tag:TEST_FOR_PROFILING_MANAGER}

和上面的 Java dump 一样，成功输出了 heap 全量的 dump 文件。

PROFILING_TYPE_STACK_SAMPLING

04-21 19:53:01.043  7704  7790 D Profiling: accept profilingResult:ProfilingResult{errorCode:0 errorMessage:null resultFilePath:/data/user/0/com.ellison.osvdemo/files/profiling/profile_testforprofilingmana_2024-04-21-19-51-55.perfetto-stack-sample tag:TEST_FOR_PROFILING_MANAGER}

dump stack 的记录也是一样，不再赘述。

PROFILING_TYPE_SYSTEM_TRACE

04-21 15:43:33.926  4730  4775 D Profiling: accept profilingResult:ProfilingResult{errorCode:7 errorMessage:Trace is not supported until redaction lands resultFilePath:null tag:null}

和前面 3 中 type 不同，这种 dump 系统 trace 的请求总是会直接失败。

ProfilingResult 结果对应的 errorCode 为 7，常量名称为 ERROR_FAILED_INVALID_REQUEST，表示请求失败了：这是一个不合法的 ProfilingRequest。

The request failed due to invalid ProfilingRequest.

单从这个 error 定义来看，压根不知道问题出在哪。

在 API 章节里我们提到过，如果调用 requestProfiling() 时传递的 Bundle 参数包含了不支持的 key-value，会造成 ERROR_FAILED_INVALID_REQUEST 错误。

但可以看到：实际上咱们的 DEMO 代码里啥 bundle 都没携带，所以应该不是这个原因。

好在，ProfilingRequest 结果还打携带了 errorMessage，其内容为：Trace is not supported until redaction lands。

笔者尝试依据该 message 找到蛛丝马迹，但无论在 Android 官网，还是在 Android 源码里，抑或是在 AOSP issue 的首页上，都没找到合相关的记录。

我猜测是 PROFILING_TYPE_SYSTEM_TRACE 需要某个 DOC 里没说明的 Bundle 参数，造成了失败。当然也有可能是 beta 版阶段的系统 bug。

后续再看。

perfetto 支持

以 PROFILING_TYPE_JAVA_HEAP_DUMP 的文件为例，从 data 目录里 pull 之后，在 中打开，可以进行分析。

DEMO 源码

结语

ProfilingManager API 允许 App 直接进行各种 Memory 数据的 dump，相信这能在一定程度上帮助开发者进行内存相关问题的回溯，不再像以前那样被动。

从上面的实战也能看到目前部分功能还存在些问题，期待正式版本能够修复。

感兴趣的朋友可以在 Android 15 稳定版的时候再行体验。

笔者猜测因为 Memory 是最高优的关注点，所以目前 ProfilingManager 只支持 dump Memory。但我相信随着该 API 的成熟和普及，以及确实有 dump 其他点强劲需求的话，肯定会逐步支持更多 dump 的内容。

参考资料