第三章 系统总体架构设计：五大模块的划分与协作
好，咱们进入正题。这一章聊的是系统总体架构设计。说白了，就是要把一个车载音响系统拆成几个大块，然后让它们各司其职、协同工作。
我个人习惯，在动手写代码之前，先把架构图画清楚。你想想看，如果连模块边界都模糊，后面调试起来得多痛苦？
3.1 为什么是这五个模块？
车载音响系统，不是简单的“放歌”设备。它要处理音频流、响应触摸屏、跟车机通信、还要省电。我把它拆成五个模块：
- 主控模块：系统的“大脑”，负责调度和决策
- 音频处理模块：声音的“心脏”，负责编解码、音效、混音
- 通信模块：系统的“神经”，负责CAN、以太网、蓝牙等
- UI模块：用户的“眼睛和手指”，负责显示和交互
- 电源管理模块：系统的“能量管家”，负责供电和功耗
这五个模块，缺一不可。我在项目中遇到过，有人把通信和主控混在一起写，结果后期维护时，改一个CAN协议，整个系统都要重新编译。嗯，那滋味不好受。
3.2 主控模块：调度一切
主控模块是核心。它不直接处理音频数据，而是告诉其他模块“什么时候该做什么”。
举个例子：用户按下“播放”按钮，UI模块把事件发给主控，主控判断当前状态（是否在导航、是否有电话），然后通知音频处理模块开始解码，同时通知电源管理模块提升音频供电。
核心职责：
- 状态机管理（待机、播放、导航混音、电话优先等）
- 模块间消息路由
- 系统启动/关闭流程控制
- 错误处理与恢复
我曾经犯过一个错：主控模块里塞了太多业务逻辑，导致状态机有十几个状态，光看代码就头晕。后来我学乖了，主控只做“调度”，不做“执行”。
3.3 音频处理模块：声音的工匠
这个模块，说白了就是跟声音打交道的一切。从解码MP3、AAC，到做均衡器、环绕声，再到混音（导航提示音和音乐同时播放），全归它管。
我建议，音频处理模块要独立成一个进程或线程。为什么？因为音频是实时性要求最高的。如果UI卡顿一下，用户还能忍；如果声音卡顿一下，用户直接骂娘。
避坑指南：
我曾经在项目里把音频处理和UI放在同一个线程，结果UI刷新时，音频就出现“啪”的爆音。后来花了三天才定位到问题。记住：音频线程优先级要最高，且不能跟其他模块共享锁。
音频处理模块的典型内部结构：
音频处理模块
├── 解码器层（MP3, AAC, FLAC, WAV）
├── 音效引擎（EQ, 环绕, 低音增强）
├── 混音器（导航音 + 音乐 + 系统音）
└── 输出管道（I2S, 模拟输出, 数字输出）3.4 通信模块：连接内外
车载音响不是孤岛。它要跟车机通信（CAN总线）、要连手机（蓝牙）、要上网（以太网或Wi-Fi）。通信模块就是负责这些“外交事务”的。
这里有个关键点：通信模块要处理多种协议，但对外暴露的接口要统一。我习惯用“消息队列”的方式，把CAN报文、蓝牙事件、网络数据包都转成统一的内部消息格式。
| 通信方式 | 典型用途 | 注意事项 |
|---|---|---|
| CAN总线 | 接收方向盘按键、车速信息 | 注意总线负载，不要频繁发送 |
| 蓝牙 | 手机音乐、电话 | 配对流程要稳定，断线重连要快 |
| 以太网 | OTA升级、在线音乐 | 考虑网络延迟，做好缓冲 |
我记得有一次，CAN总线报文解析出了问题，导致音响在高速上自动切换音源。嗯，那场面挺尴尬的。从那以后，我要求通信模块必须做“报文超时检测”和“无效数据过滤”。
3.5 UI模块：用户的第一印象
UI模块是用户直接面对的。它要流畅、美观、响应快。但车载UI有个特殊要求：不能干扰驾驶。所以，动画不能太花哨，文字不能太小，触摸反馈要清晰。
我建议，UI模块采用“分层架构”：
- 渲染层：负责绘制界面（基于LVGL或Qt）
- 逻辑层：处理用户交互（点击、滑动、长按）
- 数据层：从主控模块获取状态（当前播放曲目、音量等）
警告：
千万不要在UI线程里做耗时操作！比如解码音频、读写文件。否则界面会卡成PPT。我见过一个项目，点击“下一曲”要等2秒才响应，就是因为UI线程直接调了解码器。
UI模块跟主控模块的通信，我推荐用“信号-槽”机制或者“发布-订阅”模式。UI只管显示，不关心数据从哪来。
3.6 电源管理模块：省电就是王道
车载音响的电源管理，比手机复杂得多。车上有ACC（点火信号）、常电（电池）、还有各种休眠唤醒条件。
电源管理模块的核心任务：
- 检测ACC状态，控制系统开关机
- 管理休眠与唤醒（比如CAN总线唤醒、蓝牙配对唤醒）
- 监控电压，防止亏电
- 控制音频功放的供电（功放是耗电大户）
我遇到过最头疼的问题：音响在休眠时，电流还有50mA，导致车辆停放一周后电瓶亏电。后来发现是通信模块没有完全断电，还在监听蓝牙。嗯，从那以后，我要求电源管理模块必须能“逐级断电”。
电源状态机示例：
状态: 唤醒 → 工作 → 待休眠 → 休眠
唤醒条件: ACC上电 或 CAN总线活动 或 蓝牙配对请求
休眠条件: ACC断电 且 无活动 且 延时30秒3.7 模块间的协作：消息驱动
五个模块不是孤立的。它们通过“消息”来协作。我推荐使用“异步消息队列”，而不是直接函数调用。为什么？因为解耦。音频处理模块挂了，不能影响UI模块显示。
举个例子，用户调节音量：
- UI模块检测到旋钮转动，发送“音量调节”消息
- 主控模块收到消息，更新音量状态
- 主控模块发送“设置音量”消息给音频处理模块
- 音频处理模块调整增益，同时反馈新音量值
- 主控模块通知UI模块刷新显示
你看，整个过程没有直接函数调用，全是消息传递。这样每个模块都可以独立测试、独立升级。
3.8 我的架构设计原则
最后，分享几条我个人总结的原则：
- 单一职责：一个模块只做一件事，别贪多
- 接口稳定：模块间的接口一旦确定，尽量不改
- 可测试性：每个模块都能单独跑单元测试
- 可替换性：换一个音频解码库，不影响其他模块
说白了，架构设计不是为了炫技，而是为了以后少加班。你想想看，如果架构清晰，出了问题，看一眼日志就知道是哪个模块的锅。如果架构混乱，那调试起来就像大海捞针。
嗯，这一章就到这里。下一章咱们深入聊聊主控模块的状态机设计，那可是个有意思的话题。