יחסי תלות בין כלים וספריות

יחסי התלות ב-build הם רכיבים חיצוניים שנדרשים כדי לבנות את הפרויקט. גרסה זמינה לפריסה יכולה להיות תלויה בספריות, בפלאגינים ובפרויקטים משניים, ב-Android SDK, בכלים כמו Kotlin ומהדרים של Java, בסביבות פיתוח כמו Android Studio וב-Gradle עצמו.

כל יחסי תלות יכולים לדרוש יחסי תלות אחרים. אנחנו קוראים לקשרים האלה יחסי תלות טרנזיטיביים, והם יכולים להגדיל במהירות את מספר יחסי התלות הכוללים שבהם האפליקציה משתמשת. כשרוצים לשדרג יחסי תלות, בין שמדובר בספרייה, בכלי או ב-Android SDK, השדרוג יכול להתבצע באופן מדורג, ולשדרג יחסי תלות רבים אחרים.

בדרך כלל זה לא יגרום לבעיות, כי ספריות רבות פועלות לפי הסכמה שנקראת סמנטיקה של גרסאות. הספריות האלה מגבילות את סוגי השינויים שהן מבצעות כדי לספק תאימות לגרסאות הקודמות שלהן.

ניהול גרסאות סמנטי נעשה לפי הפורמט major.minor.patch. לדוגמה, במספר הגרסה 4.8.3, הערך 4 הוא גרסת major, הערך 8 הוא גרסת minor והערך 3 הוא המספר patch. כשהחלק major משתנה, יכול להיות שיהיו בספרייה שינויים משמעותיים ב-API או בהתנהגות. הדבר עשוי להשפיע על התנהגות ה-build או האפליקציה.

כשהחלקים minor (תכונות חדשות) או patch (תיקוני באגים) משתנים, מפתחי הספרייה מדווחים לכם שהספרייה עדיין תואמת ולא אמורה להשפיע על האפליקציה.

הערה: ייתכן שספריות מסוימות חושפות ממשקי API ניסיוניים או שצריך להביע הסכמה לשימוש בהם. ממשקי ה-API האלה עשויים להשתנות, גם בגרסאות משניות או בגרסאות תיקון. ממשקי ה-API האלה נועדו לאפשר למפתחים לנסות תכונות חדשות או שינויים ב-API ולשלוח משוב בזמן שהם עוברים תהליך יציבות. חשוב להשתמש ב-API האלה בזהירות, כי הם עשויים להשתנות ואז תצטרכו לשנות את הקוד שלכם בין השדרוגים ל-minor ול-patch.

יחסי תלות ב-build

גרסאות build של Android מכילות קשרים בין:

• קוד מקור – הקוד והמשאבים שיש לכם עליהם שליטה
• יחסי תלות בספריות – ספריות או מודולים חיצוניים שהפרויקט ופרויקטי המשנה כוללים בזמן ה-build
• כלים – קומפיילרים, יישומי פלאגין וערכות SDK שממירים את המקור לאפליקציה או לספרייה

איור 1. יצירת קשרים

קוד מקור

קוד המקור הוא קוד Kotlin או Java שכותבים באפליקציה או בספרייה. (פרטים על שימוש ב-C++‎ זמינים במאמר Android NDK).

קוד המקור תלוי בספריות (כולל ספריות של Kotlin ו-Java בסביבת זמן ריצה) וב-Android SDK, ונדרש לו המהדר המתאים של Kotlin או Java.

חלק מקוד המקור כולל הערות שדורשות עיבוד נוסף. לדוגמה, אם כותבים קוד של Jetpack Compose, מוסיפים הערות כמו @Composable שצריך לעבד באמצעות הפלאגין של קומפילטור Kotlin ב-Compose. הערות אחרות עשויות לעבור עיבוד על ידי Kotlin Symbol Processor‏ (KSP) או על ידי כלים נפרדים לעיבוד הערות.

יחסי תלות בספרייה

ספריות מכילות קוד בייט שנשלף כחלק מהאפליקציה. יכול להיות שמדובר בקובץ JAR של Java, בספריית Android (AAR) או בפרויקט משנה ב-build. ספריות רבות פועלות לפי Semantic Versioning, שעוזר להבין מתי הן נשארות תואמות (או לא) אחרי שדרוג.

ספריות יכולות להיות תלויות בספריות אחרות לצורך שימוש חוזר, שנקרא תלות טרנזיטיבית. כך מפחיתים את יחסי התלות שצריך לנהל באופן מפורש. מציינים את יחסי התלות שבהם משתמשים ישירות, ו-Gradle מושך אותם יחד עם יחסי התלות הטרנזיטיביים. חשוב לזכור שכאשר משדרגים את יחסי התלות הישירים, יכול להיות שהם ישדרגו את יחסי התלות הטרנזיטיביים.

לפעמים ספרייה עשויה לדרוש גרסאות מינימום של Android SDK בזמן ריצה (minSdk) או בזמן הידור (compileSdk). הדבר נדרש כשספרייה משתמשת בפונקציות שכלולות ב-Android SDK או בממשקי ה-JDK API שסופקו על ידו. הערך בפועל של minSdk באפליקציה הוא הערך הגבוה ביותר של minSdk שהאפליקציה מבקשת, ושל כל יחסי התלות הישירים והעקיפים שלה בספריות.

יכול להיות ששימוש בספריות מסוימות ידרוש שימוש בפלאגין ספציפי של Gradle. בדרך כלל, הפלאגינים האלה מתקינים מעבדי סמלים של Kotlin או מעבדי הערות אחרים שיוצרים קוד או משנים את הידור המקור כדי לתמוך בשימוש בתכונות הספרייה. לדוגמה, Jetpack Room כולל הערות ו-KSP שממיר אותן לקוד שנוצר כדי לאחזר ולשנות נתונים במסד נתונים. כדי להשתמש ב-Jetpack Compose, צריך לשנות את הפונקציות עם ההערות באמצעות הפלאגין של המהדר של Compose, כדי לקבוע איך ומתי הפונקציה הזו תופעל מחדש.

כלים

Gradle	Gradle הוא כלי ה-build שקורא את קובצי ה-build ויוצר את האפליקציה או הספרייה. הוא גם חושף ממשק API לפלאגינים כדי להרחיב את היכולות שלו. Gradle מפעיל כמה תהליכים במכונה וירטואלית אחת או יותר של Java, והיישומי הפלאגין של Java שלו קוראים לכלים של Java בתוך ה-JDK.
פלאגינים של Gradle	פלאגינים של Gradle מאפשרים להרחיב את Gradle על ידי הגדרת משימות והגדרות חדשות. החלת פלאגין על ה-build מאפשרת להשתמש ביכולות build ספציפיות, שמוגדרות כנתונים בסקריפטים של ה-build. לגרסאות build של Android, הפלאגין החשוב ביותר של Gradle הוא Android Gradle Plugin‏ (AGP).
מהדרים	המהדר של Kotlin או Java ממיר את קוד המקור לקוד בייטקס שניתן להריץ. המהדר של Kotlin חושף ממשק API של פלאגין שמאפשר להריץ ניתוח חיצוני ויצירת קוד ישירות בתוך המהדר, תוך גישה למבנה הקוד המנותח.
פלאגינים של קומפיילרים	פלאגינים של קומפילרים מבצעים ניתוח ויצירת קוד בתוך קומפילר Kotlin בזמן שהקומפילר של Kotlin מנתח את הקוד. הם מותקנים כשמחילים את הפלאגינים של Gradle על ה-build.
Android SDK	Android SDK מכיל את פלטפורמת Android וממשקי ה-API של Java לגרסה ספציפית של Android, ואת הכלים התואמים. הכלים האלה עוזרים לכם לנהל את ה-SDK, לפתח את האפליקציות שלכם ולתקשר עם מכשירי Android ולבצע בהם אמולציה. כל גרסה של Android SDK מספקת ממשקי API ספציפיים של Java שקוד המקור יכול לגשת אליהם, ותמיכה בהסרת סוכר לשימוש בממשקי ה-API האלה בגרסאות קודמות של Android.
JDK	ערכת הפיתוח של Java, שמכילה ספריות Java וקובצי הפעלה לצורך קומפילציה של קוד מקור Java והרצה של אפליקציות Java. יש כמה JDKs שמשפיעים על גרסאות build של Android. לפרטים נוספים, אפשר לעיין במאמר גרסאות Java ב-builds של Android.

היקפים של Gradle

Gradle מקבצ יחסי תלות בספריות להיקפים שונים (שנקראים הגדרות ב-Gradle API), ומאפשר לכם לציין קבוצות שונות של יחסי תלות בספריות לשימוש בחלקים שונים של ה-build. לדוגמה, סביר להניח שלא תרצו לכלול ספריות בדיקה כמו JUnit באפליקציה או בספרייה שפורסמו, אבל כן תרצו אותן כשאתם יוצרים ומפעילים את בדיקות היחידה. אפשר גם להשתמש בהיקפים כדי להוסיף מעבדי תוויות או תווים לניתוח הקוד.

לדוגמה, AGP מגדיר את ההיקפים implementation ו-api, שמאפשרים לציין אם יחסי התלות צריכים להיות חשופים למשתמשים בפרויקט המשנה. במאמר הגדרת יחסי תלות מוסבר על ההיקפים האלה ועל היקפים אחרים שמשמשים ב-build של Android.

מוסיפים יחסי תלות בספריות בבלוק dependencies של קובצי ה-build, כמחרוזות group:artifact:version:

Kotlin

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation("com.example:library1:1.2.3")
    api("com.example:library2:1.1.1")
}

Groovy

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation 'com.example:library1:1.2.3'
    api 'com.example:library2:1.1.1'
}

או בקטלוג גרסאות:

# Version catalog - gradle/libs.versions.toml
[versions]
exampleLib = "1.2.3"
examplePlugin = "2.3.4"

[libraries]
example-library = { group = "com.example", name = "library", version.ref = "exampleLib" }

[plugins]
example-plugin = { id = "com.example.plugin", version.ref = "examplePlugin" }

מציינים את המשתנים שנוצרו בקובצי ה-build:

Kotlin

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation(libs.example.library)
}

Groovy

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation libs.example.library
}