【无标题】个人记录Android—Gradle教程

到目前为止，Gradle基础以及Kotlin基础讲解完毕。因此，在本篇里，将会以Gradle的构建优化以及如何从Groovy迁移到KTS进行详解！

话不多说，直接开始！

1、Gradle构建优化

优化都是些配置，快速过一下就行了！重点在迁移KTS

1.1 并行编译开启

默认情况下Gradle处理多模块时，往往是挨个按顺序处理。在项目根目录下面的gradle.properties中设置开启并行编译，提升编译速度：

org.gradle.parallel=true
复制代码

1.2 开启编译守护进程（默认开启）

该进程在第一次启动后回一直存在，当你进行二次编译的时候，可以重用该进程

不需要每次启动gradle进程（JVM实例），减少了初始化相关的工作。
Daemon可以缓存项目结构，文件，task等，尽可能复用之前的编译成果，缩短编译过程
在gradle.properties设置：org.gradle.daemon=true 。（其实默认已经支持了）

1.3 加大可编译内存

Dex-in-process 允许多个DEX 进程运行在一个单独的VM 中,这使得增量构建和清理构建变得更快。需要设置至少1536MB 的堆大小内存。

在gradle.properties中设置：org.gradle.jvmargs=-Xmx4096m //这里也就是4G大小

1.4 ZipAlign优化

在应用程序上运行zipalign，使得在运行时Android与应用程序间的交互更加有效率。让应用程序和整个系统运行得更快。

在app下面的build.gradle文件中设置：

android {
...略
    buildTypes {
        release{
            zipAlignEnabled true //也可和1.6 一起 加在自定义产品风味里
        }
        debug{
            zipAlignEnabled true
        }
    }
  }
复制代码

1.5 配置dexOptions

配置 dexOptions 和开启 library pre-dexing（dex预处理）：Dex-in-process:Android Studio 2.1增加了一个新的特性：Dex In Process，可以极大的加快重新编译的速度，同样也能提高Instant Run的性能。配置相应的DEX构建特性可以提高构建速度。

android {
...略
    dexOptions {
        javaMaxHeapSize "2048m"
        jumboMode true//忽略方法数限制的检查

        //是否对依赖的库进行dex预处理来是你的增量构建更快速
        //因为这个特性可能会使你的clean构建变慢
        //因此在你的持续集成服务器上你可能想要关闭这个特性
        preDexLibraries true

        //设置最大的线程数量使用，当运行dex-in-process时，默认是4
        maxProcessCount 8
    }
  }
复制代码

dexOptions一些设置说明：

preDexLibraaies : 声明是否对依赖的库进行dex 预处理来使你的增量构建更快速，因为这个特性可能会使你的clean 构建变慢，因此在你的持续集成服务器上你可能想关闭这个特性
javaMaxHeapSize: 为DEX 编译器设置最大的堆大小，相对于设置这个属性，你应该增加 Gradle的堆大小（这个堆大小dex-in-process可用的时候对DEX 编译器有效）这个值的设置需要调整第3点优化的值。
maxProcessCount : 设置最大的线程数量使用当运行 dex-in-process时，默认值是4。
注意：这里的参数值没有一个规定的值，需要调整数值来测试一下哪个更适合，不然会得到一个负面的影响。

1.6 构建一个变体

有许多配置是你在准备app的release 版本的时候需要，但是当你开发app的时候是不需要的，开启不必要的构建进程会使你的增量构建或者clean构建变得很慢，因此需要构建一个只保留开发时需要配置的变体。通过productFlavors构建，dev代表debug版本，prod代表release版本

    flavorDimensions 'channel'
    productFlavors {
        //本地开发版本可以优化的内容
        dev {
            dimension 'channel'
            //避免编译不必要的资源
            resConfigs "en","xxhdpi"
            resValue 'string', 'bbb', 'nnnn'
			//1.4内容ZIP优化
			zipAlignEnabled true
            //禁止每次构建app都自动压缩图片
            aaptOptions{
                cruncherEnabled false
            }

            //本地开发环境可以停止友盟统计或者三方不需要的工具，这个是自定义的
            buildConfigField  "Boolean", "UM_FLAG", "false"
        }
        //正式版本
        prod {
            dimension 'channel'
            buildConfigField  "Boolean", "UM_FLAG", "true"
        }
    }
复制代码

1.7 用静态的版本依赖

当你在build.gradle文件中声明依赖的时候，你应该避免在版本号结束的地方使用+号，比如：com.android.tools.build:gradle:4.+ 因为Gradle的检查更新，用动态的版本号会导致未知的版本更新、使解决版本的差异变得困难和更慢的构建。你应该使用静态或者硬编码版本号来代替。

1.8 分多module管理

抽取代码中相对独立的功能模块，创建新的module来开发，通过这种方式模块化你的代码将允许构建系统仅仅只编译那些有改动的模块，并将其构建结果缓存下来以被后面的构建使用。同时也可以提高开发效率，发布到maven上多APP公用。（组件化、插件化）

好了，上面的都快速过一下就行了！接下来就是本篇重点了！

2、Gradle Kotlin DSL

2.1 Kotlin DSL优缺点：

Android Gradle插件4.0支持在Gradle构建配置中使用Kotlin脚本 (KTS)，用于替代 Groovy（过去在Gradle配置文件中使用的编程语言）
将来，KTS会比Groovy更适合用于编写Gradle脚本，因为采用Kotlin编写的代码可读性更高，并且Kotlin提供了更好的编译时检查和IDE支持
虽然与Groovy相比，KTS当前能更好地在Android Studio的代码编辑器中集成，但采用KTS 的构建速度往往比采用Groovy慢，因此在迁移到 KTS 时应考虑构建性能。

2.2 何为KTS?

KTS：是指Kotlin脚本，这是Gradle在构建配置文件中使用的一种Kotlin语言形式。Kotlin脚本是可从命令行运行的Kotlin代码。
Kotlin DSL：主要是指Android Gradle插件Kotlin DSL，有时也指底层Gradle Kotlin DSL
用Kotlin编写的Gradle build文件使用.gradle.kts文件扩展名。
https://zhuanlan.zhihu.com/p/433151111
https://zhuanlan.zhihu.com/p/433152925
https://zhuanlan.zhihu.com/p/433151811
https://zhuanlan.zhihu.com/p/433202577
https://zhuanlan.zhihu.com/p/433202175
https://zhuanlan.zhihu.com/p/433201561
https://zhuanlan.zhihu.com/p/433201050

好了，概念说了一大堆，现在该上手了！

2.2 开始迁移：

迁移时建议单个文件进行，由简入深依次迁移

2.2.1 迁移 settings.gradle

原settings.gradle

include ':coroutines'
include ':app'
rootProject.name = "kotlinAndroidstudy"
复制代码

先复制settings.gradle，然后删除，接着创建settings.gradle.kts

新settings.gradle.kts 注意这里后缀名

include (":coroutines",":app")
rootProject.name = "kotlinAndroidstudy"
复制代码

我们看到这里include可以连续传多个参数，能够猜想到肯定有vararg 关键字，进入对应源码看看：

abstract class SettingsDelegate : Settings {
...略
    override fun include(vararg projectPaths: String?) =
        delegate.include(*projectPaths)
}
复制代码

看了源码果然如此。迁移到Kotlin DSL后，可以随意看里面的源码，比之前的groovy轻松多了！

接着下一个！