אם נתקלת בבעיות בביצועים הנובעות משימוש הרכבה מחדש מוגזמת, עליכם לנפות באגים ביציבות של האפליקציה. המדריך הזה שלנו מפורטות כמה שיטות לעשות זאת.
הכלי לבדיקת פריסות
הכלי לבדיקת הפריסה ב-Android Studio מאפשר לראות אילו תכנים קומפוזביליים כתיבה מחדש באפליקציה שלכם. מוצגת ספירה של מספר הפעמים שפיתוח נייטיב הכינו מחדש רכיב או דילגתם עליו.
כתיבת דוחות מהדר
המהדר של Composer יכול להפיק את התוצאות של מסקנות היציבות שלו בדיקה. באמצעות הפלט הזה אפשר לקבוע אילו תכנים קומפוזביליים שניתן לדלג עליהן, ואילו לא. סעיפי המשנה הבאים מסכמים את אופן השימוש אבל כדי לקבל מידע מפורט יותר אפשר לעיין בקטע הטכני תיעוד.
הגדרה
כברירת מחדל, דוחות הידור לכתיבה לא מופעלים. אפשר להפעיל אותן באמצעות
דגל מהדר (compiler) ההגדרה המדויקת משתנה בהתאם
לפרויקט, אבל בפרויקטים שמשתמשים בבפלאגין ליצירת מהדר (compiler) gradle תוכלו
יש להוסיף את הנתונים הבאים בכל קובץ build.gradle
של המודולים.
android { ... }
composeCompiler {
reportsDestination = layout.buildDirectory.dir("compose_compiler")
metricsDestination = layout.buildDirectory.dir("compose_compiler")
}
מעכשיו, המערכת תיצור דוחות מהדר (compiler) בזמן בניית הפרויקט.
פלט לדוגמה
בפלט של reportsDestination
נוצר שלושה קבצים. אלה דוגמאות לפלט
מ-JetSnack.
<modulename>-classes.txt
: דוח על היציבות של הכיתות כאן של מודל טרנספורמר. דוגמה.<modulename>-composables.txt
: דוח שמסביר איך ניתן להפעיל מחדש של התכנים הקומפוזביליים שניתן לדלג עליהן נמצאים במודול. דוגמה.<modulename>-composables.csv
:גרסתCSV
של דוח התוכן הקומפוזבילי שאפשר לייבא לגיליון אלקטרוני או לעבד באמצעות סקריפט. דוגמה
דוח על תכנים קומפוזביליים
הקובץ composables.txt
מפרט כל פונקציות קומפוזביליות של הערך הנתון
כולל היציבות של הפרמטרים שלהם, ואם הם
שאפשר להפעיל מחדש או לדלג עליהן. הדוגמה הבאה היא
JetSnack:
restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun SnackCollection(
stable snackCollection: SnackCollection
stable onSnackClick: Function1<Long, Unit>
stable modifier: Modifier? = @static Companion
stable index: Int = @static 0
stable highlight: Boolean = @static true
)
ניתן להפעיל מחדש את התוכן הקומפוזבילי הזה מסוג SnackCollection
, שניתן לדלג עליו וגם
יציבה. בדרך כלל האפשרות הזו עדיפה, אם כי אינה חובה.
לעומת זאת, נבחן דוגמה אחרת.
restartable scheme("[androidx.compose.ui.UiComposable]") fun HighlightedSnacks(
stable index: Int
unstable snacks: List<Snack>
stable onSnackClick: Function1<Long, Unit>
stable modifier: Modifier? = @static Companion
)
לא ניתן לדלג על התוכן הקומפוזבילי HighlightedSnacks
. הכתיבה לא מדלגת עליה
במהלך ההרכבה. הפעולה הזו מתרחשת גם אם אף אחד מהפרמטרים לא השתנה.
הסיבה לכך היא הפרמטר unstable
, snacks
.
הדוח 'כיתות'
הקובץ classes.txt
מכיל דוח דומה על הכיתות בטבלה הנתונה
של מודל טרנספורמר. קטע הקוד הבא הוא הפלט של הכיתה Snack
:
unstable class Snack {
stable val id: Long
stable val name: String
stable val imageUrl: String
stable val price: Long
stable val tagline: String
unstable val tags: Set<String>
<runtime stability> = Unstable
}
לידיעתך, זו ההגדרה של Snack
:
data class Snack(
val id: Long,
val name: String,
val imageUrl: String,
val price: Long,
val tagline: String = "",
val tags: Set<String> = emptySet()
)
המהדר של Composer סימן את Snack
כלא יציב. הסיבה לכך היא שסוג
הפרמטר tags
הוא Set<String>
. זה סוג שלא ניתן לשינוי, כי הוא
אינו MutableSet
. עם זאת, סוגי איסוף רגילים כמו Set, List
,
ו-Map
הם בסופו של דבר ממשקים. לכן, ההטמעה הבסיסית עשויה
עדיין יהיו ניתנות לשינוי.
לדוגמה, אפשר לכתוב val set: Set<String> = mutableSetOf("foo")
.
הוא קבוע והסוג המוצהר שלו לא ניתן לשינוי, אבל
עדיין ניתן לשנות את ההטמעה שלו. מהדר ה-Composer לא יכול להיות בטוח
ולא ניתנים לשינוי של המחלקה הזאת, כי היא רואה רק את הסוג המוצהר. לכן היא מסמנת
tags
לא יציב.