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

יחסי התלות בבניית הם רכיבים חיצוניים שנדרשים כדי לבנות את הפרויקט בהצלחה. גרסת ה-build יכולה להיות תלויה בספריות, ביישומי פלאגין, בפרויקטים משניים, ב-SDK של Android, בכלים כמו מהדרים של 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 האלה עשויים להשתנות, גם בגרסאות שינוי או patch. ממשקי ה-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. ספריות רבות פועלות בהתאם לניהול גרסאות סמנטי, שיכול לעזור לכם להבין מתי הן תואמות (או לא) בזמן השדרוג.

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

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

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

כלים

גרדל	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 בגרסאות build של 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")
}

מגניב

// 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
}