一、多Display管理：不止是“多屏”那么简单
车载和嵌入式系统里，多Display管理是个绕不开的话题。我最早接触这个，是在一个双屏车载导航项目里——中控一个屏，仪表盘一个屏，两个屏显示的内容完全不同。你想想看，如果只是简单地把手机屏幕镜像到车机上，那根本用不着这么复杂。
Android的多Display管理，核心在于DisplayDevice和DisplayManagerService。每个物理屏幕对应一个DisplayDevice，而DisplayManagerService负责协调它们。
1.1 物理显示与逻辑显示
在SurfaceFlinger里，每个DisplayDevice都有一个唯一的ID。我习惯把物理显示叫“硬件显示”，逻辑显示叫“软件显示”。举个例子：
// 获取所有显示设备
DisplayManager dm = (DisplayManager) context.getSystemService(Context.DISPLAY_SERVICE);
Display[] displays = dm.getDisplays();
for (Display display : displays) {
// 每个display都有一个type：内置、外接、虚拟等
int type = display.getType();
String name = display.getName();
Log.d("Display", "Type: " + type + ", Name: " + name);
}
嗯，这里要注意：车载系统里经常有“主屏”和“副屏”的概念。主屏通常是中控，副屏可能是仪表盘或后排娱乐屏。它们的刷新率、分辨率、色彩空间都可能不一样。
1.2 多Display的同步问题
我在项目中遇到过最头疼的问题，就是两个屏的帧率不同步。中控屏60Hz，仪表盘30Hz，结果仪表盘显示的车速总是比实际慢半拍。后来发现，SurfaceFlinger默认是每个Display独立刷新的，没有做帧同步。
解决方案是引入Vsync偏移。每个DisplayDevice可以配置自己的Vsync相位，让它们错开刷新时间，避免同时抢带宽。
核心要点：多Display管理的关键在于DisplayDevice的独立配置和Vsync协调。不要指望所有屏都同步刷新，那是不现实的。
二、SurfaceFlinger扩展：从“窗口合成器”到“显示管家”
SurfaceFlinger在车载场景下，远不止是合成窗口那么简单。它需要管理多个Display的合成策略、HDR映射、旋转、裁剪等等。说白了，它得像个管家一样，知道每个屏要显示什么、怎么显示。
2.1 自定义合成策略
默认的SurfaceFlinger合成策略是“能硬件合成就硬件合成，不行就GPU合成”。但在车载里，这个策略不够用。比如仪表盘上的指针，需要极低延迟，最好直接走硬件覆盖层（HWC Overlay）。
我建议的做法是：在SurfaceFlinger的chooseCompositionStrategy方法里，根据Display的类型和Layer的属性，手动指定合成方式。
// 伪代码：自定义合成策略
void chooseCompositionStrategy(DisplayDevice display) {
if (display.getType() == DISPLAY_TYPE_INSTRUMENT_CLUSTER) {
// 仪表盘：强制使用硬件覆盖层
for (Layer layer : display.getLayers()) {
if (layer.isCritical()) {
layer.setCompositionType(HWC_OVERLAY);
}
}
} else {
// 中控屏：默认策略
defaultCompositionStrategy(display);
}
}
小技巧：可以用dumpsys SurfaceFlinger查看每个Layer的合成类型。如果发现关键图层走了GPU合成，那延迟肯定高。
2.2 安全显示与DRM保护
车载系统里，安全显示是个硬需求。比如倒车影像、导航地图，这些内容不能随便被截屏或录屏。Android提供了SurfaceView.SURFACE_TYPE_SECURE和FLAG_SECURE，但光靠这个不够。
DRM（数字版权管理）保护，说白了就是防止内容被非法复制。在车载里，DRM主要用于流媒体播放——比如后排娱乐屏看Netflix，内容必须加密传输到屏幕，中间不能被截获。
我踩过一个坑：以为设置了FLAG_SECURE就万事大吉，结果发现adb screencap还是能截到图。后来才知道，FLAG_SECURE只对系统截屏有效，对硬件层面的截取（比如HDMI采集卡）是没用的。
警告：FLAG_SECURE不是万能的。真正的安全显示需要结合DRM和硬件保护路径。比如使用HDCP（高带宽数字内容保护）加密HDMI输出，或者使用TrustZone保护显示缓冲区。
三、DRM保护：从“软件锁”到“硬件链”
DRM保护在Android里，核心是MediaDrm和DrmManager。但车载场景下，DRM不仅仅是播放加密视频，还包括显示路径的加密。
3.1 DRM的工作流程
简单来说，DRM保护分三步：
- 内容加密：视频流在服务器端加密，只有授权设备能解密。
- 密钥管理：设备从DRM服务器获取密钥，密钥存储在安全区域（如TEE）。
- 安全显示：解密后的视频帧，通过安全路径直接送到屏幕，中间不能被CPU或GPU读取。
第三步是最容易出问题的。我记得有一次，客户反馈说播放DRM视频时，屏幕偶尔闪一下。排查后发现，是SurfaceFlinger在合成时，把安全图层和非安全图层混在一起了，导致安全路径被破坏。
3.2 安全显示路径的实现
在SurfaceFlinger里，安全显示路径通过HWC（硬件合成器）的HWC_DISPLAY_SECURE标志来实现。当一个Layer被标记为安全时，HWC会把它单独送到一个受保护的显示通道。
// 设置Layer为安全显示
layer.setSecure(true);
layer.setCompositionType(HWC_OVERLAY);
// 在HWC中，安全图层会走独立的显示管道
hwc_display.setSecureDisplay(true);
hwc_display.addLayer(layer);
关键点：安全显示路径必须从解码器到屏幕全程加密。任何中间环节的“明文”暴露，都是安全隐患。
四、知识体系总览
下面这张图，是我自己总结的车载图形系统核心逻辑。你可以看到，多Display管理、SurfaceFlinger扩展、安全显示与DRM保护，这三者是相互关联的。
五、实战经验总结
做车载图形优化这几年，我最大的感受是：不要迷信默认配置。Android原生的图形栈是为手机设计的，到了车载里，很多地方都得改。
| 场景 | 常见问题 | 我的建议 |
|---|---|---|
| 双屏不同帧率 | 画面撕裂、延迟 | 配置Vsync偏移，错开刷新时间 |
| 仪表盘指针延迟 | 指针跟不上实际车速 | 强制使用HWC Overlay，跳过GPU合成 |
| DRM视频闪屏 | 安全图层与非安全图层混叠 | 检查HWC的安全显示路径配置 |
| 截屏泄露隐私 | FLAG_SECURE失效 | 结合硬件保护路径，如HDCP |
避坑指南：我曾经在一个项目里，为了省电把仪表盘的刷新率降到15Hz，结果指针动画卡成PPT。后来发现，不是刷新率的问题，是合成策略没优化——把指针图层单独拎出来走Overlay，30Hz就够用了。
好了，这一章的内容就到这里。车载图形系统是个大话题，多Display管理、SurfaceFlinger扩展、安全显示与DRM保护，每一个都值得深挖。希望我的经验能帮你少走些弯路。
公众号:蓝海资料掘金营，微信deep3321