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

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

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

יחסי תלות ב-build

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

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

קוד מקור

קוד המקור הוא קוד 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

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
}