הביצועים ב-Wear OS הם שיקול חשוב באפליקציות, כי למכשירים רבים עם Wear OS יש משאבי CPU ו-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 למדידות
מצב ניפוי הבאגים שימושי לזיהוי בעיות רבות, אבל הוא כרוך בפגיעה משמעותית בביצועים, לא משתמש בפרופילים של קו בסיס ויכול להקשות על זיהוי בעיות בקוד שעלולות להשפיע על הביצועים.
כדי להבין בצורה מדויקת את הביצועים של האפליקציה, צריך להריץ אותה במצב הפצה.
אפשר להסיק מסקנות סופיות לגבי הביצועים רק מבדיקות שבוצעו באפליקציות שפועלות עם אפשרויות של גרסת ייצור ובמכשירים אמיתיים.
עם זאת, כשמבצעים בדיקות השוואה, צריך להשתמש בווריאנט של בניית ההשוואה, שיש בו כמה הבדלים חשובים לעומת ניפוי באגים בגרסת ההפצה. פרטים נוספים זמינים במדריך להגדרת 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 הזה כדי להשוות בין חלקים נפרדים של ממשק המשתמש כשבודקים את תהליכי המשתמשים כדי לזהות הזדמנויות לאופטימיזציה.
בדיקות השוואה
בבדיקות מאקרו נבדקים תרחישי שימוש גדולים יותר באפליקציה, במיוחד הפעלה של האפליקציה ומניפולציות מורכבות בממשק המשתמש. כדי להתחיל, אפשר לעיין במדריך ההטמעה.
דוגמה לשימוש במבחני ביצועים רחבים כדי לאמת את הביצועים של פרופילי Baseline מופיעה בדוגמאות לביצועים ב-GitHub.
ספריית JankStats
אפשר להשתמש בספריית JankStats כדי לעקוב אחרי בעיות ביצועים באפליקציות ולנתח אותן.
לדוגמה, אפשר לעיין בדוגמה של JankStats ב-GitHub.
איסוף עקבות המערכת
עם סוגי האנימציה החדשים שהוצגו ב-Material 3 Expressive, אפשר להשתמש בתכונה System Trace ב-Android Studio כדי לבדוק ולזהות בעיות של זמן אחזור בתהליכים שעוברים המשתמשים, שעלולים להיות בעייתיים. בעזרת המידע הזה, תוכלו לאמת את התוכן של פרופילי הבסיס ולזהות חוסר יעילות פוטנציאלי בלוגיקה של הקוד.
כלים נוספים
בנוסף לכלים לשיפור הביצועים, אפשר להשתמש בכלים אחרים כדי לשפר את הפרודוקטיביות ואת תהליך העבודה.
כלים לשיפור הפרודוקטיביות ב-Android Studio
ב-Android Studio יש כמה כלים שיכולים לעזור לכם לצמצם את הזמן שאתם משקיעים בזיהוי שיפורים בביצועים.
לדוגמה, באמצעות כלים כמו עריכה בזמן אמת ותצוגות מקדימות של קומפוננטות, תוכלו לזהות רכיבי ממשק משתמש לא חלקים, יחד עם האזורים המשויכים בקוד של האפליקציה, כדי לשפר את הביצועים.
מריצים את כל בדיקות הביצועים הסופיות על חבילה של מכשירי Wear OS פיזיים שמייצגים בצורה מדויקת את בסיס המשתמשים המטורגט.
זה חשוב במיוחד כשעוברים ל-Material 3 Expressive, שכולל תכונות כמו גופנים גמישים ושינוי צורה של אלמנטים באפליקציה.
אם אתם מבצעים העברה מתצוגות, כדאי לעיין במדריך ההעברה ובשיטות המומלצות לשיפור הביצועים של Jetpack Compose כדי לוודא שהממשקי המשתמש של האפליקציה פועלים בצורה יעילה כשמשתמשים ב-Jetpack Compose.
מקורות מידע נוספים
כדי להתעדכן בחדשות האחרונות בנושא ביצועים ב-Android, אפשר לעיין בחדשות ובסרטונים האחרונים במדריך לביצועי האפליקציה.