解读

面试官问的是“手机端发送通知后，手表端自动同步显示”的完整技术链路，而不是“手表自己发通知”。
国内场景下，手机通常是 Android 品牌机，手表可能是 Wear OS（如小米 Watch 3 Pro、OPPO Watch 3/4、华为 Watch 4 海外版）或鸿蒙穿戴（华为 Watch GT 系列）。
Wear OS 设备在国内仍依赖 GMS 核心，但厂商普遍做了“华为移动服务 HMS”或“小米穿戴服务”双轨兼容；鸿蒙穿戴则完全走华为自有分布式软总线。
因此，回答必须分两条线：

1. Wear OS 路线：利用 Android 官方 Notification Bridging，无需手写代码即可同步，但要解释其限制与定制方法。
2. 鸿蒙/Wear OS 无 GMS 路线：手机端需把通知主动推送到手表厂商 SDK，手表端接收后自行构造本地通知，需解释权限、保活、节电、安全等问题。
   面试官想听到的是：

• 系统机制（Bridging、Data Layer、厂商通道）
• 权限与保电（电池白名单、后台启动、SELinux 限制）
• 兼容性（国内无 GMS、鸿蒙分布式、厂商 ROM 裁剪）
• 性能与体验（避免重复震动、图标一致、快速回复、敏感信息脱敏）

知识点

1. Notification Bridging（Wear OS 官方机制）：

   • 手机端普通 Notification 只要满足 setLocalOnly(false) 且未设置 Ongoing/Media/Custom RemoteViews，系统会自动镜像到配对手表。
   • 手表端由 Wearable 模块的 Bridging Service 负责接收，通过 Binder 到 SystemUI 渲染，无需应用安装手表 APK。
   • 可覆写 Bridging 模式：WearableExtender#setBridgeTag("tag") + 手表端 AndroidManifest 中声明 <meta-data android:name="com.google.android.wearable.notificationBridgeMode" android:value="NO_BRIDGING"/> 实现细粒度过滤。

2. Data Layer API（GMS Core）：

   • 手机端通过 Wearable.DataApi.putDataItem 发送资产，手表端 WearableListenerService 监听 onDataChanged，再构造 NotificationCompat 本地弹出。
   • 依赖 Google Play Services 22.xx 以上，国内需用户自行安装 GMS，否则走厂商代理通道。

3. 厂商通道（HMS、小米穿戴、OPPO HeyThings）：

   • 华为：手机端集成 Wear Engine SDK，调用 notifyNotificationChange，手表端注册 NotificationSubscriber；数据通过华为账号+分布式软总线加密传输，不依赖 GMS。
   • 小米：手机端集成 Xiaomi Wear SDK，通过 MiWearable.notify，手表端在 WearableReceiver 中解析 Bundle 并调用 NotificationManager.notify。
   • 所有厂商 SDK 都要求动态申请后台弹出界面、悬浮窗、电池优化白名单，否则收不到。

4. 权限与节电：

   • Android 13+ 需 POST_NOTIFICATIONS 权限；手表端若独立 APK 需 BIND_NOTIFICATION_LISTENER_SERVICE。
   • 国内 ROM 把“自启动”与“后台弹出”权限默认关闭，必须引导用户手动开启。
   • 若使用 Data Layer 高频率同步，需调用 RequestConstraint.Builder.setRechargeRequired(false) 并加入电量白名单，否则被厂商冻结。

5. 安全与隐私：

   • 通知内容含验证码、聊天信息时，需设置 NotificationCompat.Builder.setPublicVersion() 提供脱敏版本，避免手表抬腕即泄露。
   • 关键数据走 Keystore + TEE 加密，手表端解密后再显示，防止中间人截断。

6. 性能优化：

   • 手表端 Notification 图标≤1 色、尺寸 24dp，避免重复下载；大图标用 DataMap 传输 32-bit PNG 压缩。
   • 手机端使用 NotificationCompat.MessagingStyle 时，手表端自动折叠历史，减少内存占用。

答案

“在国内实现手机通知自动同步到手表，我分两条路线落地。
第一条是 Wear OS 官方方案：手机端直接发普通 Notification，只要不清掉 setLocalOnly，系统会自动桥接到已配对的手表，无需任何手表 APK。若需要定制，比如只允许重要通知同步，我会在手机端用 NotificationCompat.WearableExtender 设置 bridgeTag，然后在手表端声明 NO_BRIDGING 并在 Manifest 中注册过滤规则，这样只有带指定 tag 的通知才桥接，兼顾省电与隐私。
第二条是 GMS 不可用或鸿蒙手表场景：我会走厂商私有通道。以华为为例，手机端集成 Wear Engine，通过 notifyNotificationChange 把脱敏标题、内容、图标哈希、PendingIntent token 发到华为分布式软总线；手表端注册 NotificationSubscriber，收到后本地构造 NotificationCompat，图标复用已缓存资源，再调用 NotificationManager.notify。权限方面，必须动态申请后台弹出、电池优化白名单，并在设置中引导用户打开自启动，否则会被鸿蒙冻结。
两条路线都会做三件事：

1. 敏感信息用 setPublicVersion 做脱敏，防止抬腕泄露。
2. 图标、声音资源预置在手表，避免重复传输耗电。
3. 手表端点击通知后，通过厂商 SDK 的 PendingIntent 代理把手机端 RemoteInput 结果回传，实现快速回复，全程不走自建长连接，不额外耗电。
   上线前用 Battery Historian 对比 24 h 耗电，确保通知同步模块耗电 < 1%。”

拓展思考

1. 如果手表是 RTOS 轻量级系统（如华为 Watch GT 国内版）而非智能系统，无法运行 APK，此时只能由手机端把通知推送到厂商云，手表端从云上下发，开发者无法干预 UI，只能依赖厂商模板。如何与产品经理沟通“无法自定义图标颜色”的限制？
2. 折叠屏手机在展开态时，通知栏宽度变大，图标可能使用 48dp，而手表仍使用 24dp，如何在同一套资源里做分层打包，减少 AAB 体积？
3. 当用户开启“专注模式”或“睡眠模式”时，系统会临时关闭 Bridging，但厂商通道可能仍生效，如何统一策略，避免用户投诉“手表半夜震动”？
4. 国内监管要求即时通讯类通知必须保存 6 个月日志，若走厂商通道，日志分散在各厂商云，如何设计合规落地方案？