Android Studio编译慢、卡死和狂占内存

作者:知乎用户
链接:https://www.zhihu.com/question/27953288/answer/118031242
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
点击打开链接

至于加快编译速度,有一句说一句,我觉着一些答主的答案适用性都并不强,其实还是应该从 gradle 入手,讲的有什么不合适的地方,还请轻喷,有什么问题也可以留言。

以下我讲到的所有步骤,推荐都在终端里执行。在终端里执行编译有很多好处:
  1. 可以观察到整个编译过程,有助于理解 gradle 构建流程;
  2. 可以看到编译过程中哪些任务比较耗时,可以对编译慢的问题对症下药;
  3. 可以随时终止编译,如果被卡在某个阶段,ctrl + c 可以随时终止编译,在 Android Studio 里也终止编译,但是基本上十次有九次都会失败;
  4. 因为是在终端里,对 Android Studio 影响极小,基本不会造成 Android Studio 卡顿;
  5. 不会遇到 Android Studio 的各种 bug 。

先说一下 gradle 的生命周期吧,gradle 构建一个工程主要分为三部分(完全掌握了下面这张图,整个 gradle 的构建过程能了解个十之七八了):
<img src="https://pic2.zhimg.com/50/f084c5f0953eb2792d929dd6738822b5_hd.png" data-rawwidth="1468" data-rawheight="786" class="origin_image zh-lightbox-thumb" width="1468" data-original="https://pic2.zhimg.com/f084c5f0953eb2792d929dd6738822b5_r.png">
  1. 初始化阶段:主要是解析 setting.gradle 文件(因此有人提到减少 setting.gradle 的 module 数量,是很有道理的,但是实际操作过程限制颇多,原因最后会大致说一下);
  2. 读取配置阶段:主要是解析所有的 projects 下的 build.gradle 文件,包括 rootProject 和其他的 subprojects(子项目),检查语法,确定 tasks 依赖以建立 task 的有向无循环图,检查 task 里引用的文件目录是否存在等(这一步也进一步验证了减少 setting.gradle 里的 module 数量可以加快编译速度,因为减少一个 module ,需要解析的 build.gradle 文件就减少一个,第 3 步里就不会执行本属于这个 module 的任务了,但是还是 1 里面说的问题,限制颇多);
  3. 执行阶段:按照 2 中建立的有向无循环图来执行每一个 task ,整个编译过程中,这一步基本会占去 9 成以上的时间,尤其是对于 Android 项目来讲,将 java 转为 class
    compileDebugJavaWithJavac/compileReleaseJavaWithJavac
    
    和 将 class 合并成 dex
    transformClassesWithDexForDebug/transformClassesWithDexForRelease
    
    这两步很耗时,第一步还好,第二步会耗时非常久。首先在 gradle.properties 里设置
    org.gradle.jvmargs=-Xmx4096m //越大越好
    
    ,然后在工程的 build.gradle 里的 android 结点下增加 dexOptions 配置,如下:
dexOptions {
    dexInProcess true
    preDexLibraries true
    javaMaxHeapSize "4g"//越大越好
    incremental true
}

明确了 gradle 的生命周期,那么就可以看到加快编译速度的关键就是从第三步入手,当然,减少 setting.gradle 里的 modules 数量这一步也是必须的。下面说说我们公司的实践吧。
  1. 项目插件化改造,每位业务上的同学只需要编译一个模块即可,这一点基本上从根本上解决了编译慢的问题(对于大多数没有插件化需求的朋友们可以看下面的一些实践),首先 setting.gradle 里的 module 只有自己开发的模块了,而对应的执行阶段的任务也只有这一个 module 的任务了。
  2. 执行一次 gradle build ,我们就会发现,在这个过程中,其实是执行了多次打包任务的,在 buildTypes 里配置了多个编译打包类型,默认有 debug 和 release ,我们还可以手动配置其他的类型,而且还有 productFlavor 里的多渠道,这样就会执行多次编译打包,而正常开发过程中,只需要打 debug 包去调试,因此使用 gradle assembleDebug 即可,等发版的时候使用其他方式去打多渠道的包(如美团的方案tech.meituan.com/mt-apk);
  3. 既然编译主要时间都集中在 gradle 生命周期的第三步执行 task 任务里,那么我们就可以把一些无关紧要的任务给禁用掉,比如各种 Test ,各种 lint 等,刚好在 gradle 里有这样的指令 -x lint 可以临时禁掉 lint 任务,-x test 可以禁掉 test 任务,事实上对于一个稍微大一点的项目,lint 也是很耗时的,当然也可以通过 gradle 脚本彻底禁用 lint 和 test 任务,我也在一些微信群里分享过相关代码,但是不太建议这么做,因为有时候 lint 和 test 也是挺有用的;
  4. gradle 本身提供了一些指令参数可以加快编译,比如 --daemon ,开启守护进程,--parallel ,开启并行编译等,这个也可以在 gradle.propertites 里配置(编译使用的 jvm 内存也可以在这里配置)。
  5. 定制 gradle 编译流程,利用官方提供的 API 完全可以定制一个适合自己的编译流程,可以参考一下携程的 DynamicAPK/sub-project-build.gradle at master · CtripMobile/DynamicAPK · GitHub,里面有携程他们自己整个完整的编译流程,脚本本身很简单,一共只有两三百行代码。
上面讲到的几点,现有环境就可以做到的大概是这样(有一点要特别注意,如果工程里有交叉依赖,一定不要使用 --parallel 参数):
gradle assembleDebug --daemon --parallel -x lint -x test

,如果是要直接安装到设备上的话,就把 assembleDebug 换成 installDebug ,assembleDebug 可以简写为 asD ,installDebug 可以简写为 iD 。

最后讲一下,为什么减少 setting.gradle 里的 module 数量,确实可以加快编译,但是却限制颇多呢?
首先,我们想一下整个编译过程,先去解析 gradle 配置,建立 tasks 依赖有向图,然后再去执行每一个 module 的 task ,如果我们通过 maven 依赖,使用 aar 替掉了 module(单指 android library),如果我们要改这个 module 里的文件,岂不是每次都要修改上传再下载,这其实还好,但是有一个致命的问题:不修改版本号的话,SNAPSHOT 在 IDEA 里经常会不好使这样就导致修改的东西会不生效,去解决这个问题是非常耗费时间的。不过有一种方式,可以一定程度上解决问题,增加下面的脚本:
project.configurations.all(new Action<Configuration>() {
@Override
    void execute(Configuration files) {
        files.resolutionStrategy.cacheDynamicVersionsFor(5, TimeUnit.MINUTES)
        files.resolutionStrategy.cacheChangingModulesFor(0, TimeUnit.SECONDS)
    }
})
那有人会问,插件化里,每个人开发一个模块,对于每个模块的维护不也是要打包上传到 maven ,每次一有修改,哪怕是非常微小的修改,也要做一次上传,同样会遇到 SNAPSHOT 不好使的问题。嘿嘿,这个问题嘛,我司自己维护了一个 gradle 插件,已经解决了,至于解决方案,是公司机密,我是不会讲的。
然后,还有一点,我相信大部分开发者平常开发都是单 module 的,多 module 的情况并不多,因此大多数依赖基本也都是 aar 或者 jar ,根本就不存在所谓的将 library 转成 aar 上传的情况,因此一些答主说的根本毫无意义,这也是为什么我会说影响编译速度的情况主要集中在 gradle 生命周期的第三个阶段,至于第三个阶段的优化,看我上面的答案就好了。
展开阅读全文

没有更多推荐了,返回首页