较长的构建时间将会减缓项目的开发进度，特别是对于大型的项目，app的构建时间长则十几分钟，短则几分钟，长的构建时间已经成了开发瓶颈，本篇文章根据Google官方文档，加上自己的一些理解提供一些提升app构建速度的优化建议。
1. 为开发环境创建一个变体
有许多配置是你在准备app的release 版本的时候需要，但是当你开发app的时候是不需要的，开启不必要的构建进程会使你的增量构建或者clean构建变得很慢，因此需要构建一个只保留开发时需要配置的变体，如下例子创建了一个dev和prod变体（prod 为release 版本的配置）。
android {
...
defaultConfig {...}
buildTypes {...}
productFlavors {
// When building a variant that uses this flavor, the following configurations
// override those in the defaultConfig block.
dev {
// To avoid using legacy multidex, set minSdkVersion to 21 or higher.
minSdkVersion 21
versionNameSuffix "-dev"
applicationIdSuffix '.dev'
}
prod {
// If you've configured the defaultConfig block for the release version of
// your app, you can leave this block empty and Gradle uses configurations in
// the defaultConfig block instead. You still need to create this flavor.
// Otherwise, all variants use the "dev" flavor configurations.
}
}
}
2 . 避免编译不必要的资源
避免编译和包含你没有测试的资源（比如添加的一个本地的语言和屏幕密度资源），你可以只在你的’dev’ flavor下指定一种语言和一个屏幕密度，如下：
android {
...
productFlavors {
dev {
...
// The following configuration limits the "dev" flavor to using
// English stringresources and xxhdpi screen-density resources.
resConfigs "en", "xxhdpi"
}
...
}
}
上面的配置将会**dev变体只使用 english string 资源和 xxhdpi 屏幕密度资源。
3 . 配置debug 构建的Crushlytics为不可用状态
在debug 构建状态下，如果你不需要运行崩溃上报，你可以将这个插件设置为不可用状态来提升你的构建速度，如下：
android {
...
buildTypes {
debug {
ext.enableCrashlytics = false
}
}
上面只是举个例子，Crushlytics 为崩溃上报分析工具，在开发的时候我们可能不需要，因此不需要打开，在我们实际开发中，像崩溃上报SDK，数据统计SDK等（如 友盟统计、GrowingIO、百度统计）在开发阶段都设置为不可用，来提升构建速度。
4 . 用静态的构建配置值来构建你的Debug版
一般地，在你的debug 构建时，为manifest文件或者资源文件配置使用静态/硬编码的值。如果你的manifest或者资源文件的值每次构建都需要动态更新，那么Instant Run 无法执行代码交换－它必须重新构建和安装新的APK。
例如，使用动态的version codes ,version names ,resources或者其他更改manifest文件的构建逻辑，每次你想执行一个修改都会构建全部APK，即使实际的修改可能仅仅只需要热交换。如果这些构建配置是需要动态配置的，那么将它们从你的release 构建变体中分离出来，并且在你的debug 构建中保留它们的静态值。像下面build.gradle 文件显示的这样：
int MILLIS_IN_MINUTE = 1000 * 60
int minutesSinceEpoch = System.currentTimeMillis() / MILLIS_IN_MINUTE
android {
...
defaultConfig {
// ** either of these two values dynamic in the defaultConfig will
// require a full APK build and reinstallation because the AndroidManifest.xml
// must be updated (which is not supported by Instant Run).
versionCode 1
versionName "1.0"
...
}
// The defaultConfig values above are fixed, so your incremental builds don't
// need to rebuild the manifest (and therefore the whole APK, slowing build times).
// But for release builds, it's okay. So the following script iterates through
// all the known variants, finds those that are "release" build types, and
// changes those properties to something dynamic.
applicationVariants.all { variant -
| 
注册
登录
