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