Android 编译速度优化方案

Android 编译速度优化方案 一、背景描述

在项目体量越来越大的情况下，编译速度也随之增长，目前在以下配置的机器全部编译一次少则5分钟，多则10多分钟，严重影响开发效率

有时候一个小的改动也需要等待长达好几分钟的编译时间，基于这种情况下，查找能够提高编译效率的方案成为必须要做的待办事项。

经过几天的调研，发现了以下方案可以提高项目的编译效率：

目前开源编译方案RocketX，通过在编译流程替换module为aar方式，提高 全量编译的速度在编译时，选择不编译部分moudle来节省编译时间 二、效果展示 目标项目一共50万+行java代码和资源文件，全量编译取中间值7分钟通过以上方案，全量变量去平局值在3分钟，减少大约在4分钟的时间，提升构建效率50% 三、思路 一、在编译时，选择不编译部分moudle来节省编译时间

目前项目中使用了阿里的ARount来做组件化子模块之间间的通信方案，那么module与module之间就解耦开，不必各个模块之间相互引用，在编译的时候，如果不引入该模块是可以通过编译，并且正常运行起来，只是在设计到该模块的功能时，无法使用，所以在开发的时候，要确定目前不引入的模块跟正在开发的模块之间不存在调用问题，便可以正常的开发，调试，运行

这种方式会存在线上版本忘记修改为全模块编译的风险，因此目前的解决方案是在编译的gradle文件中去判断当前的Build 模式中是否包含Release，如果是则表明目前是在打正式包，那么直接抛出编译错误的提示，开发人员看到该提示时，就会知道忘记把快速编译开关关闭，通过这种方式来解决。

（项目所使用到的moudle）

（如果开启快速编译模式，部分moudle不会编译）

（编译正式包时，如果没有关闭快速编译模式，则会提示编译失败）

二、RocketX 编译方案 开源地址 https://github.com/trycatchx/RocketX该编译方案目前gradlew版本只兼容以下几个，在接入时需要注意

一、接入方式 在app的主 buil.gradle 中添加

apply plugin: 'com.rocketx'

在根目录的build.gradle加入

buildscript {
    dependencies {
        classpath 'io.github.trycatchx:rocketx:1.1.0'
    }
}

依赖 AS 插件 android studio setting->plugins-> marketplace 搜索 RocketX 安装（搜索不到使用本地安装

使用点击小火箭至喷火icon （开启 状态）,点击编译器 run 按钮 :
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bv55uFDm-1649596820073)(http://www.kaotop.com/file/tupian/20220518/assembleDebug.jpeg?raw=true)]

二、可选配置 openLog ：打开 logexcludeModule :哪一些模块不需要打成 aar（譬如有些模块使用了 tool:replace=“XX” ,打成 aar 后属性会消失，当然也可以移动到 app module 的 AndroidMenifest.xml）

  //app moodule下 配置插件编译项
  android {
  //..
    RocketX {
        openLog = true
        //指定哪些模块不打成 aar ，字符串为 module.path
        excludeModule = [":module_common"]
    }
   //..
   }

excludeTransForms： 编译阶段可以禁用的 transform ，编译速度更快（可通过build 的 log 搜索关键字 transFormList 查看自己项目引用了哪些 transform，并手动配置在 gradle.properties 文件下）
excludeTransForms = com.alibaba.arouter AAA bbb 三、注意项 第一次的加速，是最慢的因为需要全量编译后，打出 aar 上传到 LocalMaven目前如果编译出错，请重新再 run 一次编译后的module打成的aar文件放置在项目根路径下.gradle/文件夹下如果能够在.gradle/文件夹下找到对应的moudle生成的aar文件，并且rocketX是开启的情况下，那么就说明RocketX方案是生效的 四、结语

随着Android项目架构的演进，将会出现越来越多的提高编译效率的方案，没有那种方式是最好的，只有根据目前项目遇到的问题来选择合适的方案才是最有的，也希望自己和Android开发人员能够提供更多，更好的编译方案，促进Android编译生态的发展。