שיטות מומלצות לאופטימיזציה של אפליקציות

השיטות המומלצות הבאות יעזרו לכם לבצע אופטימיזציה של האפליקציה בלי להתפשר על האיכות.

שימוש בפרופילים של Baseline

פרופילים של Baseline יכולים לשפר את מהירות הרצת הקוד ב-30% מההפעלה הראשונה, ולשפר את כל האינטראקציות של המשתמשים – כמו הפעלת האפליקציה, מעבר בין מסכים או גלילה בתוכן – כבר מהפעם הראשונה שהם מפעילים את האפליקציה. הגברת המהירות ויכולת התגובה של האפליקציה מובילה ליותר משתמשים פעילים ביום (DAU) ולשיעור גבוה יותר של משתמשים שחוזרים לאפליקציה.

שימוש בפרופיל להפעלה

פרופיל הפעלה דומה לפרופיל Baseline, אבל הוא מופעל בזמן הקימפול כדי לבצע אופטימיזציה של פריסת ה-DEX להפעלה מהירה יותר של האפליקציה.

שימוש בספריית App Startup

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

טעינה עצלה של ספריות או השבתה של אתחול אוטומטי

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

שימוש במצב ברכיבים קומפוזביליים

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

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

var shouldLoad by remember {mutableStateOf(false)}

if (shouldLoad) {
   MyComposable()
}

טוענים את הרכיבים הקומפוזביליים בתוך הבלוק המותנה על ידי שינוי shouldLoad:

LaunchedEffect(Unit) {
   shouldLoad = true
}

הפעולה הזו מפעילה רה-קומפוזיציה שכוללת את הקוד בתוך בלוק התנאי בקטע הקוד הראשון. מידע נוסף מופיע במאמר בנושא State in composables.

אופטימיזציה של מסך הפתיחה

מסכי פתיחה הם חלק חשוב בהפעלת האפליקציה, ושימוש במסך פתיחה מעוצב היטב יכול לשפר את חוויית ההפעלה הכוללת של האפליקציה. ‫Android 12 (רמת API 31) ואילך כוללת מסך פתיחה שנועד לשפר את הביצועים. מידע נוסף זמין במאמר בנושא מסך פתיחה.

שימוש בסוגי תמונות שניתן לשנות את הגודל שלהן

מומלץ להשתמש בגרפיקה וקטורית לתמונות. אם אי אפשר, כדאי להשתמש בתמונות WebP. ‫WebP הוא פורמט תמונה שמספק דחיסת נתונים איכותית יותר מסוג lossless ו-lossy עבור תמונות באינטרנט. אפשר להמיר תמונות קיימות בפורמט BMP, ‏ JPG, ‏ PNG או GIF סטטי לפורמט WebP באמצעות Android Studio. מידע נוסף זמין במאמר יצירת תמונות WebP.

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

שימוש בממשקי API של ביצועים

‫API לביצועים של הפעלת מדיה זמין ב-Android 12 (רמת API‏ 31) ואילך. אתם יכולים להשתמש ב-API הזה כדי להבין את היכולות של המכשיר ולבצע פעולות בהתאם.

קביעת עדיפות למעקב אחר הפעלות במצב התחלתי (cold startup)

הפעלה במצב התחלתי מתייחסת להפעלה של אפליקציה מאפס, כלומר התהליך של המערכת עדיין לא יוצר את התהליך של האפליקציה. האפליקציה בדרך כלל מופעלת במצב התחלתי (cold start) אם מפעילים אותה בפעם הראשונה מאז שהמכשיר הופעל או מאז שהמערכת הפסיקה את האפליקציה בכוח. הפעלה במצב התחלתי איטית בהרבה כי האפליקציה והמערכת צריכות לבצע יותר פעולות שלא נדרשות בסוגי הפעלה אחרים – כמו הפעלה במצב ביניים (warm start) והפעלה מתוך הזיכרון (hot start). מעקב אחר המערכת הפעלות קרות מאפשר לכם לקבל תמונה טובה יותר של ביצועי האפליקציה.