9、内存与DDR功耗优化：内存带宽监控、Buffer复用策略、ION内存分配器调优、内存压缩与回收
说到Android相机性能，大家第一反应往往是CPU负载、GPU渲染、或者ISP处理流水线。但说实话，内存和DDR功耗才是那个容易被忽略的“隐形杀手”。
我做过一个项目，相机预览帧率明明达标，但手机发热严重，电池掉电飞快。查了半天，发现是DDR带宽被吃满了，内存频繁地在不同模块间搬运数据。你想想看，每一帧图像数据从Sensor到ISP，再到GPU显示，最后编码存储，这中间要经过多少次内存读写？每一次读写，都在消耗DDR的带宽和功耗。
所以这一章，我们来聊聊怎么把内存这块的功耗降下来。核心思路就四个字：少搬、快放、巧分配。
9.1 内存带宽监控：先找到“吃带宽”的元凶
优化之前，你得先知道谁在吃带宽。我个人习惯用perf或者simpleperf来抓DDR的读写事件。在Android平台上，还可以通过/sys/class/devfreq/下的接口查看DDR频率和带宽使用情况。
核心监控指标：
- DDR带宽利用率：超过70%就要警惕了，容易引发CPU/GPU等待内存访问。
- 内存延迟：延迟飙升往往意味着带宽瓶颈。
- Cache Miss率：L2/L3 Cache Miss率高，说明数据局部性差，大量请求直接打到DDR。
我曾经在一个项目中，发现相机预览时DDR带宽利用率高达85%。用trace一抓，发现是YUV数据在CPU和GPU之间来回拷贝导致的。说白了，就是数据没走对路径。
# 查看DDR当前频率和带宽（需要root）
cat /sys/class/devfreq/soc:qcom,cpubw/cur_freq
cat /sys/class/devfreq/soc:qcom,cpubw/load
# 使用perf统计内存访问事件
perf stat -e arm_ddr0:cycles,arm_ddr0:read,arm_ddr0:write -a -- sleep 5小技巧：在调试阶段，可以打开dumpsys meminfo和proc/meminfo，观察Native Heap和Graphic Buffer的占用变化。如果发现某个Buffer在多个进程间反复映射，那大概率就是优化点。
9.2 Buffer复用策略：别让数据“白跑一趟”
相机Pipeline里，Buffer复用是最直接有效的优化手段。你想想看，每一帧图像从Sensor出来，经过ISP处理，再到显示和编码，如果每个环节都重新分配Buffer，那DDR带宽会爆炸。
核心原则：能复用就不新建，能共享就不拷贝。
我建议在Camera HAL层实现一个Buffer Pool。比如，预览流和拍照流如果分辨率相同，完全可以共用同一块Buffer。或者，把YUV数据直接送到编码器，而不是先拷贝到应用层再送下去。
常见的Buffer复用场景：
- 预览与拍照复用：预览帧直接用于拍照，避免额外分配。
- GPU与编码器共享：使用
EGL_EXT_image_dma_buf_import扩展，让GPU和编码器直接操作同一块DMA-BUF。 - ZSL（零快门延迟）：环形Buffer池，循环写入和读取，减少分配和释放的开销。
// 伪代码：Buffer Pool 复用逻辑
class CameraBufferPool {
std::vector<sp<GraphicBuffer>> mBuffers;
int mCurrentIndex = 0;
sp<GraphicBuffer> acquireBuffer() {
sp<GraphicBuffer> buffer = mBuffers[mCurrentIndex];
mCurrentIndex = (mCurrentIndex + 1) % mBuffers.size();
return buffer;
}
void releaseBuffer(const sp<GraphicBuffer>& buffer) {
// 不真正释放，只是标记为可用
}
};注意：Buffer复用要小心数据竞争。比如，GPU正在渲染上一帧，编码器却开始读同一块Buffer，就会出现花屏。我建议用Fence机制来同步，或者用双缓冲/三缓冲来规避。
9.3 ION内存分配器调优：别让分配成为瓶颈
ION是Android平台上管理DMA-BUF的核心分配器。相机应用里，大量GraphicBuffer和MediaBuffer都通过ION分配。如果ION配置不当，分配和释放的开销会非常可观。
我记得有一次，相机启动时卡顿严重，抓trace发现ion_alloc耗时超过50ms。查下来，是ION的Heap配置不合理，导致频繁触发内存碎片整理。
调优要点：
- 选择合适的Heap：相机Buffer建议使用
ION_HEAP_TYPE_SYSTEM_CONTIG或ION_HEAP_TYPE_DMA，避免使用ION_HEAP_TYPE_SYSTEM（非连续，影响DMA效率）。 - 预分配大块内存：在相机启动时，一次性从ION申请一大块连续内存，然后自己管理子分配。这样可以减少ION的分配次数。
- 调整ION的缓存策略：对于频繁读写的Buffer，设置
ION_FLAG_CACHED；对于只写不读的Buffer（如编码器输入），设置ION_FLAG_CACHED_NEEDS_SYNC，减少Cache刷写开销。
// ION分配示例（简化）
struct ion_allocation_data alloc_data;
alloc_data.len = buffer_size;
alloc_data.heap_id_mask = 1 << ION_HEAP_TYPE_SYSTEM_CONTIG;
alloc_data.flags = ION_FLAG_CACHED;
int ret = ioctl(ion_fd, ION_IOC_ALLOC, &alloc_data);
if (ret < 0) {
// 分配失败，尝试其他Heap
alloc_data.heap_id_mask = 1 << ION_HEAP_TYPE_DMA;
ret = ioctl(ion_fd, ION_IOC_ALLOC, &alloc_data);
}避坑指南：我曾经遇到过ION分配失败导致相机闪退的问题。原因是系统内存碎片化严重，连续内存不足。解决方案是：在相机启动前，先通过echo 3 > /proc/sys/vm/drop_caches清理Page Cache，或者使用ION_HEAP_TYPE_SYSTEM配合SMMU（IOMMU）来使用非连续内存。
9.4 内存压缩与回收：让DDR喘口气
当系统内存紧张时，Android会启动kswapd和LMK（Low Memory Killer）来回收内存。但相机场景下，我们不希望系统频繁触发这些机制，因为回收和压缩本身也会消耗CPU和DDR带宽。
优化思路：
- 主动压缩：在相机空闲时（比如预览稳定后），主动调用
madvise(MADV_PAGEOUT)将不活跃的Buffer换出到ZRAM。ZRAM是压缩后的内存，读写速度比真正的Swap快得多。 - 控制回收阈值：通过
/proc/sys/vm/watermark_scale_factor调整内存水位线，让系统在内存还比较充裕时就开始温和回收，避免突然的“内存风暴”。 - 避免不必要的内存锁定：有些开发者喜欢用
mlockall()锁定所有内存，防止被换出。但相机场景下，只有关键Buffer（如Sensor输出Buffer）需要锁定，其他Buffer可以允许回收。
// 主动压缩不活跃Buffer
void compress_inactive_buffers(void* addr, size_t len) {
// 告诉内核：这个内存区域可以优先换出
madvise(addr, len, MADV_PAGEOUT);
}
// 调整内存水位线（需要root）
echo 50 > /proc/sys/vm/watermark_scale_factor // 默认10，增大后回收更积极核心结论：
内存与DDR功耗优化，不是单纯地“省内存”，而是让内存访问更高效。减少不必要的拷贝、复用Buffer、合理配置ION、主动管理内存压缩，这四步走下来，DDR带宽通常能降低30%-50%，功耗下降明显。
嗯，这一章的内容就到这里。下一章我们会聊聊更底层的帧率控制与VSync同步，那是保证流畅度的关键。不过那是后话了，先把今天的内存优化落地到你的项目里试试看。