Android 构建速度优化

这是我参与更文挑战的第27天，活动详情查看：更文挑战

模块build.gradle

禁用多APK构建

禁用Multiple APK构建

默认情况下，Android Studio 将会生成一个包含所有屏幕密度的通用 APK。multi-apk 是为了根据配置生成不同的APK，以达到减少APK体积大小的问题。但是这个配置没有必要在开发的时候开启。

在此技能中，你能专门排除或包含你想要在app/build.gradle支持的屏幕密度，Android Studio 将会为你生成多个 APK。

android {
  splits {
    density {
      enable true
      // Specify a list of screen densities which Gradle won't create multiple APKs for
      exclude 'ldpi', 'mdpi'
      // Specify a list of compatible screen size for the manifest
      compatibleScreens 'small', 'normal', 'large', 'xlarge'
    }
  }
}
复制代码

为ABI构建多个APK

这个技巧和前一个技巧相似，但是此技巧是用于支持Application Binary Interfaces(ABIs)。目前 Android 市场中有7个 CPU 框架，其中3个很难找到（mips，mips64，armeabi），以此你可以在app/build.gradle指定你想要支持的 ABI，Android Studio 将会为你生成多个 APK。

android {
  splits {
    abi {
      enable true
      reset()
      // Specify a list of ABIs that Gradle should create APKs for
      include 'x86', 'x86_64', 'arm64-v8a', 'armeabi-v7a'
      // If you don’t want to generate a universal APK that includes all ABIs.
      universalApk false
    }
  }
}
复制代码

以上2个我们如果用到，在开发阶段可以关闭以增加构建速度

buildTypes {
  ...
  debug {
    splits.abi.enable = false
    splits.density.enable = false
  }
}
复制代码

避免Legacy Multidex

这个小技巧大家应该比较熟悉——避免激活旧版的 MultiDex。当您的应用配置方法数超过 64K 的时候，您需要启用 multidex。当您启用了 multidex，且工程的最低 API 级别在 21 之前时，旧版的 multidex 就会被激活，这将严重拖慢您的构建速度，原因是 21 之前的 API 级别并没有原生的支持 multidex。
如果您是通过 Android Studio 的运行/调试按钮来执行构建，那么无需考虑这个问题，新版本的 Android Studio 会自动检测连接的设备和模拟器，如果系统的 API 级别大于 21 则进行原生的 multidex 支持，同时会忽略工程里对最低 API 级别 (minSdkVersion) 的设置。
在api21以上，因为Android采用了新的运行时ART，会在安装的时候将所有的classesN.dex合并成一个.oat包。你需要做的就是在编译脚本中加一行 multiDexEnabled true。但是在api21以下，你需要引入multidex support library(因为21 之前的 API 级别并没有原生的支持 MultiDex). 而且在编译过程中，编译脚本要话很长时间决定哪些class要放入primary dex中，哪些放入secondary dex中。在api21以下，这叫做legacy multidex,这一步会严重拖慢构建速度。
　　开发中，如果你不需要兼容低版本的设备的话，可以把minSdkVersion改为21以上（Android 5.0），使用ART，在Build时只做class to dex，而不做mergeing dex，这样就可以避免legacy multidex带来的编译性能消耗，同样会节省一点的时间。
习惯通过命令行窗口构建工程的开发者们则需要试着避免这个问题: 配置一个新的 productFlavor，设定工程的最低 API 级别为 21 或者以上，在命令行里调用 assembleDevelopmentDebug 即可避免这个问题。
eg：Development

flavorDimensions "default"
    productFlavors {
        development {
            dimension "default"
            minSdkVersion 21

        }
    }
复制代码

最小化使用资源文件

flavorDimensions "default"
    productFlavors {
        development {
            dimension "default"
            resConfigs("zh-rCN","xxhdpi")
        }
    }
复制代码

禁用 PNG 压缩

有效减少图片文件大小，不必执行构建时压缩，从而加快构建速度，如果你的APP用到大量图片资源的话，效果明显。可以通过将图片转换为WebP,如果不想转换，可以在开发的时候禁止png cruncher

aapt会对你的png做处理，让他们的size变得更小，这一步叫做png-cruncher，减小apk的体积。但是在开发模式下，这些并不重要，因此在开发模式下我们可以禁止png cruncher

    buildTypes {
        debug {
            crunchPngs false //default
        }
    }

复制代码

按需编译

直接**gradlew build和执行gradlew assemble** 会同时编译生成Debug和Release的包，在调试阶段其实我们可以使用：

gradlew assembleDebug
复制代码

来只编译Debug版本的包，除此之外还可以用另一个命令编译完直接安装到设备上：

gradlew installDebug
复制代码

开启多线程支持和增量编译

在gradle.properties文件中增加如下所示代码: 表示开启Gradle的多线程和多核心支持.

#开启守护线程    
org.gradle.daemon=true    
#开启并行编译任务    
org.gradle.parallel=true    
#启用新的孵化模式    
org.gradle.configureondemand=true
复制代码

在app/build.gradle **android{}**闭包中添加如下代码:表示开启Gradle的增量编译,增加编译的内存资源到4g

dexOptions{
        javaMaxHeapSize "4g"
}
复制代码

使用 Apply Changes

从 Android Studio 3.5 版开始，开发者们可以使用 Apply Changes 功能来提高构建性能，它可以让代码和资源的改动直接生效而无需重启应用，有时候甚至无需重启当前的 Activity。与 Instant Run 的实现方式不一样，Apply Changes 充分利用了 Android 8.0 以上版本操作系统的特性进行运行时检测，从而动态的对类进行重新定义。因此，如果您希望使用 Apply Changes，则需要让您的工程运行在 Android 8.0 (API级别26) 以上的真机或者模拟器上。

一些其他的小点

减少本地库依赖

Gadle在编译时会执行大量Task，生成很多中间文件，会导致磁盘IO拥堵，造成编译变慢，可以减少本地库依赖，多使用aar进行依赖。组件化之后可以实行

组件化

对于大型的项目，可能上面这些优化建议有一定的效果，但是构建速度还是有些慢，那么就可以考虑组建化了，将项目拆分成一个个单独的组件，开发环境每个module 都是一个APK，发布的时候，每个module都是一个lib 给主工程使用。篇幅有效，这里就不再详细介绍组件化，现在组件化是一个趋势，如果有精力或者有实力，组件化是一个很不错的选择。