1. Wear OS健康应用工程导论

Wear OS 是 Google 面向智能手表等可穿戴设备构建的操作系统平台，它并不是把手机界面缩小后搬到手表上，而是围绕“贴身、短时、高频、低干扰”的交互特征重新设计的计算环境。对健康类应用而言，这一平台定位决定了三件事：数据采集必须尽量在腕端完成，用户交互必须能在数秒内完成，后台任务必须严格遵守功耗与调度约束。理解这三点，是后续所有工程决策的起点。

从系统架构看，Wear OS 应用运行在手表本地，通过 Health Services、传感器框架、Compose for Wear OS 等能力获取数据并呈现界面；同时借助 Data Layer API、蓝牙或网络与手机端或云端同步。健康应用常见的场景包括：持续心率与运动状态监测、睡眠阶段记录、久坐提醒、呼吸训练引导、运动过程实时配速与心率区间提示，以及运动结束后的摘要回传。这些场景对实时性、续航和隐私的要求各不相同，工程上必须区别对待。

上图把 Wear OS 健康应用拆成四层：腕端设备层负责采集与本地交互，连接与同步层负责跨设备传输，手机端与云端层负责汇总与分析，而功耗、实时性、隐私、一致性、异常恢复则贯穿所有层。工程化开发的核心，就是让每一层都明确自己的职责边界，并让数据在层与层之间可靠流动。

健康应用场景与工程约束

不同健康场景对系统的要求差异很大。以“运动心率区间实时提示”为例，它要求心率采样间隔约 1 秒、界面刷新延迟低于 200 毫秒，并且要在屏幕常亮的情况下控制功耗；而“睡眠阶段记录”则允许分钟级采样，但要求整夜后台运行且不能频繁唤醒 CPU。再如“久坐提醒”，它只需要每 30 分钟判断一次活动状态，却必须保证提醒不被系统省电策略误杀。工程上，这些差异会直接落到采样频率、前台服务类型、唤醒锁策略和同步时机的选择上。

一个常见的教学示例参数如下：运动模式采用 1 Hz 心率采样、50 Hz 加速度采样，前台服务类型声明为 health，界面通过 Compose 的 StateFlow 每秒更新一次；睡眠模式采用 0.2 Hz 心率采样、按需读取加速度，后台使用 WorkManager 每 15 分钟做一次阶段推断。这些数值属于合理假设，用于说明工程取舍，并非实测结果。实际项目中应根据设备能力、系统版本和功耗预算调整。

工程化开发流程

Wear OS 健康应用的工程化流程可以概括为“场景定义 → 数据契约 → 腕端实现 → 同步与后台 → 验证与调优”。场景定义阶段要明确用户是谁、在什么状态下使用、一次交互持续多久；数据契约阶段要确定采样字段、时间戳精度、单位、缺失值处理和同步频率；腕端实现阶段要完成权限申请、传感器订阅、界面状态管理和本地持久化；同步与后台阶段要处理离线缓存、冲突合并和任务调度；验证与调优阶段则要在真机上观察功耗、延迟和异常恢复表现。

以心率数据为例，数据契约可以定义为：字段包括 timestamp（毫秒）、bpm（整数）、quality（枚举：good/poor）、source（sensor/estimated）；采样频率 1 Hz；同步策略为每 30 秒批量上传一次，离线时写入 Room 数据库，恢复连接后按时间顺序补传。这样的契约让腕端、手机端和云端对同一份数据有一致理解，避免后续出现单位混乱或时间戳错位。

课程项目目标

本课程围绕一个完整的“腕端健康监测应用”展开，项目目标包括：第一，能够在 Wear OS 手表上申请并获取心率、加速度等健康数据；第二，能够用 Compose for Wear OS 构建适合手表的实时界面；第三，能够把数据可靠地同步到手机端或云端；第四，能够在后台任务中完成睡眠或久坐等低频分析；第五，能够通过日志、功耗面板和真机测试判断应用是否达到预期。最终交付物是一个可运行、可观察、可复现的最小健康应用，而不是只停留在概念层面的演示。