解读

面试官问“核心差异”，不是让你把官方文档背一遍，而是考察三件事：

1. 你是否真在手表上做过页面，知道“寸土寸金”的屏幕怎么活下来；
2. 你是否理解 Google 在 Wear 上推的“Glanceable & Instant”设计哲学，并能落地到 Compose for Wear、Tiles、 complications 等具体技术；
3. 你是否能把“手机那套直接搬过来会踩什么坑”讲清楚，让老板放心把 Wear 端交给你。

国内面试场景里，大厂还会追问：圆形屏、华为鸿蒙表、小米表、Oppo 表适配差异怎么解？所以答案必须“有体感、有规范、有踩坑案例”。

知识点

1. 屏幕物理限制：1.2–1.6 英寸、圆形占 70%、PPI 300+，导致四角安全区、边缘滑动热区与手机完全不同。
2. 交互范式：抬腕即看 ≤1.5 s，单手拇指 ≤44 dp 热区，纵向 Swipe-to-Dismiss 为系统级返回，区别于手机三大键。
3. 官方设计 token：Compose for Wear 提供 ScalingLazyColumn（原 CurvedLayout）、ArcText、SwipeDismissableNavHost；字体最小 12 sp，主按钮 ≥48 dp。
4. 系统级入口：Tiles（类似桌面小组件）、Complications（表盘小部件）、Notifications（浮动通知）三者优先级高于 App 图标，国内厂商把“负一屏”也映射到 Tile。
5. 能耗红线：SurfaceFlinger 16 ms 帧率虽同手机，但 CPU 大核锁频 500 ms 即被系统限流，暗色像素省电在 OLED 表上可差 8%–12% 续航。
6. 中国特色：华为鸿蒙表无 GMS，Tile 用 Harmony 卡片协议；小米表禁止后台 Service，必须走系统推送通道；圆形屏边缘 10% 区域被国内表盘厂商占用，做全屏列表要动态避让。

答案

核心差异可浓缩为“三小三大”：

1. 小屏幕 → 大字体大留白：信息密度 ≤ 手机 30%，主行动按钮全宽 48 dp，字号 ≥14 sp，行距 1.4 倍。
2. 短时交互 → 纵向手势优先：默认返回是 Swipe-to-Dismiss，横向滑动手势留给系统快速切换 Tile；列表用 ScalingLazyColumn 做 3 项预览 + 1 项完整可见的“漏斗”效果，保证圆形屏边缘文字不裁切。
3. 小电池 → 大暗色 + 懒加载：背景纯黑，图片 WebP 量化到 80%，列表滚动时暂停所有 Coroutine，使用 Room + WorkManager 把网络请求推迟到充电 + Wi-Fi 场景。

落地技巧：

• 圆形屏用 BoxWithConstraints 取 diameterPx，再计算 10% 边缘避让区，动态给 ScalingLazyColumn 加 contentPadding；
• 国内无 GMS 设备把 Tile 当作“主界面”，直接把核心功能拆成 TileService，减少用户进 App 次数，降低被小米后台杀的概率；
• 用 Compose for Wear 的 HierarchicalFocusCoordinator 做“高亮环”焦点记忆，旋转表冠时自动把焦点还给上一次操作的按钮，符合国内用户“表冠为主、触控为辅”的习惯。

一句话总结：Wear OS 的 UI 不是把手机页面缩小，而是把“抬腕 1.5 秒可读完”作为最高优先级，所有设计、技术、性能决策都围绕它展开。

拓展思考

1. 折叠屏手机展开后 8 英寸，与 Wear 1.4 英寸形成 20 倍面积差，未来若多设备统一 Compose，如何用同一套声明式代码做“响应式布局”而非简单分支？
2. 国内表厂开始上 60 fps LTPO 屏，Google 官方仍建议 30 fps，如何在代码层动态切换帧率而不触发 SurfaceFlinger 丢帧告警？
3. 随着 AI 表盘生成，Complications 数量从 8 个涨到 20 个，系统 UI 线程 Binder 调用骤增，如何提前在 onComplicationUpdate 里做增量 Diff，防止主线程 ANR？