הביצועים ב-Wear OS הם שיקול חשוב מאוד לאפליקציות, כי למכשירים רבים עם Wear OS יש משאבי CPU ו-GPU מוגבלים בהשוואה למכשירים ניידים גדולים יותר. עם ההשקה של Material 3 Expressive, שכולל אנימציות עשירות יותר ואפקטים דינמיים, כדאי לבדוק ולשפר את הביצועים של תהליכי העבודה העיקריים באפליקציה.
כדי להגדיר ולפתח את האפליקציה לביצועים אופטימליים באמצעות Jetpack פיתוח נייטיב, אפשר להיעזר במדריך ביצועים ב-Jetpack פיתוח נייטיב. במסמך הזה אנחנו מדגישים כמה מהטכניקות שמתוארות במדריך הזה.
כדאי ליצור אסטרטגיות למדידת ביצועים ולפעול לפיהן כדי לוודא שהטכניקות האלה פועלות כמצופה באפליקציה שלכם.
טכניקות חיוניות לשיפור הביצועים
כדאי להתחיל עם הסוגים הכי יעילים של כלים לשיפור הביצועים: פרופילים של 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 הזה כדי להשוות בין חלקים נפרדים של ממשק המשתמש כשבודקים את התהליכים שהמשתמשים עוברים כדי לזהות הזדמנויות לאופטימיזציה.
בדיקות מאקרו
בבדיקות מאקרו בוחנים תרחישי שימוש גדולים יותר באפליקציה, במיוחד הפעלה של האפליקציה ומניפולציות מורכבות בממשק המשתמש. כדי להתחיל, אפשר לעיין במדריך ההטמעה.
דוגמה לשימוש במבחני ביצועים רחבים כדי לאמת את הביצועים של פרופילים בסיסיים מופיעה בדוגמאות לביצועים ב-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, אפשר לעיין בחדשות ובסרטונים האחרונים במדריך לביצועי האפליקציה.