第19章车载设置应用定制

课程目录第19章车载设置应用定制

车载设置应用定制：从Settings到车辆控制

车载系统的设置应用，跟手机上的Settings完全是两码事。手机Settings你改改Wi-Fi、调调亮度就完事了，但车载Settings要管的是灯光、空调、驾驶模式这些跟车控相关的硬核功能。我刚开始做车载系统时，第一反应是「直接改AOSP Settings不就行了？」——结果踩了一堆坑。

今天我们就来聊聊，车载Settings应用到底该怎么定制。我会从架构设计讲起，再到具体的车辆设置项、开发者选项，最后聊聊系统更新UI的设计思路。

1. Settings应用架构：别被AOSP带偏了

AOSP的Settings应用，说白了是一个巨大的Fragment容器。它用Dashboard设计，左边是分类列表，右边是具体设置页。这个架构在手机上没问题，但在车上——嗯，问题很大。

为什么？因为车载屏幕的交互逻辑完全不同。驾驶员在开车时，视线离开道路的时间不能超过2秒。你想想看，如果设置项藏得很深，驾驶员要翻好几页才能找到空调开关，这安全吗？

我个人习惯的做法是：重新设计导航层级。把最常用的车辆控制项（灯光、空调、驾驶模式）放在一级页面，而不是藏在二级菜单里。

  核心思路： 车载Settings的架构应该是「扁平化 + 快捷入口」，而不是「树形层级」。

来看一个我常用的架构设计：

// 车载Settings的Fragment层级设计
// 一级页面（直接可见）
- VehicleSettingsFragment (车辆控制主页面)
  - LightControlFragment (灯光控制)
  - ClimateControlFragment (空调控制)
  - DriveModeFragment (驾驶模式)
  
// 二级页面（需要滑动或点击进入）
- SystemSettingsFragment (系统设置)
  - DisplayFragment (显示)
  - SoundFragment (声音)
  - NetworkFragment (网络)
  
// 隐藏页面（需要特殊入口）
- DeveloperOptionsFragment (开发者选项)
- SystemUpdateFragment (系统更新)

这个设计的好处是：驾驶员在行驶中，只需要一次点击就能进入灯光或空调控制。我曾经在项目里见过一个反面案例——他们把空调控制放在了三级菜单里，结果客户试驾时直接骂娘。

2. 车辆设置项：灯光、空调、驾驶模式

车辆设置项跟普通设置项最大的区别是：它们需要跟车辆硬件通信。你不能像改Wi-Fi那样直接写个SharedPreferences就完事了。

2.1 灯光控制

灯光控制涉及近光灯、远光灯、雾灯、日间行车灯等。在Android系统里，这些通常通过CarService的CarLightManager来控制。

// 灯光控制示例代码
public class LightControlFragment extends Fragment {
    private CarLightManager mLightManager;
    
    @Override
    public void onViewCreated(View view, Bundle savedInstanceState) {
        // 获取CarLightManager实例
        Car car = Car.createCar(getContext());
        mLightManager = (CarLightManager) car.getCarManager(Car.LIGHT_SERVICE);
        
        // 控制近光灯
        mLightManager.setLightState(
            CarLightManager.LIGHT_NEAR, 
            CarLightState.STATE_ON
        );
    }
}

避坑指南： 我曾经遇到过一个问题——灯光状态在UI上显示为「开启」，但实际车灯没亮。后来发现是CarLightManager的setLightState是异步的，需要监听回调才能确认状态。所以，一定要在回调里更新UI，不要直接假设设置成功了。

2.2 空调控制

空调控制更复杂。温度、风量、风向、座椅加热、方向盘加热……每个都是独立的状态。而且空调的响应速度直接影响用户体验——你想想，大冬天上车，按了加热按钮3秒没反应，谁受得了？

我建议的做法是：使用HvacManager的批量更新接口，而不是一个一个地发指令。

// 空调批量更新示例
HvacManager hvacManager = (HvacManager) car.getCarManager(Car.HVAC_SERVICE);

// 批量设置温度和风量
hvacManager.setTemperature(22.5f);  // 设置温度
hvacManager.setFanSpeed(3);         // 设置风量
hvacManager.setAirRecirculation(true); // 内循环

注意： 不同车型的空调控制协议完全不同。有的车用CAN总线，有的用LIN总线，还有的用以太网。你在做定制时，一定要先搞清楚底层通信协议，否则UI做得再漂亮也是白搭。

2.3 驾驶模式

驾驶模式（经济、舒适、运动、越野等）是车载系统的特色功能。它不只是改个图标，而是要联动发动机、变速箱、悬架、转向等多个ECU。

在Android系统里，驾驶模式通常通过Vehicle HAL的VEHICLE_PROPERTY_DRIVING_MODE属性来控制。

// 驾驶模式切换示例
public void setDriveMode(int mode) {
    // mode: 0=经济, 1=舒适, 2=运动, 3=越野
    VehiclePropValue prop = new VehiclePropValue();
    prop.prop = VehicleProperty.DRIVING_MODE;
    prop.value = mode;
    
    // 通过Vehicle HAL发送
    mVehicle.set(prop);
}

这里有个坑：驾驶模式切换时，车辆可能会有短暂的「顿挫感」。我在项目里遇到过，切换模式时发动机转速突然飙升，把测试人员吓了一跳。后来我们在UI上加了「切换中」的动画，让用户知道系统正在处理，而不是卡死了。

3. 开发者选项定制

开发者选项在车载系统里，跟手机上的完全不同。手机上的开发者选项是给App开发者用的，但车载的开发者选项是给整车厂工程师用的。

你需要定制的内容包括：

车辆诊断信息：显示CAN总线数据、ECU状态、故障码等
传感器数据：车速、转速、油温、胎压等实时数据
日志抓取：一键抓取系统日志、HAL日志、CAN日志
OTA测试：强制检查更新、回滚版本、模拟升级失败

// 开发者选项中的诊断信息展示
public class DiagnosticFragment extends Fragment {
    @Override
    public void onViewCreated(View view, Bundle savedInstanceState) {
        // 显示车辆VIN码
        TextView vinView = view.findViewById(R.id.vin);
        vinView.setText(getVehicleProperty(VehicleProperty.VIN));
        
        // 显示当前车速
        TextView speedView = view.findViewById(R.id.speed);
        speedView.setText(getVehicleProperty(VehicleProperty.PERF_VEHICLE_SPEED) + " km/h");
    }
}

我的经验： 开发者选项一定要加「退出确认」功能。我曾经见过一个测试工程师，在开发者选项里乱改参数，结果把车辆的ESP系统搞乱了，最后只能刷机恢复。所以，每次修改参数时，都弹个确认框，让用户知道自己在干什么。

4. 系统更新UI设计

系统更新UI，说白了就是OTA升级的界面。这个界面看起来简单，但设计不好会出大问题。

你想想看：如果升级过程中突然断电，或者用户误操作点了「取消」，车辆可能就变砖了。所以，系统更新UI的核心原则是：清晰、安全、不可逆。

4.1 更新流程设计

我建议的更新流程是这样的：

检查更新：显示当前版本、最新版本、更新内容列表
下载确认：提示下载大小、预计时间、是否使用流量
下载中：显示进度条、剩余时间、下载速度
安装确认：提示「安装过程中请勿断电，车辆将无法使用约15分钟」
安装中：显示进度、禁止任何操作（包括返回键）
安装完成：提示重启，重启后显示更新成功

// 系统更新UI的状态机
public enum UpdateState {
    CHECKING,       // 检查中
    DOWNLOADING,    // 下载中
    DOWNLOADED,     // 下载完成
    INSTALLING,     // 安装中
    INSTALLED,      // 安装完成
    FAILED          // 失败
}

重要： 安装过程中，一定要禁用电源键和返回键。我曾经在项目里遇到过，用户安装更新时按了电源键，结果系统进入了休眠，更新进程被杀死，车辆直接变砖。后来我们加了一个「安装锁」，任何按键都不响应，只显示进度。

4.2 UI设计要点

系统更新UI的视觉设计，我总结了几点：

大字体：驾驶员在行驶中看不清小字，至少用24sp以上
高对比度：背景用深色，文字用亮色，避免阳光反射看不清
进度条要真实：不要用假进度条，用户会察觉。我见过一个项目，进度条走到80%卡了10分钟，用户直接骂街
错误提示要友好：不要说「Error 0x80070005」，要说「网络连接失败，请检查Wi-Fi」

知识体系总览

下面这张图，是我对本章内容的总结。你可以看到，车载Settings应用定制，核心就是三个维度：架构设计、车辆控制、安全机制。

好了，关于车载Settings应用定制，核心内容就这些。记住一句话：不要拿手机Settings的思路来做车载Settings。手机可以慢慢翻，但车不行——驾驶员的安全永远是第一位的。

📚 课程目录

车载设置应用定制：从Settings到车辆控制

1. Settings应用架构：别被AOSP带偏了

2. 车辆设置项：灯光、空调、驾驶模式

2.1 灯光控制

2.2 空调控制

2.3 驾驶模式

3. 开发者选项定制

4. 系统更新UI设计

4.1 更新流程设计

4.2 UI设计要点

知识体系总览