H5.10.3batch deferred notifications into one send window设计研究
多条待发通知应合并到同一时段批量发送而非逐条打扰
别名: 合并发送 · 发送窗口 · digest delivery
概念解释
可推迟的条目不应按产生节奏逐条推到设备上。把它们收进一个发送窗口——每小时一次、午餐一次、晚间一次——到点再发出，一次打断覆盖一批。这是发送调度，不是通知栏里把已到达的卡片收成摘要：栏里还没出现的东西，用时钟把打扰次数收成一次。
机制
每次到达都可能切一次任务。五条同类若按服务器事件时间各响一次，人付五次恢复；若攒到窗口边界一起到，恢复次数接近一，信息量仍在。窗口是在用延迟换打断次数。延迟对可推迟类型可接受，对时效类型不可接受，所以进窗口的资格应由后果矩阵把关，而不是「全部等整点」。
窗口还要防「到点炸弹」：一小时积了四十条，整点一起出声四十次，批发送就失败了。到点应是一次打断，内容上可以是一条摘要或一组几乎同时入栏但不逐条出声的卡片。
怎么研究
把同一可推迟流做成「事件后立即发」与「整点窗口发」，在真实主任务上比较打断次数、信息是否仍被看到、延迟是否造成过期。
自变量：窗口长度、窗口内是否再出声、时效类型是否绕过窗口。 因变量：打断次数、过期未看的条目、窗口到达后的打开与处理、主任务恢复滞后。
实验室里窗口显得「更整齐」，但要测过期：验证码进了窗口就废了。不要用到达条数当打扰——打扰是出声或占屏的次数。
边界
即时通讯的社会期望是秒级，强行进窗口会让通道像坏了。实时协作、导航、通话状态同样不进窗口。窗口若与用户的静默时段重叠，应在时段结束后的第一个窗口冲洗，而不是在静默中整点响。设备离线时窗口要在上线后合并成一次，不要把积压按原事件时间回放成连响。
怎么落地
- 给营销、成就、社交汇总、非时效状态设发送窗口；安全与验证码绕过。
- 窗口触发时最多一次出声，其余入栏；内容多时先发摘要。
- 过期时间短于窗口的条目不得进队。
- 验证：一小时内产生八条可推迟到达。用户应被打断一次而不是八次，且八条都能在栏里找到。若仍是八次声音，调度还在按事件滴送；若一次之后找不到成员，批发送变成了丢失。