《第12章相机与多媒体框架》一直是移动端进阶里绕不开的一块硬骨头。很多人平时写界面、接接口、做状态管理都没问题一到相机和多媒体就发怵因为这套东西不像业务代码那样“输入输出明确”它要和硬件传感器打交道要和系统底层的内存池、Buffer、编解码器打交道时序稍微不对黑屏、花屏、卡顿就全冒出来了。我当年啃这一章的时候也踩了无数坑所以这篇就按实际学习的路径把这章里的核心概念、常见场景、实操要点和排查思路一次讲透争取让看完的人再遇到相机和视频需求时心里有底。这篇内容适合两类人一类是已经在项目里写过一段时间应用层代码、准备往系统能力和多媒体方向深入的开发者另一类是被产品丢来一个“拍照、录像、剪辑、播放”需求、不得不硬着头皮上的全栈型选手。前者能从这里梳理出完整的知识框架后者能直接找到可落地的方案和排查套路。1. 整体设计思路这一章为什么难1.1 难在知识跨度大相机与多媒体框架并不是“一个库”或者“一个API”的事它是一条完整的数据流水线摄像头物理传感器产生图像信号经过驱动层、HAL硬件抽象层、框架层最后变成应用层能拿到的图像帧或编码后的视频流播放和编辑方向则反过来从文件里解封装、解码、渲染或者把数据编码、封装、写文件。任何一个环节出问题暴露出来的症状都很隐蔽。我在实际学习时把这条链路拆成了三个层面第一层是“相机采集”解决怎么拿到画面第二层是“编解码与封装”解决怎么处理这些画面第三层是“渲染与同步”解决画面怎么以正确的时序展示出来。第12章的内容基本就是围绕这三个层面展开的。如果你能先建立“数据在链路上流动”的画面感再去看具体的类和方法会轻松很多。1.2 需要提前补齐的基础知识在完整展开这一章之前有几个前置概念最好先过一遍不然后面很容易卡住。Surface 和 SurfaceTexture前者是消费图像数据的目标后者是生产侧的纹理接口。它们之间靠 BufferQueue 连接本质上是一种“生产-消费”模型。Buffer 与 BufferPool图像数据非常吃内存一帧 1080p 的数据量大约是 1920×1080×4 字节接近 8MB。如果不做缓冲区复用高帧率下内存会瞬间爆掉。线程模型Camera 的回调、编码器的回调、渲染线程不是同一条线程必须理清谁在负责什么避免在主线程里做耗时操作。OpenGL ES 纹理很多多媒体场景滤镜、特效、转码最终都会走上 GPU 处理至少要知道纹理图像是怎么映射的。这一章的定位其实就是把上面这些知识串成一条可运行、可调试的通路。带着这个目标去读源码和官方文档就不容易迷失在大量抽象类里。2. 相机框架核心链路拆解2.1 从 Camera2 到 CameraX 的演进取舍早期开发相机应用最常用的是 Camera API但它的设计比较简单很多控制能力都不开放后来被 Camera2 全面取代。Camera2 的核心对象包括CameraManager 负责发现和管理摄像头设备CameraDevice 代表一个打开的摄像头CameraCaptureSession 是采集会话CaptureRequest 是每一次采集任务的描述。这里要明白一个关键设计哲学Camera2 把相机当成一个“可编程的流水线”。你要先指定草稿模板TEMPLATE_PREVIEW、TEMPLATE_STILL_CAPTURE 等再往请求里塞各种参数比如曝光、对焦、白平衡然后把请求交给会话系统按顺序执行。这种设计的优点是灵活性极高坏处是开发成本也极高一个正常的预览流程要写一长串回调嵌套稍不留神就出问题。所以后来出现了 CameraX它对 Camera2 做了一层更贴近应用场景的封装按用例来组织比如“预览”、“拍照”、“录像”。在引入生命周期感知后很多资源管理都能自动处理代码量少了很多。根据我个人的实践经验如果项目对相机功能的定制化要求不高CameraX 是更稳妥的起点如果要做专业级的取景、多摄、深度定制再回头深入 Camera2。2.2 预览与拍照的完整流程以 Camera2 为例启动预览的基本路径是这样的通过 CameraManager.openCamera 打开指定摄像头回调里拿到 CameraDevice。从 CameraDevice 创建 CameraCaptureSession为它配置用于承载预览画面的 Surface。构建一个 TEMPLATE_PREVIEW 的 CaptureRequest并把预览 Surface 添加到请求的目标中。调用 session.setRepeatingRequest 让采集持续进行。拍照时另建一个 TEMPLATE_STILL_CAPTURE 请求设置响应的回调在 onCaptureCompleted 里读取 JPEG 结果。这里面经常被忽略的点是预览 Surface 不能随便创建。Camera 要的是支持生产者缓冲区的 Surface 类型通常通过 SurfaceTexture 或直接从 TextureView 拿到 SurfaceHolder 来对接。如果你传了一个不匹配的图像格式系统会直接报错或者预览画面黑屏。所以流程上建议先确认 StreamConfigurationMap 里支持的输出格式和分辨率再决定 Surface 的规格。2.3 预览画面背后的 Buffer 机制很多人写完预览觉得“终于能出画面了”但并不知道画面是怎么从摄像头走到屏幕上的。其实 Camera 硬件采集到的原始数据会交给系统图像管线处理原始 YUV 数据经过转换后放入 BufferQueue 中应用侧持有消费端 Surface一旦有新帧回调就触发帧数据通过 GPU 渲染到屏幕。这里我要特别提醒一点如果预览画面要被编码器消费比如录像千万不要把每一帧都转成 Bitmap 再交给编码器那样性能会非常差。正确的做法是把编码器的输入 Surface 直接作为 Camera 预览的输出目标让系统在底层完成 YUV 到编码器输入的搬运整个链路几乎不走 CPU。这也是为什么 CameraX 的 VideoCapture 和 Camera2 的持久录制都推荐“Surface 对 Surface”的原因。3. 多媒体框架骨架MediaCodec、MediaExtractor 与 MediaMuxer3.1 MediaCodec 的状态机与输入输出模型多媒体这一部分核心就是 MediaCodec。它分为编码器和解码器两个方向是系统对底层软硬件编解码能力的统一抽象。很多人第一次接触时会被它的状态机吓到其实总结下来就是几个阶段未初始化、配置、运行、结束、释放。在配置阶段你需要指定编码格式比如 H.264、AAC并给出输入输出格式在运行阶段你需要不断从输入缓冲区塞数据再不断从输出缓冲区拿数据。录入数据时代码在拿到输入缓冲区的 index 之后要把 ByteBuffer 的 position 和 limit 设置好再写好 BufferInfo 里的 flags 和 pts时间戳。这里最容易被坑的是时间戳。有些刚上手的朋友写编码时 pts 全填 0结果出来的视频播放进度是错的甚至画面卡住。我的建议是用 System.nanoTime() 的增量做一个基准或者直接利用帧率自增保证 pts 单调递增且与真实时间速率一致。3.2 解封装与封装的活MediaExtractor 和 MediaMuxer视频文件本身是一个封装容器里面有多条轨道视频、音频、字幕。MediaExtractor 的作用就是从文件里把数据分离出来MediaMuxer 则负责把编码后的数据写回容器。用 MediaExtractor 的路径很直接设置数据源、读取 track 格式、选择需要处理的轨道、循环调用 readSampleData 读取样本、处理完再 advance 到下一帧。用 MediaMuxer 就要注意addTrack 之后要先 start然后按轨道的 bufferInfo 逐块写入最后 stop 再释放。如果音频和视频轨道的时间戳不连续最后封装出来的文件会非常难用。实际操作中我见过一个常见的错误是修改视频画面后没有保留原音频轨的 pts 换算关系最后音画明显不同步。最稳妥的做法是解封装时把每条轨道的时间基准记录下来编码处理时严格按照同一个单调时钟源给新帧打时间戳封装时再按原时间基准换算。3.3 Surface 输入模式与高效渲染链路MediaCodec 有一种高效的输入模式就是直接传入一个 Surface。对于解码器你可以通过 createInputSurface 创建一个输入 Surface把解封装出来的视频帧直接丢给它其他来源的图像比如相机采集的画面也可以直接发布到这个 Surface 上交由硬件编码器处理。这种模式最典型的使用场景是“相机实时录像”和“视频转码”。在不走 Surface 的模式下每一帧都要经过 “ByteBuffer 拷贝 → 应用层处理 → 再拷贝回编码器”的路径CPU 和内存开销非常大用 Surface 模式后数据在系统内以 GPU buffer 的形式流转少了好几层拷贝。我在做视频转码时实测Surface 模式比普通 ByteBuffer 模式快了大约一倍内存占用也明显下降原理就是减少了数据搬运。不过 Surface 模式也有代价你无法直接拿到编码前的像素内容想要加滤镜或者做裁剪就必须在 OpenGL 处理之后再把纹理发布到输入 Surface 上。这属于进阶用法需要一些着色器基础。4. 从传统走向现代CameraX 与 Media3 的组合4.1 CameraX 的用例抽象与生命周期绑定CameraX 最大的价值是把“打开摄像头、配置会话、处理各种回调”这些样板代码全部收进了库内部。它提供了三个核心用例Preview、ImageCapture、VideoCapture。Preview把相机画面输出到 PreviewView 上内部处理了 Surface 生命周期。ImageCapture提供拍照能力可以指定目标旋转方向和格式。VideoCapture录制视频通常与 Media3 配合使用。使用 CameraX 之后你只需要用 ProcessCameraProvider 绑定一个 LifecycleOwner然后 bindToLifecycle 绑定用例组合摄像头资源就会在页面可见时自动打开、不可见时自动释放。我在项目里从 Camera2 迁移到 CameraX 后生命周期导致的开相机失败、释放不及时类问题几乎不再出现。4.2 Media3 对播放能力的统一以前大家处理播放习惯绕不开 ExoPlayer但它和系统框架整合得并不紧密。Media3 把播放、解码、音效、转码等能力拆成了多个模块对外提供了更统一的 Player 接口而且在 CameraX 的 VideoCapture 里也有对应整合。用 Media3 做播放的核心步骤非常简洁创建一个 Player 实例setMediaItem 指定要播放的内容prepare然后播放。如果你只是做本地视频播放这几乎就是全部。但要注意Media3 并不是只在 API 上做减法它在渲染一致性、音画同步、HDR 兼容上下了很多功夫。默认的 MediaCodecRenderer 能够处理大多数格式但遇到特殊编码格式还是需要你手动配置选择器。4.3 新旧方案怎么选才不亏从我个人的经验看选型应该优先考虑团队维护成本和产品需求而不是追逐新的库。只是预览、拍照、简单录像直接用 CameraX。需要实时美颜、滤镜、人像分割肯定绕不开 Camera2 OpenGL ES或者基于 SurfaceTexture 做自定义管线。播放需求为主直接上 Media3如果还要做视频编辑可以考虑它的 Transformer 模块但复杂编辑仍然需要自己搭时间线结构。整个多媒体链路要高度可控比如直播推流那么 MediaCodec 底层和 Surface 模型必须吃透这一章讲的基础在任何场景下都不会过时。5. 实操高频问题与排查思路5.1 相机黑屏先分级排查黑屏是相机开发中最常见、也最让人头疼的问题。我一般按这个顺序查权限是否授予。CAMERA 权限缺失时openCamera 直接抛异常。Surface 是否有效。TextureView 的 SurfaceTexture 在生命周期里可能已被清理需要在 SurfaceTextureListener 里等待就绪再创建会话。分辨率是否匹配。通过 StreamConfigurationMap 确认当前设备是否支持你选择的预览尺寸不支持会导致会话失败。摄像头是否被其他应用或组件占用。有些设备同时只能有一个前台摄像头会话某些 ROM 还会额外限制。建议在 onCaptureSessionConfigured 和 onSessionReady 回调里打上日志把初始化流程的每一步都记录下来黑屏时要能定位到具体是在哪一步断的。5.2 拍照方向旋转与镜像问题拍照得到的 JPEG 会有方向信息但部分设备不会自动帮你旋转导致照片在相册里横着或镜像。这里有两层问题设备传感器方向摄像头传感器的安装方向与屏幕方向不一致需要通过 CameraCharacteristics.SENSOR_ORIENTATION 获取角度再结合当前屏幕旋转角度换算最终计算出正确的旋转值。输出 EXIF 信息用 ImageCapture 拍照时可以指定 TargetRotation但在 Camera2 里保存 JPEG 前建议手动写入 ExifInterface.TAG_ORIENTATION。如果相机是前置摄像头还要判断是否需要镜像不然拍出来的自拍方向是反的。实际项目中我遇到过一个问题部分机型在竖屏时预览正常但保存出来的 JPEG 总是逆时针偏了 90 度。后来确认是某些系统的 Camera 设备返回的 SENSOR_ORIENTATION 并不是实际安装角度而是已经做过屏幕方向补偿的值。所以最终判断要以输出图像的实际像素排列为准不能只看文档参数。5.3 音画不同步与时间戳错乱音画不同步是播放、录制、转码场景下最容易被怀疑“编码器垃圾”的问题但根因多半出在时间戳上。录制时音频和视频轨道的时间戳必须基于同一个时钟源。转码时解码端的 pts 是参考原容器的不能直接拿来当输出编码的 pts需要按时间基准重新映射。视频帧和音频帧的间隔本身就不同视频可能是 33ms 一帧音频可能是 23ms 一块封装时需保证各自的 bufferInfo.presentationTimeUs 单调递增但不要求每一帧间隔绝对均匀。我在调试一个视频合成需求时曾发现视频画面播着播着就“跳”一下排查了半天发现是中间插入滤镜步骤时每帧经过 GPU 处理耗时不同部分帧的 pts 没有同步增加。修正方案是进入编码循环时统一基于对应原帧的 pts过滤掉重复帧并控制写帧节奏跳帧现象才消失。5.4 内存与性能优化的小技巧多媒体处理是内存大户优化空间基本集中在“减少不必要的拷贝”和“限制分配频率”。能复用 Buffer 就不新建尤其是 YUV 数据。ByteBuffer 复用后速度提升非常明显。不要把每帧转成 Bitmap 做处理。转 Bitmap 本身是一次全尺寸内存拷贝大分辨率下非常昂贵。用 Surface 模式对接编码器避免内存回读。选择合适的帧率和分辨率不要盲目上 4K。如果只是录制屏幕720p 足够。下采样时尽量用硬件能力比如 Camera2 的 ImageReader 可以选择更小的输出尺寸而不是拍完再压缩。6. 我的学习顺序与一些个人习惯很多人在第12章卡住是因为想一口吃成胖子直接上手做滤镜相机结果被一堆回调、Buffer 和状态机淹没。我的建议是分四步走用 CameraX 完成一个可用的预览、拍照、录像 Demo先把链路跑通。切换到 Camera2 做同样的事理解每一步背后的 session、request、surface。用 MediaCodec 做一次视频转码输入一个视频输出分辨率降低一半的另一个视频重点理解 Buffer 和 pts。最后再尝试把相机预览直接送进编码器做一个实时录制就完成了采集、编码、封装的闭环。最后分享一个我个人的习惯入门阶段一定要画一份属于自己的“数据流图”把采集、处理、编码、封装、播放每一步的关键类标出来并标注它们是工作在哪个线程。遇到问题先看数据流在哪一环断掉了不要上来就改代码。这条经验让我在后来做很多复杂需求时省下了大量时间希望你也能用得上。