R8 优化得分与 APP 加固性能成本矩阵 V1（未执行模板）

这是一份未执行模板，用于把当前 R8 规则、收敛后的 R8 规则、御盾基础保护和目标保护放进同一性能门禁。它不包含任何客户 App、真实规则、设备、候选包或测量结果，也不能证明御盾对启动、包体、内存、DEX、Crash/ANR 或 SDK 兼容性的实际影响。团队只有按同一业务提交、同一 Release 条件和同一测试口径执行后，才能把对应单元格从“未执行”改成“通过、失败或未覆盖”。

摘要

Android 项目出现“加固后变慢”时，常见错误是直接比较一个构建债务未清理的原包与一个正式保护包。这个对比同时改变了 R8 Keep 规则、SDK Consumer Rules、资源、签名、保护策略和运行环境，无法回答差异首先发生在哪里。

本矩阵将问题拆成四个阶段：A 组保留项目当前 R8 规则；B 组只收敛有证据支持的宽泛、重复、未使用或被覆盖规则；C 组在 B 的基础上应用御盾基础保护；D 组再应用目标保护。每一组都使用相同的业务提交、Build Variant、依赖版本、ABI、测试环境、采样方法和关键路径。门禁记录的是“本次候选是否满足本项目阈值”，不是跨 App 的性能排名。

读者对象

• 正在评估 APP 加固性能成本的 Android 研发、性能、QA 和安全团队；
• 已启用 R8，但仍有大量 Keep/Consumer Rules 或 DEX、包体、启动问题的构建负责人；
• 需要区分构建链、第三方 SDK 与保护策略责任的 PoC 和采购评审人员；
• 希望把 R8 分数回退、性能阈值、关键路径和回滚对象加入 CI/CD 的发布负责人。

验收目标矩阵：本轮主目标与非目标

本轮主目标是建立一条可复核的性能归因链：先说明现有 R8 规则是否已经限制 Release 优化，再测基础保护和目标保护各自的增量，最后把关键业务路径与量化指标绑定到同一个候选身份。只有同一批次的 A、B、C、D 四组都满足身份冻结和采样口径，结果才可以进入项目发布判断。

本轮非目标包括：评测某个客户 App、公布生产规则或 Mapping、比较不同加固厂商、证明某种保护算法强弱、推导所有 Android 设备的统一性能值，以及复制 Tinder 的提升比例。模板也不负责自动决定阈值；冷启动、内存、包体、Crash/ANR 和业务路径的门槛必须由项目结合用户分布、历史版本与风险等级约定。

执行前还应指定一个停止条件：发现候选身份不一致、测试环境漂移、关键路径定义不完整、指标工具更换或结果无法重复时，立即把相关单元格保留为“未执行”或“未覆盖”，重新生成批次。不能为了填满表格，把不同时间、不同设备或不同构建的数字拼成一个看似完整的结论。

核心结论

1. 矩阵默认全部未执行。 模板、字段或文章上线均不是兼容和性能证据。
2. R8 三个分数不是御盾安全评分。 Shrinking、Optimization、Obfuscation 分别反映代码可被对应处理的范围。
3. 规则收敛必须有动态入口证据和 Release 回归。 分数提高不能替代反射、JNI、序列化和 SDK 关键路径。
4. 先比较 A→B，再比较 B→C→D。 这样才能区分构建债务、基础保护和目标策略的增量。
5. 指标口径必须一致。 下载体积、APK/AAB 大小、安装占用不能混写；冷启动单次值不能与另一组 P95 比较。
6. 第三方案例不进入结果栏。 Google 公布的 Tinder 数字只能作为方法依据，不能填入御盾矩阵。
7. 发布决定同时看性能与业务。 分数、DEX 或体积改善不能抵消登录、支付、推送、WebView、Native 等关键路径失败。
8. 未覆盖不等于失败，也不等于通过。 每个空白条件都应保留独立状态和下一步责任人。

事实依据与脱敏证据

官方报告事实映射：来源、事实与使用边界

工具与平台动态时间线

技术拆解：四组候选为什么必须分层

A/B 两组回答“当前构建规则和收敛规则之间有什么差异”，B/C/D 三组回答“基础保护与目标保护分别增加了什么成本”。这两个问题不能用一次原包/加固包比较同时回答。技术拆解的关键不是增加包的数量，而是让每个相邻组之间只有一个可描述的变量，并让性能指标和业务路径绑定同一个候选身份。

一、候选身份冻结表

候选身份不一致时，矩阵应立即停止。比如 B 同时升级了 SDK、C 更换了渠道脚本、D 使用了不同 targetSdk，就不能把差异解释成 R8 或保护成本。若业务必须同时变更，应新增独立批次，而不是覆盖原记录。

二、R8 配置健康矩阵

“分数上升”只说明更多代码可参与对应 R8 处理。团队仍需确认被收敛规则覆盖的类、字段和方法是否存在动态调用，并用 Release 关键路径验证。任何临时宽规则都要写明责任人、适用版本和到期条件，防止兼容救火永久化。

三、性能与稳定性成本矩阵

每个数字都要附带采样工具、设备档位、系统版本、迭代次数、预热策略、网络状态和统计口径。若没有统一口径，结果栏保持未执行。对线上指标，应把发布时间、灰度比例、用户样本和业务变化单独记录，不能与本地基准直接合并。

四、关键业务路径矩阵

性能符合阈值但关键路径失败时仍应阻断。关键路径通过但性能缺少统一采样时，只能标记“业务路径通过、性能未覆盖”，不能写成整体发布通过。

五、差异归因规则

1. A 异常：优先检查现有业务、SDK、规则与 Release 构建，不进入御盾性能结论。
2. A 正常、B 改善：记录 R8 规则债务收益，再以 B 作为保护前基线。
3. B 首次失败：恢复或修正本次规则收敛，检查反射、JNI、序列化和 Consumer Rules。
4. B 正常、C 首次异常：进入基础保护、加载、包体和兼容归因。
5. C 正常、D 首次异常：定位 D 相对 C 唯一新增的目标策略，不关闭全部保护。
6. 各组均正常但线上异常：检查分发物、签名、渠道、灰度、设备分布与业务环境，不用本地矩阵覆盖线上事实。

差异归因的目标不是寻找一个默认责任方，而是找到第一次出现可重复差异的阶段。每次只改变一个能够描述的变量，并保留回滚对象与复测条件。

攻防视角：宽泛规则与保护成本

宽泛 Keep 规则会保留更多类、成员和静态结构，可能降低 R8 的缩减、优化与混淆空间；但收敛规则也可能暴露此前被掩盖的反射、JNI 或序列化契约问题。御盾目标保护则关注关键代码、Native 载体、完整性和运行时风险，两者作用层不同，不能把 R8 分数当作保护强度，也不能为了性能直接关闭全部安全能力。

攻击者可能关注可读类名、调用入口、字符串和运行时链路；项目方则必须同时保障启动、业务与发布稳定。因此门禁应保留两个独立判断：R8 是否让构建图获得合理优化空间，目标保护是否在可接受成本内达到约定安全目标。任何一项失败都需要单变量回退，而不是用另一项的改善抵消。

工程落地：CI/CD 门禁建议

• Analyzer 报告与候选版本绑定，避免读取旧报告；
• 对三个分数设置“显著回退需人工复核”，而不是盲目追求固定高分；
• 新增宽泛规则、Consumer Rules 或依赖版本时要求责任说明；
• B/C/D 使用相同业务提交和锁定依赖；
• 性能阈值与关键路径同时通过才允许进入下一阶段；
• 所有例外写明批准人、影响范围、到期条件和回滚对象；
• 未执行和未覆盖不允许被转换成通过；
• 不上传生产 Mapping、完整规则、签名材料或真实业务类名到公共系统。

风险边界与状态枚举

常见误区

最常见的误区是把“R8 已开启”理解成“当前 Release 已充分优化”，再把原始构建的全部启动、体积和 DEX 成本归到加固层。另一个误区是看到 Analyzer 标记宽泛规则就立即删除，却没有确认反射、JNI、序列化或第三方 SDK 的动态入口。正确做法是先冻结 A 组，再以可回退的小步调整形成 B 组，并对每条规则变化执行对应 Release 路径。

同样不能把第三方公开案例当作御盾第一方证据，也不能因为 C/D 的某个平均值变化不大就宣布“性能无影响”。矩阵必须保留指标口径、分位数、设备档位、关键路径、未覆盖项和回滚对象。

常见问题

可以直接把 Tinder 的 47% 填入御盾矩阵吗？

不可以。该数字描述 Tinder 在自身代码、规则、设备和用户条件下，收敛过宽 Keep 规则后的结果。它不属于御盾，也不代表其他 App 的可重复收益。

R8 分数越高，APP 就一定越安全吗？

不一定。分数描述可参与缩减、优化或混淆的代码比例，不是安全评级。R8 也不能替代运行时保护、完整性、服务端鉴权和业务风控。

B 组体积明显下降，是否可以跳过 C、D 的关键路径？

不能。规则收敛可能改变反射、JNI、序列化或 SDK 入口；保护阶段也可能引入新的加载和包体变量。每一组都必须执行约定路径。

加固候选变慢，是否应该先关闭全部保护？

不建议。应比较 B→C 和 C→D，定位差异第一次出现在哪一级，再只调整一个明确策略并保留回退。全关保护会丢失归因能力和安全目标。

这份模板能否证明御盾性能影响很小？

不能。当前模板没有真实候选包或测量数据，只提供字段、状态和归因方法。项目结论必须来自同一版本的实际执行。

延伸阅读与转化路径

先阅读R8 Configuration Analyzer 如何排查 APP 加固后 SDK 异常，理解规则、SDK 与候选组的关系；整体性能口径进入性能与兼容性中心；需要确认保护、PoC 与产品边界时进入御盾 APP 加固唯一商业入口。

若准备执行本矩阵，可提交脱敏 Analyzer 摘要、当前 R8 Release 与目标保护候选。请勿提交生产 Mapping、完整 Keep 规则、客户源码、签名材料或真实业务类名。

申请 R8 × APP 加固性能矩阵评估

结语

本矩阵的价值不是给出“御盾性能影响很小”的预设答案，而是把 R8 规则债务和保护成本放进同一条可复核链。先用 A/B 说明构建基线，再用 B/C/D 说明保护增量；同时保存指标口径、关键路径、未覆盖项和回滚对象。只有这样，启动、包体、内存与稳定性数据才足以支持项目自己的发布决定。