CPU/GPU负载优化：多线程架构设计与性能调优

各位同学好，今天我们来聊聊摄像头性能优化里最硬核的一块——CPU和GPU的负载管理。说实话，我做了这么多年Camera HAL，见过太多项目因为负载没控制好，导致预览卡顿、拍照延迟、甚至手机发热到烫手。嗯，今天就把我这些年踩过的坑和总结的经验，一次性讲清楚。

一、多线程架构设计：Producer-Consumer模型

先聊聊多线程。很多新手工程师喜欢把所有事情都塞到一个线程里，觉得这样简单。但你想啊，摄像头数据流是流水线式的——Sensor出帧、ISP处理、算法运算、编码、显示，每个环节的耗时都不一样。如果串行执行，最慢的那个环节就会拖死整条流水线。

我个人习惯用Producer-Consumer模型来解耦。说白了，就是让生产数据的线程和消费数据的线程各干各的，中间用队列缓冲。

// 一个简化的Producer-Consumer框架
class CameraPipeline {
    std::queue<FrameBuffer> bufferQueue_;
    std::mutex mutex_;
    std::condition_variable cv_;
    
    // Producer：Sensor线程
    void OnFrameAvailable(FrameBuffer& frame) {
        std::lock_guard<std::mutex> lock(mutex_);
        bufferQueue_.push(frame);
        cv_.notify_one();  // 通知消费者
    }
    
    // Consumer：算法处理线程
    void ProcessLoop() {
        while (running_) {
            std::unique_lock<std::mutex> lock(mutex_);
            cv_.wait(lock, [this]{ return !bufferQueue_.empty(); });
            auto frame = bufferQueue_.front();
            bufferQueue_.pop();
            lock.unlock();
            
            // 做算法处理
            ProcessFrame(frame);
        }
    }
};

这里有个关键点：队列长度要控制好。我在项目中遇到过，队列太长会导致延迟飙升，太短又容易丢帧。一般建议根据帧率和处理耗时来算，比如30fps的预览，队列深度设3-5帧比较合理。

二、CPU频率调度与温控

CPU频率调度，说白了就是让CPU在「够用」和「省电」之间找到平衡。很多厂商直接上最高频率，结果手机烫得能煎鸡蛋。

我建议的做法是：根据当前负载动态调整。比如预览阶段，CPU负载不高，用中等频率就够了；到了拍照瞬间，需要快速处理，可以临时拉高频率；处理完再降回来。

场景	CPU频率策略	说明
预览（30fps）	1.2-1.5GHz	够用就行，省电优先
拍照（单帧）	2.0-2.4GHz	短时爆发，快速处理
录像（4K 60fps）	1.8-2.0GHz	持续高负载，注意温控
HDR+多帧合成	2.2-2.8GHz	计算密集型，可短时冲高

温控这块，我吃过不少亏。有一次项目在夏天测试，手机温度一上来，CPU直接降频到800MHz，预览帧率掉到15fps，用户直接投诉。后来我们加了三层防护：

• 主动降频：温度超过45°C时，主动降低帧率到24fps
• 任务迁移：把重计算任务从大核迁移到中核，避免局部过热
• 帧率平滑：不要突然降帧，而是逐步降低，让用户无感

三、GPU渲染优化

GPU优化，说白了就是减少GPU的工作量。我见过最夸张的案例，一个预览界面Overdraw达到了5层——底层是Camera预览，上面叠了半透明遮罩、水印、对焦框、触摸反馈，每一层都要渲染。

3.1 Overdraw优化

Overdraw就是同一像素被多次绘制。在Camera预览里，最常见的Overdraw来源是：

• 半透明遮罩层（比如取景框外的暗角效果）
• 水印和UI叠加
• 对焦动画的残影

我的优化思路是：能用GPU合成，就别让CPU参与。比如用SurfaceView代替TextureView，因为SurfaceView有独立的合成层，不会和UI混在一起渲染。

// 推荐：使用SurfaceView减少Overdraw
<SurfaceView
    android:id="@+id/preview"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

// 不推荐：TextureView会参与UI渲染树
<TextureView
    android:id="@+id/preview"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

3.2 Shader复杂度控制

Shader复杂度直接影响GPU的吞吐量。我记得有个项目，美颜算法里用了一个100多行的Fragment Shader，里面还有循环和分支，结果在低端GPU上直接跑不动。

我建议遵循几个原则：

• Shader指令数控制在50条以内
• 避免动态分支（if-else在GPU里很慢）
• 能用纹理查找表（LUT）就别实时计算
• 减少纹理采样次数，能合并就合并

四、NEON指令集加速

NEON是ARM平台的SIMD指令集，说白了就是一条指令同时处理多个数据。在图像处理里，这玩意儿简直是神器。

举个例子，YUV转RGB这个操作，用C语言写循环要处理每个像素，用NEON可以一次处理8个像素：

// C语言版本：逐像素处理
void yuv_to_rgb_c(uint8_t* y, uint8_t* u, uint8_t* v, uint8_t* rgb, int len) {
    for (int i = 0; i < len; i++) {
        int r = y[i] + 1.402 * (v[i] - 128);
        int g = y[i] - 0.344 * (u[i] - 128) - 0.714 * (v[i] - 128);
        int b = y[i] + 1.772 * (u[i] - 128);
        rgb[i*3] = clamp(r, 0, 255);
        rgb[i*3+1] = clamp(g, 0, 255);
        rgb[i*3+2] = clamp(b, 0, 255);
    }
}

// NEON版本：一次处理8个像素
void yuv_to_rgb_neon(uint8_t* y, uint8_t* u, uint8_t* v, uint8_t* rgb, int len) {
    int i = 0;
    for (; i <= len - 8; i += 8) {
        uint8x8_t y8 = vld1_u8(y + i);
        uint8x8_t u8 = vld1_u8(u + i);
        uint8x8_t v8 = vld1_u8(v + i);
        // ... 使用NEON内联函数并行计算
        vst1q_u8(rgb + i*3, result);
    }
    // 处理剩余像素
    for (; i < len; i++) {
        // 回退到C版本
    }
}

我在项目中实测过，NEON版本比C版本快了4-6倍。但要注意，NEON不是万能的：

• 数据量太小（比如几十个像素）时，函数调用开销反而更大
• 内存对齐很重要，不对齐会触发异常
• 不同ARM架构的NEON指令集有差异，要兼容处理

五、整体架构图

下面这张图是我总结的CPU/GPU负载优化整体架构，你可以看到数据流从Sensor出来，经过多线程流水线，再到GPU渲染，每一步都有对应的优化手段。

好了，以上就是CPU/GPU负载优化的核心内容。多线程架构是骨架，频率调度是肌肉，GPU优化是减负，NEON加速是提速。把这四块做好了，你的摄像头性能基本就稳了。