从Groovy到KTS：Android Gradle脚本的华丽转身从Groovy到KTS：Android Gradle脚

从Groovy到KTS：Android Gradle脚本的华丽转身

Gradle 构建脚本：Groovy 与 KTS 的前世今生

在 Android 开发的庞大体系中，Gradle 就像是一个幕后英雄，掌控着项目构建的方方面面，从编译代码、管理依赖到生成最终的 APK，它都扮演着不可或缺的角色。而 Gradle 构建脚本，作为与 Gradle 沟通的桥梁，决定了整个构建过程的走向。

早期，Gradle 构建脚本主要采用 Groovy 语言编写。Groovy 作为一种基于 JVM 的动态语言，与 Java 有着天然的亲近感，它允许开发者在构建脚本中使用类似于 Java 的语法，同时又具备动态语言的灵活性，比如方法的动态调用、简洁的闭包语法等。在很长一段时间里，Groovy 脚本是 Android 开发者配置项目的主要方式，从设置编译版本、依赖库，到自定义构建任务，Groovy 脚本都能很好地完成任务。

然而，随着 Kotlin 在 Android 开发中的兴起，Kotlin 脚本（KTS）逐渐走入人们的视野。Kotlin 是一种由 JetBrains 开发的编程语言，它同样运行在 JVM 上，并且与 Java 有着高度的互操作性。Kotlin 以其简洁、安全、高效的特性，迅速赢得了开发者的喜爱。为了让开发者在 Gradle 构建脚本中也能享受到 Kotlin 的优势，Gradle 开始支持 KTS。从此，Gradle 构建脚本有了 Groovy 和 KTS 两种主要的编写方式，这也引发了开发者对于两者差异的探讨。

Groovy 与 KTS 核心区别大揭秘

语法风格：自由与严谨的碰撞

Groovy 的语法风格极为灵活，就像是一位随性的艺术家，允许开发者省略很多符号。在定义变量时，不需要显式声明类型，编译器会在运行时推断类型。在方法调用中，如果只有一个参数，括号也可以省略。比如在依赖配置中，使用 Groovy 编写可以这样：


dependencies {
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'
}

这里不仅省略了括号，连版本号也直接跟在依赖库名后面，简洁明了，对于熟悉这种风格的开发者来说，编写速度很快。

而 KTS 遵循 Kotlin 的语法规范，就像一位严谨的学者，每一个细节都有严格的要求。变量必须明确声明类型，方法调用必须加上括号。还是以刚才的依赖配置为例，用 KTS 来写就是：


dependencies {
    implementation("com.squareup.retrofit2:retrofit:2.9.0")
}

虽然看起来多了括号，但这种写法更加清晰，对于代码的可读性和维护性有很大帮助，尤其是在大型项目中，能够减少因语法模糊导致的错误。

类型安全保障：编译时与运行时的较量

Groovy 作为动态类型语言，在类型安全方面主要依赖运行时检查。这就好比在考试结束后才检查答案，虽然能发现错误，但往往为时已晚。在配置依赖时，如果写错了依赖库的名称或者版本号，只有在构建项目时才会报错，这可能会浪费大量的时间去排查问题。

KTS 则引入了 Kotlin 的静态类型系统，在编译时就能对代码进行严格的类型检查，如同在考试过程中就有老师随时提醒错误。还是上面依赖配置的例子，如果在 KTS 中写错了依赖库的名称或者版本号，IDE 会立即提示错误，让开发者在编写代码时就能及时修正，大大提高了代码的稳定性和可靠性。

IDE 支持差异：谁更懂开发者的心

Android Studio 作为 Android 开发的主流 IDE，对 Groovy 和 KTS 的支持程度有所不同。对于 Groovy，虽然也提供了基本的代码提示和自动补全功能，但在代码导航和重构方面相对较弱。当项目规模变大，代码结构变得复杂时，查找和修改 Groovy 脚本中的代码会比较困难。

而对于 KTS，Android Studio 提供了全方位的强大支持。代码提示更加智能，不仅能提示方法和属性，还能根据上下文提供合适的建议；自动补全功能也更加精准，能够快速补全代码；在重构方面，KTS 支持各种重构操作，如重命名、提取方法等，让代码的维护更加轻松；代码导航功能也非常强大，通过点击就能快速跳转到定义处，方便查看和修改代码，极大地提高了开发者的工作效率。

性能表现：构建速度的角逐

在构建速度方面，Groovy 由于长期的优化，早期在这方面具有一定的优势。它在大型项目中的构建速度相对较快，能够满足项目的快速迭代需求。

然而，随着 KTS 的不断发展和优化，它在性能上的表现也逐渐提升。尤其是在增量构建方面，KTS 通过对构建过程的优化，能够更准确地识别出哪些文件发生了变化，从而只对这些文件进行重新构建，大大缩短了构建时间。虽然在首次构建时，KTS 可能还稍逊一筹，但随着项目的不断构建和缓存的利用，KTS 与 Groovy 的性能差距正在逐渐缩小。

实战：项目中的 Groovy 与 KTS 写法对比

插件声明与配置

在 Groovy 中，声明插件时，使用单引号包裹插件 ID，并且可以在同一 plugins 块中声明多个插件，每个插件之间用空格分隔。例如，声明一个 Android 应用插件和 Kotlin 插件：


plugins {
    id 'com.android.application' version '8.2.0'
    id 'org.jetbrains.kotlin.android' version '1.9.20'
}

而在 KTS 中，声明插件时，需要使用双引号包裹插件 ID，并且每个插件的声明需要使用括号括起来，同时版本号的声明方式也有所不同。同样是声明 Android 应用插件和 Kotlin 插件，KTS 的写法如下：


plugins {
    id("com.android.application") version "8.2.0"
    kotlin("android") version "1.9.20"
}

这种差异虽然看似细微，但在实际编写和阅读代码时，KTS 的写法更加清晰明了，符合 Kotlin 严谨的语法风格。

Android 项目核心配置

在 Android 项目的核心配置部分，Groovy 和 KTS 也有明显的区别。在 Groovy 中，设置 compileSdk、minSdk、targetSdk 等属性时，使用的是方法调用的方式，属性名和值之间没有等号。例如：


android {
    namespace 'com.example.app'
    compileSdk 34
    defaultConfig {
        applicationId "com.example.app"
        minSdk 24
        targetSdk 34
        versionCode 1
        versionName "1.0"
    }
}

而在 KTS 中，这些属性的设置采用了赋值语句的方式，属性名和值之间用等号连接，并且属性名也有所简化。例如：


android {
    namespace = "com.example.app"
    compileSdk = 34
    defaultConfig {
        applicationId = "com.example.app"
        minSdk = 24
        targetSdk = 34
        versionCode = 1
        versionName = "1.0"
    }
}

这种写法使得 KTS 的代码更具可读性，并且在编译时能够更好地进行类型检查，减少错误的发生。

依赖管理策略

在依赖管理方面，Groovy 通常采用传统的字符串声明方式。例如，添加一个 Retrofit 依赖：


dependencies {
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'
}

这种方式虽然简单直接，但存在一些问题，比如容易出现拼写错误，并且在管理大量依赖时，维护起来比较困难。

而 KTS 引入了 Version Catalog 的概念，结合类型安全访问器，使得依赖管理更加安全和智能。首先，在gradle/libs.versions.toml文件中定义依赖的版本信息：


[versions]
retrofit = "2.9.0"

[libraries]
retrofit-core = { group = "com.squareup.retrofit2", name = "retrofit", version.ref = "retrofit" }

然后，在build.gradle.kts中使用这些依赖：


dependencies {
    implementation(libs.retrofit.core)
}

这样，不仅在编写依赖时能够获得 IDE 的智能提示，而且在修改依赖版本时，只需要在libs.versions.toml文件中统一修改，大大提高了依赖管理的效率和安全性。

构建类型与产品风味配置

在配置构建类型（如 release、debug）和产品风味时，Groovy 和 KTS 的写法也有所不同。在 Groovy 中，配置 release 构建类型时，直接在buildTypes块中定义：


buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
    }
}

这里的minifyEnabled属性没有is前缀，并且proguardFiles方法调用时，参数之间用逗号分隔。

在 KTS 中，配置 release 构建类型时，需要使用getByName方法获取构建类型，并且minifyEnabled属性有is前缀，proguardFiles方法调用时，参数需要用括号括起来：


buildTypes {
    getByName("release") {
        isMinifyEnabled = false
        proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
    }
}

在配置产品风味时，Groovy 和 KTS 也有类似的语法差异。例如，在 Groovy 中创建一个名为prod的产品风味：


productFlavors {
    prod {
        // 配置产品风味的属性
    }
}

在 KTS 中，需要显式调用create方法来创建产品风味：


productFlavors {
    create("prod") {
        // 配置产品风味的属性
    }
}

这些差异体现了 Groovy 和 KTS 在语法和编程风格上的不同，开发者在使用时需要根据具体情况进行选择和适应。

从 Groovy 迁移到 KTS 的实用指南

前期准备工作

在开始迁移之前，一定要先备份好项目代码，这是至关重要的一步，以防迁移过程中出现不可预见的问题导致代码丢失或损坏。同时，需要确认 Gradle 版本是否在 6.8 及以上，推荐使用 7.4 + 版本，因为更高的版本通常对 KTS 有更好的支持和优化。Android Studio 版本也要在 4.2 及以上，推荐使用 Arctic Fox + 版本，以确保能够顺利识别和编辑 KTS 文件，并且获得良好的代码提示和自动补全功能。

迁移步骤详解

迁移可以按照以下三个主要步骤进行。首先是重命名文件，将项目中的build.gradle文件重命名为build.gradle.kts，settings.gradle文件重命名为settings.gradle.kts。建议不要一次性迁移所有模块，可以从最简单的 library 模块开始，逐步推进，这样在遇到问题时更容易排查和解决。

然后是修改 plugins 块。在 Groovy 中，声明插件通常使用apply plugin的方式，例如：


apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'

而在 KTS 中，需要使用plugins代码块，并且插件 ID 要用双引号包裹，括号不能省略，例如：


plugins {
    id("com.android.application")
    id("kotlin-android")
}

需要注意的是，第三方插件必须在plugins块中声明版本，不再使用buildscript方式。

最后是调整语法差异。Groovy 字符串可以用单引号或双引号引用，而 Kotlin 必须用双引号；Groovy 调用方法可以省略括号，Kotlin 必须保留括号；Groovy 在分配属性时可以省略=赋值运算符，Kotlin 始终需要赋值运算符。例如，在依赖配置中，Groovy 的写法是：


dependencies {
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'
}

KTS 的写法是：


dependencies {
    implementation("com.squareup.retrofit2:retrofit:2.9.0")
}

常见问题与解决方案

在迁移过程中，可能会遇到一些常见问题。比如 ext 变量迁移问题，在 Groovy 中常用ext定义全局变量，如：


ext {
    compileSdkVersion = 33
}

在 KTS 中，可以使用extra属性，如：


val compileSdkVersion by extra(33)
// 或
extra.set("compileSdkVersion", 33)

更推荐的方式是使用buildSrc统一管理版本。

在productFlavors配置方面，Groovy 的写法是：


productFlavors {
    free {
        dimension "version"
        applicationIdSuffix ".free"
    }
}

KTS 的写法是：


productFlavors {
    create("free") {
        dimension = "version"
        applicationIdSuffix = ".free"
    }
}

这里要注意create方法和赋值操作符的变化。

还有buildTypes中的布尔属性设置问题，Groovy 的写法是：


buildTypes {
    release {
        minifyEnabled true
    }
}

KTS 的写法是：


buildTypes {
    getByName("release") {
        isMinifyEnabled = true
    }
}

Kotlin 会自动为布尔属性生成is前缀的 getter，所以在 KTS 中设置布尔属性时要记得加is前缀。