15、Camera Framework层优化：CameraService Binder调用优化、Metadata传递优化、Callback线程模型、ANR问题排查
各位好，今天我们聊点真正让Camera HAL工程师头疼的东西——Framework层优化。
很多人觉得，Camera性能瓶颈都在底层，都在ISP、都在Sensor。嗯，这话对了一半。我见过太多项目，底层流水线跑得飞起，结果卡在Framework层的Binder调用上，一帧数据从HAL送到应用层，光Binder传输就耗掉好几毫秒。你说冤不冤？
所以这一章，我们聚焦四个核心痛点：Binder调用优化、Metadata传递、Callback线程模型、ANR排查。每一个都是我踩过坑的地方。
15.1 CameraService Binder调用优化
先说说Binder。Android的IPC机制，说白了就是进程间通信。CameraService作为系统服务，和应用层、HAL层之间全是Binder调用。
我个人习惯，拿到一个新项目，第一件事就是抓一份Binder调用频次统计。你猜怎么着？很多场景下，一帧画面从Capture到返回给应用，中间要经过十几二十次Binder调用。每次调用都有序列化、反序列化、权限检查、线程切换的开销。
优化思路其实不复杂：
- 减少调用次数：能一次传完的数据，别拆成多次。比如把多个Metadata打包成一个Batch传递。
- 使用oneway调用：对于不需要同步返回结果的调用，比如通知状态变化，用oneway可以避免阻塞调用方线程。
- 避免高频轮询：我见过有些厂商在Framework层用循环去轮询HAL的状态，每次轮询都是一次Binder调用。改成回调通知，性能提升明显。
15.2 Metadata传递优化
Metadata，就是Camera的“小纸条”。应用层下发拍照参数，HAL层返回结果信息，全靠它。但问题在于，Metadata的结构复杂，包含大量键值对，序列化开销很大。
我总结了几条优化原则：
- 精简Metadata条目：只传递真正需要的key。很多厂商在初始化时一股脑把所有支持的key都塞进去，其实大部分应用根本用不到。
- 使用共享内存传递大数据：对于大块数据（比如Face landmarks、3A统计信息），走Binder传太慢了。用SharedMemory或者Gralloc Buffer来传递，效率高得多。
- 避免重复序列化：同一个Metadata对象，如果多次传递，尽量复用已经序列化好的buffer，不要每次都重新打包。
核心原则： Metadata传递的优化，本质上是“少传、快传、复用传”。
举个例子。我曾经遇到一个bug：拍照后返回的Metadata里，包含了整整200多个key。实际上应用层只关心其中10个。后来我们在Framework层加了一个filter，只传递应用层注册了监听的那些key。结果呢？拍照响应时间从120ms降到了85ms。
15.3 Callback线程模型
Callback，回调，是Camera Framework里最容易出问题的地方。为什么？因为回调的线程模型太复杂了。
你想想看，一个CameraCaptureSession，有onCaptureStarted、onCaptureProgressed、onCaptureCompleted三个回调。每个回调在哪个线程执行？是Binder线程池？还是应用层指定的Handler线程？还是CameraService内部的工作线程？
我建议的线程模型设计原则：
- 回调尽量在应用层指定的线程上执行：给应用开发者一个Handler，让他们自己控制回调的线程。这样应用层可以避免线程安全问题。
- 避免在回调中做耗时操作：回调线程通常是共享的，你在里面做耗时操作，会阻塞其他回调的投递。
- 使用独立的Callback分发线程：在CameraService内部，把回调的分发和Binder处理线程分开。这样即使回调处理慢，也不会影响Binder调用的响应。
15.4 ANR问题排查
ANR，Application Not Responding，应用无响应。在Camera场景下，ANR是高频问题。尤其是拍照、录像启动、切换摄像头这些操作。
ANR的根因，说白了就两种：
| 类型 | 典型原因 | 排查方向 |
|---|---|---|
| Binder调用超时 | CameraService处理请求太慢，导致应用层Binder调用阻塞超过5秒 | 检查CameraService主线程是否有耗时操作 |
| Callback投递阻塞 | 应用层的Handler线程被占满，回调无法及时投递 | 检查应用层主线程是否有IO操作或锁竞争 |
| Metadata传递死锁 | Framework层和HAL层互相等待锁释放 | 抓取线程堆栈，分析锁的持有关系 |
我常用的排查手段：
- 抓取Binder日志：通过
adb shell dumpsys binder查看Binder调用状态，看哪些调用处于pending状态。 - 分析线程堆栈：ANR发生时，系统会生成traces.txt。重点关注CameraService的binder线程、callback线程、以及应用层的主线程。
- 模拟低内存场景：很多ANR在低内存下才复现。用
adb shell am memory-factor模拟低内存，提前暴露问题。
知识体系总览
下面这张图，是我对Camera Framework层优化核心逻辑的总结。你可以把它当作一个检查清单，做优化时对照着看，不容易漏掉关键点。
好了，这一章的内容就到这里。Framework层的优化，很多时候不是技术难题，而是“有没有想到”的问题。多抓日志、多分析线程模型、多从应用层的角度去思考，很多性能瓶颈其实不难解决。