29、行业案例：蔚来、理想、小鹏等车型的 Android Automotive 实践分析

聊了这么多底层技术，咱们来看看真刀真枪的实战。说实话，国内新势力这三家——蔚来、理想、小鹏，在 Android Automotive 的落地路径上，各有各的「脾气」。我参与过其中一家的部分车载项目适配，也跟另外两家的同行交流过不少，今天就把这些「内幕」掰开揉碎讲给你听。

29.1 蔚来：从 NIO OS 到 Banyan 的「自研执念」

蔚来早期用的是 Linux + QNX 的混合方案，后来全面转向 Android Automotive。我个人觉得，蔚来是这三家里对「底层控制权」最执着的。

29.1.1 架构特点

• 双系统隔离：仪表盘跑在 QNX 上，中控和娱乐跑在 Android Automotive 上。中间通过 Hypervisor 做硬隔离。
• 自研 HMI 框架：蔚来没有直接用 AOSP 的 Car UI，而是基于 Android 的 SurfaceFlinger 做了深度定制。他们的 3D 车控界面，说白了就是自己写了一套渲染管线。
• OTA 升级策略：采用 AB 分区无缝升级。我印象很深的是，他们为了确保升级不丢用户数据，在 recovery 阶段做了大量测试。

29.1.2 避坑指南

我曾经在调试蔚来某款车型的蓝牙电话时，发现通话音频延迟特别大。查了半天，问题出在 AudioFlinger 的混音策略上——他们为了支持多音区（主驾、副驾独立音源），改了 AudioPolicy 的 routing 逻辑，结果导致蓝牙 SCO 链路的优先级被降了。嗯，这里要注意：改 AudioFlinger 一定要同步改 AudioPolicy 的配置，不然就会出现这种「玄学」问题。

29.2 理想：务实派的「拿来主义」

理想的策略跟蔚来完全相反。他们更倾向于「能用现成的就别自己造」。你想想看，理想的车卖得最多，研发效率必须拉满。

29.2.1 架构特点

• 基于 AOSP 的轻量定制：理想直接用了 Google 的 Car UI 库，只在上层做了主题和交互的修改。底层几乎没动。
• 多屏交互方案：理想 L9 的副驾屏、后排屏都是独立的 Android 实例，通过虚拟化技术跑在同一块 SoC 上。我建议你去看他们的「多屏同步」实现——其实就是用 Android 的 VirtualDisplay + MediaProjection 做的投屏。
• 应用生态：理想没有自研应用商店，直接接入了第三方市场。但他们在权限管理上做了「沙箱」机制，防止第三方应用乱搞车控接口。

29.2.2 技术细节

理想的「四屏交互」其实是个技术活。他们用了 Android 的 DisplayManager 来管理多个物理屏幕，每个屏幕分配独立的 DisplayContent。但有个坑：不同屏幕的触摸事件同步。我曾经在调试时发现，副驾屏滑动时主驾屏的导航会卡顿——原因是 InputDispatcher 在处理多点触控时，把不同屏幕的事件当成了同一窗口的输入。解决方案是在 InputReader 层根据屏幕 ID 做事件分流。

// 伪代码：多屏触摸事件分流
InputReader::processEvent(event) {
    if (event.screenId == DISPLAY_PRIMARY) {
        dispatchToPrimary(event);
    } else if (event.screenId == DISPLAY_SECONDARY) {
        dispatchToSecondary(event);
    }
    // 注意：这里要加锁，防止并发写入
}

29.3 小鹏：技术派的「全栈自研」

小鹏给我的感觉是「什么都想自己搞」。从 Xmart OS 的底层到上层应用，他们几乎重写了 Android Automotive 的很多核心模块。

29.3.1 架构特点

• 自研车载中间件：小鹏没有直接用 Android 的 CarService，而是自己写了一套 XService，用来管理车辆状态、信号路由和应用生命周期。
• 跨域融合：他们把智能驾驶域（XPILOT）和座舱域（Xmart OS）跑在了同一颗 Orin 芯片上，通过 Android 的 Trusty TEE 做安全隔离。
• 语音全链路自研：小鹏的语音助手从唤醒到语义理解，全部跑在本地。他们用 Android 的 NNAPI 加速了端侧推理模型。

29.3.2 技术细节

小鹏的「跨域通信」是个亮点。他们用 Android 的 HIDL 封装了 CAN 总线信号，然后在应用层通过 LiveData 做数据订阅。举个例子：

// 小鹏的车辆状态订阅示例
class VehicleSpeedLiveData : LiveData<Float>() {
    override fun onActive() {
        // 注册 HIDL 回调
        VehicleHal.getSpeed().registerCallback { speed ->
            postValue(speed)
        }
    }
    override fun onInactive() {
        VehicleHal.getSpeed().unregisterCallback()
    }
}

这个设计的好处是——应用层不需要关心底层是 CAN 还是以太网，只管订阅数据就行。但坏处是：LiveData 的生命周期管理要小心。我遇到过因为 Activity 销毁时没取消订阅，导致内存泄漏的案例。

29.4 三家对比总结

维度	蔚来	理想	小鹏
底层定制深度	高（自研 HMI 框架）	低（基于 AOSP）	极高（自研中间件）
多屏方案	独立屏幕 + Hypervisor	虚拟化 + VirtualDisplay	跨域融合 + TEE 隔离
语音集成	深度集成 CarService	第三方方案	全链路自研
升级策略	AB 分区 + 数据保护	标准 OTA	全量 + 增量混合
维护成本	中	低	高

29.5 核心知识体系

下面这张图，是我根据这三家的实践总结出来的 Android Automotive 车载系统核心架构。你想想看，不管哪家方案，都逃不出这几个模块的博弈。

这张图里，最关键的其实是「框架层」和「HAL 层」之间的接口设计。蔚来、理想、小鹏的差异，说白了就是在这两层之间「塞」了多少自研代码。我个人建议：如果你刚开始做车载项目，先学理想的「轻量定制」路线，等团队成熟了再学蔚来或小鹏的深度定制。

---

公众号:蓝海资料掘金营，微信deep3321