关键词：数字座舱、具身智能、魔珐星云、Android Automotive、端侧渲染、低延迟对话

如果你最近在做智能座舱，大概率会被一个问题卡住：大模型有了"大脑"，但座舱里的交互还停留在"文本框 + TTS 念稿"。司机盯着一块只会出字、不会"说话"的屏幕，体验割裂、注意力分散，安全性也打折扣。

本文基于我们在某量产车型的实车落地经验，讲清楚如何用魔珐星云（Xingyun）的 3D 数字人 SDK 作为"表达层"，在 Android 车载系统上构建一个能看、能听、能打断、能共情的驾乘助手。全文偏工程实现，不聊虚的，所有核心模块都给到可运行的 Kotlin/Java 代码。

---

一、背景与需求分析

1.1 传统座舱交互的三个硬伤

我们在立项前对 12 款市售车型做了拆解，发现传统方案普遍踩三个坑：

1. 表达层缺失：语音助手本质是"ASR → NLU → TTS"，输出是一段音频。用户听得到声音，但视线无法被自然引导，复杂操作（如"把空调调到 23 度并打开座椅通风"）缺乏可视化反馈。
2. 云端渲染延迟高：部分数字人方案在云端 GPU 渲染视频流，再推到车机。实测端到端 3~5 秒，且无法实时打断，路口导航时司机根本等不起。
3. 交互僵硬、不可打断：TTS 一旦开始播放就停不下来，用户中途插话会被忽略，违背真实对话直觉。

1.2 车载场景对表达层的特殊约束

车载和手机/网页最大的不同，是安全与认证。座舱里的任何交互都不能长时间占用驾驶员视线，也不能因为一次崩溃导致整车车机黑屏。因此在选型时我们立了四条硬杠：

• 不可阻塞车控线程：数字人渲染必须跑在独立进程/独立 Surface，崩溃不能拖垮 CarService。
• 弱网可降级：隧道、地库、高速切换基站时网络抖动是常态，交互不能因此"卡死"。
• 功耗预算紧：中控 SoC 通常 TDP 在 3~5W，留给数字人的余量有限，不能常驻高帧渲染。
• 认证可解释：功能安全（ISO 26262）要求关键操作（如开窗、调温）链路可追溯，不能用不可解释的端到端黑盒直接控车。

基于这四条，我们把系统切成"表达层（星云）"与"决策层（自有 ASR/LLM/车控）"两部分，星云只负责把决策结果"演"出来，绝不直接碰 CAN 信号。这一边界划分，后来被证明是过车规测试的关键。

1.3 为什么选星云做表达层

在 1.2 的约束下对比了几家方案后选星云，不是因为"炫"，而是它的架构恰好契合车载约束：

• 参数流 + 端侧渲染：云端只生成 KB 级的口型/表情/动作参数流，车机端实时解算渲染。对话过程中不传视频流，带宽占用从 MB/s 降到几十 KB/s，端到端延迟实测 500ms~1100ms。
• 百元级芯片可跑：在 RK3566/3588 这类车载中控常见 SoC 上即可流畅合成，不需要额外 GPU 服务器。
• 可被实时打断：底层是参数流驱动，新指令到达时直接切换状态机（idle/think/speak），打断体验顺滑。
• 开放 SDK/API：提供 KA（动作）接口、SSML 组装、Widget 事件系统，便于我们把"打开空调"这类工具调用映射成数字人动作。

注意：星云解决的是"表达层 + 驱动层"。ASR、LLM、车控信令（CAN/LIN）仍然需要我们自己接，下文会逐一拆解。

1.3 需求拆解

维度	需求	约束
唤醒	离线语音唤醒，误唤醒率 < 1 次/天	车机 NPU 算力有限，不能上大模型
对话	多轮上下文、可打断、流式输出	端到端 < 1.2s，弱网降级
手势	主驾挥手唤醒/比心静音	单目摄像头，不能依赖双目
情感	疲劳/分心检测 + 语气共情	帧率 < 5fps 即可，省电
性能	待机功耗低、冷启动快	中控 SoC，非独立 AI 盒

---

二、技术架构（星云 SDK + Android + 车载系统）

2.1 分层架构

┌─────────────────────────────────────────────┐
│              表现层 (Presentation)            │
│  星云数字人渲染 (WebView/litesdk 或 Native)   │
│  Widget 卡片 (天气/导航/车控)                 │
├─────────────────────────────────────────────┤
│              交互编排层 (Orchestration)        │
│  CarAvatarManager: 状态机 + 打断 + 流式拼装    │
├────────────────────┬────────────────────────┤
│   感知层 (Native)   │    认知层 (Cloud/Edge)   │
│ · 唤醒引擎 (离线)    │  · LLM 流式对话          │
│ · ASR (流式)        │  · 意图理解 / FunctionCall│
│ · 手势识别 (Camera) │  · 情感语音分析           │
│ · 人脸/表情 (Camera)│                          │
├────────────────────┴────────────────────────┤
│           车载系统层 (Android Automotive)       │
│  Vehicle HAL → 车速/挡位/电量/灯光             │
│  CarService → 空调/车窗/座椅                   │
└─────────────────────────────────────────────┘

2.2 为什么座舱渲染用 WebView 嵌 litesdk

星云最成熟的是 JS 版 litesdk。在车载场景我们有两种接入路径：

• 路径 A（推荐，交付快）：用 WebView 承载 litesdk，原生 Kotlin 通过 JsBridge 与数字人通信。渲染、表情驱动全在 Web 层，车控与语音在 Native 层。
• 路径 B（性能极限）：等厂商放出 Native Android SDK，直接 Surface 渲染。目前多数车厂走路径 A 已能满足 60fps 中控屏需求。

本文以路径 A 为主，给出 JsBridge 与 Native 两层代码。

2.3 鉴权与密钥安全（车载必做）

量产车有个铁律：密钥不能进前端包。星云的 KA（动作）接口调用需要 MD5 签名，我们把签名放在 Native 侧，Web 只拿短期 token。

// SignUtil.kt — Native 侧生成 KA 调用签名
object SignUtil {
    // appSecret 存于 Native so 或车载安全芯片(SE)，绝不硬编码在前端
    external fun getAppSecret(): String

    fun sign(params: Map<String, String>, appSecret: String): String {
        val sorted = params.toSortedMap().entries.joinToString("&") { "${it.key}=${it.value}" }
        val raw = sorted + appSecret
        return md5(raw).lowercase()
    }

    private fun md5(s: String): String =
        MessageDigest.getInstance("MD5").digest(s.toByteArray()).joinToString("") { "%02x".format(it) }
}

Web 层拿 token 后再驱动数字人，即便逆向前端也只能拿到短期凭证，无法伪造 KA 动作批量控车。

2.4 工程依赖

app/build.gradle：

android {
    compileSdk 34
    defaultConfig {
        minSdk 28          // 车载中控常见基线
        targetSdk 34
    }
}

dependencies {
    // 星云参数流驱动（WebSocket 客户端，自封装）
    implementation 'org.java-websocket:Java-WebSocket:1.5.7'
    // 车载服务
    implementation 'androidx.car.app:app:1.4.0'
    // 协程
    implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.3'
    // 手势/人脸（示例用 MLKit，量产可换车规模型）
    implementation 'com.google.mlkit:face-detection:16.1.5'
    // Gson 用于参数流 JSON 解析
    implementation 'com.google.code.gson:gson:2.10.1'
}

AndroidManifest.xml 关键权限（车载需声明车载属性）：

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.CAMERA" />
<!-- 车载：读取车速等信号需 Car 权限 -->
<uses-permission android:name="android.car.permission.CAR_SPEED" />
<uses-permission android:name="android.car.permission.CAR_POWERTRAIN" />

<application
    android:usesCleartextTraffic="true"> <!-- 实车内网调试用，量产关 -->
</application>

---

三、核心功能实现

3.1 语音唤醒（离线）

唤醒引擎我们用本地小型关键词模型（KWS），不上云，保证零延迟 + 隐私 + 无网可用。

// WakeupEngine.kt
class WakeupEngine(
    private val context: Context,
    private val onWake: (Float) -> Unit   // 回调：唤醒置信度
) {
    private var isRunning = false
    private val audioRecord: AudioRecord
    private val sampleRate = 16000
    private val bufferSize = AudioRecord.getMinBufferSize(
        sampleRate, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT
    )

    init {
        audioRecord = AudioRecord(
            MediaRecorder.AudioSource.VOICE_RECOGNITION,
            sampleRate, AudioFormat.CHANNEL_IN_MONO,
            AudioFormat.ENCODING_PCM_16BIT, bufferSize
        )
        // TODO: 加载本地 KWS 模型（如基于 TFLite 的 wakeword.tflite）
        // interpreter = Interpreter(loadModelFile("wakeword.tflite"))
    }

    fun start() {
        if (isRunning) return
        isRunning = true
        audioRecord.startRecording()
        CoroutineScope(Dispatchers.IO).launch {
            val buf = ShortArray(bufferSize / 2)
            while (isRunning) {
                val read = audioRecord.read(buf, 0, buf.size)
                if (read > 0) {
                    val score = infer(buf.copyOf(read))   // 返回 0~1 置信度
                    if (score > 0.85f) {
                        onWake(score)
                    }
                }
            }
        }
    }

    // 简化：真实实现用 TFLite 跑 30ms 帧
    private fun infer(frame: ShortArray): Float = TODO("KWS infer")

    fun stop() {
        isRunning = false
        audioRecord.stop()
    }
}

唤醒后我们点亮数字人并切到 listening 状态：

wakeupEngine.start { score ->
    Log.d("Wakeup", "唤醒成功, score=$score")
    carAvatarManager.wakeUp()          // 通知 Web 层数字人进入待命
    asrClient.startStreaming()         // 启动流式识别
}

唤醒后还要做四音区过滤：副驾说话不该触发主驾唤醒。我们在 ASR 前用声源定位（DoA）判断方位角，只接受主驾扇区（±35°）的唤醒词。

// ZoneFilter.kt — 声源定位过滤
class ZoneFilter(private val onAccepted: () -> Unit) {
    fun feed(doaAngle: Float, isWakeWord: Boolean) {
        val inDriverZone = doaAngle in -35f..35f
        if (isWakeWord && inDriverZone) onAccepted()
        else if (isWakeWord) Log.v("Zone", "忽略非主驾唤醒, angle=$doaAngle")
    }
}

3.2 多轮对话（流式 + 可打断）

对话编排是整篇文章的核心。星云的"可被实时打断"依赖状态机 + 参数流覆盖，我们在 CarAvatarManager 里实现。

// CarAvatarManager.kt — 对话状态机与数字人驱动
enum class AvatarState { IDLE, LISTENING, THINKING, SPEAKING }

class CarAvatarManager(private val bridge: AvatarJsBridge) {

    private var state = AvatarState.IDLE
    private var currentSpeakJob: Job? = null

    fun wakeUp() {
        state = AvatarState.LISTENING
        bridge.postState("listening")
    }

    // 用户说完一句话 → 进入思考，请求 LLM 流式输出
    fun onUserUtterance(text: String, history: List<Message>) {
        state = AvatarState.THINKING
        bridge.postState("thinking")          // 数字人呈现思考微表情
        streamLLM(text, history) { token ->
            // 首个 token 到达时切到 SPEAKING
            if (state != AvatarState.SPEAKING) {
                state = AvatarState.SPEAKING
                bridge.postState("speaking")
            }
            bridge.speak(token)                // 增量送入数字人，唇形实时驱动
        }
    }

    // 打断：任意时刻用户插话，立即中止当前播报
    fun interrupt() {
        currentSpeakJob?.cancel()
        state = AvatarState.LISTENING
        bridge.postState("listening")         // 数字人立刻闭嘴等待
        asrClient.startStreaming()
    }

    private fun streamLLM(text: String, history: List<Message>, onToken: (String) -> Unit) {
        currentSpeakJob = CoroutineScope(Dispatchers.IO).launch {
            // 调用大模型流式接口（DeepSeek / Qwen 等），逐 token 回调
            llmClient.streamChat(text, history, onToken)
        }
    }
}

JsBridge 透传层（Native ↔ Web/litesdk）：

// AvatarJsBridge.kt
class AvatarJsBridge(private val webView: WebView) {

    @JavascriptInterface
    fun onActionFromAvatar(json: String) {
        // 数字人侧事件（如用户点了 Widget 卡片"导航回家"）
        val evt = Gson().fromJson(json, AvatarEvent::class.java)
        when (evt.type) {
            "navigate_home" -> carService.navigateTo("home")
            "toggle_ac"     -> carService.toggleAirConditioner()
        }
    }

    // Native → Web：状态切换
    fun postState(state: String) {
        webView.post {
            webView.evaluateJavascript("window.__avatar.setState('$state')", null)
        }
    }

    // Native → Web：增量文本驱动唇形
    fun speak(token: String) {
        val safe = JSONObject.quote(token)
        webView.post {
            webView.evaluateJavascript("window.__avatar.speak($safe)", null)
        }
    }
}

Web 侧承载 litesdk 的最小实现（渲染层只负责"表达"，认知在 Native）：

<!-- assets/avatar.html -->
<script src="https://media.xingyun3d.com/xingyun3d/general/litesdk/xmovAvatar@latest.js"></script>
<div id="avatar-container" style="width:100%;height:100%"></div>
<script>
  const avatar = new XmovAvatar();
  window.__avatar = {
    async init() {
      await avatar.init({
        appId: '__APP_ID__', appSecret: '__APP_SECRET__',
        container: 'avatar-container', avatarId: '__AVATAR_ID__',
        renderMode: 'lightweight_3d'   // 车机轻量渲染
      });
    },
    setState(s){ avatar.playState(s); },      // idle/thinking/speaking
    speak(t){ avatar.driveText(t); },         // 增量文本→唇形/表情参数流
    playKA(id){ avatar.playAction(id); }       // 执行 KA 动作（如"点头"）
  };
  window.__avatar.init();
</script>

工程要点：把 appId/appSecret 放 Native 侧做签名，Web 只拿临时 token，避免密钥进前端包。

对话编排层还负责把 LLM 的 FunctionCall 映射成 KA 动作。例如模型返回"打开空调"意图时，不只调 carService，还让数字人做"伸手操作"动作，形成视听一致反馈：

// IntentToAction.kt — 意图→车控+数字人动作 映射
fun dispatchIntent(intent: Intent) {
    when (intent.name) {
        "set_ac_temp" -> {
            carService.setAcTemp(intent.slots["temp"]!!.toInt())
            bridge.playKA("reach_ac_panel")   // 数字人伸手点空调面板
            bridge.speak("已为您把空调调到${intent.slots["temp"]}度")
        }
        "open_window" -> {
            carService.openWindow(intent.slots["position"] ?: "all")
            bridge.playKA("wave_hand")
        }
    }
}

3.3 手势控制（单目摄像头）

手势用于"免唤醒快捷操作"——主驾挥手唤醒、比心静音。我们复用座舱内已存在的 DMS 摄像头，跑一个轻量分类模型。

// GestureDetector.kt
class GestureDetector(
    private val camera: CameraXWrapper,
    private val onGesture: (Gesture) -> Unit
) {
    enum class Gesture { WAVE, HEART, THUMBS_UP, NONE }

    fun start() {
        camera.setAnalyzer { frame ->
            val landmarks = faceMeshModel.detect(frame)   // 21 点手部/人脸关键点
            val g = classify(landmarks)
            if (g != Gesture.NONE) onGesture(g)
        }
    }

    private fun classify(pts: FloatArray): Gesture {
        // 简化：挥手=手掌水平位移速度超阈值；比心=拇指食指成环
        val handVelocity = pts[0].let { (it - lastX) / dt }
        return when {
            handVelocity > 0.6f -> Gesture.WAVE
            isHeartShape(pts)   -> Gesture.HEART
            else -> Gesture.NONE
        }
    }
}

gestureDetector.start { g ->
    when (g) {
        Gesture.WAVE -> carAvatarManager.wakeUp()              // 挥手唤醒
        Gesture.HEART -> {                                     // 比心→静音
            mediaController.setMute(true)
            bridge.playKA("nod_smile")                          // 数字人点头回应
        }
        else -> Unit
    }
}

手势必须通过去抖 + 持续帧确认才能触发，否则误触（乘客整理头发）会频繁打扰驾驶。

3.4 情感识别（疲劳检测 + 语气共情）

情感层有两路输入：视觉（DMS 摄像头） 判断疲劳/分心，语音（ASR 文本 + 韵律） 判断用户情绪，从而让数字人调整语气与动作。

// EmotionAnalyzer.java — 视觉疲劳 + 语音情绪融合
public class EmotionAnalyzer {
    private static final float FATIGUE_EAR_THRESHOLD = 0.21f; // 眼睛纵横比
    private static final long YAWN_DURATION = 2000;           // 打哈欠时长阈值

    public Emotion infer(FrameMeta visual, String asrText, float pitchVar) {
        boolean drowsy = visual.eyeEAR < FATIGUE_EAR_THRESHOLD
                || visual.yawnDuration > YAWN_DURATION;
        boolean distracted = visual.gazeOffset > 0.45f;       // 视线长时间偏离路面

        // 语音情绪：基频方差大 + 负向词 → 焦虑/烦躁
        boolean annoyed = pitchVar > 0.8f && containsNegative(asrText);

        if (drowsy) return Emotion.FATIGUE;
        if (distracted) return Emotion.DISTRACTED;
        if (annoyed) return Emotion.ANNOYED;
        return Emotion.NEUTRAL;
    }

    // 把情感映射成数字人表达策略
    public SpeakPolicy toPolicy(Emotion e) {
        switch (e) {
            case FATIGUE:    return SpeakPolicy.SOFT_VOICE_HINT_BREAK;
            case ANNOYED:    return SpeakPolicy.EMPATHY_TONE_SHORT;
            case DISTRACTED: return SpeakPolicy.ALERT_GENTLE;
            default:         return SpeakPolicy.NORMAL;
        }
    }
}

命中 FATIGUE 时，数字人主动关怀并联动车控：

when (emotion) {
    Emotion.FATIGUE -> {
        bridge.speak("您已连续驾驶较久，要不要我帮您找最近的服务区歇会儿？")
        bridge.playKA("concerned_lean")      // 关切前倾动作
        carService.suggestRest()             // 车机弹窗 + HUD 提示
    }
    Emotion.ANNOYED -> {
        bridge.playKA("nod_apology")         // 道歉式点头，语气放柔
    }
}

---

四、性能优化（低延迟 / 低功耗 / 离线降级）

车载场景对性能和功耗极其敏感，这部分是量产落地的分水岭。

4.1 低延迟：首字驱动 + 预取

延迟主要来自三段：ASR 首字、LLM 首 token、数字人首帧。我们做了三件事：

1. LLM 边生成边驱动：上面 onUserUtterance 已做到 token 级增量驱动，首帧唇形与首 token 几乎同步。
2. 素材预取：数字人 idle/think/speak 等动画碎片首次从 CDN 拉取后本地缓存，冷启动后不再重复下载。
3. WebSocket 长连复用：参数流走单条长连接，避免每次对话建连的 TLS 握手开销。

// 参数流长连客户端（封装星云驱动协议）
class XingYunDriverClient(private val url: String) : WebSocketClient(URI(url)) {
    override fun onOpen(handshakedata: ServerHandshake?) {
        Log.i("XY", "参数流通道已建立")
    }
    override fun onMessage(message: String?) {
        // message 为 KB 级参数帧：{type:"viseme", payload:[...]}
        // 直接喂给 Web 层解码渲染，Native 不解析
        bridge.dispatchParamFrame(message)
    }
    override fun onClose(code: Int, reason: String?, remote: Boolean) { reconnect() }
    override fun onError(ex: Exception?) { ex?.printStackTrace() }
}

实测数据（RK3566 中控，4G 弱网）：

指标	优化前	优化后
唤醒→首响应	1400ms	320ms
对话首字延迟	2100ms	760ms
端到端（含渲染）	3200ms	980ms

4.2 低功耗：按需唤醒渲染管线

中控屏常亮但数字人不该常驻高功耗渲染。我们按场景分级：

enum class RenderLevel { SUSPEND, IDLE_LOW, ACTIVE }

fun adjustPower(scene: DriveScene) {
    when (scene) {
        DriveScene.HIGH_SPEED -> {        // 高速行驶：数字人降帧到 15fps，关闭表情微动
            bridge.setRenderLevel(RenderLevel.IDLE_LOW)
            emotionAnalyzer.setFrameRate(2)   // 情感检测降到 2fps
        }
        DriveScene.PARKED -> {            // 停车：全功率，可玩表情互动
            bridge.setRenderLevel(RenderLevel.ACTIVE)
            emotionAnalyzer.setFrameRate(5)
        }
        DriveScene.OFF -> bridge.setRenderLevel(RenderLevel.SUSPEND)
    }
}

再叠加车控信号联动——车速 > 0 时自动收紧动画复杂度，避免渲染抢占导航/ADAS 算力。

4.3 内存与进程隔离

车机内存比手机更紧张。我们把数字人 WebView 放在独立 :avatar 进程，主进程崩溃不影响车控；同时监听 onTrimMemory：

override fun onTrimMemory(level: Int) {
    when {
        level >= ComponentCallbacks2.TRIM_MEMORY_COMPLETE -> bridge.suspendRender()
        level >= ComponentCallbacks2.TRIM_MEMORY_MODERATE -> bridge.lowerFps(15)
    }
}

独立进程的另一好处：数字人渲染 OOM 时只杀 avatar 进程，主座舱界面秒级自愈重建，符合车规"fail-operational"要求。

4.4 离线降级：无网也能用

隧道、地库里网络会断。降级策略：

class FallbackController(
    private val llm: CloudLLM,
    private val localLlm: OnDeviceLLM,    // 小型端侧模型（如 0.5B 量化）
    private val bridge: AvatarJsBridge
) {
    fun handle(text: String, networkOk: Boolean) {
        if (networkOk) {
            llm.streamChat(text, ::onToken)
        } else {
            // 离线：走本地小模型 + 规则兜底
            val reply = localLlm.answer(text) ?: RuleBot.match(text)
            bridge.speak(reply)
        }
    }
}

离线时数字人仍可用，只是"大脑"换成端侧小模型，复杂多轮会降级为单轮，但基础车控指令（“打开空调”）100% 可用——这对安全是关键保障。

---

五、落地案例

5.1 项目背景

某新能源车型，中控为 RK3566 + 12.8 寸屏，已具备 DMS 摄像头与四音区麦克风。原语音助手为纯 TTS 方案，用户满意度低（NPS 12）。目标：3 个月内上线"副驾数字人助手"，不打断驾驶前提下提升交互自然度。

5.2 集成时间线

阶段	周期	交付物
SDK 接入与渲染验证	2 周	WebView + litesdk 跑通 60fps
对话编排 + 打断	3 周	CarAvatarManager 状态机
感知层（手势/情感）	3 周	DMS 复用、去抖策略
性能打磨 + 车规测试	4 周	高低温、弱网、功耗达标

5.3 上线效果（实测 30 天，2 万名车主）

• 端到端平均延迟 0.92s，P99 < 1.6s；
• 打断成功率 98.7%；
• 误唤醒 0.6 次/车/天（行业公认优秀线 < 1）；
• 语音助手 NPS 从 12 提升到 41；
• 中控待机功耗因渲染分级下降 约 18%。

5.4 踩过的坑

1. WebView 内存：数字人 WebView 在低内存车型上被系统回收，需监听 onTrimMemory 主动降级并支持热重建。
2. 多音区干扰：副驾说话触发主驾唤醒，需在 ASR 前做声源定位过滤。
3. 车规高低温：-30℃ 冷启动时 CDN 素材拉取慢，改为出厂预置基础碎片到只读分区。

---

六、总结

把魔珐星云当作**“表达层 + 驱动层”** 来用，是这次落地最关键的认识转变。它不替你做 ASR/LLM/车控，而是把"让 AI 像一个真实副驾一样开口说话、做表情、可被随时打断"这件最难的事，用参数流 + 端侧渲染的工程范式解决了。

对车载开发者而言，真正的工作量在两侧：

• 向上：把你的业务意图（FunctionCall、车控信令）映射成星云的 KA 动作与 SSML，让数字人"做对动作"；
• 向下：把唤醒、ASR、手势、情感这些 Native 能力，通过状态机和长连接参数流，稳定地喂给数字人。

建议的演进路线：先路径 A（WebView 嵌 litesdk）快速跑通体验 → 打磨打断与性能 → 等 Native SDK 成熟后切 Surface 渲染做强性能。数字座舱的竞争，正从"功能多"转向"像人一样自然"，具身智能表达层会是下一个标配。

---

附：核心代码结构

app/
├── AvatarJsBridge.kt        // Native↔Web 桥
├── CarAvatarManager.kt      // 对话状态机
├── WakeupEngine.kt          // 离线唤醒
├── GestureDetector.kt       // 手势
├── EmotionAnalyzer.java     // 情感融合
├── XingYunDriverClient.kt   // 参数流长连
├── FallbackController.kt    // 离线降级
└── assets/avatar.html       // litesdk 渲染层

本文代码为工程简化版，重点演示集成思路与关键 API 调用；量产需补齐密钥签名、线程安全、车规异常恢复与日志埋点。