12、车载网络与连接：WLAN 与以太网管理、CarNetworkService、远程信息处理（T-Box）

各位同学，今天我们来聊聊车载系统里一个特别“接地气”但又极其关键的部分——网络与连接。

你想想看，一辆智能汽车，如果连不上网，那它跟一台功能机有什么区别？导航没法实时更新、语音助手变哑巴、OTA升级更是无从谈起。所以，车载网络这块，说白了就是整车的“神经系统”。

我个人习惯把车载网络分为两大块：一块是车内通信，比如以太网、CAN总线这些；另一块是车外通信，也就是T-Box负责的蜂窝网络、WLAN这些。今天咱们重点讲WLAN、以太网管理，以及CarNetworkService这个核心服务，最后再聊聊T-Box。

12.1 WLAN 管理：不仅仅是连个Wi-Fi

很多人觉得WLAN嘛，不就是手机连Wi-Fi那套？其实在车上，情况要复杂得多。

车载WLAN有几个典型场景：

• 车主手机连接车机热点：车机作为AP，提供网络共享。
• 车机连接外部Wi-Fi：比如在自家车库，车机连上家庭Wi-Fi下载OTA包。
• 车机作为Station同时开启P2P：用于无线投屏、手机互联等。

在Android Automotive中，WLAN的管理是通过WifiManager和底层的wpa_supplicant来完成的。但车载场景下，我们往往需要更精细的控制。

我曾经在一个项目中遇到过这样的坑：某款芯片宣称支持双模式，但实际测试发现，当Station和AP同时开启时，吞吐量掉得厉害，甚至出现断连。后来排查发现是驱动层的电源管理策略有问题，一进入省电模式就把其中一个接口的功率降了。嗯，这里要注意，选型时一定要做足压力测试。

12.1.1 WLAN 状态机与连接策略

车载WLAN的连接策略跟手机不太一样。手机通常是“用户手动连”，但车机需要更智能的决策。

举个例子：车机在行驶过程中，不应该主动去扫描周围的Wi-Fi，因为这会干扰蜂窝网络。只有在停车状态下，才允许进行WLAN扫描和连接。

我建议在实现时，定义一个WifiStateMachine，它监听车辆的CarPowerState：

// 伪代码示例
if (carPowerState == POWER_STATE_ON_DRIVE) {
    disableWifiScan();
    keepCurrentConnectionIfAny();
} else if (carPowerState == POWER_STATE_ON_PARK) {
    enableWifiScan();
    triggerAutoConnect();
}

另外，车载WLAN还有一个特殊需求：优先连接已保存的、信号强度足够的网络。如果同时有多个已知网络，应该选择信号最好的那个，而不是像手机那样弹个列表让用户选。

12.2 以太网管理：车内骨干网

以太网在车载领域越来越重要。为什么？因为ADAS、高清地图、车载娱乐系统这些“吃带宽”的应用，CAN总线那点速率根本不够看。

车载以太网通常使用100BASE-T1或1000BASE-T1，物理层是单对双绞线，跟咱们办公室的以太网不太一样。但上层的IP协议栈是一样的。

在Android Automotive中，以太网的管理是通过EthernetManager和EthernetNetworkFactory来实现的。但有个问题：标准Android的以太网管理比较简单，基本就是插拔网线自动连。但在车上，以太网端口是固定的，而且可能有多个物理端口（比如一个连T-Box，一个连座舱域控制器）。

12.2.1 多网络优先级与路由策略

一辆车可能有多个网络接口：WLAN、以太网、蜂窝网（通过T-Box）。那么问题来了：数据包到底走哪个接口？

Android系统本身有ConnectivityService来管理网络优先级，但车载场景下，我们需要自定义策略。

举个例子：OTA下载时，优先走以太网（如果可用），其次走WLAN，最后走蜂窝网。而且，当以太网连接时，应该把默认路由切换到以太网，同时保留蜂窝网用于紧急呼叫（eCall）。

我曾在项目中实现过一个CarNetworkPolicyManager，它维护一个优先级列表：

// 网络优先级配置
NetworkPolicy[] policies = {
    new NetworkPolicy(TRANSPORT_ETHERNET,  PRIORITY_HIGH),
    new NetworkPolicy(TRANSPORT_WIFI,      PRIORITY_MEDIUM),
    new NetworkPolicy(TRANSPORT_CELLULAR,  PRIORITY_LOW)
};

当某个网络可用时，系统自动将默认路由切换到优先级最高的那个。同时，低优先级的网络仍然保持连接，用于特定应用（比如eCall）。

12.3 CarNetworkService：车载网络的“大管家”

好了，前面讲了WLAN和以太网各自的管理，但实际开发中，我们需要一个统一的入口来管理所有网络。这就是CarNetworkService的职责。

CarNetworkService是Android Automotive中CarService的一部分。它负责：

• 监听所有网络接口的状态变化。
• 根据车辆状态（驾驶/停车/充电）调整网络策略。
• 向上层应用提供统一的API，比如isNetworkAvailable()、getPreferredNetwork()。

说白了，它就是车载网络的“大管家”。你不需要关心底层是WLAN还是以太网，只需要问它“现在能不能上网？”它就会给你一个靠谱的答案。

下面这张图展示了CarNetworkService在车载网络架构中的位置：

从图中可以看出，CarNetworkService处于中间层，它屏蔽了底层网络接口的差异，向上层应用提供统一的网络服务。这样做的好处是：当底层硬件更换时（比如换了另一家的Wi-Fi芯片），上层应用完全不需要改动。

12.4 远程信息处理（T-Box）：车联网的“心脏”

最后，我们来聊聊T-Box。T-Box（Telematics Box）是车载远程信息处理的核心硬件。它通常包含：

• 4G/5G 蜂窝通信模块
• GPS/北斗定位模块
• 蓝牙模块（用于蓝牙钥匙、蓝牙电话）
• 一个独立的MCU或SoC，运行轻量级RTOS或Linux

T-Box的主要职责是：

1. 车外通信：通过蜂窝网络连接云端，上传车辆状态、接收远程指令。
2. 定位服务：提供高精度定位，用于导航、紧急救援（eCall）。
3. 蓝牙网关：作为蓝牙中心节点，连接手机、蓝牙钥匙等设备。
4. 安全通信：支持TLS/SSL加密，确保数据传输安全。

我记得有一次，客户反馈说车辆在隧道里丢失了GPS信号，导致导航偏移。排查后发现，T-Box的GPS天线安装位置不对，被车顶的金属结构遮挡了。嗯，硬件布局的问题，软件再牛也救不了。所以，做T-Box开发时，一定要跟硬件团队确认天线布局。

12.4.1 T-Box 与车机的通信协议

T-Box与车机之间的通信，通常走以太网，使用标准的TCP/IP协议栈。但应用层协议各家不同，常见的有：

• MQTT：轻量级，适合车况上报、远程控制。
• HTTP/HTTPS：用于OTA下载、地图数据更新。
• 私有协议：一些厂商会自定义二进制协议，用于低延迟场景（比如远程启动发动机）。

我建议在车机端封装一个CarTelematicsManager，提供如下API：

// 远程信息处理API示例
public class CarTelematicsManager {
    // 发送远程控制指令（如开锁、关窗）
    public void sendRemoteCommand(String command, Bundle params);
    
    // 获取当前车辆位置
    public Location getVehicleLocation();
    
    // 检查T-Box连接状态
    public boolean isTBoxConnected();
    
    // 监听T-Box事件（如eCall触发）
    public void registerTBoxCallback(TBoxCallback callback);
}

这里有个细节：T-Box的eCall功能是独立于车机系统的。即使车机死机了，T-Box仍然可以独立拨打紧急电话。所以，在设计时，eCall的触发逻辑一定要放在T-Box内部，而不是依赖车机。

12.5 小结

好了，今天的内容就到这里。我们讲了WLAN和以太网的管理，重点介绍了CarNetworkService这个核心服务，最后聊了T-Box的职责和通信方式。

车载网络这块，说白了就是“连接”二字。但要把连接做好，让用户感觉不到网络的存在，才是最高境界。你想想看，用户上车后，音乐自动缓存、导航自动更新、OTA静默完成——这些背后，都是我们今天讲的内容在支撑。

下次遇到网络问题，别急着甩锅给硬件，先看看CarNetworkService的策略配置对不对。

---