在 Android Automotive OS 上建立信息娱乐程序时一个问题会反复出现：你需要将一个应用程序的使用者界面显示在另一个应用程序的界面中。其实，例如在启动器中添加手机小部件，在仪表盘中添加媒体卡片。或者在 OEM 程序界面中嵌入第三方应用程序的内容。 听起来很简单——直到你真正尝试实现它。 许多开发者会因为跨进程渲染和生命周期管理而感到头疼。

从机制来看，

• 内部组件/视图——这是的首选：所有内容都直接建立在宿主应用内部。没有跨进程开销，缺点是需要掌握相关知识，而且存在耦合问题。在汽车领域，要建立一个媒体卡片。你的团队需要学习并理解完整的 MediaSession/MediaBrowser 堆栈；要建立一个电话组件，他们需要 Telephony API。再加上汽车 API、OEM 内部 API 还有每个领域特有的特性——你的团队就变成了十几个互不相关领域的专家。每个组件都与其依赖的 API 紧密耦合，而当 API 发生变化时没有人记得当初为何如此设计。
• TaskView / CarTaskView — 在程序级别运行，将另一个应用的完整 Activity 嵌入到你的窗口层级结构中。它仅限于程序应用，需要特权权限，会在主机和客户端之间建立紧密的生命周期耦合，并添加一个专用的 SurfaceFlinger 层——会迅速消耗 Hardware Composer 的叠加层预算。特别是在多使用者多显示器 设置中，例如主机、乘客显示屏和后排屏幕/使用者同时运行。按理说，
• SurfaceControlViewHost — 避免了特权权限。并共享相同的层开销，但引入了脆弱的进程间通信 边界。虽然基本渲染功能正常，但同步结构更改、处理客户端进程崩溃还有管理 AAOS 旋转焦点或无缝触摸手势切换都迫使主机采用复杂的手动变通方案。
• RemoteViews — 任何应用均可使用，无需特殊权限。但它的组件库过于原始，无法建立任何严肃的使用者界面：只有寥寥几个 TextView、ImageView 和 Button。其他功能都无法实现，

Remote Compose方案

每种方法都存在无法避免的权衡取舍。远程组合 打破了这种模式。它将丰富的使用者界面意图序列化为紧凑的声明式二进制流——绘制指令，而非具体界面元素；宿主程序充当浏览器：它接收这些指令，并在其自身层内独立渲染。无需了解提供程序应用程序的生命周期、进程状态或权限。点击和交互在本地处理并返回给提供程序。所以即使提供程序进程负载较高，使用者界面也能保持响应。完整组合表达能力，以数据形式交付。让开发者摆脱了传统 View 层级复杂度。

Remote Compose 的工作原理

从本质上讲，RemoteCompose 文档是 Canvas 绘制调用的一系列序列化记录——与 Android 用于渲染任何 UI 的原语相同。提供者不会立即执行这些调用，而是将它们打包成紧凑、独立的数据格式。其中包含形状、带有字体和样式文本、图像甚至动画表达式。

当主机收到此文档时它只需根据本地 Canvas 迭代指令即可；无需关心数据来源域知识，只需回放即可。这类似浏览器呈现静态页面但提供者可以以 IPC 允许速度推送更新。这样就能实现流畅状态驱动 UI 更新，无需 XML 膨胀开销。

动画平滑动画，无需往返通讯。

PoC的观点是，将理论付诸实践

I 想看看 RemoteCompose 作为跨应用 UI 机制能发展到什么程度。在 AAOS 堆栈多年后我看到 OEM 编写数千行样板文件只是为了共享一个简单的小部件——这正是汽车发射器所适用的大舞台。

模拟环境

• 主显示屏： 主机采用三列布局。
• 第二个显示器： 专用呼叫提供商应用程序。

This simulator allows me to trigger various call states—incoming or active—and observe host reactions in real time. It’s a “byte input,integer output” contract under extreme pressure;provider runs on a different display context yet launcher remains buttery smooth.

共存证明的观点是，一个屏幕。三个建筑世界

• X 列：Native Widget. 直接在 Launcher 进程实现标准视图，需要启动器管理电话 API 与观察者逻辑—极大耦合与维护成本。
• X 列：RemoteCompose. 我们的 PoC 电话小部件。通过迁移至 RemoteCompose，Launcher 仅管理布局槽并回放传入 UI 描述；电话团队可独立更新 UI，无需触碰 Launcher 代码。
• X 列：CarTaskView. 完全映射活动嵌入 Launcher 表面—重叠层耗费高且生命周期紧耦合。

This integration confirms RemoteCompose 可以与传统基于 View 的程序和复杂 CarTaskView 环境共存。而不会产生副作用，为 OEM 提供无缝升级方法—无需整个程序重写，即可逐步引入现代远端驱动组件，从而减少成本与风险。

PoC 架构

Coresplit： 架构围绕两个不同进程中的独立应用。通过 AIDL 服务绑定通信：

• `Host`：** 包含 RC 播放器小部件，可本地呈现 UI；话说回来，对电话逻辑一无所知。
• <**Provider**：** 保存业务逻辑，将 UI 状态构造为 RC 文档—a compact byte array representing entire UI tree.

*Happy Path*: 生命周期完全被动。当状态变化时 Provider 将 RC 文档字节推送给 Host，即刻反序列化呈现。当使用者点击按钮时 Host 将轻量级操作 ID 返回给 Provider，由 Provider 执领域务逻辑并推送新文档—无缝体验却极低耦合！

• *Edge Cases – Elastic Lifecycle Management*: 与 SurfaceControlViewHost 或 TaskView 不同。如果 Guest 崩溃导致“死”表面或黑洞出现，RemoteCompose 可确保整个生命周期隔离；Host 检测 AIDL 链路死亡并及时替换占位符或闪烁状态—UI 无闪烁且保持响应，即便连接恢复也无延迟感知！

This establishes a clean contract: **bytes input。integer output**—两端可独立演化，不破坏彼此UI体验，是领域采用关键所在！

传输层选择建议

• AIDL: 低延迟直连 IPC，非常适合频繁更新—PoC 正是使用此方式！
• ContentProvider: 若小部件数据已建模为内容。如媒体元数据或联系人，可拉取式模型适用于静态/慢变更UI。
• BroadcastReceiver: 简单推送模型，但缺乏背压与 payload 大小限制—仅适用于微小更新。
• WebSocket: 服务器驱动场景下可直接从后端获取文档—适用于云端控制UI。

PoC 中 AIDL 合约简述：

// Implemented by Provider
interface ICallProviderService {
void registerCallback;老实说，void unregisterCallback;void sendAction;}
// Implemented by Host
oneway interface IDocumentCallback {
void onDocumentUpdated;}

The contract is minimalistic – bytes in,integers out – exactly what developers crave when decoupling front‑end from back‑end logic.

Provider：生成 UI & 捕获 ByteArray

// Build familiar Compose syntax but capture as remote doc
suspend fun createIdleDocument : ByteArray {
return captureSingleRemoteDocument { IdleScreen }.bytes
}
@Composable @RemoteComposable
private fun IdleScreen {
RemoteColumn.padding) {
RemoteText
entries.forEachIndexed { index。entry ->
RemoteRow(
modifier = RemoteModifier
.fillMaxWidth
.clickable))
) {
RemoteText
RemoteText
}
}
}
}

Syntax almost identical to standard Compose – only difference is Remote prefix and output being ByteArray rar than pixels on screen.

Host Side Rendering via Player – No Jetpack Dependency Needed!

The host receives raw bytes via AIDL callback,wraps m into RemoteDocument。and hands m over to RemoteDocumentPlayer. That player automatically parses and draws everything – all without knowing anything about provider’s business logic or layout structure!

再看务实之路，无需迁移即集成现有视图堆栈!

The main challenge many OEMs face is cost of adopting modern frameworks. For our PoC we used standard AAOS CarLauncher as host – built on legacy view system . Migrating an entire production shell to Jetpack Compose simply isn’t realistic for most OEMs. Fortunately RemoteCompose was designed precisely for that reality!It ships with two player artifacts:

• remote-player-compose – for hosts already running Jetpack Compose.
• remote-player-view – for traditional view‑based applications. Since CarLauncher is view‑based we used view player artifact. RemoteDocumentPlayer is just a plain FrameLayout you can drop into any XML layout and call setDocument to render provider’s UI onto its own canvas. No extra Compose dependencies or wrappers are required on host side – zero migration effort!话说回来，Meanwhile provider side stays identical regardless of who renders it: same byte array pushed everywhere. This demonstrates a key adoption point: a provider can serve both modern compose hosts and legacy view hosts with zero coupling!

关于 Android 框架 的说明  如果仔细查看最新 AOSP 更新。你会发现 Android 从 API 开始已将自己的 native RemoteCompose 播放器直接烘焙到框架中，为标准程序小部件的新 DrawInstructions 提供支持。话说回来，只是依赖框架播放器代表着把你的宿主绑上操作程序更新周期。这增加了开发难度，3️⃣ CVAA & 可访问性 - 支持基本语义描述，但画布元素不产生语义节点；缺少 liveRegion、焦点顺序控制等高级可访问性功能。可访问性责任从生产者转移到宿主，需要额外实现工作。4️⃣ 旋转导航 & 输入事件转发 - 当前播放器未公开对焦点管理或旋转输入 的明确支持。其实，宿主只能捕获旋转事件，却无法将其路由至文档内滚动内容。--- 结论 RemoteCompose 将思维模型从共享表面转换为共享意图。按理说，不必把外部进程嵌入自己的 UI，而是交换紧凑声明式描述。使团队能够独立演化而不破坏彼此边界. 它显著降低耦合度，并简化所有权边界，让大型 AAOS 程序更易维护。PoC 明确表明，该方法不仅可行。也可以实用集成到现有基于视图堆栈之中，没有迁移中断风险。只是它仍未完全准备好投入生产——工具链性能及程序集成方面还存在关键挑战。如果你正在面对类似跨品牌、多品牌信息娱乐网站中的这种挑战，我很乐意交流想法。

---

bq.welcome search & follow公众号「稀有猿诉」获取更多不错的文章！老实说，保护原创，请勿转载！按理说，<\/cite>"

---