گردل gradle در اندروید استودیو : کامل ترین معرفی که میتونید پیدا کنید

گردل gradle در اندروید استودیو : کامل ترین معرفی که میتونید پیدا کنید
در این پست می‌خوانید:

در این مطلب درباره گردل صحبت میکنم ، و کامل فایل های که در اندروید استودیو داره رو معرفی و بررسی میکنیم . . .

گردل در اندروید استودیو

گردل (Gradle) چیه و چرا ما اندرویدکارها ازش استفاده می‌کنیم؟

وقتی تازه شروع به برنامه‌نویسی اندروید می‌کنیم، معمولاً اصلاً به گرادل توجهی نداریم. همه تمرکزمون روی نوشتن کدهای کاتلین و ساخت اپ‌های جذاب و کاربردیه که هم قیافه خوبی داشته باشن، هم به درد کاربرا بخورن.

ولی یه وقتایی وسط کار که داریم اپ می‌سازیم، به یه مشکلی برمی‌خوریم. بعد می‌فهمیم این مشکل قبلاً توسط یه نفر دیگه حل شده و اون آدم راه‌حلش رو به شکل یه کتابخونه (Library) آماده منتشر کرده. حالا ما می‌تونیم اون کتابخونه رو توی پروژه‌مون استفاده کنیم و حتی اگه لازم شد، یه کم شخصی‌سازیش کنیم.

برای این کار، میایم توی فایل build.gradle اسم کتابخونه و نسخه‌ش رو می‌نویسیم و همین! اینجوری اون کتابخونه میاد توی پروژه‌مون. این یکی از ساده‌ترین و رایج‌ترین کاراییه که با گرادل توی پروژه‌های اندروید انجام می‌دیم.

چی شد که علاقه‌مند شدم Gradle رو یاد بگیرم؟

اوایل که شروع به کار کرده بودم، اصلاً حس نمی‌کردم نیاز باشه بیشتر درباره گرادل بدونم. برای من، گرادل یه سری فایل عجیب‌غریب بود که فقط اسم کتابخونه‌هایی که لازم داشتم رو توش می‌نوشتم. حتی جرئت نمی‌کردم چیزی توی این فایل‌ها تغییر بدم! می‌ترسیدم خرابکاری کنم و کل پروژه بپره.

ولی یه روز به خودم گفتم: “بابا، این فایل‌ها هم که کدن! خب منم برنامه‌نویسم دیگه! چرا باید از کدهای گرادل بترسم؟ مگه چیه؟!”

این یه کشف بزرگ بود برام! 😄
بعدش تصمیم گرفتم برم و گرادل رو بهتر یاد بگیرم. حالا می‌خوام توی این مقاله، چیزایی که درباره فایل‌های گرادل تو پروژه‌های اندروید یاد گرفتم رو با بقیه به اشتراک بذارم. اینجوری هر کسی می‌تونه بخونه و بفهمه این “گرادل” که انقدر اسمش رو می‌شنوه، چیه و چیکار می‌کنه.

گردل چیه؟

ببین، گرادل یه ابزار ساخت (Build Tool) هست که توی برنامه‌نویسی اندروید استفاده می‌شه تا کارای مربوط به ساخت و انتشار اپلیکیشن رو خودکار کنه. حالا شاید فکر کنی ساختن و اجرای یه اپ خیلی ساده‌ست، فقط کافیه دکمه Run رو توی Android Studio بزنی و خلاص! ولی پشت این کار ساده، کلی اتفاق پیچیده داره میفته. وقتی دکمه Run رو می‌زنی، گرادل یه سری کارای پشت‌صحنه رو انجام می‌ده که باعث می‌شه اپلیکیشن روی شبیه‌ساز یا گوشی واقعی اجرا بشه.

خب گرادل چه مراحلی رو طی می‌کنه؟

  1. خوندن فایل تنظیمات: اول از همه گرادل میره سراغ فایل‌های پیکربندی مثل build.gradle. توی این فایل مشخص می‌کنیم اپ ما چه کتابخونه‌هایی نیاز داره، چه نوع ساخت‌هایی (مثل debug یا release) باید داشته باشه و کلی تنظیمات دیگه.
  2. دانلود کتابخونه‌ها: بعدش گرادل میره کتابخونه‌هایی که توی فایل تعریف کردیم رو بررسی می‌کنه و اگه لازم باشه، می‌ره از اینترنت دانلودشون می‌کنه. این وابستگی‌ها (Dependencies) همون ابزارها و کدهای آماده‌ای هستن که توی پروژه استفاده می‌کنیم.
  3. کامپایل کد: حالا نوبت اینه که کدهایی که با کاتلین یا جاوا نوشتیم رو به بایت‌کد تبدیل کنه؛ یعنی کدی که ماشین می‌فهمه و می‌تونه اجراش کنه.
  4. بسته‌بندی فایل‌ها: بعد از کامپایل، گرادل کدهای کامپایل‌شده و منابعی مثل عکس‌ها و فایل‌های XML رو برمی‌داره و اونا رو توی یه فایل APK (همون فایل نصبی اندروید) بسته‌بندی می‌کنه.
  5. نصب و اجرا: در آخر، گرادل فایل APK رو روی شبیه‌ساز یا گوشی نصب می‌کنه و اپ رو اجرا می‌کنه.

زبان DSL چیه؟

گرادل فقط یه ابزار ساده نیست، بلکه بهت اجازه می‌ده که منطق مورد نظر خودت رو هم توش بنویسی. برای این کار از یه زبان مخصوص به اسم DSL (Domain-Specific Language) استفاده می‌کنه. این زبان که بر پایه Groovy یا Kotlin هست، مخصوص نوشتن اسکریپت‌های ساخت پروژه طراحی شده.

فرقی نمی‌کنه از Groovy استفاده کنی یا Kotlin، ساختار فایل‌های گرادل تقریباً شبیه‌هم هستن و بخش‌های مختلفش از همین DSL ساخته شدن.

تا اینجا هر چیزی که لازم بود بدونی تا یه دید کلی از گرادل داشته باشی رو گفتم. از اینجا به بعد می‌خوام درباره فایل‌های مختلفی که مربوط به گرادل هستن و یه برنامه‌نویس اندروید هر روز باهاشون سروکار داره حرف بزنم. این فایل‌ها رو یکی‌یکی باز می‌کنیم و بررسی می‌کنیم که هرکدومشون چه کاری انجام می‌دن. به شکل زیر توجه کن:

 

 

البته قبل از این این فایل رو معرفی کنیم نیاز داریم که مفهوم ماژول رو معرفی کنیم :

Module  یا ماژول چیست ؟

کلمه “module” به معنی “ماژول” است؛ یعنی یک بخش مستقل و جداشدنی در سیستم یا برنامه که وظیفه خاصی دارد، مثل یک قسمت از کد یا کتابخانه در برنامه‌نویسی.

از کجا بفهمم پروژه‌ام چند تا ماژول داره؟

تعداد ماژول‌های پروژه‌ات رو خیلی راحت می‌تونی از چند جا بفهمی:

۱. بخش Gradle Scripts در Android Studio

  • توی Android Studio، سمت چپ برو به نمای Project”.
  • حالت نمایش رو از Android” به Project” تغییر بده.
  • حالا توی پوشه اصلی پروژه (Root)، دنبال فایل settings.gradle.kts یا settings.gradle بگرد.

مانند شکل زیر :

مثلا ، در این پروژه ، ما یه ماژول داریم ، به نام  app

 نمای “Android” در Android Studio

  • اگه توی نمای Android” باشی، ماژول‌ها به ترتیب توی لیست نمایش داده می‌شن.
    معمولاً اولین ماژول همون app هست (ماژول اصلی اپلیکیشن).
    هر پوشه‌ای که کنار اسمش آیکن ماژول داشته باشه، یه ماژوله.

بررسی پوشه‌ها

در پوشه پروژه‌ات، هر پوشه‌ای که فایل build.gradle.kts یا build.gradle داشته باشه، یه ماژوله.

نتیجه

برای فهمیدن تعداد ماژول‌ها، راحت‌ترین راه اینه که به فایل settings.gradle.kts نگاه کنی یا از نمای Project” توی Android Studio استفاده کنی. هر چیزی که با include لیست شده، یه ماژوله. 😊

حالا به عنوام مثال داخل شکل زیر یه پروژه مولتی ماژول رو میتونید ببیند :

فایل‌های Gradle Scripts در اندروید استودیو

این فایل، تنظیمات کلی پروژه رو مدیریت می‌کنه. یعنی هر چیزی که قراره توی همه ماژول‌ها (مثلاً اپلیکیشن، کتابخونه‌ها، یا ماژول‌های دیگه‌ای که تو پروژه داری) به کار بره، اینجا تعریف می‌شه. به بیان ساده، این فایل مثل یه “مدیر پروژه” عمل می‌کنه و همه تنظیمات عمومی رو کنترل می‌کنه.

کد های Build.gradle.kts :

// Top-level build file where you can add configuration options common to all sub-projects/modules.
plugins {
    alias(libs.plugins.android.application) apply false
    alias(libs.plugins.kotlin.android) apply false
    alias(libs.plugins.kotlin.compose) apply false
}

حالا این کد ها که این جاست ،  یه سری پلاگین رو معرفی کرده و مشخص کرده این پلاگین‌ها توی سطح پروژه فقط تعریف می‌شن ولی اجرا نمی‌شن. اجراشون توی فایل‌های Build.gradle.kts مربوط به ماژول‌ها (مثل اپلیکیشن) اتفاق می‌افته.

کامنتی که نوشته شده اینه:

// Top-level build file where you can add configuration options common to all sub-projects/modules.

ترجمه:
“این فایل ساخت سطح بالاست که می‌تونید تنظیمات مشترک بین همه زیرپروژه‌ها یا ماژول‌ها رو توش اضافه کنید.”

یعنی هر چیزی که قراره بین همه ماژول‌ها مشترک باشه یا چیزی که همه زیرپروژه‌ها نیاز دارن، باید توی این فایل تعریف بشه.

 کدهای داخل فایل چی کاره‌اند؟

حالا بیایم کد رو باز کنیم و توضیح بدیم:

plugins {

alias(libs.plugins.android.application) apply false

alias(libs.plugins.kotlin.android) apply false

alias(libs.plugins.kotlin.compose) apply false

}

بخش plugins:

این قسمت برای معرفی پلاگین‌ها استفاده می‌شه. پلاگین‌ها ابزارهایی هستن که وظایف خاصی رو برای Gradle تعریف می‌کنن و کمک می‌کنن پروژه رو بسازی. مثلاً:

  • android.application: پلاگینی برای ساخت اپلیکیشن اندرویدی.
  • kotlin.android: پلاگینی برای اضافه کردن قابلیت‌های کاتلین توی پروژه.
  • kotlin.compose: پلاگینی برای استفاده از Jetpack Compose (کتابخونه UI مدرن اندروید).

بخش alias(…):

اینجا از چیزی به اسم alias استفاده شده که مربوط به فایل libs.version.toml هست. این فایل یه جور لیست پلاگین‌ها و کتابخونه‌هایی که پروژه نیاز داره رو مدیریت می‌کنه. توی فایل libs.version.toml مثلاً ممکنه چیزی این شکلی تعریف شده باشه:

[plugins]

android.application = { id = "com.android.application", version = "8.1.0" }

kotlin.android = { id = "org.jetbrains.kotlin.android", version = "1.9.0" }

kotlin.compose = { id = "org.jetbrains.kotlin.compose", version = "1.5.0" }

اینجا داری به Gradle می‌گی که از این پلاگین‌ها استفاده کن.

بخش apply false:

این یعنی این پلاگین‌ها فقط تعریف می‌شن ولی توی این سطح پروژه اجرا نمی‌شن. چرا؟

چون اجرای این پلاگین‌ها توی فایل‌های Build.gradle.kts مربوط به ماژول‌ها اتفاق می‌افته. مثلاً پلاگین android.application توی ماژول اپلیکیشن اجرا می‌شه، نه توی سطح پروژه.

چرا این تنظیمات توی سطح پروژه تعریف می‌شه؟

فرض کن پروژه‌ات چند تا ماژول داره، مثل یه :

  • ماژول اپلیکیشن،
  • یه ماژول کتابخونه،
  • و یه ماژول دیگه برای تست.

حالا اگه همه این ماژول‌ها از پلاگین‌های مشابهی استفاده کنن، به جای اینکه توی هر ماژول جداگانه این پلاگین‌ها رو معرفی کنی، می‌تونی توی سطح پروژه این پلاگین‌ها رو تعریف کنی و فقط توی ماژول‌هایی که نیاز دارن، اجراشون کنی.

این کار باعث می‌شه:

  • کدها مرتب‌تر بشن
  • مدیریت پلاگین‌ها راحت‌تر بشه
  • از تکرار کد جلوگیری بشه

 جمع‌بندی

این فایل تنظیمات کلی پروژه رو مدیریت می‌کنه و توی اون، پلاگین‌هایی که توی پروژه لازم داری، فقط تعریف شدن (نه اجرا). اجرای این پلاگین‌ها توی فایل‌های سطح ماژول اتفاق می‌افته. کامنت بالا هم یه توضیح کلی داده که این فایل برای تنظیمات مشترک بین همه ماژول‌هاست.

این فایل تنظیمات خاص هر ماژول رو مدیریت می‌کنه. یعنی اگه پروژه‌ات چند تا ماژول داره، هر ماژول برای خودش یه فایل build.gradle.kts داره که تنظیمات اختصاصی اون ماژول توش نوشته می‌شه. مثلاً توی ماژول اپلیکیشن، چیزایی مثل نسخه‌های SDK، وابستگی‌ها (dependencies)، و تنظیمات مخصوص اپلیکیشن رو اینجا تعریف می‌کنی.

کدهای build.gradle.kts (module)

plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.android)
    alias(libs.plugins.kotlin.compose)
}

android {
    namespace = "ir.brazandeh.learngit"
    compileSdk = 35

    defaultConfig {
        applicationId = "ir.brazandeh.learngit"
        minSdk = 24
        targetSdk = 35
        versionCode = 1
        versionName = "1.0"

        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            isMinifyEnabled = false
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_11
        targetCompatibility = JavaVersion.VERSION_11
    }
    kotlinOptions {
        jvmTarget = "11"
    }
    buildFeatures {
        compose = true
    }
}

dependencies {

    implementation(libs.androidx.core.ktx)
    implementation(libs.androidx.lifecycle.runtime.ktx)
    implementation(libs.androidx.activity.compose)
    implementation(platform(libs.androidx.compose.bom))
    implementation(libs.androidx.ui)
    implementation(libs.androidx.ui.graphics)
    implementation(libs.androidx.ui.tooling.preview)
    implementation(libs.androidx.material3)
    testImplementation(libs.junit)
    androidTestImplementation(libs.androidx.junit)
    androidTestImplementation(libs.androidx.espresso.core)
    androidTestImplementation(platform(libs.androidx.compose.bom))
    androidTestImplementation(libs.androidx.ui.test.junit4)
    debugImplementation(libs.androidx.ui.tooling)
    debugImplementation(libs.androidx.ui.test.manifest)
}

توضیح کدهای فایل

۱. بخش plugins:

اینجا داری پلاگین‌هایی که این ماژول لازم داره رو معرفی می‌کنی. مثلاً:

plugins {

alias(libs.plugins.android.application)

alias(libs.plugins.kotlin.android)

alias(libs.plugins.kotlin.compose)

}
  • android.application: این پلاگین برای ساخت اپلیکیشن اندرویدی استفاده می‌شه.
  • kotlin.android: این پلاگین قابلیت‌های کاتلین رو برای اپلیکیشن اضافه می‌کنه.
  • kotlin.compose: این پلاگین برای استفاده از Jetpack Compose (کتابخونه مدرن طراحی UI اندروید) کاربرد داره.

۲. بخش android:

این قسمت تنظیمات مخصوص خود اپلیکیشن رو مدیریت می‌کنه. حالا بیایم خط به خط توضیح بدیم:

android {

namespace = "ir.brazandeh.learngit"

compileSdk = 35


  • namespace: اسم بسته (package name) اپلیکیشن رو مشخص می‌کنه.
  • compileSdk: نسخه SDK‌ای که قراره اپلیکیشن باهاش کامپایل بشه (اینجا نسخه 35).

بخش defaultConfig:

تنظیمات پیش‌فرض اپلیکیشن رو تعریف می‌کنه:

defaultConfig {

applicationId = "ir.brazandeh.learngit"

minSdk = 24

targetSdk = 35

versionCode = 1

versionName = "1.0"

testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"

}


  • applicationId: شناسه اپلیکیشن. این همون چیزی هست که وقتی اپ رو نصب می‌کنی، به‌عنوان اسم منحصربه‌فردش استفاده می‌شه.
  • minSdk: حداقل نسخه اندرویدی که اپلیکیشن اجرا می‌شه (اینجا 24).
  • targetSdk: نسخه اندرویدی که اپلیکیشن بهینه‌شده براش (اینجا 35).
  • versionCode: شماره نسخه اپلیکیشن (برای آپدیت‌ها).
  • versionName: اسم نسخه‌ای که کاربر می‌بینه (اینجا “1.0”).
  • testInstrumentationRunner: تنظیمات مربوط به تست‌های اندرویدی.

بخش buildTypes:

اینجا نوع ساخت اپلیکیشن رو مشخص می‌کنی. مثلاً:

buildTypes {

release {

isMinifyEnabled = false

proguardFiles(

getDefaultProguardFile("proguard-android-optimize.txt"),

"proguard-rules.pro"

)

}

}
  • release: تنظیمات مربوط به نسخه نهایی اپلیکیشن (مثلاً وقتی قراره منتشر بشه).
  • isMinifyEnabled: اگه true باشه، سایز کد رو کوچک می‌کنه (برای بهینه‌سازی).
  • proguardFiles: فایل‌های تنظیمات ProGuard که برای بهینه‌سازی و امن کردن کد استفاده می‌شه.

بخش compileOptions و kotlinOptions:

اینجا تنظیمات مربوط به نسخه جاوا و کاتلین مشخص می‌شه:

compileOptions {

sourceCompatibility = JavaVersion.VERSION_11

targetCompatibility = JavaVersion.VERSION_11

}

kotlinOptions {

jvmTarget = "11"

}
  • sourceCompatibility و targetCompatibility: نسخه جاوایی که اپلیکیشن باهاش سازگار باشه (اینجا نسخه 11).
  • jvmTarget: تنظیمات مربوط به JVM برای کاتلین (اینجا هم نسخه 11).

بخش buildFeatures:

اینجا مشخص می‌کنی که از قابلیت‌های خاصی مثل Compose استفاده می‌کنی:

buildFeatures {

compose = true

}
  • compose = true: یعنی Jetpack Compose توی اپلیکیشن فعال باشه.

۳. بخش dependencies:

اینجا کتابخونه‌هایی که اپلیکیشن نیاز داره رو معرفی می‌کنی. مثلاً:

dependencies {

implementation(libs.androidx.core.ktx)

implementation(libs.androidx.lifecycle.runtime.ktx)

implementation(libs.androidx.activity.compose)

implementation(platform(libs.androidx.compose.bom))

implementation(libs.androidx.ui)

implementation(libs.androidx.ui.graphics)

implementation(libs.androidx.ui.tooling.preview)

implementation(libs.androidx.material3)

testImplementation(libs.junit)

androidTestImplementation(libs.androidx.junit)

androidTestImplementation(libs.androidx.espresso.core)

androidTestImplementation(platform(libs.androidx.compose.bom))

androidTestImplementation(libs.androidx.ui.test.junit4)

debugImplementation(libs.androidx.ui.tooling)

debugImplementation(libs.androidx.ui.test.manifest)

}

انواع وابستگی‌ها:

  • implementation: کتابخونه‌هایی که توی کد اصلی اپلیکیشن استفاده می‌کنی.
  • testImplementation: کتابخونه‌هایی که برای تست استفاده می‌کنی.
  • androidTestImplementation: کتابخونه‌هایی که برای تست‌های اندرویدی استفاده می‌کنی.
  • debugImplementation: کتابخونه‌هایی که فقط برای حالت دیباگ استفاده می‌شن.

مثال کتابخونه‌ها:

  • androidx.core.ktx: قابلیت‌های کاتلین برای اندروید.
  • androidx.compose.bom: مدیریت نسخه‌های کتابخونه‌های Compose.
  • androidx.material3: کتابخونه متریال دیزاین نسخه جدید.

جمع‌بندی این بخش : 

این فایل برای تنظیمات اختصاصی ماژوله.

  • بخش plugins می‌گه این ماژول از چه پلاگین‌هایی استفاده می‌کنه.
  • بخش android تنظیمات اپلیکیشن مثل نسخه SDK، شناسه اپ، و نوع ساخت رو مشخص می‌کنه.
  • بخش dependencies کتابخونه‌هایی که این ماژول نیاز داره رو معرفی می‌کنه.

اگه پروژه‌ات چند ماژول داره، هر ماژول تنظیمات خودش رو توی این فایل داره. این کار باعث می‌شه همه چیز مرتب‌تر و راحت‌تر مدیریت بشه. 😊

این فایل یه جور “نگهبان” برای کدهای اپلیکیشنته. وقتی اپت رو برای انتشار (Release) آماده می‌کنی، ابزار Proguard میاد و کدتو بهینه، فشرده و مبهم می‌کنه. یعنی جلوی دزدیدن یا مهندسی معکوس کدتو می‌گیره. این کار باعث می‌شه کدت برای کسی که می‌خواد اون رو بخونه یا ازش سوءاستفاده کنه، غیرقابل فهم بشه.

چی‌کار می‌کنه؟

وقتی Proguard فعال باشه (با تنظیمات در فایل build.gradle)، این فایل (Proguard-rules.pro) تعیین می‌کنه که:

  1. کدهای خاصی که نباید حذف بشن یا تغییر کنن: اگر می‌خوای یه سری کلاس‌ها یا متدها حتی بعد از فشرده‌سازی دست‌نخورده باقی بمونن، توی این فایل مشخصشون می‌کنی.
  2. چیزهایی که باید حفظ بشن: مثلاً کلاس‌هایی که توسط Reflection یا WebView استفاده می‌شن و نباید حذف بشن.
  3. تنظیمات مخصوص امنیت: می‌تونی تنظیمات اضافی برای امنیت بیشتر اضافه کنی.

توضیح کامنت‌های داخل فایل

# Add project specific ProGuard rules here.

# You can control the set of applied configuration files using the

# proguardFiles setting in build.gradle.

اینجا می‌گه که تنظیمات مخصوص پروژه رو می‌تونی توی این فایل اضافه کنی. همچنین می‌گه که Proguard از طریق تنظیمات proguardFiles در فایل build.gradle کنترل می‌شه.

لینک توضیحات بیشتر:

# For more details, see

#   http://developer.android.com/guide/developing/tools/proguard.html

اینجا لینکی به مستندات رسمی Proguard داده شده که جزئیات بیشتری در مورد نحوه استفاده و تنظیمش پیدا کنی.

۳. تنظیمات مخصوص WebView با جاوا اسکریپت:

  

# If your project uses WebView with JS, uncomment the following

# and specify the fully qualified class name to the JavaScript interface

# class:

#-keepclassmembers class fqcn.of.javascript.interface.for.webview {

#   public *;

#}

  • اگه پروژه‌ات از WebView و جاوا اسکریپت استفاده می‌کنه، باید این تنظیم رو فعال کنی.
  • اینجا کلاس‌هایی که برای ارتباط بین WebView و جاوا اسکریپت استفاده می‌شن، حفظ می‌شن تا حذف یا تغییر نکنن.
  • fqcn.of.javascript.interface.for.webview رو باید با اسم کامل کلاس جاوا اسکریپت خودت جایگزین کنی.

۴. حفظ اطلاعات خط‌های کد (Debugging):

          

# Uncomment this to preserve the line number information for

# debugging stack traces.

#-keepattributes SourceFile,LineNumberTable

  • اگه می‌خوای اطلاعات مربوط به شماره خط‌ها (برای دیباگ کردن مشکلات) حفظ بشه، این خط رو فعال کن.
  • این بهت کمک می‌کنه توی گزارش‌های خطا، شماره خط‌های واقعی رو ببینی.

۵. مخفی کردن اسم فایل‌های منبع:

  

# If you keep the line number information, uncomment this to

# hide the original source file name.

#-renamesourcefileattribute SourceFile

  • اگه اطلاعات شماره خط رو حفظ کردی، می‌تونی اسم فایل‌های منبع رو مخفی کنی. این باعث می‌شه کسی نتونه بفهمه کد اصلیت مربوط به کدوم فایل بوده.

چرا این فایل مهمه؟

  1. امنیت: جلوی مهندسی معکوس و دزدیدن کد رو می‌گیره.
  2. بهینه‌سازی: سایز اپلیکیشن رو کوچیک‌تر می‌کنه و عملکرد بهتری ارائه می‌ده.
  3. کنترل: بهت اجازه می‌ده بخش‌هایی از کد رو که نباید حذف یا تغییر بشن، مشخص کنی.

چطور استفاده کنیم؟

  • وقتی اپ رو برای انتشار آماده می‌کنی، Proguard از تنظیمات این فایل استفاده می‌کنه.
  • اگه نیاز داری کلاس یا متدی خاص رو نگه داری، باید قوانین مربوط به اون رو توی این فایل اضافه کنی.
  • مثال نگه داشتن یک کلاس:

      

-keep class com.example.myclass {

    public *;

}

   

 

این تنظیم می‌گه کلاس com.example.myclass و همه متدهای عمومی اون باید دست‌نخورده باقی بمونن.

جمع‌بندی :

فایل Proguard-rules.pro مثل یه نگهبان برای کدهای اپلیکیشنته که توی مرحله انتشار (Release) فعال می‌شه و کد رو:

  • فشرده می‌کنه تا سایز اپ کوچیک‌تر بشه.
  • مبهم می‌کنه تا فهمیدن کد سخت‌تر بشه.
  • تنظیمات خاص مثل حفظ کلاس‌ها یا متدهای مهم رو می‌تونی توش تعریف کنی.

این فایل خیلی مهمه، مخصوصاً اگه اپلیکیشن رو قراره منتشر کنی و امنیت کد برات اولویته. 😊

 

این فایل مثل یه دفترچه تنظیمات برای Gradle عمل می‌کنه. توش می‌تونی پارامترهای کلی مثل حافظه موردنیاز Gradle، تنظیمات مربوط به پروژه، و گزینه‌های سفارشی رو تعریف کنی. این فایل به Gradle کمک می‌کنه که پروژه رو بهتر، سریع‌تر، و بهینه‌تر بسازه.

توضیح خط به خط کدهای فایل

۱. توضیحات کلی:

   

# Project-wide Gradle settings.

# IDE (e.g. Android Studio) users:

# Gradle settings configured through the IDE *will override*

# any settings specified in this file.

این توضیح می‌گه تنظیماتی که توی این فایل تعریف می‌کنی، تنظیمات کلی پروژه هستن. ولی اگه توی IDE (مثلاً Android Studio) تنظیمات جداگانه‌ای برای Gradle انجام بدی، اون تنظیمات، تنظیمات این فایل رو لغو می‌کنن.

۲. تنظیمات JVM برای Gradle:

   

# Specifies the JVM arguments used for the daemon process.

# The setting is particularly useful for tweaking memory settings.

org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8

اینجا تنظیمات مربوط به JVM (ماشین مجازی جاوا) رو برای Gradle مشخص می‌کنه:

  • -Xmx2048m: این خط می‌گه Gradle اجازه داره تا ۲ گیگابایت حافظه استفاده کنه. اگه پروژه سنگین باشه، می‌تونی این مقدار رو بیشتر کنی تا Gradle سریع‌تر کار کنه.
  • -Dfile.encoding=UTF-8: این خط تنظیم می‌کنه که Gradle از کدگذاری UTF-8 برای فایل‌ها استفاده کنه. این باعث می‌شه کاراکترهای خاص (مثل فارسی) درست خونده بشن.
  •  

۳. حالت موازی Gradle:

      

# When configured, Gradle will run in incubating parallel mode.

# This option should only be used with decoupled projects.

# org.gradle.parallel=true

  • این تنظیم باعث می‌شه Gradle کارها رو به‌صورت موازی انجام بده (Parallel Build).
  • org.gradle.parallel=true: اگه پروژه‌ات چند ماژول داره و این ماژول‌ها به هم وابسته نیستن، می‌تونی این رو فعال کنی تا Gradle سریع‌تر کار کنه.
  • ولی اگه ماژول‌ها وابسته باشن، ممکنه فعال کردن این گزینه باعث مشکل بشه.

۴. استفاده از AndroidX:

  
# AndroidX package structure to make it clearer which packages are bundled with the

# Android operating system, and which are packaged with your app's APK

android.useAndroidX=true
  • android.useAndroidX=true: این خط مشخص می‌کنه که پروژه از AndroidX استفاده می‌کنه.
  • AndroidX یه نسخه به‌روزرسانی‌شده از کتابخونه‌های قدیمی اندروید (Support Library) هست که امکانات مدرن‌تر و بهتر ارائه می‌ده. این گزینه معمولاً همیشه باید فعال باشه.

۵. استایل کدنویسی Kotlin:

# Kotlin code style for this project: "official" or "obsolete":

kotlin.code.style=official
  • kotlin.code.style=official: این خط می‌گه پروژه از استایل رسمی کدنویسی Kotlin استفاده کنه.
  • اگه مقدار رو به “obsolete” تغییر بدی، پروژه از استایل قدیمی Kotlin استفاده می‌کنه (که دیگه پیشنهاد نمی‌شه).

۶. کاهش حجم کلاس R:

    

# Enables namespacing of each library's R class so that its R class includes only the

# resources declared in the library itself and none from the library's dependencies,

# thereby reducing the size of the R class for that library

android.nonTransitiveRClass=true

  • android.nonTransitiveRClass=true: این تنظیم باعث می‌شه کلاس R (که لیست منابع پروژه رو نگه می‌داره) کوچیک‌تر بشه.
  • به‌جای اینکه کلاس R تمام منابع پروژه رو نگه داره، فقط منابع مربوط به هر کتابخونه رو نگه می‌داره. این باعث می‌شه کامپایل سریع‌تر بشه و حجم کلاس R کمتر باشه.

چرا این فایل مهمه؟

  1. کنترل حافظه: اگه پروژه سنگین باشه، می‌تونی به Gradle حافظه بیشتری بدی تا سریع‌تر کار کنه.
  2. بهینه‌سازی ساخت: تنظیمات موازی یا کاهش حجم کلاس R باعث بهینه‌تر شدن فرآیند ساخت پروژه می‌شه.
  3. مدیریت نسخه‌ها: چیزهایی مثل استفاده از AndroidX یا استایل کدنویسی Kotlin رو می‌تونی توی این فایل مدیریت کنی.

جمع‌بندی به زبان ساده

  • فایل Gradle.properties یه فایل تنظیمات کلی برای Gradle هست.
  • توش چیزهایی مثل مقدار حافظه، استفاده از AndroidX، استایل کدنویسی Kotlin، و بهینه‌سازی Gradle رو تنظیم می‌کنی.
  • این فایل کمک می‌کنه پروژه سریع‌تر و بهینه‌تر ساخته بشه، مخصوصاً وقتی پروژه بزرگ و چندماژولی باشه. 😊
 

فایل libs.versions.toml یه مکان مرکزی برای مدیریت وابستگی‌ها (dependencies) و نسخه کتابخونه‌ها در پروژه Gradle است. این فایل به پروژه کمک می‌کنه که همه وابستگی‌ها و نسخه‌ها به صورت متمرکز و مرتب مدیریت بشن. حالا بیایم سه بخش اصلی این فایل رو بررسی کنیم:

۱. [versions]: تعریف نسخه‌ها

این بخش برای تعریف نسخه‌های کتابخونه‌ها و پلاگین‌ها استفاده می‌شه. به جای اینکه توی هر ماژول نسخه کتابخونه‌ها رو جداگانه تعریف کنی، اینجا همه نسخه‌ها یکجا مدیریت می‌شن.

    

[

versions]

agp = "8.8.0"

kotlin = "2.0.0"

coreKtx = "1.15.0"

junit = "4.13.2"

junitVersion = "1.2.1"

espressoCore = "3.6.1"

lifecycleRuntimeKtx = "2.8.7"

activityCompose = "1.10.0"

composeBom = "2024.04.01"

چی کار می‌کنه؟

  • اینجا برای هر کتابخونه یا پلاگین یه نام مشخص (کلید) تعریف می‌کنیم و نسخه مربوط به اون رو مشخص می‌کنیم.
  • مثلاً:
    • agp = “8.8.0”: نسخه پلاگین Android Gradle Plugin.
    • kotlin = “2.0.0”: نسخه کاتلین.
    • coreKtx = “1.15.0”: نسخه کتابخونه androidx.core:core-ktx.

چرا مهمه؟

  • با این کار، اگه بخوای نسخه یه کتابخونه رو تغییر بدی، فقط کافیه اینجا نسخه رو به‌روزرسانی کنی و این تغییر توی کل پروژه اعمال می‌شه.
  • پروژه مرتب‌تر و قابل مدیریت‌تر می‌شه.

۲. [libraries]: تعریف کتابخونه‌ها

این بخش برای تعریف وابستگی‌های پروژه استفاده می‌شه. هر کتابخونه با مشخصات کاملش (شامل گروه، نام، و نسخه) اینجا تعریف می‌شه.

[libraries]

androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "coreKtx" }

junit = { group = "junit", name = "junit", version.ref = "junit" }

androidx-junit = { group = "androidx.test.ext", name = "junit", version.ref = "junitVersion" }

androidx-espresso-core = { group = "androidx.test.espresso", name = "espresso-core", version.ref = "espressoCore" }

androidx-lifecycle-runtime-ktx = { group = "androidx.lifecycle", name = "lifecycle-runtime-ktx", version.ref = "lifecycleRuntimeKtx" }

androidx-activity-compose = { group = "androidx.activity", name = "activity-compose", version.ref = "activityCompose" }

androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "composeBom" }

   

چی کار می‌کنه؟

  • اینجا کتابخونه‌ها با جزئیات کاملشون تعریف می‌شن:
    • group: گروه کتابخونه (مثل androidx.core).
    • name: نام کتابخونه (مثل core-ktx).
    • version.ref: نسخه کتابخونه که به یکی از کلیدهای تعریف‌شده در [versions] ارجاع داده می‌شه.
  • مثلاً:
    • androidx-core-ktx: با نسخه مشخص‌شده در [versions] (اینجا coreKtx = “1.15.0”) استفاده می‌شه.
    • junit: با نسخه junit = “4.13.2”.

چرا مهمه؟

  • کل وابستگی‌های پروژه توی یه بخش تعریف می‌شن و هر وقت بخوای وابستگی جدید اضافه کنی یا تغییر بدی، فقط کافیه اینجا تغییرات رو انجام بدی.
  • با ارجاع به [versions]، تغییر نسخه‌ها خیلی راحت می‌شه.

۳. [plugins]: تعریف پلاگین‌ها

این بخش برای تعریف پلاگین‌های مورد استفاده در پروژه استفاده می‌شه.

     

[plugins]

android-application = { id = "com.android.application", version.ref = "agp" }

kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }

kotlin-compose = { id = "org.jetbrains.kotlin.plugin.compose", version.ref = "kotlin" }

چی کار می‌کنه؟

  • اینجا پلاگین‌هایی که پروژه نیاز داره، با مشخصاتشون تعریف می‌شن:
    • id: شناسه پلاگین (مثل com.android.application یا org.jetbrains.kotlin.android).
    • version.ref: نسخه پلاگین که به یکی از کلیدهای [versions] ارجاع داده می‌شه.
  • مثلاً:
    • android-application: نسخه‌اش از [versions] با کلید agp خونده می‌شه.
    • kotlin-android: نسخه‌اش از [versions] با کلید kotlin خونده می‌شه.

چرا مهمه؟

  • بهت اجازه می‌ده پلاگین‌های پروژه رو یه‌جا مدیریت کنی.
  • تغییر نسخه پلاگین‌ها راحت‌تر می‌شه.

چرا این فایل مهمه؟

  1. مرکزیت و نظم: همه نسخه‌ها، کتابخونه‌ها، و پلاگین‌ها توی یه فایل متمرکز هستن.
  2. مدیریت راحت‌تر: تغییر نسخه کتابخونه‌ها یا پلاگین‌ها خیلی راحت‌تر می‌شه.
  3. جلوگیری از تکرار: نیازی نیست توی هر ماژول نسخه‌ها رو دوباره‌نویسی کنی؛ فقط یه بار اینجا تعریفشون می‌کنی.

جمع‌بندی به زبان ساده

  • [versions]: نسخه کتابخونه‌ها و پلاگین‌ها اینجا تعریف می‌شن.
  • [libraries]: کتابخونه‌ها با مشخصات کاملشون (گروه، نام، نسخه) اینجا تعریف می‌شن.
  • [plugins]: پلاگین‌های پروژه با شناسه و نسخه اینجا تعریف می‌شن.

این فایل باعث می‌شه همه چیز مرتب، متمرکز و قابل مدیریت باشه. 😊

 

این فایل مخصوص تنظیمات سیستم خودت هست و نباید توی سیستم کنترل نسخه (مثل Git) ثبت بشه. این فایل شامل اطلاعاتی هست که فقط روی کامپیوتر شخصی تو معتبره و تنظیمات کلی پروژه رو تحت تأثیر قرار نمی‌ده.

توضیحات فایل

۱. توضیحات کلی:

          

## This file is automatically generated by Android Studio.

# Do not modify this file -- YOUR CHANGES WILL BE ERASED!

#

# This file should *NOT* be checked into Version Control Systems,

# as it contains information specific to your local configuration.```

این توضیحات می‌گه:

– این فایل توسط Android Studio تولید شده.

– نباید این فایل رو تغییر بدی، چون تغییراتت پاک می‌شه.

– این فایل نباید توی سیستم کنترل نسخه (مثل Git) ثبت بشه، چون حاوی اطلاعات شخصی و محلیه.

 

 

۲. تنظیم مسیر SDK اندروید:

# Location of the SDK. This is only used by Gradle.

# For customization when using a Version Control System, please read the

# header note.

sdk.dir=H\:\\Android\\sdk

این خط مهم‌ترین قسمت این فایله.

  • sdk.dir: این خط مسیر نصب Android SDK (Android Software Development Kit) رو مشخص می‌کنه.
  • H\:\\Android\\sdk: مسیر SDK روی کامپیوتر شما (مثال). این مسیر بستگی به جایی داره که SDK رو نصب کردی.

چرا این فایل مهمه؟

  1. تنظیمات محلی: شامل تنظیماتی هست که فقط برای کامپیوتر شخصی تو معتبره.
  2. مسیر SDK: به Gradle کمک می‌کنه که SDK اندروید رو پیدا کنه.
  3. عدم نیاز به اشتراک‌گذاری: نیازی نیست این فایل رو با هم‌تیمی‌هات به اشتراک بذاری.

چطور استفاده کنیم؟

  • Android Studio این فایل رو به‌صورت خودکار ایجاد می‌کنه.
  • اگه مسیر SDK رو تغییر دادی، باید این فایل رو ویرایش کنی و مسیر جدید رو وارد کنی.

جمع‌بندی به زبان ساده

  • local.properties فایل تنظیمات محلی کامپیوتر توئه.
  • مهم‌ترین بخشش، مسیر نصب Android SDK رو مشخص می‌کنه.
  • نیازی نیست این فایل رو توی سیستم کنترل نسخه ثبت کنی. 😊
 

این فایل نقش اصلی رو در مدیریت ساختار پروژه Gradle ایفا می‌کنه. این فایل تعیین می‌کنه که پروژه شامل چه ماژول‌هایی هست و چطور این ماژول‌ها با هم در ارتباط هستن. به عبارت دیگه، این فایل “نقشه” پروژه شماست.

نکته
اگه میخوای بدونی که چرا در این جا خط کد مایکت اضافه شده این مطلب رو بخون :تحریم های اندروید استودیو و 3 راهکار دور زدن

توضیحات خط به خط کدهای فایل

۱. pluginManagement { … }: مدیریت پلاگین‌ها

این بخش برای مدیریت پلاگین‌های Gradle استفاده می‌شه.

pluginManagement {

    repositories {

        google {

            content {

                includeGroupByRegex("com\\.android.*")

                includeGroupByRegex("com\\.google.*")

                includeGroupByRegex("androidx.*")

            }

        }

        mavenCentral()

        gradlePluginPortal()

        maven{url = uri("https://maven.myket.ir")}

    }

}

  • repositories { … }: اینجا مخازن (repositories) برای دانلود پلاگین‌ها مشخص می‌شن.
    • google { … }: مخزن Google برای پلاگین‌ها و کتابخانه‌های Android.
      • content { … }: فیلترهایی برای محدود کردن محتوای دانلود شده از گوگل.
        • includeGroupByRegex(…): این خطوط مشخص می‌کنن که از این مخزن، پلاگین‌ها و کتابخانه‌هایی با نام‌های شروع شده با عبارت‌های منظم (regex) com.android.*, com.google.*, و androidx.* دانلود بشن.
    • mavenCentral(): مخزن مرکزی Maven.
    • gradlePluginPortal(): مخزن رسمی پلاگین‌های Gradle.
    • maven{url = uri(“https://maven.myket.ir”)}: اضافه شدن یک مخزن سفارشی (myket.ir).

چرا این بخش مهمه؟

  • این بخش به Gradle می‌گه که از کجا پلاگین‌ها رو دانلود کنه (مثل Android Gradle Plugin).
  • مدیریت پلاگین‌ها رو متمرکز می‌کنه.

۲. dependencyResolutionManagement { … }: مدیریت وابستگی‌ها

این بخش برای مدیریت کتابخانه‌ها و وابستگی‌های پروژه (dependencies) استفاده می‌شه.

 

dependencyResolutionManagement {

    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)

    repositories {

        google()

        mavenCentral()

        maven{url = uri("https://maven.myket.ir")}

    }

}

   

  • repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS): این خط مشخص می‌کنه که اگه یه وابستگی توی مخازن پروژه پیدا نشد، ساخت پروژه با خطا متوقف بشه.
  • repositories { … }: اینجا مخازن (repositories) برای دانلود وابستگی‌ها مشخص می‌شن.
    • google(): مخزن Google.
    • mavenCentral(): مخزن مرکزی Maven.
    • maven{url = uri(“https://maven.myket.ir”)}: اضافه شدن مخزن سفارشی (myket.ir).

چرا این بخش مهمه؟

  • این بخش به Gradle می‌گه که از کجا کتابخانه‌ها و وابستگی‌های پروژه رو دانلود کنه.
  • مدیریت وابستگی‌ها رو متمرکز می‌کنه.

۳. rootProject.name = “Train Navigation”: نام پروژه

rootProject.name = "Train Navigation"
  • rootProject.name: اسم پروژه Gradle رو مشخص می‌کنه.
  • “Learn git”: نام پروژه در اینجا “Train Navigation” هست.

چرا این بخش مهمه؟

  • این اسم، اسم پروژه رو برای Gradle و محیط توسعه (IDE) مشخص می‌کنه.

۴. include(“:app”) و include(“:app:hello”): تعریف ماژول‌ها

include(":app")

include(":app:hello")
  • include(…): این تابع، ماژول‌های پروژه رو تعریف می‌کنه.
  • “:app”: این خط، ماژول اصلی اپلیکیشن (معمولاً شامل کد و منابع اپلیکیشن) رو به پروژه اضافه می‌کنه. – “:app:hello”: این خط، ماژول فرعی یا زیر-ماژول “hello” رو به پروژه اضافه می‌کنه. این ماژول می‌تونه شامل کد یا منابع خاصی باشه (مثلاً یه ماژول برای تست یا یه کتابخونه).

چرا این بخش مهمه؟

  • این خطوط به Gradle می‌گن که چه ماژول‌هایی در پروژه وجود دارن.
  • Gradle از این اطلاعات برای ساخت پروژه استفاده می‌کنه.

جمع‌بندی به زبان ساده

  • این فایل “نقشه” پروژه Gradle شماست.
  • مشخص می‌کنه که از کجا پلاگین‌ها و کتابخونه‌ها دانلود بشن.
  • اسم پروژه رو تعیین می‌کنه.
  • ماژول‌های پروژه (مثل app) رو تعریف می‌کنه.

بسیار خب ، در این اموزش خیلی ساده و خودمونی ، مبحث گردل در اندروید استودیو رو بررسی کردیم ، درمورد دستور های که میشه ، این گردل رو سفارشی کرد ، صحبت نکردم ، ان شاء الله در مبحث های بعدی به این مورد میپردازیم .

امیدوارم که این اموزش براتون مفید واقع بشه و هر موقع اسم گردل در اندروید استودیو رو شنیدید ، نترسید 😁 ، با آموزش  منظم  ، هیچ چیزی سخت نیست . ✨

موفق باشید 🥰

دیدگاه‌ها ۰
ارسال دیدگاه جدید