K4.08.2watch sync freshness versus battery设计
后台数据同步频率需要在及时性与续航之间取舍
别名: 手表后台同步 · 及时性续航 · background fetch
概念解释
手表要在没人操作时把邮件摘要、健康样本、日历变更拉到腕上，每一次后台同步都要唤醒射频或问手机。拉得越勤，抬腕时越可能看见「现在」；拉得越勤，电也掉得越快。取舍发生在及时性和续航之间，对象是整机后台管道（通知、样本、收件箱），不是表盘某一个槽的时间线预算。手机可以相对慷慨地常开推送，手表的电芯不允许同一策略原样搬过来。
机制
后台同步的成本是一次射频会话的固定开销，与这一次到底拉了几个字节关系不大。把间隔从十五分钟收到三十秒，次数乘几十，底噪按倍数涨，用户感知的「新」却不是线性变好——多数查询并不需要秒级新鲜。推送比轮询省在「没事不醒」，但应用若把所有变更都标成高优先级，推送会退化成变相轮询。手表还常常经过手机中继：一次同步可能是「手机已经有了 → 再转发腕上」，两跳都在耗各自的电，但人只责备手表晚上不够用。迟到的数据若仍看起来像现在（精确到分钟的时间戳还在），及时性失败会伪装成正确，直到人拿手机一对。
边界
安全告警、跌倒检测、导航纠偏不能进这条取舍去「省着拉」，它们的延迟有人身代价。仅在充电或 Wi-Fi 时做的大包同步（表盘资源、音乐库）不应混进全天候的小包管道，以免把白天预算拿去搬文件。无手机且无蜂窝时管道不存在，及时性为零，界面要承认「不是现在」，而不是继续按在线间隔空转。企业邮箱强制即时到达，会把取舍权从产品拿走，需要在电量界面上把这笔账标出来，让人知道是策略而不是故障。
怎么落地
- 按问题给同步分档：必须立刻到腕上的走推送；按小时问一次就够的走窗口；只有打开应用才需要的不要后台拉。
- 禁止应用把所有变更标成高优先级。高优先级名额按天限额，用尽后降到窗口同步。
- 数据带上「采于何时」。超过该问题可接受窗口的值，显示成旧的，而不是精确到分地假装活着。
- 验证：把某类后台从「尽量即时」改到与问题匹配的窗口，对数天的到达延迟中位数和同窗电池曲线。延迟仍在问题可接受范围内且傍晚电量回升，说明原先在用同步频率冒充及时，而不是在服务抬腕。