一、车载多屏系统概述：Android Automotive 架构简介、多屏交互的应用场景、车载显示系统的发展趋势

各位同学，大家好。我是你们这门课的主讲人。在正式开始动手写代码之前，我觉得有必要先聊聊「多屏」这件事到底是怎么回事。

说实话，我最早接触车载多屏系统是在2018年。那时候我还在做手机ROM，突然被拉去搞一个「三屏互动」的项目。当时我心想，不就是把手机屏幕搬到车上吗？结果一上手就发现，完全不是那么回事。嗯，这里面的坑，我后面会慢慢讲。

1.1 Android Automotive 架构简介

先说说Android Automotive。它和我们手机上的Android，说白了是「同源不同路」。

Android Automotive是Google专门为汽车打造的操作系统。它不是Android Auto那种手机投屏方案，而是直接跑在车机硬件上的完整系统。

我个人的习惯是，看一个系统先看它的分层。Android Automotive的架构大致分这么几层：

• 应用层：包括系统应用和第三方应用。比如地图、音乐、设置等。
• 框架层：提供各种API，比如Car API、Media API等。
• 硬件抽象层（HAL）：这是车载特有的。比如车辆属性（车速、车门状态）的获取，都通过Vehicle HAL。
• 内核层：Linux内核，加上一些车载驱动。

这里有个关键点：Android Automotive的显示系统是支持多Display的。也就是说，系统底层就允许你接多个屏幕，每个屏幕可以独立运行。

我在项目中遇到过一个问题：两个屏幕同时播放视频，结果音频串了。后来发现是Audio Policy没有针对多Display做配置。这个坑，后面讲音频路由的时候会细说。

1.2 多屏交互的应用场景

多屏交互，说白了就是「让车里的屏幕们协同工作」。我把它分成三类场景：

场景一：信息扩展与联动

最常见的就是仪表盘和中控屏的联动。比如中控屏设置导航，仪表盘显示导航箭头。或者中控屏播放音乐，仪表盘显示歌词。

你想想看，如果所有信息都堆在中控屏上，驾驶员操作时视线离开路面太久，很危险。多屏交互的核心目的之一，就是减少驾驶员的注意力分散。

场景二：娱乐与驾驶分离

副驾屏和后排屏，主要是给乘客用的。副驾可以看视频、玩游戏，不影响驾驶员看导航。这里有个技术难点：如何保证副驾屏的娱乐内容不会干扰到驾驶信息？

我记得有一次，客户要求副驾屏播放视频时，中控屏的导航语音不能被打断。这个需求看似简单，但涉及到音频焦点管理、窗口焦点管理等多个层面。嗯，后面我们会专门讲这个。

场景三：跨屏任务流转

这个比较高级。比如你在中控屏上打开了一个应用，然后把它「甩」到副驾屏上继续操作。或者你在后排屏上玩游戏，下车前把游戏进度同步到手机上。

这种场景对系统架构的要求很高。它需要应用本身支持多实例或状态迁移，同时系统要提供跨屏的拖拽或投屏机制。

场景类型	典型应用	技术挑战
信息扩展与联动	导航联动、仪表盘扩展	数据同步、延迟控制
娱乐与驾驶分离	副驾视频、后排游戏	音频焦点、窗口管理
跨屏任务流转	应用跨屏拖拽、状态迁移	多实例支持、状态序列化

1.3 车载显示系统的发展趋势

这几年车载显示的变化，说实话比手机快多了。我总结几个趋势：

• 屏幕数量越来越多：从单屏到双屏，再到三屏、五屏。有些高端车型已经做到全车7块屏。
• 屏幕尺寸越来越大：以前7寸算大的，现在12.3寸起步，还有贯穿式的大连屏。
• 交互方式越来越丰富：从触控到语音，再到手势、视线追踪。多屏交互不再只是「点一点」，而是「看一看、说一说、动一动」。
• 系统复杂度越来越高：多屏意味着多任务、多窗口、多音频流。系统需要更强的调度能力。

还有一个趋势值得关注：虚拟化技术。有些车厂开始用Hypervisor在同一块芯片上跑多个系统，比如一个Android跑娱乐，一个QNX跑仪表。这种方案对多屏交互提出了新的挑战——跨系统的屏幕共享怎么做？

嗯，这个我们后面讲到「跨系统投屏」的时候会展开。

小结

这一节我们聊了Android Automotive的架构特点，多屏交互的三大应用场景，以及车载显示的发展趋势。说白了，多屏交互不是简单的「多块屏幕」，而是「多块屏幕如何协同工作，让驾驶更安全、让体验更流畅」。

下一节，我们会深入Android的显示系统，看看一块屏幕上的内容是怎么画出来的。到时候我会带大家看一些实际的代码，包括SurfaceFlinger的工作原理。准备好了吗？