H5.09.4subscription state syncs between notification and settings设计研究
订阅设置需要在通知本身与设置页之间保持同步
别名: 订阅状态同步 · 通知与设置不一致 · channel state drift
概念解释
在通知上关掉一类，设置页必须立刻显示已关；在设置页打开一类，下一张该类通知上的状态也要一致。两处是同一份订阅，不是两套开关。不同步时，人会认为自己的选择没生效，下一步就是绕过应用、去系统权限。
这条是状态的单一来源。它不是「通知上要有退订入口」本身，也不是类型该多细。
机制
人把最近一次操作当成真相。操作发生在通知上，眼睛却可能下次去设置页核对；或反过来。两处各写各的，核对失败，信任从「这类听我的」掉到「这个应用的开关是摆设」。系统通道、应用内设置、服务器侧名单若再加第三份，漂移会在飞行中的推送上表现出来：刚关仍收到，或刚开仍没有入口去确认。
同步必须是双向且即时的。只把设置页当主、通知上的关只静音眼前这一张，会让就地操作变成谎言。只把通知当主、设置页缓存旧值，人会在设置里把已经关掉的再打开，以为自己在开启。
怎么研究
让人在一面改订阅，立刻去另一面读状态，再发一张该类通知看是否遵守新状态。插入延迟、失败和多设备。
自变量：改动发生在通知还是设置、同步延迟、是否有第三份系统通道列表。 因变量：两面一致所需时间、改后仍到达或仍不出现、人是否改去关系统权限。
实验室单设备、即时网络会低估漂移。至少用两台设备或人为延迟。不要把「最终一致」当合格——人在改完的当下就会核对。
边界
离线时可以先写本地再排队，但回线后的第一件事是收敛，并在仍未收敛时不要发送该类。操作系统自己的通道开关若被用户在系统设置里改了，应用内页必须读到那次改动，不能覆盖回去。被管理设备上管理员策略与个人设置冲突时，两面都要显示「由管理员锁定」，而不是一边能拨一边拨不动。
怎么落地
- 通知菜单、应用设置、服务器名单共用一个订阅记录；任一处写入后其他处只读这一份。
- 写入失败要在操作发生的那一面报出来，不要显示成功却继续按旧名单发。
- 多设备在打开设置页或收到下一张通知前必须拉一次。
- 验证：在通知上关「社交」，一秒钟内打开设置页，该项应为关；再发一条社交，不应到达。设置页打开「社交」后，下一张社交通知的菜单应显示为开。任一步反了，人就会去关系统权限。