简介：这份资源面向Android车机与车载影像方向的开发者，聚焦高通平台EVS（Exterior View System）影像系统的HAL层实现，涵盖EVS1.0与EVS2.0两个版本，可用于后视、环视、行车记录及ADAS等车载相机场景的学习与二次开发。压缩包共124个文件，约366KB，以46个h头文件与43个cpp源文件为主体，配合8个mk编译脚本、5个rc启动配置、3个xml与2个json配置，以及license、notice、png等辅助文件，结构紧凑，便于直接编译与裁剪。内容涉及相机枚举、状态控制、配置管理、GL渲染与顶层视图绘制等模块，读者可据此理解HAL如何屏蔽底层硬件差异、通过标准接口调用图像处理能力，并掌握rc文件控制开机自启或分阶段启动的配置思路。目前已有1651人学习下载，适合具备一定Android系统与C++基础、希望深入车载影像链路的中高级开发者参考。
1. 车机影像系统：为什么倒车影像挂 R 挡就能秒出画面
倒车时挂入 R 挡，中控屏几乎在瞬间就亮起车尾画面，这个体验背后其实藏着一个反直觉的结论：车载影像系统并不是“打开相机 App 再预览”那套逻辑。手机上的相机从点击图标到出画，要经过应用启动、权限检查、相机服务绑定、预览流协商，一两秒算快的。但车机不允许这样——法规对倒车影像的响应时间有硬性要求，挂挡到出画通常要在两秒以内，部分场景甚至更短。
所以 Android 车机上的 EVS（Exterior View System）从设计之初就不是普通相机应用，它是绕开常规相机框架、直接对接底层显示与采集链路的一套独立系统。它要解决的核心问题是：在系统还没完全起来、应用还没启动的时候，如何让摄像头画面以最短路径送到屏幕上。搞懂这套机制，你才能理解为什么车机的倒车影像、环视、盲区监测能做到“挂挡即出”，也才能明白为什么直接套用 Camera2 或 CameraX 在车机上会翻车。这份资源围绕的正是这套 EVS 的完整实现，值得从底层链路一层层拆开看。
2. EVS 的架构分层：为什么它要绕开 Camera2
2.1 从应用层到驱动的四层结构
Android 车机的 EVS 在 AOSP 里有一套相对固定的分层，从上到下大致是：应用层（EVS App / 环视应用）、框架层（android.hardware.automotive.evs相关的 HIDL/AIDL 接口）、本地服务层（EvsEnumerator、EvsCamera、EvsDisplay等 native 服务）、以及最底层的 V4L2 驱动和显示驱动。这套结构和普通相机的 CameraService 是平行的两条线，互不干扰。
关键点在于：EVS 的服务是native 服务，不是 Java 层的系统服务。它通过IEvsEnumerator这个接口对外暴露能力，应用拿到的是IEvsCamera和IEvsDisplay的代理。这样做的好处是链路短——从摄像头 buffer 到显示 buffer，中间不经过 SurfaceFlinger 的复杂合成，也不需要应用层做格式转换。常见的实现思路是让 EVS 直接操作 gralloc 分配的图形缓冲区，采集端和显示端共享同一套 buffer 管理机制，从而把延迟压到最低。
2.2 为什么不用 Camera2：延迟与启动时序的硬约束
Camera2 的设计目标是通用性，它要支持预览、拍照、录像、多流并发、3A 控制等一大堆能力，代价是链路长、状态机复杂。一个典型的 Camera2 预览要经过：应用请求 → CameraService → CameraProvider → HAL → 驱动，回来还要经过 buffer 队列和 Surface 合成。这条链路在手机上是可接受的，但在车机倒车场景下，每一环都是延迟。
更致命的是启动时序。倒车影像要求系统在Android 框架还没完全就绪时就能出画。Camera2 依赖 CameraService 起来、依赖应用进程启动，而 EVS 的 native 服务可以更早被 init 拉起，甚至在system_server之前就准备好。这就是为什么 EVS 要独立成一套：它不是“更好的相机”，而是“在特定时序约束下唯一能 work 的相机”。
2.3 数据流的真实路径
把数据流摊开看：摄像头 sensor 出 RAW → ISP 处理成 YUV → V4L2 驱动把帧写入 gralloc buffer → EVS 的EvsCamera拿到 buffer → 通过IEvsCameraStream回调交给消费者 → 消费者（可能是显示模块或算法模块）处理后 →EvsDisplay把 buffer 送到显示控制器。整条路径里，buffer 是零拷贝传递的，EVS 只传句柄不传数据。
// EVS 采集回调的典型形态（简化示意） Return<void> deliverFrame(const BufferDesc& buffer) { // buffer 里是 gralloc 句柄，不是像素数据本身 // memHandle 指向已经由驱动填好的图形缓冲区 if (buffer.memHandle == nullptr) { // 空帧，通常意味着采集异常或超时 return Void(); } // 直接把句柄交给显示端，避免一次内存拷贝 mDisplay->postBuffer(buffer); // 用完必须归还，否则采集端 buffer 池会耗尽 mCamera->doneWithFrame(buffer); return Void(); }这段逻辑里有两个容易忽略的点。第一，doneWithFrame必须调用，否则采集端的 buffer 池很快耗尽，表现为画面卡住或黑屏。第二，postBuffer和doneWithFrame的顺序在某些实现里会影响帧率，因为显示端可能还在读这块 buffer。参数上，BufferDesc里的bufferId、memHandle、stride、pixelSize都要和显示端对齐，格式不匹配会直接花屏。
3. 采集与显示链路：buffer 怎么流转才不卡
3.1 V4L2 采集与 gralloc 的配合
EVS 底层采集走的是标准 V4L2，但和普通 V4L2 应用不同的是，它要求驱动直接把帧 DMA 到 gralloc 分配的 buffer 里。这意味着EvsCamera在初始化时要先向 gralloc 申请一组 buffer，把这些 buffer 的物理地址或 dma-buf fd 通过VIDIOC_QBUF交给驱动，驱动填完再VIDIOC_DQBUF取回。这套机制叫buffer 池 + 队列轮转，是保证连续采集不丢帧的基础。
常见的坑是 buffer 数量给太少。如果只申请两三个 buffer，一旦消费者处理慢一点，采集端就没有空闲 buffer 可填，驱动只能丢帧。车机场景下一般会给到 4 到 8 个，具体看分辨率和帧率。分辨率越高、帧率越高，buffer 就要越多，否则一定翻车。
3.2 显示端的叠加与格式转换
显示端EvsDisplay拿到的 buffer 格式未必和屏幕原生格式一致。摄像头常见输出是 NV12 或 YUYV，而显示控制器可能要求 RGBA 或 RGB565。这时候要么在 EVS 内部做一次格式转换，要么交给 GPU 或硬件合成器。格式转换是延迟大户，能硬件做就别软件做。
另一个细节是叠加层。倒车影像上通常还要叠加动态轨迹线、雷达距离条这些 UI 元素。这些叠加如果放在应用层用 SurfaceFlinger 合成，延迟就上去了；更常见的做法是在 EVS 显示端直接做硬件叠加，或者把 UI 画到同一块 buffer 上。这里的设计取舍是：硬件叠加延迟低但灵活性差，软件叠加灵活但吃 CPU/GPU。
3.3 帧同步与 tearing 问题
采集和显示是两个独立的时钟域，如果不同步，画面会出现撕裂（tearing）。EVS 里常见的处理方式是双缓冲或三缓冲 + vsync 对齐：显示端只在 vsync 到来时切换 buffer，采集端持续往空闲 buffer 写。这样即使采集帧率和显示刷新率不一致，也不会撕裂。
// 显示端 vsync 对齐的简化逻辑 void onVsync() { // 只在 vsync 时切换当前显示的 buffer if (mPendingBuffer != nullptr) { // 把待显示 buffer 设为当前，旧的归还给采集端 swapBuffers(mPendingBuffer); mCamera->doneWithFrame(mPreviousBuffer); mPreviousBuffer = mPendingBuffer; mPendingBuffer = nullptr; } }参数上要注意vsync周期和摄像头帧率的匹配。如果摄像头是 30fps 而屏幕是 60Hz，那每两帧显示一次，逻辑上没问题；但如果摄像头帧率抖动，就要靠 buffer 池来吸收抖动，池子太小就会丢帧。这套机制的本质是用空间（buffer）换时间（平滑度）。
4. 避坑与排查：EVS 集成里最容易翻车的几件事
4.1 挂 R 挡黑屏，但相机本身是好的
现象：单独测试摄像头能出图，但集成到 EVS 后挂 R 挡黑屏。原因通常是EVS 服务启动时序晚于倒车信号，或者EvsEnumerator没枚举到摄像头。排查时先看IEvsEnumerator::getCameraList返回是否为空，再看 init.rc 里 EVS 服务的启动优先级。解决方式是把 EVS 服务提前到倒车信号处理之前启动，或者让倒车应用在收到信号后主动等待 EVS 就绪。
4.2 画面花屏或颜色不对
现象：画面能出，但颜色偏绿、偏紫，或者有条纹。原因基本是像素格式不匹配，比如采集端给的是 NV12，显示端按 RGBA 解析。排查时打印BufferDesc里的format、stride、pixelSize，和显示端配置逐项对比。解决方式是统一格式，或者在 EVS 内部加一层格式转换。注意stride不等于宽度，有对齐填充，按宽度解析一定错位。
4.3 帧率上不去，画面卡顿
现象：画面能出但明显卡顿，帧率远低于预期。原因可能是 buffer 池太小导致丢帧，也可能是doneWithFrame调用不及时。排查时统计采集回调和归还的帧数差，如果差值持续增大，说明消费者没及时归还。解决方式是增大 buffer 池，或者把耗时处理从回调线程挪到独立线程，避免阻塞采集。
4.4 多路摄像头同时开就崩
现象：单路正常，同时开四路环视就崩溃或严重掉帧。原因是带宽和内存带宽被打满，尤其是高分辨率多路并发时。排查时看每路的带宽需求和总带宽上限，以及 gralloc 内存是否够。解决方式是降分辨率、降帧率，或者用硬件 ISP 做多路复用。车机 SoC 的 ISP 通道数有限，超过就是硬伤，软件绕不过去。
4.5 退出倒车后摄像头没释放
现象：倒车影像正常，但退出后摄像头一直占用，下次挂 R 挡打不开。原因是closeCamera没被调用，或者服务被异常杀死后资源没回收。排查时看/dev/video*的占用情况，以及 EVS 服务的生命周期。解决方式是在应用 onPause/onStop 里确保释放，服务端加超时兜底，异常退出时由 init 重启服务并清理资源。
5. 设计取舍：EVS 为什么不做成通用相机
EVS 这套设计从头到尾都在做一个取舍：牺牲通用性，换确定性和低延迟。它不支持拍照、不支持复杂的 3A 手动控制、不支持多流任意组合，因为这些能力都会让链路变长、状态机变复杂。车机影像要的是“挂挡必出、出画必稳”，而不是“功能丰富”。
从实现上看，EVS 把 buffer 管理、格式协商、显示叠加这些事都收拢到 native 层，应用层只拿到一个极简的接口。这样做的好处是链路可控，坏处是灵活性差——想加个新功能，往往要动 native 服务。常见的实现思路是在 EVS 之上再包一层业务框架，把轨迹线、雷达这些业务逻辑放在应用层，底层只负责出画。
验证一套 EVS 实现是否合格，我一般会走这么几步：先测冷启动挂 R 挡的出画时间，再测连续挂挡退出的稳定性，然后测多路并发时的帧率和内存占用，最后测异常场景（服务被杀、摄像头拔掉）的恢复能力。这几步走完，基本能看出这套实现是能用还是只能跑 demo。
从那以后我每次评估车机影像方案，都会先问一句：你的 buffer 池多大、doneWithFrame在哪调的、格式转换是硬件还是软件。这三个问题答不上来，后面大概率要踩坑。希望帮到你。
本文还有配套的精品资源，点击获取
