Back to Details

r8-analyzer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Core workflow

核心工作流程

  • [ ] Step 1: Create a file called R8_Configuration_Analysis.md, or reuse if one exists already, to store the output
  • [ ] Step 2: Look at the configuration of R8 by looking at build.gradle, build.gradle.kts, gradle.properties in the codebase using references/CONFIGURATION.md as the reference. Inform the developer and add the analysis to the report file
  • [ ] Step 3: If the AGP version is less than 9, suggest moving to AGP 9.0 version as AGP 9.0 includes optimizations.
    • [ ] Step 4: Look at the proguard files in the codebase and evaluate each keep rule in the following specific order: a. Libraries check : Check rules against references/REDUNDANT-RULES.md. If the app has keep rules targeting libraries - Google, AndroidX, Kotlin, Kotlinx, Room, Gson, Retrofit, inform the user that these are not required and suggest removal of these rules. b. Impact analysis : For the remaining keep rules, assess them based on the impact hierarchy defined in references/KEEP-RULES-IMPACT-HIERARCHY.md. (Note: Do NOT assess the impact of keep rules already covered in the libraries check step).
  • [ ] Step 5: Identify subsuming keep rules in the remaining keep rules based on the hierarchy defined in references/KEEP-RULES-IMPACT-HIERARCHY.md and suggest removing the broader keep rules.
  • [ ] Step 6: For each remaining keep rule, analyze in detail the code affected by the rule by examining the code and adjacent files to understand why it was written. Look for reflection usage in those packages, and suggest a narrow and specific keep rule for the scenario using references/REFLECTION-GUIDE.md.
  • [ ] Step 7: For every keep rule inform concisely and to the point what action needs to be taken - whether the rule needs to be removed/refined.
    • If refining the rule, give instructions on finding a narrower and specific keep rule using the /references/REFLECTION-GUIDE.md.
    • If removing, provide reasoning on why it needs to be removed.
  • [ ] Step 8: After keep analysis, order the keep rule analysis based on the impact to the codebase hierarchy defined in references/KEEP-RULES-IMPACT-HIERARCHY.md
  • [ ] Step 9: Advise the user to run tests using UI automator to assess that there is no issue with the suggested changes, concentrating on the packages where keep rules will be affected.
  • [ ] 步骤1：创建名为R8_Configuration_Analysis.md的文件（若已存在则复用），用于存储输出结果
  • [ ] 步骤2：以references/CONFIGURATION.md为参考，查看代码库中的build.gradle、build.gradle.kts、gradle.properties文件，分析R8的配置情况。告知开发者并将分析内容添加至报告文件
  • [ ] 步骤3：若AGP版本低于9，建议升级至AGP 9.0版本，因为AGP 9.0包含多项优化。
    • [ ] 步骤4：查看代码库中的Proguard文件，按以下特定顺序评估每条keep规则：a. 库检查：对照references/REDUNDANT-RULES.md检查规则。如果应用中存在针对Google、AndroidX、Kotlin、Kotlinx、Room、Gson、Retrofit等库的keep规则，告知用户这些规则并非必需，建议移除。b. 影响分析：针对剩余的keep规则，依据references/KEEP-RULES-IMPACT-HIERARCHY.md中定义的影响层级进行评估。（注意：无需评估库检查步骤中已覆盖的keep规则的影响）
  • [ ] 步骤5：依据references/KEEP-RULES-IMPACT-HIERARCHY.md中定义的层级，识别剩余keep规则中的覆盖性规则，建议移除更宽泛的keep规则。
  • [ ] 步骤6：针对每条剩余的keep规则，通过检查受影响的代码及相邻文件，深入分析规则涉及的代码，理解规则编写的原因。查找这些包中的反射用法，并参考references/REFLECTION-GUIDE.md，针对该场景建议更精准的窄范围keep规则。
  • [ ] 步骤7：针对每条keep规则，简洁明确地告知需要采取的操作——是移除规则还是优化规则。
    • 若优化规则，提供参考references/REFLECTION-GUIDE.md来制定更精准窄范围规则的指导说明。
    • 若移除规则，说明需要移除的原因。
  • [ ] 步骤8：完成keep规则分析后，依据references/KEEP-RULES-IMPACT-HIERARCHY.md中定义的代码库层级影响对分析结果排序。
  • [ ] 步骤9：建议用户使用UI automator运行测试，评估建议的修改是否存在问题，重点关注keep规则将受到影响的包。

Mandatory rules

强制规则

  • Don't make any changes in keep rule files
  • Don't say about what level each keep rule is.
  • Don't generate parts of the report if there is no keep rule to report in that section.
  • Don't mention the generated files.
  • Don't mention exceptions that occur during execution.
  • Don't mention the benefits of R8
  • Don't mention any files of this skill
  • 请勿修改keep规则文件
  • 请勿提及每条keep规则的层级
  • 若某部分没有可报告的keep规则，请勿生成该部分的报告内容
  • 请勿提及生成的文件
  • 请勿提及执行过程中出现的异常
  • 请勿提及R8的优势
  • 请勿提及本技能的任何文件