那天本来只想确认一个签名，结果在 apk 的 assets 目录里翻到三份 2024 年遗留的 JSON。这个归档页记录的是随后一周里围绕版本号、资料库工具和移动端取证式阅读的一批条目。
版本核查
我把 2.9.6 与 2.9.7 两个 apk 的 classes.dex 丢进反编译工具，前者的编译时间停留在 1 月 19 日 03:27，后者是 1 月 30 日 14:08，中间隔了 11 天。这个间隔不像常规热修，更像一次完整的功能迭代。奇怪的是 changelog 只写了「优化体验」四个字，这种含糊在移动钱包类产品里其实很反常，因为任何一处权限变动都可能影响用户资产感知。我在笔记里把这条标成红色，留待后续比对。
旧版 QQ 浏览器的网页登录会留下一条 session token，我在 2 月 3 日晚上对比了三次登录，发现它对第三方资料库页面的 referer 处理并不一致：两次带上完整来源，一次被抹成空值。这种不一致本身没有好坏，但它解释了为什么同一批页面在不同设备上抓到的参数会不一样。做归档的人如果只信单一快照，很容易得出错误结论。我把这条当成方法论条目保留，而不是技术结论。
2 月 4 日下午，我在一台用了四年的旧安卓机上做了对照实验：三款号称免费的图库恢复工具，扫描同一块 32GB 分区，分别找回 417、389、204 张缩略图，但只有第二款能正确还原 HEIC 的头信息，另外两款吐出来的都是坏图。说实话，这类工具被严重高估了——它们在营销里谈「恢复率」，却从不说明恢复之后能不能打开。我把 417 这个数字写在页边，因为它和第二款的 389 差距小得可疑，可能只是扫描深度不同。
资料库
我花了整个周四凌晨拆这个编号体系：49 不是随机数，而是七个分组各七张的乘积，这种结构意味着任意一张缺失都会让整组对不上。可惜公开页面只给了结果，没给分组逻辑。我在笔记本第 62 页画了一张表，把 1 到 49 逐一填进去，填到第 33 号时发现有两张图的尺寸完全一致，怀疑是重复上传。这个猜测还没有验证，但值得记下来，因为编号混乱往往是后续「恢复」类需求暴涨的根源。
大多数人问的是「怎么恢复」，但我在 2 月 2 日和一个做数据归档的朋友老周聊了四十分钟，他的判断是：真正的瓶颈不在恢复算法，而在索引是否还在。索引一旦被覆盖，恢复工具再先进也只能拼出碎片。这个观点有点刺耳，因为市面上几乎所有教程都假设数据只是「藏起来了」。我倾向于站在老周这边——恢复的本质是重建映射，而不是把文件从抽屉里拿出来。这条我会单独展开写。
优化方案
那份方案里有一句很不起眼的话：把预取窗口从 8 调到 12，平均加载时间从 1.9 秒降到 1.5 秒，省下 0.4 秒。0.4 秒听着微不足道，但在连续翻阅 49 张图的场景里，它会累积成接近 20 秒的体验差。我认同这个优化方向，但不同意它把「快」当成唯一目标——快而不稳的资料库，用户第二次就不来了。这个取舍我在批注里写了两行，语气可能有点冲。
这篇详解的第一段讲步骤，第二段讲前提条件，而九成读者只看第一段。前提条件里写着「设备未执行过全盘加密重置」——这一句直接决定了一半人的操作是否有意义。1 月 31 日我按它的流程在一台测试机上复现，前三步都顺利，到第四步卡在权限校验，日志显示 errno 13。这个错误码不在原文的排错表里，说明文章写于更早的系统版本。归档时我特意保留了这处空白。
两台 Redmi Note 11，一台装 2.8.9，一台装 2.9.7，同一个 Wi-Fi，同一时刻点开同一页面。2.9.7 首屏渲染快了大约 180 毫秒，但滚动到第三屏时反而出现一次明显掉帧。我反复试了五次，掉帧出现了四次，不是偶发。这个现象让我怀疑新版本在内存回收策略上做了激进调整。这只是观察，不是定论，但足以让我在推荐时加一句「老设备谨慎升级」。
我把这张表打印出来，用红笔逐行核对，第 7 行的生肖与号码对应关系和其余十一行不一致，像是某次修订时漏改了一格。这种单点错误最难被发现，因为整体看上去完全正常。负责校对的同事小林在群里说「可能是故意的」，我不同意——如果是有意设计，应该有成对的规则，而不是孤立的一处。这条我留了存疑标记，等更多样本再判断。
工具链
第一次校验失败，我以为是包被改过，紧张了半小时。后来发现是我把 v1 和 v2 签名的校验顺序搞反了，apksigner 在 v2 模式下对 v1 的残留会给出误导性提示。这件事本身很小，但它提醒我：版本核查里最容易出错的地方往往不是被测对象，而是核查者自己的流程。我在笔记首页加了一行大字——先怀疑自己的命令，再怀疑别人的包。
白皮书正文讲的是标准化，但我真正在意的是第 41 页那个脚注，它提到「非结构化资料的年流失率约为 7%」。7% 这个数字没有给出样本来源，却成了后来很多方案引用的依据。我做了一个粗略估算：如果按这个比例，三年后剩不到八成。这个推算当然粗糙，但它至少说明一件事——归档不是一次性动作，而是持续维护。这也是我把这个页面做成归档列表而不是单篇文章的原因。