第1章 HAL内存管理概述

1、HAL内存管理概述：为什么内存管理是Camera性能的关键

各位做Camera的朋友，咱们开门见山。内存管理这事儿，说大不大，说小不小。但你要是没处理好，它能让你的预览卡成PPT，让录像掉帧掉到怀疑人生。我这些年调过的Camera HAL，十有八九的性能问题，根因都能追溯到内存上。

你想想看，Camera这条Pipeline有多长？从Sensor拿到RAW数据，经过ISP处理，再到算法模块，最后送给Display或Encoder。每一帧数据都在内存里流转。哪个环节出了岔子，整条链路的性能就崩了。

说白了，Camera是实时系统。每一帧都有严格的deadline。比如30fps的预览，留给你的时间只有33ms。内存分配慢了，或者分配不到，帧就丢了。

我遇到过最典型的场景：某个项目在低内存压力下跑得挺好，一开微信视频通话，后台再挂几个App，预览就开始一卡一卡的。查了半天，发现是HAL层在每一帧都做内存分配，系统内存紧张时分配耗时暴涨，直接拖垮了帧率。

核心观点：Camera性能的瓶颈，往往不在算力，而在内存。算力不够可以降分辨率，内存管理不好，系统直接罢工。

还有一点容易被忽略——功耗。频繁的内存分配和释放，会让CPU和DDR频繁唤醒，功耗蹭蹭往上涨。做手机的朋友应该深有体会，相机发热很多时候不是ISP在发热，是内存控制器在加班。

咱们先捋一捋HAL层的内存模型。嗯，这里要注意，不同平台（高通、MTK、展锐）的细节有差异，但大框架是相通的。

HAL层主要管理这几类内存：

我习惯把HAL层的内存模型画成三层：

你看，每一层的内存特性都不一样。应用层接口用的是GraphicBuffer，走ION分配器，特点是支持跨进程共享。HAL内部我建议用私有Buffer池，提前分配好，运行时只做引用计数，不做分配释放。硬件驱动那层最麻烦，需要连续物理内存，系统内存碎片化严重时，分配很容易失败。

个人经验：我在做某个8K录像项目时，发现硬件驱动层分配连续内存经常失败。后来改成在开机时预留一块大内存，用CMA管理，问题就解决了。说白了，连续内存这种稀缺资源，能提前占就提前占。

做Camera HAL这么多年，我总结下来，内存问题就三大类。咱们一个一个说。

这个最要命。泄漏了不会立刻崩，但跑个几小时，系统内存被吃光，Camera服务就被杀了。

我见过最经典的泄漏场景：每一帧都new一个buffer，处理完忘了delete。或者引用计数没处理好，buffer永远回不到池子里。

怎么排查？我个人的习惯是：

避坑指南：我曾经在一个项目里，泄漏问题查了三天。最后发现是某个算法模块在异常分支里没有释放临时buffer。从那以后，我要求所有buffer分配必须用RAII思想，构造函数分配，析构函数释放，杜绝手动管理。

碎片化是个隐形杀手。系统总内存还有不少，但就是分配不到一块连续的大内存。尤其是硬件驱动层需要连续物理内存时，碎片化问题特别突出。

为什么会这样？你想想看，系统跑久了，各种大小的内存块被分配又释放，内存就像被啃过的奶酪，到处是洞。这时候你要一块8MB的连续内存，系统翻遍整个内存空间都找不到。

我建议的做法：

抖动这个问题，说白了就是频繁分配和释放。它不一定会导致OOM，但会让性能变得很不稳定。

我遇到过最典型的抖动场景：某个降噪算法每帧都要分配一个临时buffer，处理完就释放。看起来没问题对吧？但问题是，这个buffer大小刚好落在系统内存分配器的某个临界点上，导致每次分配都要去合并相邻的空闲块，耗时从几十微秒暴涨到几毫秒。

结果就是帧率忽高忽低，有时候33ms能处理完，有时候要50ms，直接丢帧。

怎么解决？

个人建议：我现在的做法是，在HAL初始化阶段就把所有可能用到的buffer都分配好。运行时只做引用计数和状态切换，不做任何内存分配。这样虽然初始化慢一点，但运行时性能非常稳定，不会有任何抖动。

嗯，总结一下。内存管理是Camera HAL的基石。泄漏、碎片、抖动，这三个问题你搞定了，Camera性能至少能提升30%。下一章我会详细讲Buffer池的设计和实现，那是解决这些问题的核心手段。