Gradle KTS — ما هو، Kotlin DSL لـ Gradle وبناء الجملة

ما هو Gradle KTS؟

Gradle KTS هو DSL من Kotlin (لغة خاصة بالمجال) يوفر بديلاً لـ Groovy لكتابة ملفات تهيئة Gradle. بدلاً من بناء جملة Groovy، يستخدم المطورون Kotlin — لغة شديدة الكتابة تتحقق من صحة التهيئة في وقت الترجمة. تم تقديم KTS لأول مرة في Gradle 5.0 في 2018 كميزة تجريبية ووصلت إلى مرحلة الاستقرار في Gradle 6.0.

الهدف الرئيسي من KTS هو القضاء على عيوب Groovy في سكريبتات البناء. Groovy هي لغة ذات كتابة ديناميكية حيث تظهر أخطاء التهيئة فقط في وقت التشغيل عند تنفيذ مهمة. يتيح KTS اكتشاف نفس الأخطاء في مرحلة تحرير الكود بفضل الكتابة الثابتة لـ 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. يتعرف Gradle على الامتداد ويمرر السكريبتات إلى محرك سكريبتات 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 مقابل Groovy: مقارنة

Groovy كانت DSL الأصلية لـ Gradle ولا تزال مدعومة بالكامل. ومع ذلك، تقدم KTS العديد من المزايا التي تجعلها الخيار الموصى به للمشاريع الجديدة. الكتابة الثابتة، وأداء تحرير أفضل في 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 المساعدة داخل سكريبت البناء. هذا مفيد بشكل خاص للتهيئات المتكررة مثل إعدادات التوقيع أو إدارة الإصدارات. بفضل الكتابة الثابتة، يمكن استدعاء هذه الدوال مع التحقق من المعاملات في وقت الترجمة، مما يلغي الأخطاء في تهيئات التوقيع قبل النشر على 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 الجذر، وأخيراً الوحدات.

تشمل الخطوات الرئيسية للترحيل: استبدال بناء جملة closures باللامبدا، وإضافة علامات = للتعيين، واستبدال مفاتيح السلاسل النصية بثوابت مقولة، والكتابة الصريحة للمتغيرات. Android Studio يوفر تحويلاً تلقائياً من Groovy إلى KTS للكتل البسيطة، لكن التهيئات المعقدة ذات closures المتداخلة تتطلب إعادة كتابة يدوية.

تشمل المشكلات النموذجية في الترحيل استدعاءات طرق Groovy الضمنية التي ليس لها مقابل في Kotlin، والإضافات التي لا توفر API صديقة لـ Kotlin. للمشكلة الأولى، يوفر Gradle التوافق عبر withGroovyBuilder — آلية تتيح استدعاء طرق Groovy من KTS. للمشكلة الثانية — من الضروري انتظار تحديث الإضافة أو استخدامها في وحدة Groovy حتى الترحيل الكامل.

Gradle KTS لـ Kotlin Multiplatform

Kotlin Multiplatform هو المشروع الرئيسي حيث KTS مطلب إلزامي. توفر إضافة kotlin multiplatform امتدادات لتهيئة المنصات المستهدفة ومجموعات المصادر وملفات framework الثنائية المتاحة فقط من خلال 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"
        }
    }
}

بفضل الكتابة الثابتة لـ KTS، يحصل مطورو KMM على إكمال تلقائي لمجموعات المصادر والتبعيات، والتحقق من أنواع تهيئة framework، وإمكانية إعادة هيكلة أسماء المنصات. KTS أيضاً يبسط التصحيح: تظهر الأخطاء في تهيئة KMM كأخطاء ترجمة Kotlin مع رسائل واضحة، على عكس Groovy حيث يمكن أن تبقى الأخطاء مخفية حتى تنفيذ مهمة Gradle.