现象描述

App 接入 360 加固后，冷启动极低概率出现业务逻辑异常。经定位，原因是 UserDefaults 在启动早期读取数据返回 nil。

  • 特征：仅发生在冷启动阶段；运行中正常；加固后始现概率性异常，此前原生环境从未出现。

  • 误区：初次排查怀疑是加固导致文件解密读取失败，但实施数据以明文存储的迁移方案后问题依旧。

根因分析

问题的核心在于加固逻辑干扰了 CFPreferences 的初始化进程：

  • 机制干扰：加固插件在 main 函数执行前进行 Hook 系统函数、内存校验等耗时操作，导致原本瞬时完成的 CFPreferences 缓存重建（rebuild）变为异步耗时过程。

  • 竞态条件：当 didFinishLaunching 触发时，磁盘文件尚未完成加载解析并映射至内存。此时调用 UserDefaults API，因内存缓存为空且后台同步未完成，直接返回 nil。

  • 性质：数据并未丢失，只是由于读取时机早于系统完成初始化的时机，产生了“预热未完成”的空值。

方案选型

  • 舍弃方案：要求加固方优化 Hook 逻辑或强制将 rebuild 改为同步。由于系统底层机制闭源且加固逻辑不可控，这类“硬碰硬”的方案不可行。

  • 最终解决（双读写备份）：

    • 持久化备份：在 App 进入后台时，将关键配置同步写入自定义的磁盘文件

    • 降级兜底：冷启动时，若检测到 UserDefaults 读取为 nil，则立即读取备份文件，并将其回填至 UserDefaults。

    • 效果：手动回填会直接更新 UserDefaults 的内存缓存，即便此时系统级的异步 rebuild 尚未结束，后续业务读取也能获取正确值，待系统 rebuild 完成后会自动进行数据合并。

第三条路

我们应警惕“表象原因”带来的误导。盲目施治导致的故障率下降，往往是隐患深埋的开始，这不仅会模糊真相，更会加剧后续解决问题的成本。

解决问题的核心在于达成结果。与其困于修正不可控的环境，不如通过自身的“兼容”与“补位”化解冲突。正如加固与系统的不兼容，世间许多矛盾不在于谁对谁错，而在于如何找到共存的最优解。