הביצועים ב-Wear OS הם שיקול חיוני לאפליקציות, כי למכשירי Wear OS רבים יש משאבי מעבד ו-GPU מוגבלים בהשוואה למכשירים ניידים גדולים יותר. ב-Material 3 Expressive יש אנימציות עשירות יותר ואפקטים דינמיים, לכן כדאי לבדוק ולשפר את הביצועים של תהליכי העבודה העיקריים באפליקציה.
כדי להגדיר ולפתח את האפליקציה לביצועים אופטימליים באמצעות Jetpack Compose, אפשר להיעזר במדריך Jetpack Compose Performance. במסמך הזה מודגשות חלק מהשיטות שמתוארות במדריך.
כדי לוודא שהשיטות האלה פועלות כמצופה באפליקציה, כדאי ליצור אסטרטגיות למדידת ביצועים ולפעול לפיהן.
שיטות חיוניות לשיפור הביצועים
כדאי להתחיל עם סוגי הכלים היעילים ביותר לשיפור הביצועים: פרופילי Baseline (כולל פרופילים להפעלה) והכלי R8 לאופטימיזציה של קוד.
מעדכנים את התלות ב-Compose לגרסה 1.8 ואילך, שכוללת כמה תכונות חדשות וחשובות ומשפרת את היציבות הכללית של הספרייה. כדי לעדכן, אפשר להיעזר בהוראות שבמאמר הצהרה על יחסי תלות. מידע נוסף זמין בפוסט בבלוג שלנו על גרסה 1.8 ובשיחת I/O בנושא מה חדש ב-Compose.
פרופילים של Baseline
כדי לשפר את ביצועי האפליקציה, אפשר להשתמש בפרופילים של Baseline. מקבצים יחד את המחלקות והשיטות שמייצגות את תהליכי העבודה העיקריים של האפליקציה, שהמערכת יכולה לקמפל מראש באמצעות פרופיל בסיסי. הפעולה הזו יכולה לקצר את זמני ההפעלה, לצמצם את מספר הפריימים המקוטעים ולשפר את הביצועים בדרכים נוספות.
כל ספריית Jetpack Compose כוללת כללי פרופיל משלה. אם האפליקציה שלכם תלויה בספרייה, כללי הפרופיל של הספרייה מתמזגים באופן אוטומטי ומופצים עם ה-APK של האפליקציה לצורך הידור מראש.
כדי לאמת את פרופילי הבסיס, אפשר להשתמש בשיטות הבאות:
- להשתמש בבדיקות Macrobenchmark.
- משתמשים בפקודות ADB ספציפיות כדי לאמת את מצב ההגדרה של פרופיל האפליקציה. השלבים של שתי השיטות האלה מוסברים במדריך מדידה ואימות של ביצועים.
פרופילים להפעלה
פרופילים להפעלה הם קבוצת משנה של פרופילים של Baseline, והם מבצעים אופטימיזציה נוספת של המחלקות והשיטות שהם מכילים כדי לצמצם את זמן האחזור של הפעלת האפליקציה.
הוספה של פרופיל הפעלה תגדיל את קובץ ה-APK של האפליקציה, אז לפני שמוסיפים פרופיל כזה לגרסת הייצור, חשוב לבדוק את היתרונות והחסרונות של גודל ה-APK לעומת זמן האחזור של ההפעלה.
כדי להתחיל, קראו את המאמר יצירת פרופיל סטארט-אפ.
R8
משתמשים במהדר R8 כדי לכווץ אפליקציות ולבצע בהן אופטימיזציה. R8 מסיר קוד ומשאבים שלא בשימוש, משכתב קוד כדי לשפר את הביצועים בזמן הריצה ועוד.
במדריכים improve performance Overview, קראו את השיקולים לגבי R8, כולל שלבים עיקריים להסרת משאבים שלא בשימוש.
מדידת ביצועים ואימות
במאמר סקירה כללית על מדידת ביצועים של אפליקציות מוסבר על אסטרטגיות כלליות למדידת ביצועים ב-Android. בקטע הזה מתוארות חלק מהשיטות שמופיעות במסמכי התיעוד האלה.
בחירת וריאנט build למדידות
מצב ניפוי באגים שימושי לזיהוי בעיות רבות, אבל הוא פוגע באופן משמעותי בביצועים, לא משתמש בפרופילים בסיסיים ויכול להקשות על זיהוי בעיות בקוד שעלולות להשפיע על הביצועים.
כדי להבין במדויק את ביצועי האפליקציה, צריך להפעיל אותה במצב הפצה.
כדי להסיק מסקנות סופיות לגבי הביצועים, צריך להסתמך רק על בדיקות שבוצעו באפליקציות שפועלות עם אפשרויות של גרסת build להפצה ובמכשירים אמיתיים.
עם זאת, כשמבצעים בדיקת השוואה, צריך להשתמש בווריאנט ה-build להשוואה, שיש לו כמה הבדלים עיקריים מניפוי באגים בגרסה. פרטים נוספים זמינים במדריך להגדרת Macrobenchmark.
אימות פרופילי הבסיס של האפליקציה
קודם כל, בודקים את סטטוס הפרופיל:
adb shell dumpsys package dexopt | grep -A 1 $PACKAGE_NAME
אם הסטטוס הוא לא status=speed-profile, כללי הפרופיל עדיין לא הוחלו כדי לבצע אופטימיזציה של האפליקציה.
הכללים מופעלים באמצעות משימה ברקע שפועלת כשהמכשיר נטען ולא בשימוש. כדי להפעיל את זה באופן ידני, מריצים את הפקודה הבאה אחרי שהאפליקציה מופעלת ועובר מספיק זמן כדי שמתקין הפרופיל יאתחל את הפרופיל ברקע. התהליך הזה נמשך בדרך כלל כ-40 שניות.
adb shell cmd package bg-dexopt-job
לאחר מכן, מריצים מחדש את הפקודה הקודמת כדי לוודא שהסטטוס הוא speed-profile.
במצבים שבהם האופטימיזציה מתרחשת במהלך ההתקנה, אפשר לעיין במאמר בנושא טעינת פרופיל Baseline ממקורות לא מאושרים.
UI Automator API
UI Automator API מבצע אינטראקציות באופן פרוגרמטי. אפשר להשתמש ב-API הזה כדי להשוות בין חלקים נפרדים של ממשק המשתמש כשבודקים את התהליך שעובר המשתמש כדי למצוא אופטימיזציות פוטנציאליות.
בדיקות Macrobenchmark
בדיקות Macrobenchmark בודקות תרחישים לדוגמה גדולים יותר של האפליקציה, במיוחד הפעלה של האפליקציה ושינויים מורכבים בממשק המשתמש. כדי להתחיל, אפשר לעיין במדריך ההטמעה.
דוגמה לשימוש ב-Macrobenchmark כדי לאמת את הביצועים של פרופילי Baseline מופיעה בדוגמאות לביצועים ב-GitHub.
ספריית JankStats
אתם יכולים להשתמש בספריית JankStats כדי לעקוב אחרי בעיות בביצועים של אפליקציות ולנתח אותן.
לדוגמה, אפשר לעיין בדוגמה של JankStats ב-GitHub.
איסוף עקבות המערכת
ב-Material 3 Expressive יש סוגים חדשים של אנימציות. אתם יכולים להשתמש בתכונה עקבות המערכת ב-Android Studio כדי לבדוק ולאבחן את זמן האחזור בתהליכים שעוברים המשתמשים, שעלולים להיות בעייתיים. בעזרת המידע הזה, אתם יכולים לאמת את התוכן של פרופילי הבסיס ולזהות חוסר יעילות פוטנציאלי בלוגיקה של הקוד.
כלים נוספים
בנוסף לכלים לשיפור הביצועים, אתם יכולים להשתמש בכלים אחרים כדי לשפר את הפרודוקטיביות ואת תהליך העבודה.
כלים לשיפור הפרודוקטיביות ב-Android Studio
ב-Android Studio יש כמה כלים שיכולים לקצר את הזמן שאתם משקיעים בזיהוי שיפורים בביצועים.
לדוגמה, באמצעות כלים כמו עריכה בזמן אמת ותצוגות מקדימות של רכיבים, אתם יכולים לזהות רכיבים בממשק המשתמש שגורמים לבעיות, יחד עם האזורים המשויכים בקוד של האפליקציה, כדי לשפר את הביצועים.
מריצים את כל בדיקות הביצועים הסופיות על חבילה של מכשירי Wear OS פיזיים שמייצגים באופן מדויק את בסיס המשתמשים המטורגטים.
זה חשוב במיוחד כשעוברים ל-Material 3 Expressive, שכולל תכונות כמו גופנים גמישים ושינוי צורה באפליקציה.
אם אתם עוברים מתצוגות, כדאי לעיין במדריך להעברת נתונים (מיגרציה) ובשיטות המומלצות לביצועים של Jetpack Compose כדי לוודא שממשקי המשתמש של האפליקציה פועלים היטב כשמשתמשים ב-Jetpack Compose.
משאבים אחרים
כדי להתעדכן בחדשות האחרונות בנושא ביצועי Android, עיינו בקטע חדשות וסרטונים אחרונים במדריך לביצועי האפליקציה.