Jetpack Glance+Remote Compose：Wear OS磁贴升级为小组件

Wear OS 的交互形态正在经历一次底层重构。Google 将原本全屏的 Tile（磁贴）正式演进为 Wear Widgets（手表小组件），并把它们纳入统一的 Android Widgets 生态——与手机小组件共享同一套 Jetpack Glance 基础设施。负责 Glanceable Experiences 的 Frank Choi 和专注 Remote Compose 的工程师 Yuri Shumka 在技术演讲中完整拆解了这次迁移的路径、代码模型与工具链。

从磁贴到小组件：一次生态级的统一

过去，Wear OS 的 Tile 使用 Proto Layout 这一专为手表磁贴构建的库，与手机端小组件的技术栈彼此割裂。现在，Wear Widgets 改用 Jetpack Glance 构建，意味着开发者可以用同一套心智模型同时覆盖手机和手表的"应用外"体验。

支撑这一变化的是全新的 UI 框架 Remote Compose。它把声明式 API 带入远程 UI 场景，与 Jetpack Compose 高度对齐，同时为小组件带来现代图形能力和响应式布局，并兼顾性能与电量效率。更关键的是，Remote Compose 将 UI 与应用进程解耦——据演讲中的说明，组件被安全序列化后可在广泛的 Android 设备上渲染。

这种解耦带来的直接好处是：开发者把富交互体验带到几乎所有受支持的远程界面时，所需额外工作量很小。对长期在 Wear 平台受限于专用布局系统的团队来说，这是一次明显的基础设施升级。

Jetpack Glance 是 Google 推出的、用于构建 App Widgets 的声明式 UI 工具包，它基于 Jetpack Compose 的运行时和编译器，但针对远程 UI 场景（如桌面小组件）做了专门适配。Glance 的核心价值在于让开发者用类似 Compose 的写法构建小组件，并通过一套中间表示将 UI 描述序列化后交给宿主渲染，而不是直接操作 RemoteViews。在此之前，Wear OS 的 Tile 依赖 Proto Layout，与手机小组件技术栈分离；改用 Glance 后，手机与手表小组件共享同一套 API 模型、主题系统和工具链，跨端复用成为可能。

Proto Layout 是 Wear OS 此前用于构建 Tile 的专用布局库，采用基于 protobuf 的布局描述与表达式绑定机制。它针对手表磁贴的尺寸和刷新频率做了优化，但与 Jetpack Compose 的编程模型差异较大，学习成本高且生态封闭。随着 Wear Widgets 转向 Jetpack Glance，Proto Layout 进入遗留状态，现有磁贴代码需要通过迁移 skill 或手动改写为 Remote Compose 实现。

两种容器尺寸，对齐手机小组件的心智模型

为了让迁移尽可能平滑，Google 引入了 small 和 large 两种标准容器尺寸，分别对应开发者在手机小组件中熟悉的 2x1 与 2x2 网格格式。这种对齐不是巧合，而是刻意降低跨端开发者的认知负担。

平台层面的呈现方式也在变化。从 Wear 7 开始，在部分硬件厂商的设备上，Wear Widgets 会出现在一个垂直滚动托盘里，与其他应用的小组件并列。演讲中以三星 Galaxy Watch 展示了实际效果。平台架构本身已为垂直滚动托盘做好准备，等待更多厂商采用这一模式。

开发者不必担心抛弃老用户。Jetpack Glance Wear API 向下兼容至 Wear 4。在仅支持水平托盘的老设备上，系统会自动处理适配——开发者只需在代码中声明希望支持全屏模式，系统就会把 large 小组件以传统全屏磁贴的形式呈现。

迁移策略：双服务还是单服务

如果是从零构建新的 Wear Widget，只需定义一个 Glance Wear Widget service，并用 Remote Compose 构建 UI。但对已有线上磁贴的应用，服务和数据层都需要迁移。演讲给出了两条路径：

• 双服务（推荐）：保留现有的 tile service 服务老版本 Wear OS，同时新增一个 Glance Wear Widget service 面向 Wear 7 及以上。职责清晰，老设备行为不受影响。
• 单服务：创建一个同时处理两种协议的 Glance Wear Widget service，在兼容模式下把小组件翻译成老设备上的磁贴。代码库更精简，但兼容层需要自行承担。

两种方案都能覆盖全部用户，区别只在于长期维护的代码形态。Android 开发者网站已发布详细文档，说明各自适用场景与使用时机。

Remote Compose 的代码心智模型

UI 层的迁移本质上是一次心智模型的切换。Proto Layout 是专为 Wear 磁贴打造的一次性方案，而 Remote Compose 与 Jetpack Compose UI 共享同一套核心编译器和运行时，并刻意贴近 Foundation、Material 3 等 Compose UI 库的写法。

具体差异体现在命名与交互原语上：Box、Column、Text 换成 RemoteBox、RemoteColumn、RemoteText；熟悉的 Modifier 和 Boolean 在远程场景中有对应类型 RemoteModifier 和 RemoteBoolean；lambda 则被 action 取代——开发者需要声明一个动作，例如启动 PendingIntent、调用服务或更新某个值，而不是在闭包内直接写执行代码。

演讲用一个基于 Material 3 的开关按钮做了对照：左侧是标准 Wear Compose 组件，右侧是 Remote Compose 版本，两者模式高度相似，最终渲染出的交互动画几乎看不出差别。主题系统同样对齐——Material 3 配色方案可以直接应用到 Remote Compose 组件上，让小组件与 App 品牌保持一致。此外，库中提供了一整套专为小组件设计的即用型 Remote Compose 组件，现有 Wear Material 3 设计稿（包括 Figma 中的资产）可以较容易地适配到小组件，对工程师和设计师都是熟悉的路径。

Remote Compose 与标准 Jetpack Compose 的关键差异在于运行位置：标准 Compose 的 UI 在应用进程内组合与渲染，而 Remote Compose 构建的 UI 会被序列化为一种中间表示，交由宿主进程（如手表系统界面）反序列化并渲染。这种“UI 与进程解耦”的设计意味着组件不能直接持有应用进程内的对象引用，也不能在 lambda 中执行任意代码。因此 Remote Compose 用 action 取代 lambda：开发者声明一个动作（如启动 PendingIntent、调用服务或更新某个值），由系统在宿主侧触发后回调到应用进程。同理，RemoteModifier 和 RemoteBoolean 等类型是对标准 Modifier 和 Boolean 的远程安全替代，确保所有 UI 描述都可被序列化传输。理解这一约束是掌握 Remote Compose 编程模型的核心。

Compose Preview：不依赖真机的布局验证

小组件依赖 OEM 特定的容器约束，包括尺寸、形状、内边距和圆角半径。为此，Google 为 Wear Widgets 增加了 Compose Preview 支持：在标准 preview 注解基础上增加一个 parameter provider，用于注入这些配置。

库中预置了匹配真实 Wear OS 设备的 preview parameter provider 实现，开发者可以快速验证布局在多种硬件形状下的表现。这些预览还能用于生成设备端小组件选择器所需的静态图片——库提供了矩形预览形状参数，模拟未裁剪的完整矩形容器。

实践层面，Horologist Media Sample 应用已更新，新增了一个展示该 API 的媒体小组件，同时包含 small 和 large 两个版本。GitHub 上可以并排对比遗留 Proto Layout 代码与新的 Remote Compose 实现。

Compose Preview 的 parameter provider 是 Jetpack Compose 预览机制的一种扩展：通过 @PreviewParameter 注解，开发者可以向预览函数注入一组参数，从而在 Android Studio 中同时渲染多个变体。在 Wear Widgets 场景中，Google 预置了匹配真实 Wear OS 设备的 provider 实现，每个参数对应一种 OEM 容器约束组合（尺寸、形状、内边距、圆角半径）。这样开发者无需逐一连接真机，就能在 IDE 中验证小组件在方形、圆形等不同表盘下的布局表现，并导出静态图片供设备端小组件选择器使用。

用 AI 工具加速迁移

演讲最后提到一个实用工具：GitHub 上发布了 tiles-to-widgets 迁移 skill，可以配合开发者选择的 agent 使用，也可以通过 Android CLI 直接加入 Android Studio。这延续了把 AI 辅助嵌入开发流程的思路，对需要批量处理既有磁贴代码的团队尤其有意义。

这次演进意味着什么

从技术选型看，Wear Widgets 的推出不是又一套平台专属 API，而是把 Wear 拉回 Jetpack Compose 的主干。对已经熟悉 Compose 的 Android 开发者，学习曲线被压缩到"给熟悉的组件加一个 Remote 前缀"这个量级；对设计团队，Material 3 资产的复用降低了跨端适配成本。

迁移的复杂度主要落在服务层而非 UI 层：双服务与单服务的选择，考验的是团队对未来维护成本和兼容范围的权衡。Google 推荐双服务，本质上是用代码冗余换取老设备行为的确定性。

此外，Remote Compose 将 UI 序列化并与进程解耦的设计，暗示了更长远的方向——同一套组件未来可以渲染到更多远程界面，而不只是手表。演讲中"以最小工作量覆盖几乎所有受支持的远程界面"的表述，指向的正是这种可移植性。

对正在维护 Wear 磁贴的团队，现在就可以从 Android 开发者网站的入门指南开始迁移；对尚未涉足 Wear 的 Android 开发者，这套与手机小组件共享基础设施的 API，显著降低了进入门槛。