使用Perfetto定位Android Binder性能瓶颈及Google AOSP优化方案实践

常规方法

1. 抓取 trace： 重点关注 aidl、binder 等相关的性能事件。
2. 使用 SQL 按进程和秒分组查询 Binder 调用次数。你还可以进一步查询持续时间字段，例如 client_dur、server_dur、aidl_dur，以此来找出耗时较长的 Binder 调用。

3. 根据分析结果进行针对性优化。

Google AOSP Binder 优化思路：IpcDataCache

为了系统性优化频繁的 Binder 调用，Android 系统层面引入了 IpcDataCache 机制，其核心实现位于以下文件：

• frameworks/base/core/java/android/os/IpcDataCache.java
• frameworks/base/core/jni/com_android_internal_os_ApplicationSharedMemory.cpp

其基本思想是让 App 等客户端进程能够缓存来自 system_server 等服务端的、不经常变化的数据，从而避免重复的 Binder 跨进程通信。这个方案巧妙地利用了 nonce（一次性随机数）值来判断缓存数据是否需要更新。

服务端负责生成并维护这个 nonce 值，通常基于时间戳。客户端进程在发起请求时，会携带自己持有的 nonce 与服务端当前值进行比对。如果两者一致，说明缓存有效，直接使用本地数据；如果不一致，则意味着数据已更新，客户端需要重新发起 Binder 请求以获取新数据并更新缓存。

nonce 值通过匿名共享内存（ashmem）实现，客户端进程通过 mmap 将其映射到自己的地址空间。为了保证读写的原子性，nonce 被设计为 int64 类型，客户端通常以只读方式访问，而服务端拥有读写权限。这种设计在提升Android/iOS应用性能的同时，也保证了网络/系统层面数据同步的一致性。

使用 dumpsys cacheinfo 查看详情

你可以通过 adb shell dumpsys cacheinfo 命令来查看系统中各进程的 Binder 缓存详情，包括缓存命中率、nonce 值等关键信息。

其它优化思路

AOSP 的 IpcDataCache 优化主要从“减少不必要的重复请求”这个维度出发，但它无法避免第一次必要的 Binder 调用。

对于一些对启动速度、响应延迟要求极高的关键场景，我们甚至可以尝试优化掉这“第一次”的 Binder 请求。例如，在 App 启动阶段，可以将某些预先可知的、必需的 Binder 数据请求，合并到更早的 Application binder 请求中一并处理，从而减少启动路径上的 IPC 次数。这类深度优化方案，在像云栈社区这样的技术论坛中，时常有开发者进行探讨和分享。