Gradle KTS — คืออะไร, Kotlin DSL สำหรับ Gradle และไวยากรณ์

Gradle KTS คืออะไร?

Gradle KTS คือ Kotlin DSL (Domain Specific Language) ที่เป็นทางเลือกแทน Groovy สำหรับเขียนไฟล์กำหนดค่า Gradle แทนที่ไวยากรณ์ Groovy นักพัฒนาจะใช้ Kotlin — ภาษาที่มีการตรวจสอบชนิดอย่างเข้มงวด ซึ่งตรวจสอบความถูกต้องของการกำหนดค่าในเวลาคอมไพล์ KTS ถูกนำมาใช้ครั้งแรกใน Gradle 5.0 เมื่อปี 2018 ในฐานะฟีเจอร์ทดลอง และถึงระดับเสถียรใน Gradle 6.0

เป้าหมายหลักของ KTS คือกำจัดข้อบกพร่องของ Groovy ในสคริปต์บิลด์ Groovy เป็นภาษาที่มีการตรวจสอบชนิดแบบไดนามิก ซึ่งข้อผิดพลาดในการกำหนดค่าจะปรากฏเฉพาะในขณะรันไทม์เมื่อดำเนินงาน KTS ช่วยให้ตรวจพบข้อผิดพลาดเดียวกันได้ในขั้นตอนการแก้ไขโค้ดด้วย static typing ของ Kotlin นอกจากนี้ KTS ยังให้การเข้าถึง API ของ Gradle พร้อมเอกสารชนิดข้อมูลที่สมบูรณ์ ซึ่งช่วยให้การเรียนรู้และการใช้บล็อกการกำหนดค่าที่ซับซ้อนง่ายขึ้นอย่างมาก

ระบบนิเวศของ KTS รองรับโดยเครื่องมือหลักทั้งหมด: Android Studio, IntelliJ IDEA, VS Code ที่มีปลั๊กอิน Kotlin และ Gradle Build Tool ปลั๊กอินสมัยใหม่ทั้งหมด (Android Gradle Plugin, Kotlin Multiplatform, Protobuf, Compose) มี API ที่เป็นมิตรกับ Kotlin พร้อมชนิดข้อมูลที่ชัดเจน ทำให้ KTS เป็นตัวเลือกที่ต้องการสำหรับโปรเจกต์ใหม่

Gradle KTS ทำงานอย่างไร

Gradle KTS ใช้คอมไพเลอร์ Kotlin เพื่อประมวลผลไฟล์ .gradle.kts Gradler รู้จักนามสกุลไฟล์และส่งสคริปต์ไปยังเอนจินสคริปต์ของ Kotlin ซึ่งจะคอมไพล์เป็นคลาส จากนั้นคลาสเหล่านี้จะถูกดำเนินการโดย Gradle เพื่อสร้างโมเดลโปรเจกต์ ความแตกต่างหลักจาก Groovy: สคริปต์ KTS จะถูกคอมไพล์ล่วงหน้า ไม่ได้ถูกแปลความหมายแบบไดนามิก ซึ่งช่วยให้ตรวจพบข้อผิดพลาดก่อนที่การดำเนินงานจะเริ่มขึ้น

สถาปัตยกรรม KTS มีพื้นฐานบน kotlin-scripting ไฟล์ .gradle.kts แต่ละไฟล์คือสคริปต์ Kotlin ที่มีการนำเข้า API ของ Gradle โดยปริยาย นักพัฒนาสามารถใช้โครงสร้าง Kotlin ใดก็ได้: ฟังก์ชันส่วนขยาย แลมบ์ดา คลาสข้อมูล และแม้แต่ประกาศฟังก์ชันช่วยเหลือภายในสคริปต์บิลด์ Gradle มีชุดฟังก์ชันส่วนขยายสำหรับการกำหนดค่าแบบมีชนิดของบล็อก: dependencies, android, kotlin และอื่นๆ

plugins {
    id("com.android.application") version "8.4.0"
    kotlin("android") version "2.0.21"
}

android {
    namespace = "com.itsectr.app"
    compileSdk = 34

    defaultConfig {
        applicationId = "com.itsectr.app"
        minSdk = 26
        targetSdk = 34
        versionCode = 1
        versionName = "1.0.0"
    }
}

dependencies {
    implementation(platform("androidx.compose:compose-bom:2024.06.00"))
    implementation("androidx.compose.ui:ui")
    implementation("androidx.core:core-ktx:1.13.1")
}

การแปลงชนิดใน KTS

หนึ่งในความแตกต่างหลักระหว่าง KTS และ Groovy คือการจัดการชนิดข้อมูล ใน Groovy การกำหนดค่าทั้งหมดรับ Object ในขณะที่ KTS รับชนิด Kotlin ที่เฉพาะเจาะจง ตัวอย่างเช่น compileSdk รับ Int ไม่ใช่สตริง ซึ่งช่วยขจัดข้อผิดพลาดเกี่ยวกับชนิดที่ไม่ถูกต้อง: ใน Groovy compileSdk 34 และ compileSdk "34" ทำงานเหมือนกัน ในขณะที่ KTS เฉพาะรูปแบบแรกเท่านั้นที่ถูกต้อง ความเข้มงวดนี้ทำให้การกำหนดค่าคาดเดาได้ง่ายขึ้นและมีเอกสารครบถ้วน

Gradle KTS vs Groovy: เปรียบเทียบ

Groovy เป็น DSL ดั้งเดิมสำหรับ Gradle และยังคงได้รับการสนับสนุนอย่างเต็มที่ อย่างไรก็ตาม KTS มีข้อดีหลายประการที่ทำให้เป็นตัวเลือกที่แนะนำสำหรับโปรเจกต์ใหม่ Static typing, ประสิทธิภาพการแก้ไขใน IDE ที่ดีขึ้น และไวยากรณ์ที่เข้มงวดกว่าเป็นเหตุผลหลักในการเปลี่ยนไปใช้ KTS ในขณะเดียวกัน Groovy ยังคงความได้เปรียบในด้านความกระชับสำหรับการกำหนดค่าที่เรียบง่าย

ประสิทธิภาพการบิลด์บน KTS และ Groovy เกือบจะเหมือนกันหลังจากการคอมไพล์สคริปต์ สคริปต์ KTS ใช้เวลาในการคอมไพล์นานกว่าในการรันครั้งแรกหรือหลังจากล้างแคช แต่การบิลด์ครั้งต่อๆ ไปทำงานด้วยความเร็วเดียวกันกับสคริปต์ Groovy Gradle เก็บแคชสคริปต์ KTS ที่คอมไพล์แล้วในไดเรกทอรีบิลด์ ดังนั้นการคอมไพล์ใหม่จะเกิดขึ้นเมื่อสคริปต์มีการเปลี่ยนแปลงเท่านั้น

การเลือกระหว่าง KTS และ Groovy ในปี 2026 นั้นชัดเจน: สำหรับโปรเจกต์ใหม่ — KTS Google, JetBrains และ Gradle แนะนำ KTS สำหรับโปรเจกต์ใหม่ทั้งหมด Groovy ยังคงเกี่ยวข้องสำหรับการบำรุงรักษาโปรเจกต์เดิมที่การย้ายระบบไม่เหมาะสมเนื่องจากปริมาณการกำหนดค่าหรือปลั๊กอินเฉพาะที่เข้ากันไม่ได้กับ KTS

ตัวอย่างโค้ด: สคริปต์บิลด์บน KTS

มาดูบล็อกการกำหนดค่าทั่วไปใน KTS สำหรับ Android, Kotlin Multiplatform และ Compose Multiplatform โปรเจกต์ Android ที่ใช้ KTS ต้องการการระบุชนิดอย่างชัดเจนในการกำหนดค่า buildTypes และ productFlavors ตัวอย่างด้านล่างแสดงการตั้งค่าแอปพลิเคชันที่มีสองรสชาติ

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

    flavorDimensions += "version"
    productFlavors {
        register("demo") {
            dimension = "version"
            versionNameSuffix = "-demo"
        }
        register("full") {
            dimension = "version"
        }
    }
}

สำหรับ Kotlin Multiplatform นั้น KTS เป็นสิ่งจำเป็น — Groovy ไม่รองรับการกำหนดค่าโมดูลข้ามแพลตฟอร์มอย่างถูกต้อง การกำหนดค่าโมดูล KMM รวมถึงการตั้งค่าแพลตฟอร์มเป้าหมายและชุดซอร์ส ตัวอย่างด้านล่างแสดงการกำหนดค่าโมดูลที่ใช้ร่วมกับ iOS และ Android

kotlin {
    androidTarget {
        compilations.all {
            kotlinOptions {
                jvmTarget = "17"
            }
        }
    }

    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "Shared"
            isStatic = true
        }
    }

    sourceSets {
        commonMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0")
        }
        androidMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.9.0")
        }
    }
}

ฟังก์ชันช่วยเหลือและงานที่กำหนดเอง

KTS อนุญาตให้ประกาศฟังก์ชัน Kotlin ช่วยเหลือภายในสคริปต์บิลด์ ซึ่งสะดวกเป็นพิเศษสำหรับการกำหนดค่าที่ทำซ้ำ เช่น การกำหนดค่าลายเซ็นหรือการจัดการเวอร์ชัน ด้วย static typing ฟังก์ชันเหล่านี้สามารถเรียกใช้พร้อมการตรวจสอบพารามิเตอร์ในเวลาคอมไพล์ ซึ่งช่วยขจัดข้อผิดพลาดในการกำหนดค่าลายเซ็นก่อนเผยแพร่บน Google Play

fun Project.configureSigning() {
    android {
        signingConfigs {
            register("release") {
                storeFile = file("release.keystore")
                storePassword = System.getenv("KEYSTORE_PASSWORD")
                keyAlias = System.getenv("KEY_ALIAS")
                keyPassword = System.getenv("KEY_PASSWORD")
            }
        }
    }
}

// การใช้งานใน build.gradle.kts
configureSigning()

การย้ายจาก Groovy ไปยัง KTS

การย้าย จาก Groovy ไปยัง KTS เป็นกระบวนการที่สามารถทำได้ทีละน้อย Gradle รองรับโปรเจกต์แบบผสมที่บางโมดูลใช้ Groovy (build.gradle) และบางโมดูลใช้ KTS (build.gradle.kts) settings.gradle และ build.gradle หลักสามารถย้ายได้ก่อนเนื่องจากไม่ขึ้นอยู่กับปลั๊กอินของโมดูล Google แนะนำให้เริ่มการย้ายด้วย settings.gradle.kts จากนั้น build.gradle.kts หลัก และสุดท้ายจึงย้ายโมดูล

ขั้นตอนหลักของการย้ายรวมถึง: การแทนที่ไวยากรณ์ closure ด้วยแลมบ์ดา, การเพิ่มเครื่องหมาย = สำหรับการกำหนดค่า, การแทนที่คีย์สตริงด้วยค่าคงที่แบบมีชนิด และการกำหนดชนิดตัวแปรอย่างชัดเจน Android Studio มีการแปลง Groovy → KTS อัตโนมัติสำหรับบล็อกที่เรียบง่าย แต่การกำหนดค่าที่ซับซ้อนที่มี closure ซ้อนกันต้องเขียนใหม่ด้วยตนเอง

ปัญหาทั่วไปในการย้ายรวมถึงการเรียกเมธอด Groovy โดยปริยายที่ไม่มีสิ่งที่เทียบเท่าใน Kotlin และปลั๊กอินที่ไม่มี API ที่เป็นมิตรกับ Kotlin สำหรับปัญหาแรก Gradle มีความเข้ากันได้ผ่าน withGroovyBuilder — กลไกที่อนุญาตให้เรียกเมธอด Groovy จาก KTS สำหรับปัญหาที่สอง — จำเป็นต้องรอการอัปเดตปลั๊กอินหรือใช้ในโมดูล Groovy จนกว่าจะย้ายเสร็จสมบูรณ์

Gradle KTS สำหรับ Kotlin Multiplatform

Kotlin Multiplatform เป็นโปรเจกต์หลักที่ KTS เป็นข้อกำหนดบังคับ ปลั๊กอิน kotlin multiplatform มีส่วนขยายสำหรับการกำหนดค่าแพลตฟอร์มเป้าหมาย ชุดซอร์ส และไบนารีเฟรมเวิร์กที่พร้อมใช้งานผ่าน Kotlin DSL เท่านั้น Groovy ไม่รองรับการกำหนดค่าหลายแพลตฟอร์มอย่างถูกต้อง ดังนั้นโปรเจกต์ KMM จึงใช้ KTS โดยเฉพาะ

การกำหนดค่า KMM ใน KTS มีบล็อกที่ไม่มาตรฐาน: kotlin.target สำหรับระบุแพลตฟอร์ม, kotlin.sourceSets สำหรับจัดระเบียบโค้ดทั่วไปและโค้ดเฉพาะแพลตฟอร์ม, kotlin.cocoapods สำหรับการรวมกับ CocoaPods และ kotlin.jvmToolchain สำหรับการเลือก JDK แต่ละบล็อกมี API ที่มีการตรวจสอบชนิดอย่างเข้มงวดพร้อมการเติมข้อความอัตโนมัติใน Android Studio ซึ่งมีค่าอย่างยิ่งสำหรับการกำหนดค่าโปรเจกต์ KMM ที่ซับซ้อนที่มีหลายแพลตฟอร์ม

kotlin {
    iosArm64()
    iosSimulatorArm64()
    iosX64()

    cocoapods {
        summary = "Shared Kotlin module"
        homepage = "https://itsectr.com"
        framework {
            baseName = "Shared"
            isStatic = false
        }
        pod("Alamofire") {
            version = "5.9"
        }
    }
}

ด้วย static typing ของ KTS นักพัฒนา KMM จะได้รับการเติมข้อความอัตโนมัติสำหรับชุดซอร์สและ dependencies, การตรวจสอบชนิดของการกำหนดค่าเฟรมเวิร์ก และความสามารถในการปรับโครงสร้างชื่อแพลตฟอร์ม KTS ยังช่วยให้การดีบักง่ายขึ้น: ข้อผิดพลาดในการกำหนดค่า KMM จะปรากฏเป็นข้อผิดพลาดการคอมไพล์ Kotlin พร้อมข้อความที่ชัดเจน ต่างจาก Groovy ที่ข้อผิดพลาดอาจถูกซ่อนจนกว่างาน Gradle จะถูกดำเนินการ