第二章：软件架构基础

各位同学，今天我们聊聊软件架构的基础。说实话，很多刚入行的工程师觉得架构是虚的，不如写代码实在。我当年也这么想，直到被一个项目狠狠教育了一回——那是一个座舱项目，前期只顾着堆功能，后期改一个需求要动半套代码。嗯，从那以后，我再也不敢轻视架构设计了。

2.1 分层架构设计原则

分层架构，说白了就是把软件切成几层，每层各司其职。就像盖楼，地基、框架、装修各管各的，互不干扰。

我个人习惯把座舱软件分成四层：

• 硬件抽象层（HAL）：屏蔽芯片差异，让上层不用管你是高通还是瑞萨
• 系统服务层：提供窗口管理、输入事件、音频策略等基础能力
• 应用框架层：封装HMI组件、数据绑定、状态管理
• 应用层：仪表、中控、空调等具体功能

这里有个关键原则——单向依赖。上层只能调用下层，下层绝不能反向依赖上层。我在项目中遇到过有人为了图方便，在底层直接调了上层接口，结果后面换UI框架时，底层代码全得重写。血的教训啊。

2.2 模块化与解耦思想

模块化，就是把大系统拆成小模块。每个模块有清晰的职责边界。你想想看，一个座舱系统动辄上百万行代码，如果不拆，谁能维护得了？

我建议用接口隔离原则来指导模块划分。举个例子，空调模块需要知道车速吗？其实不需要。它只需要知道发动机状态就够了。所以接口设计要精简，别把不相关的东西传进来。

// 不好的设计：空调模块依赖了整个车辆状态
class AirConditioner {
    void update(VehicleState state) {
        if (state.engineRunning && state.speed > 0) {
            // 调整空调功率
        }
    }
}

// 好的设计：只依赖必要信息
class AirConditioner {
    void update(EngineStatus engineStatus) {
        if (engineStatus.running) {
            // 调整空调功率
        }
    }
}

解耦的另一个手段是事件驱动。模块之间不直接调用，而是通过消息总线通信。我曾经在一个项目中，把所有模块的交互都改成了事件驱动，结果新增一个功能时，只需要注册事件监听，完全不用改已有代码。那种感觉，真的很爽。

2.3 座舱软件架构的演进趋势

座舱架构这几年变化很快。我入行时还是单芯片跑所有功能，现在已经是多域融合的天下了。

阶段	特点	典型方案
1.0 单体架构	所有功能在一个进程中，耦合严重	裸机+简单RTOS
2.0 分层架构	按功能分层，模块化初步	Linux+Qt，AUTOSAR Classic
3.0 面向服务架构	功能以服务形式提供，动态组合	Some/IP，DDS，AUTOSAR Adaptive
4.0 舱驾融合	座舱与智驾共享算力，统一调度	中央计算平台，虚拟化

为什么会这样演进？说白了，用户需求越来越复杂。十年前仪表显示个车速就够了，现在要3D导航、AR-HUD、多屏互动。如果还用单体架构，改一个功能就得重新编译整个系统，谁能受得了？

我个人比较看好面向服务架构（SOA）。它把每个功能封装成独立服务，服务之间通过标准协议通信。比如空调服务、导航服务、媒体服务，它们各自独立开发、独立部署。你想升级导航？只替换导航服务就行，其他服务完全不受影响。

还有一个趋势是虚拟化。通过Hypervisor在单芯片上运行多个操作系统，比如一个Linux跑娱乐系统，一个QNX跑仪表。这样既能隔离安全关键功能，又能享受Linux丰富的生态。嗯，这个我们在后面的章节会详细讲。

最后说一句，架构设计没有银弹。每个项目都有自己的约束条件——芯片算力、内存大小、开发周期、团队能力。我建议你从分层架构入手，等吃透了再考虑SOA、虚拟化这些高级玩法。路要一步一步走，饭要一口一口吃。

好，这一章就到这里。下一章我们聊聊具体的分层实现，我会带大家看一个实际的座舱项目代码。有什么问题，欢迎课后交流。