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

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

חשוב לעקוב אחרי שינויים כאלה, ויש כמה כלים לשדרוג יחסי תלות שיכולים לעזור.

יחסי תלות ב-build

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

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

קוד מקור

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

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

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

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

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

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

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

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

כלים

היקפי הרשאות של Gradle

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

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

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

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

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

dependencies {
    implementation(libs.example.library)
}

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

dependencies {
    implementation libs.example.library
}