כש-Compose מעדכן פריים, הוא עובר שלושה שלבים:
- קומפוזיציה: Compose קובע מה להציג. הוא מפעיל פונקציות קומפוזביליות ובונה את עץ ממשק המשתמש.
- פריסה: Compose קובע את הגודל והמיקום של כל רכיב בעץ ממשק המשתמש.
- ציור: Compose מעבד בפועל את רכיבי ממשק המשתמש הספציפיים.
התכונה 'יצירה' יכולה לדלג באופן חכם על שלבים שלא נדרשים. לדוגמה, נניח שרכיב גרפי יחיד מתחלף בין שני סמלים באותו גודל. מכיוון שהגודל של הרכיב הזה לא משתנה, ולא מתווספים או מוסרים רכיבים מעץ ממשק המשתמש, Compose יכול לדלג על שלבי הקומפוזיציה והפריסה ולצייר מחדש רק את הרכיב הזה.
עם זאת, טעויות בתכנות יכולות להקשות על Compose לדעת אילו שלבים אפשר לדלג עליהם בבטחה. במקרה כזה, Compose מריץ את כל שלושת השלבים, מה שעלול להאט את ממשק המשתמש. לכן, הרבה מהשיטות המומלצות לשיפור הביצועים נועדו לעזור ל-Compose לדלג על השלבים שהוא לא צריך לבצע.
מידע נוסף זמין במדריך בנושא שלבים ב-Jetpack Compose.
עקרונות כלליים
יש כמה עקרונות כלליים שכדאי לפעול לפיהם כדי לשפר את הביצועים באופן כללי:
- כדאי להוציא חישובים מפונקציות שאפשר להרכיב מהן פונקציות אחרות, אם אפשר. יכול להיות שיהיה צורך להפעיל מחדש פונקציות שניתנות להגדרה בכל פעם שממשק המשתמש משתנה. כל קוד שמוסיפים לרכיב הניתן להרכבה מופעל מחדש, ויכול להיות שבכל פריים של אנימציה. כדאי להגביל את הקוד של הרכיב הניתן להרכבה רק למה שנדרש לבניית ממשק המשתמש.
- כדאי לדחות את קריאות המצב כמה שיותר. אם מעבירים את קריאת המצב לרכיב צאצא שאפשר להרכיב או לשלב בשלב מאוחר יותר, אפשר לצמצם את ההרכבה מחדש או לדלג על שלב ההרכבה לחלוטין. כדי לעשות את זה, מעבירים פונקציות lambda במקום ערך המצב עבור מצב שמשתנה לעיתים קרובות, ומעדיפים שינויים מבוססי-lambda כשמעבירים מצב שמשתנה לעיתים קרובות. דוגמה לטכניקה הזו מופיעה בקטע הדחייה של פעולות קריאה ככל האפשר במאמר שיטות מומלצות.
מקורות מידע נוספים
- מדריך לביצועי האפליקציה: כאן תמצאו שיטות מומלצות, ספריות וכלים לשיפור הביצועים ב-Android.
- בדיקת הביצועים: בדיקת ביצועי האפליקציה.
- השוואה לשוק: השוואה של ביצועי האפליקציה לשוק.
- הפעלת האפליקציה: אופטימיזציה של הפעלת האפליקציה.
- פרופילים של Baseline: הסבר על פרופילים של Baseline.