解读

面试官问的是“差异”，而不是“标准本身”。他想知道你是否真正在 Wear 项目里踩过坑，能否把国内多渠道（华为、小米、OPPO、vivo 手表应用商店）与 Google Play 的 Wear OS 专区政策分开讲清楚，并给出可落地的规避方案。回答时务必先抛出“维度”，再逐点对比，最后落到“国内上架 checklist”，让面试官一听就知道你带过发版。

知识点

1. 国内 Wear 分发渠道：华为运动健康、小米穿戴、OPPO HeyTap、vivo 手表商店，各自有独立审核后台，不走 Google Play。
2. Google Play Wear OS 专区政策：官方 2023 年 10 月收紧，强制 targetSdk≥33、支持“表盘格式（Watch Face Format）”、必须适配 Wear 4 的 Tiles 与 Complications。
3. 硬件约束：Wear 3/4 主流 RAM 1 GB 以下，CPU A53 1.2 GHz，圆形屏 466×466 与 450×450 为主，必须做 dp 与 px 双验证。
4. 电池与性能：Google 要求后台 10 分钟必须进入 Deep Sleep，国内渠道要求“亮屏 20 分钟耗电≤3 %”。
5. 权限与隐私：Wear 无 READ_PHONE_STATE、无 SMS，定位只能用“被动式 Fuse Location”，且国内渠道额外要求“权限最小化声明”人工复核。
6. 交互合规：国内对“滑动误触”零容忍，必须提供 24 dp 以上点击热区；Google 则要求支持旋转表冠与实体按键。
7. 审核周期：Google Play 平均 3 天，国内渠道 5–7 个工作日，节假日顺延，且 OPPO/vivo 强制线下真机复测。

答案

我从“Google Play Wear OS 专区”与“国内四大手表商店”两条线总结差异，共 6 个维度，可直接当发版 checklist 用。

1. 性能与功耗
   Google：后台 10 分钟必须挂起，前台 CPU 占用 15 % 以上且持续 30 s 会被拒；Battery Historian 报告亮屏耗电 1 h≤5 %。
   国内：华为要求“亮屏 20 min 耗电≤3 %”，小米额外统计“蓝牙 BLE 扫描次数≤60 次/小时”，超限直接打回。

2. 屏幕与交互
   Google：必须适配圆形屏边缘 5 % 安全区，支持表冠滚动与实体按键 KEYCODE_STEM_1；拒绝纯手机拉伸 UI。
   国内：vivo 要求“点击热区≥24 dp、误触率≤1 %”，OPPO 强制“深色模式默认开启”，否则人工审核不通过。

3. 权限与隐私
   Google：禁止请求 READ_PHONE_STATE、SMS、CAMERA；定位只能用 PASSIVE，后台定位必须加 foregroundServiceType="location" 并弹持续通知。
   国内：华为额外扫描“权限与功能是否匹配”，若声明 ACTIVITY_RECOGNITION 但 APK 内无运动模块，直接驳回；小米要求隐私政策里单独声明“穿戴设备标识符”使用场景。

4. 功能与组件
   Google：2023 年 10 月起新表盘必须采用官方 Watch Face Format（XML 声明式），不再接受 Canvas 绘制；必须实现 Tiles 与 Complications 数据提供器。
   国内：四大商店目前仍允许 Canvas 表盘，但华为 2024 Q4 起将同步 Google 政策；小米要求“运动类应用必须接入小米运动 SDK”否则无法读取心率原始数据。

5. 包体与版本
   Google：强制 AAB，targetSdk≥33，32 bit 与 64 bit 分包后总大小≤50 MB（Wear 专用包）。
   国内：华为/小米只收 APK，单包≤100 MB，32 bit 即可；但 OPPO 要求 64 bit 优先，否则在商店列表降权。

6. 审核节奏与复测
   Google：平均 3 天，拒绝会给出 Systrace 截图与 Battery Historian 链接，可申诉。
   国内：周期 5–7 个工作日，vivo 与 OPPO 需线下真机复测，若发现“亮屏掉电”超标直接打回且 7 天内不得重复提包；小米提供线上云真机日志，可快速定位。

落地建议：
a. 本地先用 gradle wearQaRelease 打出 Wear 专用包，跑 adb shell cmd activity start -S -W -R 50 做 50 次冷启动，确保冷启动≤800 ms。
b. 用 Battery Historian 生成 1 h 亮屏报告，耗电>5 % 就回炉；国内渠道再加华为功耗测试工具，确保 20 min≤3 %。
c. 权限最小化脚本：通过 aapt dump permissions 列出全部权限，与功能清单逐项映射，写进 README，审核员一眼看懂。
d. 圆形屏边缘 5 % 安全区用 Jetpack Compose Modifier.padding(5.percent) 一次性解决，真机用 466×466 圆形 AVD 验证。
e. 发版前 48 h 冻结代码，把 Google 与国内渠道分成两条 CI 流水线，Google 走 AAB+Proguard，国内走 APK+R8+渠道包，避免混淆规则冲突。

拓展思考

如果公司下一步做 Wear 表盘订阅化，需提前关注两件事：

1. Google 2024 年将强制 Watch Face Format，届时 Canvas 表盘无法更新，必须把绘制逻辑迁到 XML+WFF 脚本，动画帧率限制在 30 fps，且禁用 OpenGL。
2. 国内华为、小米预计同步该政策，但会保留“中国特色”入口：华为可能要求接入 HMS Core 表盘服务，小米可能把订阅计费强制走小米支付，不再允许微信/支付宝内嵌。
   建议现在就把表盘拆成“渲染引擎+数据服务”两层，渲染层预留 WFF 转换脚本，数据层用 Kotlin Multiplatform 写业务逻辑，届时只需替换入口即可一次开发，双端上架。