1. 车载Android应用架构工程导入
欢迎进入《车载Android应用架构工程》课程。在动手写第一行代码之前，我们需要先建立一张"地图"：这门课要解决什么问题、车载应用和手机应用到底差在哪里、架构工程真正要关注什么、以及接下来三十章会沿着怎样的路径推进。本章不涉及具体编码，但它决定了你后面每一章的学习姿势——是把它当成"又一套Android API教程"，还是当成"面向整车生命周期的软件工程方法"。
一、课程目标：从"能跑"到"可交付"
手机应用的目标通常是"功能可用、体验流畅、快速迭代"；车载应用的目标则要复杂得多。一个车载应用从立项到量产，往往要经历需求冻结、架构设计、多屏适配、性能与稳定性验证、整车集成、OTA升级、售后诊断等环节，生命周期长达五到十年。因此本课程的目标可以概括为三层：
- 认知层：理解车载Android与手机Android在系统裁剪、硬件形态、交互方式、安全合规上的本质差异。
- 设计层：掌握分层架构、模块化、组件通信、多屏与多用户、状态管理等架构手段，并能针对具体场景做出取舍。
- 交付层：能够输出可评审的架构文档、可复现的工程骨架、可验证的性能与稳定性指标，并完成一次完整的实战项目。
换句话说，本课程不满足于"应用能启动"，而是要求"应用能在整车上被集成、被测试、被升级、被维护"。
二、车载应用与手机应用的核心差异
很多工程师第一次做车载项目时，习惯性沿用手机经验，结果在屏幕适配、内存回收、后台限制上接连踩坑。差异不是"屏幕大一点"这么简单，而是系统约束、使用场景和工程标准三个维度的整体变化。
从系统约束看，车机通常运行定制Android（如AAOS，Android Automotive OS），系统分区、权限模型、后台进程策略都被收紧；从使用场景看，驾驶场景要求"低注意力占用"，交互以语音、方向盘按键、物理旋钮为主，触屏操作被严格限制；从工程标准看，车载软件要满足功能安全、信息安全、EMC、温度范围（常见-40℃~85℃）、启动时间（倒车影像通常要求2秒内出图）等硬指标。
下面这张图把两类应用的关键差异按"约束—场景—工程"三条链路并列呈现，便于对照记忆。
三、架构工程的核心关注点
理解了差异，就能理解为什么车载应用需要"架构工程"而不是"写代码"。架构工程关注的是那些一旦定错、后期修改代价极高的决策。结合车载场景，核心关注点可以归纳为五类：
- 分层与边界：UI层、业务层、数据层、车辆信号层如何划分，谁可以依赖谁，车辆信号（如车速、挡位、灯光）通过什么接口进入应用。
- 模块化与解耦：功能模块如何拆分，模块间通过接口还是事件通信，如何避免"改一个页面影响整个应用"。
- 多屏与多用户：仪表、中控、副驾屏、HUD如何共享数据又各自渲染；不同驾驶员账号如何隔离配置与数据。
- 性能与稳定性：冷启动时间、内存峰值、ANR率、崩溃率如何设定目标并在架构层面预留手段。
- 可升级与可诊断：OTA升级时如何保证数据兼容，售后如何通过日志定位问题。
这五类关注点会在后续章节逐一展开。这里先给出一个判断标准：如果一个决策在项目中期修改需要超过两周，它就应该在架构阶段被明确记录并评审。
四、整体学习路径与实战项目
本课程共30章，整体按"认知—设计—实现—验证—交付"推进。前几章建立差异认知与架构方法论；中间章节深入分层、模块化、车辆信号接入、多屏多用户、状态管理、性能优化、稳定性治理；后段进入OTA、诊断、安全合规与架构评审；最后以一个完整的实战项目收束。
实战项目设定为"车载多媒体与车辆状态联动应用"，运行在AAOS环境，包含以下可交付物：
- 一份架构设计文档，含分层图、模块依赖图、关键接口定义。
- 一个可编译运行的工程骨架，包含UI层、业务层、数据层与车辆信号适配层。
- 一组性能与稳定性指标基线，例如冷启动≤1.5秒、内存峰值≤180MB、连续运行2小时无ANR。
- 一次架构评审记录，包含决策理由与被否决方案。