第30章案例实战

课程目录第30章案例实战

案例实战：四大场景下的Camera性能优化

各位好，我是负责Camera HAL的老工程师。今天咱们不讲理论，直接上实战。我挑了几个真实项目里遇到的典型案例——旗舰机启动慢、中端机预览卡顿、平板录视频功耗高、折叠屏切摄像头延迟大。这些坑，我基本都踩过。

嗯，咱们一个一个来。每个案例我都会讲清楚：问题现象、根因分析、优化方案、以及我当时的踩坑记录。

核心思路：Camera性能优化，说白了就是跟时间、功耗、流畅度这三个维度较劲。启动优化看时间，预览优化看帧率，录制优化看功耗，多摄切换看延迟。每个维度都有对应的HAL层手段。

1. 旗舰机型：Camera启动优化实战

问题现象：某骁龙8 Gen2旗舰机，冷启动相机App到第一帧预览显示，耗时约1.8秒。竞品同平台机型在1.2秒以内。用户反馈“打开相机慢半拍”。

根因分析：我带着团队抓了systrace，发现几个关键瓶颈：

HAL初始化串行化：openCamera()内部做了太多同步操作，比如Sensor初始化、ISP加载固件、3A算法库加载，全部串行执行。
Stream配置冗余：App请求了4个stream（预览、拍照、视频、深度），但实际预览只需要2个。HAL层没有做stream合并优化。
Buffer分配阻塞：Gralloc分配GraphicBuffer时，因为ION内存碎片化，耗时增加了300ms。

优化方案：

HAL初始化并行化：把Sensor初始化、ISP固件加载、3A算法库加载拆成三个独立线程，用Future等待结果。我习惯用std::async + shared_future，避免死锁。
Stream合并：在configureStreams()中，如果预览和拍照的尺寸、格式一致，合并成一个stream，通过buffer handle复用。这个改动让配置时间从400ms降到150ms。
预分配Buffer池：在App启动阶段，提前分配好3帧的GraphicBuffer，避免首次分配时的ION碎片化问题。

// 伪代码：HAL初始化并行化
void CameraHAL::openCamera() {
    auto sensor_init = std::async(std::launch::async, [this](){ initSensor(); });
    auto isp_load = std::async(std::launch::async, [this](){ loadISPFirmware(); });
    auto algo_load = std::async(std::launch::async, [this](){ load3AAlgo(); });
    
    sensor_init.get();
    isp_load.get();
    algo_load.get();
    // 这里要注意：3A算法依赖ISP固件，所以algo_load必须在isp_load之后启动
    // 我当初没注意这个依赖关系，导致3A初始化失败，排查了半天...
}

避坑指南：我曾经在并行化时忽略了Sensor和ISP的依赖关系——Sensor需要ISP提供的MIPI时钟才能完成初始化。后来加了依赖图检查，才稳定下来。

优化结果：冷启动时间从1.8秒降到1.1秒，提升了约39%。用户反馈“感觉不到延迟了”。

2. 中端机型：预览卡顿优化实战

问题现象：某天玑8200中端机，预览时画面每隔2-3秒卡顿一次，帧率从30fps掉到15fps左右。用户说“画面像幻灯片”。

根因分析：抓trace发现，卡顿时刻CPU频率被降到了最低。为什么？因为温控模块检测到电池温度超过45°C，触发了降频策略。但实际Camera预览的CPU负载并不高，降频后反而导致HAL的3A算法线程无法按时完成。

优化方案：

CPU频率锁定：在Camera打开期间，通过powerHAL接口锁定大核最低频率到1.2GHz。这个操作需要跟温控团队协调，否则会被温控覆盖。
3A算法轻量化：把自动白平衡(AWB)的统计窗口从全分辨率改为中心区域，减少计算量。说白了，预览阶段不需要全图精准白平衡，中心区域就够了。
Buffer丢帧策略：当HAL检测到CPU负载过高时，主动丢弃一帧预览buffer，而不是让App端卡住。用户感知上只是轻微跳帧，比卡顿好得多。

// 伪代码：丢帧策略
void CameraHAL::processPreviewFrame() {
    static int64_t last_frame_time = 0;
    int64_t now = systemTime();
    
    if (now - last_frame_time > 100ms) { // 帧间隔超过100ms，说明CPU吃紧
        // 丢弃当前帧，不送到App端
        return;
    }
    // 正常处理
    last_frame_time = now;
    sendFrameToApp();
}

注意：丢帧策略不能滥用。我见过一个项目丢帧率超过10%，用户反馈“画面不连贯”。建议丢帧率控制在3%以内，且只在CPU负载超过80%时触发。

优化结果：预览帧率稳定在28-30fps，卡顿现象消失。电池温度虽然上升了2°C，但用户更在意流畅度。

3. 平板设备：视频录制功耗优化实战

问题现象：某平板在1080P 30fps视频录制时，整机功耗约4.5W。竞品同尺寸平板在3.2W左右。用户抱怨“录半小时视频，平板发烫严重”。

根因分析：我仔细看了功耗分解数据，发现ISP的功耗占了1.8W，占比40%。为什么这么高？因为ISP一直在全流水线模式下工作，即使预览和录制只需要部分功能。

优化方案：

ISP流水线裁剪：录制模式下，关闭不需要的ISP模块，比如HDR合成、多帧降噪、人脸检测。这些模块在录制时用不上，但默认是开启的。
DDR带宽优化：把YUV输出格式从NV12改为NV21，减少DDR读写带宽。NV21的UV分量排列更紧凑，带宽节省约15%。
帧率自适应：当场景亮度足够时（>300 lux），自动降低Sensor增益，减少ISP的噪声处理负载。说白了，光线好就别让ISP做那么多降噪。

优化项	优化前功耗	优化后功耗	节省
ISP流水线	1.8W	1.1W	0.7W
DDR带宽	1.2W	1.0W	0.2W
Sensor+其他	1.5W	1.3W	0.2W
总计	4.5W	3.4W	1.1W

个人经验：ISP流水线裁剪这个事，一定要跟ISP厂商的FAE确认。我当初想当然地关闭了某个模块，结果导致录制画面出现条纹。后来才知道那个模块虽然叫“HDR合成”，但内部还负责了像素校正。

优化结果：整机功耗从4.5W降到3.4W，温升从12°C降到7°C。用户反馈“录视频不再烫手了”。

4. 折叠屏：多摄切换延迟优化实战

问题现象：某折叠屏手机，从主摄切换到超广角时，画面黑屏约800ms。用户说“切换摄像头像死机了一样”。

根因分析：这个问题的根因比较隐蔽。我查了HAL层的log，发现切换时做了以下操作：关闭主摄stream → 销毁主摄pipeline → 创建超广角pipeline → 配置超广角stream。整个过程是串行的，而且每个步骤都涉及内核驱动交互，耗时较长。

优化方案：

双pipeline预创建：在App启动时，同时创建主摄和超广角两个pipeline，但只激活主摄的stream。切换时，只需要停掉主摄stream，激活超广角stream。pipeline创建耗时从400ms降到0。
Stream复用：主摄和超广角使用相同的stream配置（尺寸、格式、buffer数），切换时不需要重新配置stream。这个改动节省了200ms。
Sensor同步：在切换前100ms，提前给超广角Sensor发送stream on命令，让Sensor提前进入工作状态。这样切换时Sensor已经稳定输出，不需要等待。

// 伪代码：双pipeline预创建
void CameraHAL::initMultiCamera() {
    // 创建主摄pipeline
    mMainPipeline = createPipeline(CAMERA_ID_MAIN);
    mMainPipeline->configureStreams(mPreviewStreamConfig);
    
    // 创建超广角pipeline，但不激活stream
    mUltraWidePipeline = createPipeline(CAMERA_ID_ULTRAWIDE);
    mUltraWidePipeline->configureStreams(mPreviewStreamConfig); // 复用相同配置
    mUltraWidePipeline->deactivateStreams(); // 先停掉
}

void CameraHAL::switchToUltraWide() {
    // 提前100ms给超广角Sensor发stream on
    mUltraWidePipeline->sensorStreamOn();
    usleep(100000);
    
    // 停掉主摄stream
    mMainPipeline->deactivateStreams();
    
    // 激活超广角stream
    mUltraWidePipeline->activateStreams();
    
    // 切换完成
}

注意：双pipeline预创建会额外占用内存。每个pipeline大约需要50MB的buffer内存。如果同时创建3个pipeline（主摄、超广角、长焦），内存占用会到150MB。我建议只预创建用户最常用的两个摄像头组合，比如主摄+超广角。

优化结果：切换延迟从800ms降到150ms，用户几乎感觉不到黑屏。这个优化方案后来被用到了该折叠屏的整个产品线。

知识体系总结

好了，四个案例讲完了。我画了一张图，把核心逻辑串起来，方便你理解。

这张图把四个案例的核心维度、优化目标、具体手段、以及常用分析工具都串起来了。你想想看，其实每个优化手段背后，都是在跟“等待”和“冗余”做斗争。启动优化是减少初始化等待，预览优化是减少CPU等待，功耗优化是减少ISP冗余计算，切换优化是减少pipeline重建等待。

嗯，今天就到这里。这些案例都是真实项目里打磨出来的，希望能帮你少走弯路。如果你在实际项目中遇到类似问题，欢迎随时交流。

📚 课程目录

案例实战：四大场景下的Camera性能优化

1. 旗舰机型：Camera启动优化实战

2. 中端机型：预览卡顿优化实战

3. 平板设备：视频录制功耗优化实战

4. 折叠屏：多摄切换延迟优化实战

知识体系总结