Gradle: جوهر نظام البناء لـ Android و build.gradle
Gradle هو نظام بناء يعمل على أتمتة التجميع والاختبار وتغليف تطبيقات Android. على عكس Apache Ant أو Maven، فهو يدعم البناء التدريجي وتخزين النتائج مؤقتًا. اقرأ المزيد عن ميزاته في التوثيق الرسمي لـ Gradle. منذ عام 2013، تُستخدم الأداة كنظام بناء قياسي لمشاريع Android في Android Studio.
الخلاصة
- Gradle — نظام البناء القياسي لـ Android منذ 2013، حل محل Ant و Maven
- Build.gradle.kts مع Kotlin DSL — المعيار الحديث للتكوين مع التحقق من الأنواع
- Build variants تجمع بين أنواع البناء ونكهات المنتج لإصدارات مختلفة من التطبيق
- الملحقات توسع الوظائف: من تطبيق أدوات Android إلى نشر الإصدارات
- البناء التدريجي والتخزين المؤقت يقللان وقت إعادة التجميع عدة مرات
ما هو Gradle؟
Gradle هي أداة أتمتة بناء مفتوحة المصدر مكتوبة بلغة Java وتعمل على JVM. تأخذ كمدخل الكود المصدري والتبعيات والموارد، وتنتج كخرج تطبيقًا جاهزًا — APK أو AAB لنظام Android. في جوهرها، تستخدم Gradle مفهوم الرسم البياني غير الدوري الموجه (DAG) للمهام، حيث كل مهمة هي وحدة عمل ذرية والروابط بينها تحدد ترتيب التنفيذ. على عكس Make أو Ant، لا تتطلب Gradle وصف تسلسل الخطوات يدويًا: يكفي الإعلان عن التبعيات بين المهام، وسيحدد النظام الترتيب الأمثل بنفسه. هذا النهج يجعل Gradle مرنة وقابلة للتوسع لمشاريع من أي حجم.
يستخدم النظام ثلاث مراحل للتنفيذ: التهيئة (تحديد المشاريع المشاركة)، والتكوين (بناء الرسم البياني للمهام)، والتنفيذ (تشغيل المهام بالترتيب المطلوب). مرحلة التكوين هي الفارق الرئيسي لـ Gradle: يتم تنفيذ سكريبت البناء بالكامل قبل بدء المهام، مما يسمح بتغييرات ديناميكية في الرسم البياني حسب الظروف. وهذا يجعل من الممكن، على سبيل المثال، إضافة مهام فقط لإصدارات بناء محددة دون تكرار الكود. أداة البناء مكتوبة بلغة Groovy، لكن ملفات التكوين تدعم لغتين: Groovy DSL و Kotlin DSL.
كيف يدير Gradle بناء مشاريع Android؟
ملحق Android لـ Gradle يتكون من com.android.application و com.android.library، اللذين يضيفان مهام للمشروع للعمل مع أدوات Android. عندما يبدأ المطور البناء، ينفذ Gradle بالترتيب العشرات من المهام: تجميع Kotlin و Java عبر javac أو kotlinc، معالجة الموارد عبر AAPT2، إنشاء R.java، تجميع البايت كود إلى DEX عبر D8 أو R8، التوقيع وضغط APK. تتحقق كل مهمة مما إذا كانت بيانات الإدخال قد تغيرت، وإذا لم تكن كذلك، تستخدم النتيجة المخزنة مؤقتًا. هذه الآلية تسمى البناء التدريجي وتسرع إعادة التجميع بنسبة 60–80% مقارنة بإعادة البناء الكاملة.
يتم تعيين تكوين وحدة Android في كتلة android من ملف build.gradle.kts. داخل الكتلة، يتم تعريف compileSdk و minSdk و targetSdk وإصدار التطبيق والتوقيعات والمعلمات الأخرى. ينشئ Gradle تلقائيًا عدة إصدارات بناء لكل وحدة — مزيج من النوع (release, debug) والنكهة. على سبيل المثال، لوحدة ذات نكهتين ونوعين، يولد Gradle أربع مهام: assembleDemoDebug و assembleDemoRelease و assembleFullDebug و assembleFullRelease. يمكن تنفيذ كل هذه المهام بشكل فردي أو تشغيلها بأمر واحد لجميع الإصدارات مرة واحدة.
Build.gradle و build.gradle.kts: هيكل التكوين
كل مشروع Android يحتوي على مستويين من التكوين: build.gradle.kts الجذر (إعدادات لجميع الوحدات) و build.gradle.kts على مستوى الوحدة (إعدادات لوحدة معينة). في الملف الجذر، يتم الإعلان عن الملحقات دون تطبيقها، والمستودعات والمتغيرات العامة. في ملف الوحدة، يتم تطبيق الملحقات على الوحدة المحددة وتكوين معلمات البناء. يسمح هذا النهج بالإدارة المركزية لإصدارات التبعيات من خلال كتالوج الإصدارات أو كتلة ext.
Kotlin
@Suppress("UnstableApiUsage")
plugins {
id("com.android.application") version "8.2.2"
id("org.jetbrains.kotlin.android") version "1.9.22"
}
android {
namespace = "com.example.myapp"
compileSdk = 34
defaultConfig {
applicationId = "com.example.myapp"
minSdk = 24
targetSdk = 34
versionCode = 1
versionName = "1.0"
}
}كتلة dependencies هي عنصر حاسم آخر في build.gradle.kts. تسرد المكتبات والوحدات وتبعيات الملفات التي يحتاجها التطبيق. يدعم Gradle عدة تكوينات للتبعيات: implementation (متاحة فقط للوحدة الحالية)، api (متاحة أيضًا للوحدات التابعة)، testImplementation (للاعتبارات فقط)، androidTestImplementation (للاعتبارات الآلية) و compileOnly (في وقت التجميع فقط). كل تكوين يدير رؤية الفئات في رسم التبعيات، مما يؤثر على وقت البناء وحجم القطعة النهائية.
Kotlin
dependencies {
implementation("androidx.core:core-ktx:1.12.0")
implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.7.0")
implementation("androidx.activity:activity-compose:1.8.2")
testImplementation("junit:junit:4.13.2")
androidTestImplementation("androidx.test.ext:junit:1.1.5")
}Build variants: خيارات بناء التطبيق
build variant هو مزيج من نوع البناء ونكهة المنتج الذي يحدد إصدار التطبيق بإعدادات وكود وموارد فريدة. نوع البناء يحدد معلمات التغليف: debug (مع التصحيح واللاحقة .debug) أو release (مع التعتيم والتوقيع). نكهة المنتج تحدد الإصدارات الوظيفية: على سبيل المثال، demo (إصدار محدود) و full (إصدار كامل بميزات إضافية). ينشئ Gradle تلقائيًا مهام لكل مزيج، مما يسمح ببناء جميع الإصدارات بأمر واحد.
Kotlin
android {
buildTypes {
release {
isMinifyEnabled = true
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
debug {
applicationIdSuffix = ".debug"
}
}
flavorDimensions += "version"
productFlavors {
create("demo") {
dimension = "version"
applicationIdSuffix = ".demo"
}
create("full") {
dimension = "version"
applicationIdSuffix = ".full"
}
}
}كل build variant له مجموعة مصادر منفصلة. يستخدم Gradle أدلة src/demo/release و src/full/debug وغيرها، والتي تخزن الموارد والملفات البيانية والملفات المصدر الفريدة لإصدار معين. يبقى الكود المشترك في src/main. يسمح هذا النهج بإعادة استخدام المنطق الرئيسي واستبدال الأجزاء المختلفة فقط: السلاسل والأيقونات ونقاط نهاية API أو ملفات التكوين. يمكن لمجموعة المصادر تجاوز أي موارد من main: البيان والرسومات والقيم أو حتى فئات Kotlin. عند بناء إصدار معين، يدمج Gradle الملفات من main ومجموعة المصادر المقابلة، مع إعطاء الأولوية للملفات من الإصدار.
ملحقات Gradle لـ Android: توسيع الإمكانيات
يغطي نظام ملحقات Gradle جميع مراحل تطوير تطبيقات Android. تشمل الملحقات الرسمية من Google com.android.application (لوحدة التطبيق) و com.android.library (لوحدة المكتبة) و com.android.test (لوحدات الاختبار) وملحقات Kotlin من JetBrains. تضيف الملحقات مهام جديدة للمشروع، وتوسع DSL بكتل تكوين جديدة وتصل أدوات إضافية. بدون ملحق com.android.application، لا يمكن للمشروع بناء APK: هذا الملحق يسجل جميع المهام الخاصة بـ Android ويربطها في رسم البناء.
الملحقات الخارجية تحل مهام أكثر تحديدًا. Google Services (com.google.gms.google-services) يدمج Firebase و Google Play Services، ويدرج تلقائيًا google-services.json في البناء. Hilt (dagger.hilt.android.plugin) يولد كود حقن التبعيات في وقت التجميع. Safe Args (androidx.navigation.safeargs.kotlin) ينشئ فئات آمنة من حيث الأنواع للتنقل بين الأجزاء. كل ملحق يضاف في build.gradle.kts الجذر عبر كتلة plugins ويتطلب عادةً تكوينًا ضئيلًا. يحل Gradle تلقائيًا التبعيات المتعدية بين الملحقات ويضمن توافق الإصدارات من خلال ملفات Bom وكتالوجات الإصدارات.
مهام Gradle: أتمتة عمليات البناء
المهمة (task) هي وحدة عمل ذرية في Gradle. كل مهمة لها بيانات إدخال وبيانات إخراج وإجراء. تشمل المهام المضمنة لـ Android assemble (بناء جميع الإصدارات) و lint (فحص الكود) و test (تشغيل اختبارات الوحدة) و clean (تنظيف الملفات المؤقتة). يمكن للمطور إضافة مهام خاصة به باستخدام Groovy أو Kotlin DSL. المهام المخصصة مفيدة لأتمتة العمليات الروتينية: إنشاء التقارير ونسخ القطع الأثرية والنشر على أجهزة الاختبار أو التكامل مع أنظمة CI.
Kotlin
tasks.register("printBuildInfo") {
description = "يعرض معلومات البناء"
group = "custom"
doLast {
println("Build variant: ${project.name}")
println("Version: ${android.defaultConfig.versionName}")
}
}كل مهمة يمكن أن تعتمد على مهام أخرى من خلال آلية dependsOn. إذا كانت المهمة A تعتمد على المهمة B، يضمن Gradle أن B ستنفذ قبل A. لا يتطلب النظام تحديد الترتيب يدويًا لكل زوج — يكفي الإعلان عن التبعيات، وسيبني Gradle رسمًا بيانيًا موجهًا محسنًا للتنفيذ المتوازي للمهام المستقلة. المهام المضمنة لملحق Android مترابطة بالفعل: lint يعتمد على التجميع، test يعتمد على assemble، assembleDebug يعتمد على compileDebugKotlin. يمكن للمطور إدراج مهامه الخاصة في أي عقدة من الرسم باستخدام dependsOn أو mustRunAfter أو shouldRunAfter.
الأخطاء الشائعة عند العمل مع Gradle
إحدى المشكلات الشائعة هي تضارب إصدارات التبعيات، عندما تتطلب مكتبتان إصدارات مختلفة من نفس التبعية المتعدية. يبلغ Gradle عن خطأ التضارب، لكنه لا يقدم دائمًا حلاً تلقائيًا. للتشخيص، استخدم الأمر ./gradlew :app:dependencies الذي يعرض شجرة التبعيات الكاملة. يوصى بفرض إصدار المكتبة المتضاربة من خلال كتلة resolutionStrategy. سيناريو شائع آخر هو البناء البطيء بسبب نقص المعالجة التدريجية. تأكد من تحديث جميع الملحقات وتفعيل Gradle Daemon (org.gradle.daemon=true) وتعيين ذاكرة كافية في gradle.properties: org.gradle.jvmargs=-Xmx4096m.
تنشأ مشكلات التخزين المؤقت بعد تحديث التبعيات: قد يستخدم Gradle مخبأ قديمًا ويفشل البناء. الحل هو تشغيل البناء مع العلم --refresh-dependencies أو مسح المخبأ يدويًا عبر ./gradlew cleanBuildCache. الخطأ الثالث الأكثر شيوعًا هو عدم توافق الإصدارات بين Android Gradle Plugin (AGP) و Gradle. كل إصدار من AGP يتطلب إصدارًا أدنى محددًا من Gradle. يُنشر جدول التوافق على developer.android.com. إذا كانت الإصدارات غير متوافقة، يفشل Gradle في مرحلة التكوين برسالة حول الإصدار الأدنى المطلوب. تحقق دائمًا من أن إصدار wrapper الخاص بـ Gradle يتوافق مع متطلبات AGP.
الأسئلة الشائعة
ما هو Gradle بكلمات بسيطة؟
Gradle هو مبرمج آلي لبناء المشاريع. يأخذ الكود المصدري الخاص بك بلغة Kotlin أو Java، ويوصل المكتبات من الإنترنت، ويجمع كل شيء إلى بايت كود ويغلفه في APK. يعمل على JVM ويستخدم سكريبتات تعريفية بدلاً من التعليمات اليدوية. يحتاج المطور فقط إلى وصف القواعد، ويقوم Gradle بالباقي.
كيف يختلف build.gradle.kts عن build.gradle؟
Build.gradle يكتب بلغة Groovy — لغة ديناميكية بنحو مرن ودقة أقل. Build.gradle.kts يستخدم Kotlin DSL: كتابة قوية وإكمال تلقائي في Android Studio والتحقق من الأخطاء في وقت التجميع. توصي Google باستخدام Kotlin DSL لجميع المشاريع الجديدة. ملفات Groovy أسهل في الترحيل، لكن ملفات Kotlin أكثر موثوقية في الصيانة.
كيف تسريع بناء Gradle؟
فعّل Gradle Daemon (org.gradle.daemon=true) والبناء المتوازي (org.gradle.parallel=true). زد ذاكرة JVM إلى 4–8 جيجابايت عبر org.gradle.jvmargs. استخدم تكوين المشاريع عند الطلب (org.gradle.configureondemand=true). لمشاريع Android، هيئ تخزين المهام مؤقتًا وابنِ فقط لـ ABI المطلوب. في Android Studio، شغّل Build Analyzer للعثور على الاختناقات.
ما هو build variant في Android؟
Build variant هو مزيج من نوع البناء (مثل debug أو release) ونكهة المنتج (مثل demo أو full). يمكن أن يكون لكل إصدار اسم حزمة وإصدار وموارد وملفات مصدر خاصة به. ينشئ Gradle تلقائيًا مهمة بناء منفصلة لكل إصدار. هذا يسمح ببناء إصدارات متعددة من التطبيق من مشروع واحد.
كيف إضافة تبعية في Gradle؟
تضاف التبعيات في كتلة dependencies من ملف build.gradle.kts. صيغة التسجيل: configuration("group:artifact:version"). على سبيل المثال، implementation("androidx.core:core-ktx:1.12.0"). للاختبارات استخدم testImplementation، للاختبارات الآلية — androidTestImplementation. من الملائم وضع الإصدارات في كتالوج إصدارات منفصل عبر ملف libs.versions.toml.
الملخص
- Gradle — نظام البناء القياسي لـ Android، يعمل على JVM ويستخدم DAG للمهام
- البناء التدريجي والتخزين المؤقت يقللان وقت إعادة التجميع بنسبة 60–80%
- Kotlin DSL (build.gradle.kts) — تنسيق تكوين حديث مع إكمال تلقائي والتحقق من الأنواع
- Build variants تجمع بين نوع البناء ونكهة المنتج، وتنشئ مجموعات مصادر منفصلة لكل إصدار
- الملحقات توسع Gradle: من ملحق Android الأساسي إلى Firebase و Hilt و Safe Args
- المهام المخصصة تسمح بأتمتة أي مراحل بناء وتكامل
- المشكلات الشائعة — تضارب الإصدارات والبناء البطيء وعدم توافق AGP مع إصدار Gradle
سنقوم بتطوير تطبيق جوال جاهز
تقدم IT Sectr تطبيقات iOS وAndroid للشركات الناشئة والشركات منذ عام 2017. سوف نقدم لك النصح ونقترح أفضل حل.
اقرأ أيضًا