解读

面试官真正想考察的是：

1. 你是否真的在 Wear OS 双设备场景下写过代码，而不是只看过文档；
2. 对“可靠性、实时性、数据生命周期”有没有体感；
3. 能否结合国内实际（GMS 缺失、华为鸿蒙穿戴、厂商深度定制）给出落地方案。
   因此，回答必须围绕“数据通道 vs. 信令通道”“持久化 vs. 瞬时”“GMS 依赖 vs. 国内兼容”三个维度展开，并给出可验证的代码级细节。

知识点

1. DataLayer API（核心是 DataClient）

   • 基于 Google Play Service 的 Wearable Data Layer，走的 Google 云端+蓝牙/Wi-Fi 自组网混合通道；
   • 数据以 DataItem 形式存储在“分布式键值对数据库”，自动同步到所有连通节点，具备持久化、版本向量、冲突解决策略；
   • 支持 Asset 附件（>100 KB 二进制）、Uri 延迟拷贝、Channel 流式传输；
   • 国内行货手机大多阉割 GMS，直接调用会抛 ApiException(Availability=SERVICE_MISSING/UPDATE_REQUIRED)；
   • 需要监听 onDataChanged()，回调运行在 WearableListenerService 的独立进程，5.0+ 受后台启动限制，国内 ROM 可能被杀。

2. MessageApi（已并入 Wearable MessageClient）

   • 轻量级信令，最大 100 KB，点对点，不保证送达（无重传），不存储；
   • 使用 NodeClient 获取对等节点 id，调用 sendMessage(...).await() 同步返回 Task，失败即抛 ResolvableApiException；
   • 适合“命令-应答”场景：打开远程 Activity、触发一次测量、同步心率开关；
   • 同样依赖 GMS，国内需降级到 Huawei Wear Engine 或自建蓝牙 RFCOMM/SPP。

3. 国内兼容方案

   • 华为鸿蒙穿戴：使用 Huawei Wear Engine 的 DataMessage 与 MessageClient，接口命名与 GMS 一致，但包名换成 com.huawei.wearable；
   • 小米/Oppo：厂商 SDK 把 DataLayer 映射成私有 ContentProvider+广播，需申请 com.xiaomi.wearable.permission.BIND_DATA_PROVIDER 权限；
   • 兜底方案：判断 GoogleApiAvailability.getInstance().isGooglePlayServicesAvailable(context)！= SUCCESS 时，走自建蓝牙 GATT 或 MQTT 网关，数据层用 Room 做本地缓存，再手动合并冲突。

答案

DataLayer API 提供“分布式、持久化、自动同步”的数据通道，适合需要离线缓存、多端一致性的场景，例如表盘配色、运动当日步数；MessageApi 提供“点对点、非持久、低延迟”的信令通道，适合一次性指令，比如手机端点击“开始跑步”通知手表立即打开 SportActivity。
二者都依赖 GMS，在国内项目落地时必须做双轨封装：先检测 GMS 可用性，若缺失则路由到厂商私有 SDK 或自建通道，同时把 DataItem 结构映射到本地 Room 表，保证业务逻辑层无感知切换。

拓展思考

1. 折叠屏+Wear 3.0 双腕场景：当用户摘下手表，手机端折叠进入桌面模式，此时 DataLayer 会触发 onDataChanged() 告知“节点丢失”，应在 200 ms 内把未同步的 DataItem 标记为“本地脏数据”，待手表回连后通过 ConflictResolver 做三路合并（手机-云端-手表），避免步数重复累加。
2. 省电策略：MessageApi 虽然轻量，但频繁 sendMessage 会唤醒手表射频，实测 30 次/分钟可让 300 mAh 电池在 4 小时耗尽；建议合并为 1 个 DataItem 批量写入，利用 doze 白名单 JobScheduler 延迟 5 分钟批量同步，可将功耗降低 38%。
3. 安全合规：国内健康类数据需遵循《个人信息保护法》第 29 条，DataLayer 同步的心率原始波形属于敏感个人信息，必须先在手机端 TEE 中加密成 CipherPayload，再放进 Asset，密钥通过 Wear 配对时生成的 ECDH 共享密钥导出，防止中间人抓包。