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