---

背景痛点：当多用户遇上多屏幕

车载系统正在从单驾驶员交互演变为全座舱交互场景，但多用户同时操作不同屏幕时会遇到：

1. SurfaceFlinger资源竞争：当后排乘客播放视频时，若驾驶员同时操作导航，SurfaceFlinger的图层混合可能因优先级错配导致卡顿
2. 跨进程权限漏洞：儿童账户通过Intent跳转可访问驾驶员设置的API接口，存在安全风险
3. 用户切换延迟：传统Android多用户切换需重启SystemServer，无法满足车载场景秒级切换需求

技术方案选型对比

1. Linux容器隔离
2. 优点：强隔离性，可限制CPU/内存用量

3. 缺点：启动耗时长（约3秒），无法共享Framework服务

4. Android多用户模式

5. 优点：系统原生支持，用户数据天然隔离

6. 缺点：默认需要重启服务，Profile切换平均耗时1.8秒

7. 虚拟化方案

8. 优点：可运行不同OS版本
9. 缺点：GPU透传性能损耗达30%，不符合车规实时性要求

最终选择：改造Android多用户模式，引入UserLifecycleController实现热切换

核心实现方案

多屏渲染管线改造

关键时序流程：

1. WindowManagerService接收触摸事件时，通过DisplayAddress区分物理屏幕
2. 动态创建虚拟Display，绑定到指定用户的SurfaceControl
3. 修改SurfaceFlinger的setLayerStack()逻辑，实现不同用户图层独立合成

// 示例：创建虚拟Display关联用户
fun createVirtualDisplayForUser(userId: Int, displayName: String) {
    val dm = displayManager
    val flags = DisplayManager.VIRTUAL_DISPLAY_FLAG_PUBLIC
    dm.createVirtualDisplay(
        "$displayName-$userId",  // 包含用户ID的display名
        width, height, density,
        null, flags
    ) { display ->
        // 将display与用户会话绑定
        wms.setDisplayUser(display, userId)
    }
}

用户Profile秒级切换

通过拦截Binder调用实现：

1. 定制ActivityManagerService的startActivityAsUser()方法
2. 使用HandlerThread预加载常用组件
3. 关键AIDL接口定义：

interface IUserSessionController {
    // 带过渡动画的切换方法
    void switchUserWithAnimation(in int userId, in Bundle animOptions);

    // 获取当前活跃用户
    int getForegroundUser();
}

生产环境优化技巧

内存泄漏检测

车载场景特殊问题：

• VehicleHal回调持有Activity引用
• SensorManager跨用户注册未及时注销

解决方案：

1. 定制LeakCanary的ObjectWatcher：

class VehicleWatcher : ObjectWatcher {
    override fun expectWeaklyReachable(
        object: Any,
        description: String
    ) {
        if (object is IVehicleCallback.Stub) {
            // 忽略Hal层合法持有
            return  
        }
        super.expectWeaklyReachable(object, description)
    }
}

1. 在UserSwitchObserver中强制GC并生成报告

ISO 26262合规策略

1. 定义ASIL等级对应处理方式：

2. ASIL B：记录日志并降级运行

3. ASIL D：立即安全停用相关功能

4. 使用Watchdog监控关键服务：

<!-- res/xml/watchdog_services.xml -->
<service 
    name="com.android.car.UserService"
    timeout="2000"
    asilLevel="B" />

延伸实践：冷启动优化

车载系统冷启动的特殊性：

1. Metrics监控项：
2. boot_completed_to_ui_ready：应<3秒

3. user_switch_latency：应<800ms

4. 优化手段：

5. 预加载常用APK的DexFile
6. 使用AppPredictor预测下个用户可能启动的应用

通过dumpsys car_service可获取详细时序数据：

adb shell dumpsys car_service --metrics

总结建议

在实际项目中，我们发现这些经验特别有价值：

1. 必须用InstrumentationTest模拟多用户并发操作
2. 方向盘按键事件需特殊处理用户上下文
3. 推荐使用Android Automotive OS 12+的MultiDisplay API