车机App与普通手机App最大的差异在于，它不仅要处理触摸交互和界面渲染，还要面对来自整车总线的实时状态数据、车载扬声器的音频资源竞争以及行车过程中的安全约束。三个核心模块——车辆状态控制、导航、音乐——在同一个应用中并存，决定了车机App的架构不能简单照搬手机开发模式。车辆状态控制要求低延迟和高可靠性，导航需要持续占用定位与地图渲染资源，音乐播放则对音频链路有独占性需求。这三者如果互不感知，最终体验一定混乱。
一个典型的车机App运行在基于Android Automotive OS的系统中，底层通过Vehicle HAL与CAN总线通信。应用层需要获取车速、电量、车门状态等信号时，不能直接读写总线，而是通过CarService提供的VehiclePropertyManager接口订阅属性变化。导航模块通常以SDK形式集成，负责定位、地图渲染和路径计算。音乐模块则通过MediaSession与系统音频服务交互。三个模块各自独立，但共享系统的显示区域、音频输出和CPU资源，这就要求架构层面有清晰的层次划分与优先级管理。
车辆状态控制：从总线信号到UI展示的完整链路
车辆状态控制模块的核心任务是把整车网络上的原始信号转换成用户可读、可操作的界面元素。底层信号以VehicleProperty ID为标识，例如车辆速度对应VehiclePropertyIds.PERFORMANCE_VEHICLE_SPEED，剩余电量对应VehiclePropertyIds.RANGE_REMAINING。应用层通过CarPropertyManager注册监听器，系统在信号变化时回调onPropertyChanged方法，数据包中携带了时间戳、数值和状态。
这里有一个容易踩坑的地方：不同车型对同一属性的定义可能不同。比如车门状态的枚举值，有些车用0表示关闭、1表示打开，有些车则完全反过来。因此应用层必须在数据链路后端做一个归一化处理层，将厂商自定义的property值映射到统一的语义模型上。否则UI层会直接显示错误的状态信息，这种问题在实车测试阶段才能暴露出来。
开发时可以封装一个车辆状态仓库（VehicleStateRepository），它对外暴露响应式数据流。所有的UI组件只依赖这个仓库，不直接接触CarPropertyManager。这样当车辆适配范围扩大时，只需要修改仓库内部的映射逻辑，界面完全不受影响。另外，状态上报频率也需要注意，像车速这类高频信号可能会达到每秒几十次回调，如果UI直接跟随刷新，列表页会明显卡顿，通常需要加一个节流器。
class VehicleStateRepository(
private val propertyManager: CarPropertyManager
) {
private val _speed = MutableStateFlow<Int>(0)
val speed: StateFlow<Int> = _speed.asStateFlow()
private val scope = CoroutineScope(Dispatchers.Default + SupervisorJob())
fun startObserving() {
scope.launch {
propertyManager.registerCallback(
callback,
VehiclePropertyIds.PERFORMANCE_VEHICLE_SPEED,
CarPropertyManager.SENSOR_RATE_ONCHANGE
)
}
}
private val callback = object : CarPropertyManager.CarPropertyEventCallback {
override fun onPropertyChanged(property: CarPropertyValue<*>) {
when (property.propertyId) {
VehiclePropertyIds.PERFORMANCE_VEHICLE_SPEED -> {
val rawValue = property.value as? Float ?: return
val normalized = normalizeSpeed(rawValue)
_speed.value = normalized
}
}
}
override fun onError(propertyId: Int, status: Int) {
// 记录错误并更新模块状态为不可用
}
}
}
除了读取状态，车辆状态控制还包含远程控制指令的下发，比如解锁车门、开启空调、启动充电等。这类指令往往有权限校验和延迟确认机制，不能只发送一次就认为成功。建议为每条控制指令维护一个状态机，从“请求中”流转到“执行成功”或“执行失败”，并且设置超时时间。这个设计能让用户在界面看到明确的反馈，而不是点完按钮之后无任何反应。
导航模块集成：定位、地图渲染与语音播报的取舍
导航模块在车机App中的定位比较特殊，大多数开发团队不会自己实现地图引擎，而是集成高德地图车机版SDK或百度地图车机SDK。这种SDK会提供一个独立的TextureMapView用于渲染地图，同时需要传入定位回调以实时更新车辆位置。车机环境下的定位信号在城市高架、隧道中会频繁丢失，所以导航SDK一般会融合轮速脉冲和惯性导航数据。
地图渲染对GPU资源的消耗很大，如果和车辆状态动画同时进行，低端车机芯片可能出现掉帧。一种做法是把地图渲染放到独立的SurfaceView中，让系统为它分配单独的合成层级。同时，在导航页面中尽量简化车辆状态区的刷新逻辑，比如把实时刷新的数据帧率从每秒30帧降低到每秒5帧，等退出导航页面后再恢复全速刷新。
导航语音播报与音乐播放之间的音频冲突是集成阶段最头痛的问题。导航播报属于“提示音”类别，而音乐属于“媒体”类别。Android系统的AudioFocus机制规定，当导航播报获取音频焦点时，媒体播放器应该降低音量或者暂停播放。但在车机上，用户通常期望音乐声音只是被压低而非完全中断，这被称为“闪避”或Ducking。有的车机系统支持策略配置，也可以手动实现一个音频焦点监听器，在收到AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK时调用播放器的setVolume降低音量。
private AudioManager.AudioFocusChangeListener focusListener =
new AudioManager.AudioFocusChangeListener() {
@Override
public void onAudioFocusChange(int focusChange) {
switch (focusChange) {
case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK:
// 导航播报期间压低音乐音量，而不是暂停
mediaPlayer.setVolume(0.3f, 0.3f);
break;
case AudioManager.AUDIOFOCUS_GAIN:
// 播报结束，恢复音量
mediaPlayer.setVolume(1.0f, 1.0f);
break;
case AudioManager.AUDIOFOCUS_LOSS:
// 永久失去焦点，暂停播放
mediaPlayer.pause();
break;
}
}
};
如果导航SDK自带语音播报功能，建议将播报通道指定为独立的音频流类型，例如AudioManager.STREAM_MUSIC，并在播报前手动请求音频焦点。有些车机系统的AudioService已经实现了“导航混音”策略，此时应用层只需要正确设置音频流的属性即可，不需要重复处理Ducking逻辑。开发者需要先确认目标平台的系统行为，再决定代码中的处理方式。
音乐模块：跨模块媒体会话与播放队列管理
音乐播放模块的技术复杂度不在播放本身，而在于它要与车辆状态模块和导航模块共存。Android系统通过MediaSession机制向外界暴露播放器的状态，包括曲目信息、播放进度、播放/暂停状态。车机系统的媒体栏、方向盘按键、语音助手都需要通过MediaSession来间接控制播放器。因此音乐模块必须首先建立一个唯一的MediaSession实例，并正确处理回调。
播放队列的管理同样值得重视。在驾车场景下，用户不会频繁操作播放列表，因此App应当维护一个可持久化的播放队列，以便在车辆重启后自动恢复上次的播放状态。这需要把队列内容序列化保存到本地存储，同时保存媒体源的URI和封面图的本地缓存路径。这里有一个细节：如果媒体源来自在线音乐平台，直接保存URI是可行的，但如果来自USB设备，则需要同时记录设备的挂载路径。
音乐模块与车辆状态模块的交互体现在“行车安全”场景中。当车辆处于行驶状态时，某些操作如浏览歌单列表会被限制；反之，当车辆处于驻车状态时，全部功能开放。这个场景推荐采用“单例状态存储”的设计，即定义一个全局的DriveState对象，由车辆状态模块持续更新，音乐模块和导航模块都读取同一个实例。通过这种方式，两个模块之间不用互相引用，也不会产生循环依赖。
object DriveState {
val isParked = MutableStateFlow(true)
fun updateParkingStatus(parked: Boolean) {
isParked.value = parked
}
}
class MusicPlaybackViewModel(private val mediaSession: MediaSession) {
fun onPlaylistItemClicked(index: Int) {
if (!DriveState.isParked.value) {
// 行驶中禁止浏览歌单，引导用户使用语音
return
}
mediaSession.controller.transportControls.skipToQueueItem(index)
}
}
媒体音量与导航播报音量的协调在Hi-Fi系统上尤其重要。建议音乐模块采用独立的AudioAttributes构建播放器，明确其usage为USAGE_MEDIA。这样系统的音量键会默认调节媒体音量，而导航播报不会使用这个音量的最大值，从而保留一定的动态余量。否则用户把媒体音量调到最大后，播报声音会显得十分突兀，这种细节很容易被忽略但影响体验很大。
三模块协同的架构实践：模块化、优先级与性能底线
综合上面的分析，车辆状态控制、导航、音乐三个模块在车机App里应当被设计成三个可以独立开发、独立测试的组件。每个组件对外暴露的接口要足够少，例如状态控制组件只提供getSpeedFlow()、lockDoor()这类方法，导航组件只提供startNavigation(destination)和stopNavigation()，音乐组件只提供播放控制与焦点回调。模块之间的通信全部通过共享的Application单例或依赖注入容器完成，禁止直接跨模块调用内部类。
优先级策略要明确：安全类功能优先于娱乐类功能。车辆状态组件中涉及安全告警的信息，例如胎压异常、电池温度过高，必须抢占最高显示优先级，播放中的音乐需要在告警弹出时自动降低音量。导航语音的优先级低于安全告警，但高于音乐。这种优先级关系可以抽象为一张配置表，由产品负责人维护，避免在代码里散落各种magic number。
性能方面需要设定底线：在低端车机芯片（例如八核A53、2GB内存）上，音乐播放时导航地图的拖动帧率不能低于每秒25帧，车辆状态页面的整体内存占用不能超过300MB。为了满足这个标准，三个模块的UI实现都要避免使用过多的半透明叠加层，减少不必要的阴影和模糊效果。同时要注意，如果车机屏幕分辨率达到1920x720，位图资源必须按照对应DPI提供适配版本，否则内存占用会成倍增长。
<!-- 模块化依赖关系的合理划分 -->
<!-- 三个feature模块互不依赖，都只依赖core模块 -->
<dependency>
<groupId>com.example.vehicle</groupId>
<artifactId>core-common</artifactId>
<version>1.0.0</version>
</dependency>
<!-- 车辆状态控制模块 -->
<dependency>
<groupId>com.example.vehicle</groupId>
<artifactId>feature-vehicle-status</artifactId>
<version>1.0.0</version>
</dependency>
<!-- 导航模块 -->
<dependency>
<groupId>com.example.vehicle</groupId>
<artifactId>feature-navigation</artifactId>
<version>1.0.0</version>
</dependency>
<!-- 音乐模块 -->
<dependency>
<groupId>com.example.vehicle</groupId>
<artifactId>feature-music</artifactId>
<version>1.0.0</version>
</dependency>
最后需要特别强调测试策略。车机App的测试不能只依赖模拟器，因为模拟器无法模拟真实的总线信号和音频焦点抢占。建议搭建一个硬件在环测试环境，通过CAN卡向车辆控制模块发送模拟的车速、车门、电量信号，验证UI刷新和异常处理逻辑。音频相关的测试则需要准备一套完整的音频链路，用来对比验证导航播报打断音乐时的音量变化是否符合设定值。只有在这种接近实车的环境下，三个模块的协同问题才能被尽早暴露和修复。