AHardwareBuffer 零拷贝管线：为什么少搬一次大图像就可能少卡一次
视频和图像处理里，数据很大。1080p 一帧 YUV 数据可能几 MB，60fps 下每秒就是大量内存搬运。CPU 不一定输在计算，可能输在搬数据。
零拷贝的目标很朴素：能不复制就不复制。
什么是拷贝成本
假设一帧图像从解码器出来后，要经过三步。
decoder buffer -> CPU 内存
CPU 内存 -> GPU 纹理
GPU 纹理 -> 显示
每搬一次，都可能带来：
CPU 时间
内存带宽
缓存污染
延迟增加
功耗上升
零拷贝不是完全没有成本，而是让多个组件共享同一块合适的 buffer，减少中间搬运。
AHardwareBuffer 是什么
AHardwareBuffer 是 Android NDK 暴露的硬件缓冲区对象。官方文档说明，它可以和 Java 侧 android.hardware.HardwareBuffer 互转，并可通过 Binder 在组件之间传递。
你可以把它理解成一块系统认可的图像/数据缓冲区，能被图形、媒体、计算组件共享。
什么时候需要它
普通播放器直接把 AMediaCodec 输出到 Surface，已经是低拷贝路径。你不一定需要自己管理 AHardwareBuffer。
它更适合这些场景。
视频帧需要进入 GPU 后处理
相机帧要被 native、OpenGL/Vulkan、Java 多方共享
跨进程传递图像数据
AI 推理前处理要减少 CPU 拷贝
初学阶段不要一上来用它。先把 Surface 解码渲染跑稳，再进入零拷贝管线。
基本生命周期
AHardwareBuffer_Desc desc = {};
desc.width = width;
desc.height = height;
desc.layers = 1;
desc.format = AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM;
desc.usage = AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE |
AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT;
AHardwareBuffer* buffer = nullptr;
int result = AHardwareBuffer_allocate(&desc, &buffer);
if (result != 0 || buffer == nullptr) {
return;
}
AHardwareBuffer_release(buffer);
注意：allocate 后必须 release。如果多个组件持有，要用 AHardwareBuffer_acquire 增加引用。
usage 很重要
usage 描述这块 buffer 准备用来做什么。
GPU sampled image：作为纹理采样
GPU color output：作为渲染输出
CPU read/write：CPU 读写
usage 选错，后续组件可能无法绑定，或者触发额外拷贝。
零拷贝的代价
零拷贝更复杂。
生命周期更难管理
同步更难处理
格式兼容性要检查
GPU/CPU 访问需要 fence 或同步机制
不同 Android 版本和设备能力差异更明显
所以它不是普通优化第一步。第一步永远是 simpleperf 和数据链路图。
播放器后处理示例
普通路径：
AMediaCodec -> Surface -> 显示
后处理路径：
AMediaCodec -> SurfaceTexture / GPU texture
GPU shader 处理
输出到显示 Surface
如果后处理链需要在 native 和 GPU 之间共享 buffer，才考虑 AHardwareBuffer 或相关图形 API 互操作。
本章实验
先不要直接改播放器。做一个独立实验。
分配 AHardwareBuffer
确认 desc 与实际 buffer 信息
acquire/release 成对出现
记录分配失败原因
再评估是否接入图形链路。
接入前帧延迟
接入后帧延迟
内存占用
CPU memcpy 占比
设备兼容性
小白常见误解
第一，零拷贝不是“没有内存”。它只是尽量避免在 CPU 和 GPU、组件和组件之间重复搬运。
第二，零拷贝不一定更简单。它通常更难调试，因为生命周期和同步更复杂。
第三，播放器输出到 Surface 已经是低拷贝路径。普通播放不需要一上来手写 AHardwareBuffer。
第四，AHardwareBuffer 不是万能图像容器。format、usage、设备能力不匹配时，它可能无法被目标组件使用。
工程风险与观测
零拷贝管线要把“少拷贝”和“可回滚”同时设计进去。
建议保留两条路径。
基础路径：codec -> Surface
增强路径：AHardwareBuffer / GPU 后处理
运行时根据设备能力选择。
zero_copy_available=true path=enhanced
zero_copy_available=false path=surface_fallback
关键观测项：
buffer_allocate_count
buffer_release_count
gpu_wait_ms
cpu_memcpy_percent
frame_latency_p95
fallback_count
如果增强路径延迟更高，就应该降级。零拷贝是性能手段，不是架构信仰。
发布风险：
buffer acquire/release 不成对
跨线程访问缺少同步
某些设备 usage 不支持
GPU 后处理失败但没有 fallback
这些问题都应该在独立实验里先暴露，再接入播放器主链路。
本章结论
AHardwareBuffer 适合跨组件共享大块图像数据，目标是减少昂贵的内存搬运。它不是播放器入门必需品，但当 simpleperf 证明瓶颈在拷贝和图像管线时，它就是进入更底层优化的重要工具。