Android MultiDex 构建优化

解决了65535/64K的问题了，但是问题就是这样给解决了，但是上篇已经说了，会给性能造成损耗，那就是说有负副作用。

究竟有什么副作用？

1，应用第一次启动的时候，Dalvik虚拟机会对所有的.dex文件执行dexopt操作，生成ODEX文件，这个过程很复杂而且耗时，如果应用classes.dex很多，太大，可能会导致ANR。

2，如果API14之前那就是说Android 4.0之前的系统上，由于Dalvik 线性内存分配器限制，linearAlloc自身的bug ，使用multiDex会导致启动失败。建议将minSdk Version设置为14,问题就决解。

3，由于线性内存分配器限制，使用Multidex的应用在出现很大的内存分配时可能会OOM。因为Android2.3版本以下是(5M),Android2.3是8M，Android4.0分配16M，如果classes.dex太庞大就会挂，Android5.0使用ART虚拟机就不会存在linearAlloc的问题。

4，如果引入MultiDex机制时，必然就会有主classes.dex和次classes.dex之分，应用所需要的类都必须放到，主dex中，否则会出现NoClassDefFoundError中。

所以，引入MultiDex机制时，必定会使APP构建速度下降很多，浪费很多青春，所以。。

如何优化

1，在工程的主模块，.gradle文件中使用productFlavors来创建两个flavor:一个时开发使用的，一个时真正打包的时候用。

那就时说在开发阶段，我们使用ART虚拟机设置minSdkVersion=21,在真是打包上线版本使用真正的minSdkversion，这样可以大大提高构建速度。

2，上述配置完成后，可以使用devDebug variant来构建我们的应用，它会结合dev的productFlavor和debug的buildType的配置，也就是最终生成的APK不会使用ProGuard,只能是Multidex。minSdkVersion21,AndroidGradle插件做了如下工作：

a 将Android studio工程中每个module包括它的以来构建生成一个独立的.dex文件，也就做pre-dexing。

b 将所有.dex文件都包含进APK中，不做任何修改。

c 最重要的一点是每个module对用的.dex文件不会被合并，因此避免了决定那些类要放到主.dex中耗时计算。

结论

那就是说这样配置，在开发阶段，只有发生改动的module的.dex文件会重新计算生成并且打包到APK中，其他module会维持不变。从而实现快速构建，这种情况，只能在Android5.0设备上进行测试。

如何使用Build Variant

如下图：

好了，大概差不多，介绍完了，有什么需要改进的，错误的欢迎评论。