2. Wear OS系统架构与后台运行机制

Wear OS 并不是把手机 Android 简单缩小后塞进手表，它在应用进程模型、系统服务组织和后台限制策略上都做了针对穿戴设备的裁剪与强化。理解这套架构，是后续做后台任务调度和电量优化的前提。本节从应用进程模型、系统服务、后台限制策略以及 Doze 与 App Standby 在手表上的表现四个层面展开。

应用进程模型：前台、可见与缓存的分层

Wear OS 基于 Android 的进程管理机制，但可用内存更小、CPU 更弱，因此进程回收更激进。一个应用通常以以下几种进程形态存在：

• 前台进程：正在与用户交互的 Activity，或持有前台服务（Foreground Service）。优先级最高，几乎不会被系统回收，但会持续占用 CPU 与屏幕相关资源。
• 可见进程：Activity 仍可见但不在前台（例如被表盘覆盖一部分），或绑定了一个可见服务。优先级次之。
• 服务进程：运行普通后台 Service，未绑定前台通知。在手表上这类进程存活时间明显短于手机。
• 缓存进程：无活跃组件、仅保留在 LRU 列表中的进程。手表内存通常只有 512MB～1GB，缓存进程很快被回收。

关键结论是：在 Wear OS 上，普通后台 Service 不是可靠的长期运行载体。如果业务需要持续采集心率、持续定位或维持网络连接，应使用前台服务并配合常驻通知，或改用 WorkManager 等受系统调度的机制。下面这张图展示了 Wear OS 中应用进程、系统服务与后台限制策略之间的整体关系。

系统服务：谁在管后台

Wear OS 中与后台行为直接相关的系统服务主要有四类。ActivityManager 负责进程优先级判定与低内存回收，它决定了你的进程在内存紧张时是否被杀死。AlarmManager 负责定时唤醒，但在 Doze 下会被延迟到维护窗口。JobScheduler 负责带约束的延迟任务，是后台工作的推荐入口。PowerManager 管理唤醒锁与 Doze 状态切换。此外 SensorService 在手表上尤为关键，因为心率、加速度计等传感器是穿戴设备后台耗电的主要来源之一。

需要特别注意的是，Wear OS 对 AlarmManager 的精确闹钟限制比手机更严。在 Doze 状态下，setExactAndAllowWhileIdle() 虽然能触发，但系统仍会做对齐，且频率被限制。如果应用依赖每分钟唤醒一次做数据采集，在手表上几乎必然被压制，应改用传感器批处理（batch）或前台服务。

后台限制策略与 Doze 在手表上的表现

Android 6.0 引入的 Doze 与 App Standby 在 Wear OS 上被进一步强化。手表进入 Doze 的条件比手机更容易满足：屏幕关闭后，只要设备静止（加速度计判定无显著运动），通常在数分钟内就会进入 Doze。进入后系统会：

• 暂停网络访问，推迟 JobScheduler 任务与 AlarmManager 闹钟；
• 忽略 WakeLock，除非应用持有前台服务；
• 停止 GPS 与大部分传感器的高频采样；
• 仅保留维护窗口（maintenance window）周期性放行任务，窗口间隔随静止时间延长而增大。

App Standby 则按应用使用频率分桶。手表上用户主动打开应用的频率远低于手机，因此大量应用会落入 rare 或 restricted 桶，网络和任务配额被大幅压缩。这意味着“装上去就一直在后台跑”的假设在 Wear OS 上不成立。

实践判断：如何验证后台是否被限制

在真机或模拟器上，可以通过以下命令观察 Doze 与待机桶状态：

# 查看当前 Doze 状态
adb shell dumpsys deviceidle

# 查看应用的待机桶
adb shell am get-standby-bucket com.example.wearapp

# 强制进入 Doze 进行测试
adb shell dumpsys deviceidle force-idle

# 退出 Doze
adb shell dumpsys deviceidle unforce

执行 force-idle 后，观察应用日志中后台任务的触发时间。如果原本每 15 分钟执行一次的任务变成数十分钟甚至更久才执行一次，说明已被 Doze 压制。此时应检查任务是否使用了 setExactAndAllowWhileIdle、是否声明了 REQUEST_IGNORE_BATTERY_OPTIMIZATIONS（手表上通常不推荐），以及是否应该改为前台服务。

另一个可观察指标是待机桶。若 get-standby-bucket 返回 40（rare）或 45（restricted），说明系统已将该应用归入低频使用，网络与任务配额都会收紧。此时应优先保证前台体验，把非关键同步延后到充电或维护窗口执行。

架构层面的优化启示

综合来看，Wear OS 的后台机制可以归纳为三条工程原则。第一，前台优先：任何需要持续运行的能力都应通过前台服务加通知来声明，让用户和系统都明确知道。第二，批处理优先：传感器数据尽量使用 batch 模式累积后一次性上报，减少唤醒次数。第三，约束优先：用 WorkManager 声明网络、充电、空闲等约束，把执行时机交给系统统一调度，而不是自己用 Alarm 硬拉。