1. Wear OS后台与电量优化工程导论
Wear OS 应用与手机应用最本质的差别，不在于屏幕小，而在于电量预算被压缩了一个数量级。一块典型智能手表电池容量约 300～450 mAh，而手机普遍在 4000～5000 mAh；手表却要在一天甚至更长时间内持续承担心率采集、计步、通知同步、表盘刷新等常驻任务。这意味着：手机上一个"偶尔多耗一点电"的后台设计，搬到手表上就可能直接表现为"下午三点没电"。本课程的目标，就是建立一套从平台特性出发、以电量预算为约束、可度量可验证的后台任务工程方法。
一、课程要解决的核心问题
后台与电量优化不是"少写几行代码"，而是一组需要同时权衡的工程决策：任务该在什么时机执行、由谁触发、允许运行多久、失败后如何重试、结果如何缓存、用户抬起手腕时能否立刻看到数据。本课程围绕四条主线展开：
- 平台机制：Doze、App Standby、后台执行限制、前台服务类型、WorkManager 与 AlarmManager 的适用边界。
- 任务建模：把"需要定期做的事"拆成约束（网络、充电、电量、时机）与工作单元，而不是简单起一个 Timer。
- 电量度量：用 Battery Historian、Perfetto、Energy Profiler 把"感觉费电"变成"某进程某时段某唤醒源耗了多少"。
- 工程闭环：设定预算 → 实现 → 采集 → 对比 → 回归，形成可重复的验证流程。
二、Wear OS 平台特性对后台设计的约束
Wear OS 基于 Android，但做了大量面向可穿戴的裁剪与增强，理解这些差异是优化的前提。
首先是交互模型。手表以"抬腕即看"为主，单次交互通常只有几秒，因此应用必须做到"数据已就绪"，而不是"打开后再去拉取"。这直接决定了后台任务的核心职责：在用户不看的时候，把数据准备好。
其次是常亮与低功耗显示（Ambient Mode）。进入 Ambient 后，刷新率下降、颜色受限、部分传感器降频。表盘和常驻界面必须区分"交互态"与"环境态"两套刷新策略，否则会在用户根本没看的时候持续高刷。
第三是传感器与健康数据的持续性。心率、血氧、步数等采集往往需要长时间运行，这类任务不能依赖普通后台线程，而要走前台服务并声明正确的服务类型，同时接受系统对采样频率的调节。
第四是与手机的协同。Wear OS 应用常通过 Data Layer、MessageClient 与手机端通信。通信本身会唤醒射频模块，是典型的"高单价"操作，必须合并、批量、去重，而不是每条数据都发一次。
三、后台任务与电量消耗的关系
电量消耗并不与"任务数量"成正比，而与唤醒次数、射频激活时长、传感器占用时长、CPU 高频运行时长强相关。一次网络请求的真正代价，往往不在数据传输本身，而在于把 CPU 和射频从低功耗状态唤醒、建立连接、保持尾时间（tail time）这一整套过程。
因此优化的第一原则是合并与批处理：把 10 次每分钟的独立请求，合并为 1 次每 10 分钟的批量同步，即使总数据量不变，唤醒次数也下降一个数量级。第二原则是约束驱动：把"必须联网"改为"在充电且连 Wi-Fi 时执行"，让系统在合适窗口调度。第三原则是可中断与可恢复：任务被系统终止是常态，必须能从中断点继续，而不是从头再来。
下图给出一个典型手表应用的后台信号链与电量影响路径，用于建立"任务—唤醒—耗电"的整体视角。
四、优化工程的整体视角
把优化当成"改代码"是低效的，更有效的做法是把它当成一个带预算的工程闭环。建议按以下顺序推进：
- 建立基线：在真实手表上跑一遍典型使用场景（例如 8 小时佩戴，含 3 次同步、持续计步、每小时一次心率），记录整机耗电曲线与各进程占比。
- 定位大头：用 Battery Historian 查看唤醒锁（wakelock）、JobScheduler 任务、Alarm 触发次数与射频活跃时长，找出贡献最大的 1～2 项。
- 设定预算：例如"后台同步每小时不超过 1 次、单次射频活跃不超过 8 秒、整机待机电流不超过 3 mA"。
- 改造实现：合并任务、加约束、缩短尾时间、缓存结果。
- 回归对比：在相同场景下重跑，比较耗电曲线与唤醒次数，确认是否达标。
这里的关键是可度量。没有基线和预算，"优化"就只是主观感受。下面给出一份可直接使用的后台任务预算与验证记录表，用于把上述闭环落到具体任务上。
| 任务名称 | 触发方式 | 约束条件 | 目标频率 | 单次射频上限 | 基线唤醒/小时 | 优化后唤醒/小时 | 是否达标 |
|---|---|---|---|---|---|---|---|
| 健康数据同步 | WorkManager 周期 | 充电 + Wi-Fi | 1 次/小时 | ≤ 8 s | 60 | 1 | 是 |
| 表盘天气刷新 | 抬腕触发 + 缓存 | 网络可用 | ≤ 1 次/30 分钟 | ≤ 3 s | 24 | 2 | 是 |
| 心率持续采集 | 前台服务 | 无（常驻） | 按系统采样率 | 不涉及 | — | — | 按传感器预算评估 |
| 消息推送接收 | MessageClient | 无 | 事件驱动 | ≤ 2 s | 不定 | 合并去重后下降 | 待测 |
五、本课程的学习路径
后续章节将沿着"机制 → 建模 → 度量 → 优化 → 验证"的顺序展开：先讲清 Doze、App Standby、前台服务类型等平台规则，再讲如何用 WorkManager 正确建模周期任务与约束，然后进入 Battery Historian、Perfetto 的实操分析，最后落到表盘刷新、健康采集、消息同步等具体场景的优化与回归验证。
学完本课程，你应当能够独立完成这样一件事：拿到一个耗电偏高的 Wear OS 应用，在真机上采集基线，定位到具体的唤醒源或传感器占用，给出改造方案，并用同一场景的数据证明优化有效。这正是"后台与电量优化工程"区别于零散技巧的地方——它是一套可复现、可验证的工程方法。