附录 C 客户端架构评审清单

怎么用这张清单

这是一张证据清单，不是打分表。每一组检查项都要求给出可核对的证据：一张依赖图、一段测试输出、一份真机报告、一条线上查询。答「有做」不算通过，答「证据在哪」才算。

建议在两个时点使用：

• 立项或大改版前：完整过一遍，标出没有证据的项，作为技术方案的第一批风险。
• 版本复盘时：只过与本次改动相关的组，确认没有回退。

判定只有三档：通过（证据齐全）、部分（有设计无证据）、未过（无设计且无证据）。「部分」按未过处理，因为它意味着结论还没被验证。

一、分层与依赖

最关键的一条是「边界有断言」。写在 Wiki 里的分层规则，三个月后就会变成历史建议；写成测试的规则，才会在 CI 里拦住违规提交。

二、生命周期与恢复

判断标准很简单：任意时刻强杀进程，重新进入后玩家损失是否可以接受。「可以接受」要写进产品需求，不能由开发自己拍。

三、配置

最常见的事故不是「配置错了」，而是「配置错了之后客户端没有兜底」。校验解决的是发布前，兜底解决的是发布后。

四、资源与内存

降级顺序必须事先定死：先降特效、再降分辨率、再降同屏单位、最后降帧率。每次临时决定顺序，结果就是同一款产品在不同版本里表现不一致。

五、UI 与输入

UI 层的评审要拿真机截图，不要只看设计稿。安全区、字体缩放、系统深色模式这三件事，设计稿永远显示不出来。

六、帧率与功耗

帧率类问题的难点不在「优化」，而在「验收」。没有预算表和真机曲线，「我觉得还行」会一直拖到玩家投诉。

七、存档

存档是唯一不可重建的玩家资产。其它模块出问题可以热更，存档出问题往往只能补偿。

八、区域化

区域化评审最容易漏的是「字体覆盖」和「时区口径」。前者上线才看得见，后者往往在跨时区活动开启的第一天才爆发。

九、可观测性

没有切片的可观测性等于没有可观测性。一个 0.1% 的整体崩溃率，可能由某个机型 5% 的分支和其余机型 0.02% 拼成；只看总数，永远找不到那个分支。

十、评审的收口方式

评审结束时，产出一张表，而不是一段结论：

「部分」项要写明缺的是哪份证据，以及什么时候能补。没有截止时间的「部分」，三个月后仍然是「部分」。

第 13 章会把这张表与双案例基线合并成两份可复核的产出：模块矩阵与性能预算。评审清单负责「有没有」，基线表负责「到什么程度」；两者都齐了，卷一才算真正收口。