Android分包(MultiDex)后编译加速方案

96
彼时芒种
0.1 2016.04.28 20:08* 字数 578

书接上一回记Android分包(MultiDex)后单元测试错误的debug过程
应用了分包(MultiDex)之后Android Studio的编译时间达到了历史新高,随便更改一处代码,重新编译运行都需要1min~2min,严重的时候甚至达到3min。

这简直就是在浪费程序员的生命啊!

在笔者写下这篇文章的时候google已经推出了Android Studio 2.1.0 及gradle 2.1.0 稳定版。理论上InstantRun会让编译时间不再是问题,但可悲的是对于采用了multidex的项目InstantRun只在该项目的minSDK>21时才可用,也就是说:

InstantRun不支持能在Android 5.0以下的multidex项目!

在此建议Android初级程序员在选择第三方库的时候要多考虑库的大小,从根本上避免项目不大却也需要分包情况。既然回头太难,这问题还是要想办法解决的,以下是我们使用inloop方法数统计分析的结果:

APK方法数分析

其中可精简的大项就已经占了11k左右,如果能够有效精简这部分相信就不用分包,这就没有分包后编译慢的烦恼了,不过精简的问题还是下次聊,今天我们先来解决目前的问题。

如何解决呢?我今天就来跟各位做个翻译官。
stackoverflow-答案原文链接
解决原理其实很简单:

测试时:设置minSdk>=21以开启InstantRun提高编译速度
发布时:恢复minSdk为正常值

其实这些手动也能做到,只是在build.gradle里来回手动切换很麻烦,也很Low,程序员专业的领域怎能这么Low呢?
好了,AndroidStudio自带的功能Build Variants出场:


AndroidStudio左下角的Build Variants

是不是每天都见却从来没有用到过?
以下是解决方案:

1.在build.gradle里加入:

//测试和发布时分别设置不同的minSdk
android {
   ...
   productFlavors {
       dev { 
             minSdkVersion  21
       }
       prod {
             minSdkVersion  14
       }
   }
   //非必要部分,大内存机器可加入
   dexOptions { 
      javaMaxHeapSize "4g"
   }
   ...
}

2.选择测试及发布各自的编译方式

测试时选择编译方式(选择一次即可):

测试编译方式

发布时选择编译方式:

发布编译方式

3.最后记得开启InstantRun

(觉得InstantRun不稳定不想开启也没关系,只要用SDK>=21的模拟器编译也会快不少):


开启InstantRun

对比该方案编译效果:
应用前:每次耗时平均1min 45s
应用后:首次耗时平均2min, 后续耗时平均15s

备注:本文基于AndroidStudio 2.1.0 及cradle 2.1.0

Android
Web note ad 1