WhatsApp网页版

索引校验与重建的边界

◆ 索引重建耗时与历史条数近似正相关，与设备性能的关系弱于直觉，别急着怪机器。◆

如果你也在处理WhatsApp网页版，这篇可以顺手对一下。 如果你也在处理WhatsApp网页版，这篇可以顺手对一下。 相关的坑WhatsApp网页版 里列得比较细，可以对照看看。 顺便一提，WhatsApp网页版 讲的是另一个容易忽略的点。

检视过程并不读取全部消息，只比对索引头部的校验值。

校验值一致就直接挂载，界面几乎瞬时可用。

不一致才触发重建，此时耗时随条数线性增长。

两万条以内通常两秒内完成，十万条会跨多轮空闲调度。

重建期间界面仍可用，只是检索结果暂时缺失。

反复重建通常意味着存储配额不足，索引写不完整。

把可用存储提到五百兆以上，重建次数明显下降。

媒体缓存的生命周期

◆ 媒体按最近访问顺序淘汰，保留窗口约半年，未点开的文件几乎不落盘，点开才算缓存。◆

图片与语音在首次展示时才下载，下载后写入本地。

视频与文档默认不预取，仅保留缩略图与占位信息。

超过保留窗口的条目，由下一次清理任务按序移除。

移除只影响本地副本，重新点开仍可从服务端取回。

真正不可恢复的是被撤回或已删除的内容，与缓存无关。

通知抵达的三道关

◆ 通知能否抵达取决于标签是否被挂起，权限只是最外层那道门，过了门也未必送到。◆

授予通知权限之后，页面仍需处于可唤醒状态。

标签被系统挂起时，长连接休眠，通知改由系统层补发。

补发存在数秒到数十秒延迟，且不保证先后顺序。

常驻可减少挂起，代价是常驻内存持续抬升。

通话类请求依赖实时链路，挂起状态下必然错过。

内存台阶的成因与回收

◆ 内存曲线呈阶梯上升，每级台阶对应一次长会话挂载，台阶不会自行回落只增不减。◆

初始加载后稳定在两百余兆，随后随浏览历史抬升。

每打开一个长会话，曲线出现一级台阶，幅度约三十兆。

连续使用六小时，占用到四百兆以上属常见区间。

重载标签可拉回基线，代价是重新走一次同步补齐。

观测项	参考值
索引校验	＜ 80 ms
索引重建	1.8–6.4 s
缓存命中	约 71%
缓存窗口	180 天
重载建议	每 6 小时

1. 记录首次打开到可交互的耗时，作为当日基线。
2. 对比六小时后的内存读数，算出台阶幅度。
3. 重载后复测，验证是否回落至基线区间。
4. 回落失败则检查存储配额是否逼近上限。

章节收束：三个判断口径

◆ 判断索引是否健康看检索命中率，判断缓存是否有效看重新点开的等待，判断内存是否该回收看台阶。◆

检索结果缺段，先看索引是否处于重建窗口。

重新点开历史文件若立即出现，说明本地副本仍在。

内存台阶超过三级且持续不回落，即可安排重载。

索引头部

记录校验值与分段偏移的元数据区，决定是否全量重建。

缓存淘汰

按最近访问时间排序移除的策略，不区分文件类型。

标签挂起

浏览器为省资源冻结后台页面的机制，会中断心跳。

同一条消息为何有时搜得到有时搜不到

[核心疑难] 检索不稳定多与重建期间的分段缺失有关。

[底层诊断] 重建按分片推进，已完成分片可检索，未完成分片被跳过，重建结束即恢复。

清理缓存会不会把消息弄丢

[核心疑难] 清理本地缓存不影响服务端留存的消息本体。

[底层诊断] 丢的是缩略图与已下载副本，重新点开按需回源，仅多一次流量。

长期挂着网页端是不是更省心

[核心疑难] 常驻能减少挂起导致的通知延迟，但内存只增不减。

[底层诊断] 挂载过的会话不会被主动卸载，六小时后重载是较优折中。