3. 车载Android应用开发基础：Activity与Service在车载场景下的特殊生命周期管理
各位同学，咱们今天聊聊车载场景下Activity和Service的生命周期。说实话，这东西跟手机上的差别太大了。我刚开始做车载项目时，拿着手机那套经验直接往上套，结果被坑得够呛。
为什么会这样？你想想看，手机是你个人的，想开就开，想关就关。但车机不一样，它要跟车辆状态深度绑定。比如你正在导航，突然倒车了，这时候导航界面该不该被倒车影像覆盖？覆盖之后回来，导航数据还在不在？
嗯，这就是车载场景下生命周期管理的核心问题。
3.1 Activity的“非标准”生命周期
手机上的Activity生命周期，大家都很熟悉：onCreate → onStart → onResume → onPause → onStop → onDestroy。但在车载场景下，这套流程会被打断。
第一个特殊点：多窗口模式下的生命周期变化
车机现在普遍支持分屏，比如左边导航，右边音乐。这时候两个Activity都处于可见状态，但只有一个是真正获得焦点的。我记得有一次调试，发现音乐App的onPause被频繁调用，查了半天才发现是分屏切换焦点导致的。
关键结论：在车载多窗口模式下，Activity的onPause不再意味着用户离开了当前应用，而只是失去了焦点。onStop也不一定触发，因为另一个Activity可能只是部分遮挡。
第二个特殊点：车载特有的“显示优先级”
车机上有个概念叫“显示优先级”。比如倒车影像的优先级最高，来电界面次之，导航再次之。当高优先级界面弹出时，当前Activity会被强制进入onPause甚至onStop状态。
我建议你在处理这种场景时，不要在onPause里做太重的操作。我曾经见过一个项目，在onPause里保存大量数据，结果倒车影像弹出时卡顿了半秒，用户投诉说倒车影像延迟。
避坑指南：onPause中不要做耗时操作，尤其是IO操作。如果必须保存状态，使用onSaveInstanceState替代。
3.2 Service的“常驻”与“保活”
车载Service跟手机Service最大的区别在于：车机要求Service必须稳定、常驻。你不能像手机那样，系统内存不够就把Service杀了。
前台Service是标配
在车载场景下，几乎所有重要的Service都要以前台Service的形式运行。比如语音助手、导航引擎、蓝牙连接等。为什么？因为车机系统对后台进程的管理策略跟手机完全不同。
我记得有个项目，导航Service用的是普通后台Service，结果用户开车半小时后，导航突然没声音了。查日志发现Service被系统回收了。从那以后，我要求所有核心Service必须绑定前台通知。
// 车载前台Service的标准写法
public class NavigationService extends Service {
@Override
public void onCreate() {
super.onCreate();
// 创建通知渠道
NotificationChannel channel = new NotificationChannel(
"nav_channel",
"导航服务",
NotificationManager.IMPORTANCE_HIGH
);
// 构建通知
Notification notification = new Notification.Builder(this, "nav_channel")
.setContentTitle("导航运行中")
.setContentText("正在为您导航")
.setSmallIcon(R.drawable.ic_nav)
.build();
// 启动前台服务
startForeground(1, notification);
}
}
个人经验：车载Service的onStartCommand返回值一定要用START_STICKY。这样即使Service被异常杀死，系统也会自动重启。我习惯在onStartCommand里加上重连逻辑，确保Service能快速恢复。
绑定Service vs 启动Service
在车载场景下，我建议优先使用绑定Service。为什么？因为绑定Service的生命周期跟客户端绑定。比如你的音乐App，当用户切到导航界面时，音乐Service不应该停止，但可以降低优先级。
说白了，绑定Service更适合“服务跟随客户端”的场景。而启动Service更适合“服务独立运行”的场景，比如后台下载地图数据。
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 导航引擎 | 启动Service + 前台通知 | 需要独立运行，不受UI影响 |
| 音乐播放 | 绑定Service | 跟随音乐App的生命周期 |
| 蓝牙连接 | 启动Service + 前台通知 | 需要常驻，即使UI关闭 |
| 语音识别 | 绑定Service | 只在语音界面时工作 |
3.3 车载特有的生命周期回调
车机系统在标准Android生命周期之外，还增加了一些车载特有的回调。比如：
- onCarModeChanged：当车辆进入或退出车载模式时触发
- onDrivingStateChanged：当驾驶状态变化时触发（行驶/驻车）
- onDisplayPriorityChanged：当显示优先级变化时触发
这些回调是车载系统独有的，手机上没有。我建议你在Activity中注册这些回调，以便及时响应车辆状态变化。
核心原则：车载Activity和Service的生命周期管理，核心是“状态感知”和“优先级管理”。你要时刻知道车辆当前的状态，并根据状态调整你的组件行为。
3.4 实战中的避坑指南
最后，我总结几个实战中容易踩的坑：
- 不要在onPause里做UI操作：车载场景下onPause可能频繁触发，UI操作会导致ANR。
- Service的onDestroy不一定会执行：系统强杀Service时，onDestroy可能不调用。所以重要的状态要实时保存。
- 注意多用户场景：车机可能支持多用户切换，切换时所有Activity和Service都会被销毁重建。
- 前台通知不能取消：一旦Service以前台方式运行，通知就不能被用户手动清除。否则Service会被降级为普通Service。
嗯，今天就先聊这么多。车载场景下的生命周期管理，说白了就是“适应车辆状态，保持服务稳定”。你只要记住这个核心原则，大部分问题都能迎刃而解。