23、Camera系统启动优化：快速预览、冷启动与热启动、Boot Time优化
各位做车载Camera的朋友，启动优化这块，说白了就是跟时间赛跑。用户坐进车里，挂倒挡，如果倒车影像要等两三秒才出来，那体验就太糟糕了。我个人习惯把启动优化分成三个维度来拆解：冷启动、热启动，以及系统级的Boot Time优化。今天咱们就聊聊这些实战中的门道。
23.1 冷启动 vs 热启动：本质区别在哪？
先搞清楚概念。冷启动，指的是系统从完全断电状态（比如车辆刚上电）开始，Camera HAL、Framework、硬件驱动全部需要重新初始化。热启动呢，是系统已经运行，只是Camera从休眠或低功耗模式恢复到工作状态。
我在项目中遇到过一个问题：冷启动时预览画面要2.8秒才出来，但热启动只需要0.5秒。为什么差这么多？因为冷启动要加载驱动、分配内存、初始化ISP管线，而热启动这些资源都还在。
| 启动类型 | 典型耗时 | 主要瓶颈 |
|---|---|---|
| 冷启动 | 1.5s - 3.0s | 驱动加载、ISP初始化、内存分配 |
| 热启动 | 0.3s - 0.8s | Sensor唤醒、Pipeline恢复 |
嗯，这里要注意：车载场景下，冷启动的优化空间最大，也是我们重点要啃的硬骨头。
23.2 快速预览的核心思路
快速预览，说白了就是让用户尽快看到画面，哪怕画质差一点、帧率低一点。我习惯用「渐进式预览」的策略：先出图，再优化。
核心原则：第一帧画面必须在500ms内呈现给用户，后续再逐步提升画质和帧率。
具体怎么做？我总结了几条实战经验：
- 预分配内存池：在Camera HAL加载阶段，提前申请好Gralloc Buffer。别等到Stream开启时才去分配，那太慢了。我曾经在某个项目中，把内存分配提前到HAL初始化阶段，直接省了200ms。
- 精简Pipeline：冷启动时先走一个简化版的ISP管线，比如只做Bayer到RGB的转换，不做降噪、HDR合成。等画面稳定了，再切换到完整管线。
- Sensor快速出图：配置Sensor寄存器时，先输出低分辨率、低帧率的预览流。我见过有些方案直接让Sensor输出640x480@15fps，第一帧能在300ms内出来。
小技巧：在HAL的open()函数里，不要等所有资源都准备好才返回。可以先返回一个空的CameraDevice，后台异步初始化。Framework那边可以提前显示一个占位图，等第一帧到了再替换。
23.3 Boot Time优化：从系统层面加速
Boot Time优化，不只是Camera的事，它涉及整个Android系统的启动流程。但Camera作为车载的核心功能，往往是最早上电的模块之一。
我参与过一个项目，要求从车辆上电到倒车影像显示，总时间不超过1.5秒。这逼着我们从系统层面做了很多优化：
23.3.1 驱动加载优化
Camera相关的驱动（Sensor、ISP、CSI）要优先加载。怎么做？
- 把Camera驱动编译进内核，而不是作为模块加载。模块加载需要等待文件系统挂载，太慢了。
- 使用异步probe机制，让驱动初始化不阻塞其他模块的启动。
// 内核驱动中启用异步probe
static int sensor_probe(struct i2c_client *client) {
// 初始化硬件
// 注册v4l2设备
return 0;
}
// 在驱动结构体中设置
static struct i2c_driver sensor_driver = {
.probe = sensor_probe,
.probe_type = PROBE_PREFER_ASYNCHRONOUS, // 异步probe
};
23.3.2 HAL层启动优化
HAL的加载时机很关键。我建议把Camera HAL做成一个独立的服务，在SurfaceFlinger启动之前就加载好。
注意：不要等所有HAL都加载完才启动Camera。可以设计一个「快速通道」：当检测到倒车信号时，直接跳过一些非必要的初始化步骤。
我记得有个项目，HAL初始化时要去读取一个很大的校准文件（几百KB），每次都要花300ms。后来我们改成只读取关键参数，其他参数在后台异步加载。第一帧预览时间直接降了250ms。
23.3.3 Framework层优化
Framework这边，主要优化CameraService的启动流程：
- 减少Binder调用的次数。把多个配置参数打包成一个Bundle，一次调用传过去。
- 使用共享内存传递大块数据（比如校准参数），避免序列化开销。
- 提前创建CameraClient实例，不要等到应用请求时才创建。
23.4 启动流程的SVG架构图
下面这张图，是我根据实际项目经验画的。它展示了从车辆上电到预览画面显示的关键路径，以及每个阶段的优化点。
23.5 实战中的避坑指南
做启动优化，坑不少。我挑几个典型的说说：
坑1：千万不要在HAL的open()里做耗时操作。我曾经见过一个方案，在open()里读取EEPROM校准数据，结果每次都要等500ms。正确的做法是：open()只做轻量初始化，重活放到configureStreams()或者后台线程去做。
坑2：热启动时，别以为所有资源都还在。有些系统在休眠时会释放GPU/ISP的电源域，唤醒后需要重新配置。我建议在热启动路径上也做一次快速资源检查，别直接复用旧的句柄。
我的经验：启动优化一定要用profiling工具量化。别靠感觉优化。我用过systrace、perfetto，还有我们自研的HAL层打点工具。每次优化前后，都要记录「上电到第一帧」的精确时间。没有数据，一切都是空谈。
嗯，启动优化这块，说到底就是「时间换空间，空间换时间」的博弈。你要在有限的硬件资源下，把每一毫秒都榨干。我个人觉得，最有效的优化往往不是某个大招，而是把每个环节都抠掉几十毫秒，积少成多。
最后说一句：别为了追求启动速度，牺牲了功能安全。我记得有个项目，为了快100ms，跳过了Sensor自检，结果倒车时画面卡死，差点出事。优化要有底线，安全永远是第一位的。