הביצועים ב-Wear OS הם שיקול חשוב מאוד לאפליקציות, כי למכשירים רבים עם Wear OS יש משאבי מעבד ו-GPU מוגבלים בהשוואה למכשירים ניידים גדולים יותר. עם ההשקה של Material 3 Expressive, שכולל אנימציות עשירות יותר ואפקטים דינמיים, כדאי לבדוק ולשפר את הביצועים של תהליכי העבודה העיקריים באפליקציה.
כדי להגדיר ולפתח את האפליקציה לביצועים אופטימליים באמצעות Jetpack Compose, אפשר להיעזר במדריך ביצועים ב-Jetpack Compose. במסמך הזה אנחנו מדגישים כמה מהטכניקות שמתוארות במדריך הזה.
כדאי ליצור אסטרטגיות למדידת ביצועים ולפעול לפיהן כדי לוודא שהטכניקות האלה פועלות כמצופה באפליקציה שלכם.
טכניקות חיוניות לשיפור הביצועים
כדאי להתחיל עם הסוגים הכי יעילים של כלים לשיפור הביצועים: פרופילים של Baseline (כולל פרופילים של הפעלה) והכלי R8 לאופטימיזציה של קוד.
צריך לעדכן את התלות ב-Compose לגרסה 1.8 ואילך, שבה הוספנו כמה תכונות חדשות וחשובות ושיפרנו את היציבות הכוללת של הספרייה. הוראות לעדכון מופיעות במאמר הצהרת תלות. מידע נוסף מופיע בפוסט בבלוג על גרסה 1.8 ובשיחה What's New in Compose ב-I/O.
פרופילים של Baseline
כדי לשפר את ביצועי האפליקציה, אפשר להשתמש בפרופילים של Baseline. כדאי לקבץ את המחלקות והשיטות שמייצגות את תהליכי העבודה העיקריים באפליקציה, שהמערכת יכולה לבצע להם קומפילציה מראש באמצעות פרופיל בסיסי. הפעולה הזו יכולה לקצר את זמני ההפעלה, לצמצם את מספר הפריימים המגומגמים ולשפר את הביצועים.
כל ספרייה של Jetpack Compose מגיעה עם כללי פרופיל משלה. כשהאפליקציה שלכם תלויה בספרייה, כללי הפרופיל של הספרייה משולבים ומפוזרים אוטומטית עם קובץ ה-APK של האפליקציה לצורך קומפילציה מראש.
כדי לאמת את פרופילי הבסיס, אפשר להשתמש בטכניקות הבאות:
- שימוש בבדיקות מאקרו.
- אפשר להשתמש בפקודות ADB ספציפיות כדי לאמת את מצב ההגדרה של הפרופיל באפליקציה. הסבר על השלבים של שתי השיטות האלה מופיע במדריך בנושא מדידה ואימות של ביצועים.
פרופילים של חברות סטארט-אפ
פרופילים להפעלה הם קבוצת משנה של פרופילים של Baseline, והם מאפשרים לבצע אופטימיזציה נוספת של המחלקות והשיטות שהם מכילים כדי לצמצם את זמן האחזור של הפעלת האפליקציה.
הוספת פרופיל הפעלה תגדיל את גודל ה-APK של האפליקציה, לכן לפני שמוסיפים פרופיל כזה לגרסת הייצור, חשוב להעריך את האיזון בין גודל ה-APK לבין זמן האחזור של ההפעלה.
כדי להתחיל, קוראים את המאמר יצירת פרופיל סטארט-אפ.
R8
כדי לצמצם את גודל האפליקציות ולבצע אופטימיזציה שלהן, אפשר להשתמש בקומפיילר R8. R8 מסיר קוד ומשאבים שלא בשימוש, משכתב קוד כדי לבצע אופטימיזציה של ביצועי זמן הריצה ועוד.
במדריכים בנושא שיפור הביצועים – סקירה כללית, כדאי לקרוא את ההמלצות לגבי R8, כולל השלבים העיקריים להסרת משאבים שלא נעשה בהם שימוש.
מדידת ביצועים ואימות
במאמר סקירה כללית של מדידת הביצועים של אפליקציות מוסבר על אסטרטגיות כלליות למדידת הביצועים ב-Android. בקטע הזה מתוארות כמה מהטכניקות שמוזכרות במסמכי התיעוד האלה.
בחירת וריאנט build למדידות
מצב ניפוי הבאגים אמנם שימושי לזיהוי בעיות רבות, אבל הוא כרוך בעלויות ביצועים משמעותיות, לא משתמש בפרופילים של קו בסיס ויכול להקשות על זיהוי בעיות בקוד שעשויות להשפיע על הביצועים.
כדי להבין בצורה מדויקת את הביצועים של האפליקציה, מריצים אותה במצב הפצה.
אפשר להסיק מסקנות סופיות לגבי הביצועים רק מבדיקות שבוצעו באפליקציות שפועלות עם אפשרויות של גרסת הפצה ובמכשירים אמיתיים.
עם זאת, כשמבצעים בדיקות השוואה, צריך להשתמש בווריאנט build של נקודת ההשוואה, שיש בו כמה הבדלים משמעותיים לעומת ניפוי באגים בגרסת הפצה. פרטים נוספים זמינים במדריך להגדרת בדיקות מאקרו.
אימות פרופילי הבסיס של האפליקציה
מתחילים בבדיקת הסטטוס של הפרופיל:
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
בדיקות מאקרו הן בדיקות של תרחישי שימוש גדולים יותר באפליקציה, במיוחד הפעלה של האפליקציה ומניפולציות מורכבות בממשק המשתמש. כדי להתחיל, אפשר לעיין במדריך ההטמעה.
דוגמה לשימוש במבחני ביצועים רחבים כדי לאמת את הביצועים של פרופילי Baseline מופיעה בדוגמאות לביצועים ב-GitHub.
JankStats Library
אפשר להשתמש בספריית JankStats כדי לעקוב אחרי בעיות בביצועים של אפליקציות ולנתח אותן.
לדוגמה, אפשר לעיין בדוגמה של JankStats ב-GitHub.
איסוף עקבות המערכת
עם סוגי האנימציה החדשים שהושקו ב-Material 3 Expressive, אפשר להשתמש בתכונה System Trace ב-Android Studio כדי לבדוק את זמן האחזור ולזהות בעיות פוטנציאליות בתהליכי משתמש. בעזרת המידע הזה, תוכלו לאמת את התוכן של פרופילי הבסיס ולזהות חוסר יעילות פוטנציאלי בלוגיקה של הקוד.
כלים נוספים
בנוסף לכלים לשיפור הביצועים, אפשר להשתמש בכלים אחרים כדי לשפר את הפרודוקטיביות ואת תהליך העבודה.
כלים לשיפור הפרודוקטיביות ב-Android Studio
ב-Android Studio יש כמה כלים שיכולים לעזור לכם לצמצם את הזמן שאתם משקיעים בזיהוי שיפורים בביצועים.
לדוגמה, בעזרת כלים כמו Live Edit ותצוגות מקדימות של קומפוננטות, תוכלו לזהות רכיבי ממשק משתמש לא חלקים, וגם את האזורים שקשורים אליהם בקוד של האפליקציה, כדי לשפר את הביצועים.
מריצים את כל בדיקות הביצועים הסופיות על חבילה של מכשירי Wear OS פיזיים שמייצגים בצורה מדויקת את בסיס המשתמשים המטורגט.
זה חשוב במיוחד כשעוברים ל-Material 3 Expressive, שכולל תכונות כמו גופנים גמישים ושינוי צורה של אלמנטים באפליקציה.
אם אתם מבצעים מיגרציה מתצוגות, כדאי לעיין במדריך המיגרציה ובשיטות המומלצות לשיפור הביצועים של Jetpack Compose כדי לוודא שממשקי המשתמש של האפליקציה פועלים בצורה יעילה כשמשתמשים ב-Jetpack Compose.
משאבים אחרים
כדי להתעדכן בחדשות האחרונות בנושא ביצועים ב-Android, אפשר לעיין בחדשות וסרטונים אחרונים במדריך לביצועי האפליקציה.