书接上一回记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