I4.03.3match update rate to change rate设计

更新频率需与内容变化率匹配

别名: 变化率匹配 · update cadence · 刷新节奏 · freshness cadence

概念解释

通道选完之后,还要决定「多勤地让界面跟上事实」。更新频率与变化率匹配指界面刷新的节拍对着内容真正发生变化的节拍,而不是对着技术能达到的最快节拍。变化以小时计的资料,每秒刷一次是在表演实时;变化以百毫秒计的对局,每十秒问一次是在装聋。通道是手段,匹配是策略。

机制

内容有自己的时间结构。聊天消息成簇到达,中间有长静默;股价在开盘时段密、收盘后停;文档的「他人正在编辑」只在有人动时为真。界面若用一条均匀的高频去覆盖所有这些,会在静默期制造大量无变化的重绘和请求,在高峰期又可能仍跟不上。匹配的意思是让采样密度跟着源的带宽走:源静则界面静,源密则界面密,并设上限以免事件把绘制打满。

不匹配有两种失败,观感不同。过密:数字或列表在人还没读完时就换掉,注意被刷新本身吸走,电池和流量无收益地耗着。过疏:人按内容类型期待已经变了,界面还停在旧帧,于是去手动下拉——手动刷新是匹配失败的症状,不是功能。

边界

同一屏上的不同区域变化率不同(会话流和侧栏在线人数),不能共用一个频率;侧栏可以更疏。变化率会随时段跳变(开盘 / 收盘、比赛开始 / 结束),固定匹配会在跳变后立刻错位,需要跟着源的状态机改节拍。无障碍用户若每次刷新都被读屏重读整块区域,过密的匹配会变成无法使用,应对变化做聚合后再宣告。合规或审计要的是「某一时刻的快照」而不是最新,匹配最新会破坏那条产品约束。

怎么落地

  • 给每类内容写清源的典型变化间隔和可接受的界面延迟,两者应对齐,而不是对齐「我们有推送所以总能最新」。
  • 静默期降低刷新或暂停;源进入高峰时提高,但给绘制设合并窗口,避免每一事件都触发布局。
  • 把「手动下拉才有新内容」当成匹配失败的信号:先查频率是否低于源,再查通道是不是断了。
  • 验证:在源几乎不变的时段看请求和重绘,应接近安静。在源变密的时段,界面跟上的延迟应落在预算内,且读屏不会被逐条刷新淹没。把频率调到远高于源,用户应开始抱怨闪;调到远低于源,应开始出现频繁手刷。

延伸

  • 同组I4.03.1 轮询简单但存在延迟与浪费 · I4.03.2 推送实时但依赖连接维持
  • 相邻I4.07 实时性等级与一致性预期 · I2.12 缓存与陈旧内容
  • 站内检索update cadence · change rate · refresh budget

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/I4.03.3