ביצועים של Jetpack פיתוח נייטיב ב-Wear OS

הביצועים ב-Wear OS הם שיקול חשוב מאוד לאפליקציות, כי למכשירים רבים עם Wear OS יש משאבי CPU ו-GPU מוגבלים בהשוואה למכשירים ניידים גדולים יותר. עם ההשקה של אנימציות עשירות יותר ואפקטים דינמיים ב-Material 3 Expressive, כדאי לאמת ולשפר את הביצועים של תהליכי העבודה העיקריים באפליקציה.

אפשר להשתמש במדריך ביצועים ב-Jetpack פיתוח נייטיב כדי להגדיר ולפתח את האפליקציה לביצועים אופטימליים באמצעות Jetpack פיתוח נייטיב. במסמך הזה אנחנו מדגישים כמה מהטכניקות שמתוארות במדריך הזה.

כדאי ליצור אסטרטגיות למדידת הביצועים ולפעול לפיהן כדי לוודא שהטכניקות האלה פועלות באפליקציה שלכם כמצופה.

טכניקות חיוניות לשיפור הביצועים

כדאי להתחיל עם סוגי הכלים הכי יעילים לשיפור הביצועים: פרופילים בסיסיים (כולל פרופילים של הפעלה) ואופטימיזציית הקוד R8.

צריך לעדכן את התלות ב-Compose לגרסה 1.8 ואילך, שבה הוספנו כמה תכונות חדשות ומשמעותיות ושיפרנו את היציבות הכוללת של הספרייה. הוראות לעדכון מפורטות במאמר הצהרה על תלות. מידע נוסף זמין בפוסט בבלוג על גרסה 1.8 ובשיחה What's New in Compose בכנס I/O.

פרופילים של קבוצת הבסיס

כדי לשפר את ביצועי האפליקציה, אפשר להשתמש בפרופילים בסיסיים. כדאי לקבץ את המחלקות והשיטות שמייצגות את תהליכי העבודה העיקריים של האפליקציה, שהמערכת יכולה לבצע להם קומפילציה מראש באמצעות פרופיל בסיסי. השינוי הזה יכול לקצר את זמני ההפעלה, להפחית את מספר הפריימים המקוטעים ולשפר את הביצועים.

כל ספריית Jetpack Compose מגיעה עם כללי פרופיל משלה. כשהאפליקציה שלכם תלויה בספרייה, כללי הפרופיל של הספרייה משולבים ומפוזרים אוטומטית עם קובץ ה-APK של האפליקציה לצורך קומפילציה מראש.

כדי לאמת את פרופילי הבסיס, אפשר להשתמש בטכניקות הבאות:

  • שימוש בבדיקות מאקרו.
  • משתמשים בפקודות ספציפיות של ADB כדי לאמת את מצב ההגדרה של הפרופיל באפליקציה. השלבים לביצוע שתי הטכניקות האלה מוסברים במדריך בנושא מדידה ואימות של ביצועים.

פרופילים של חברות סטארט-אפ

פרופילים להפעלה הם קבוצת משנה של פרופילי בסיס, והם מבצעים אופטימיזציה נוספת של המחלקות והשיטות שהם מכילים כדי להפחית את זמן האחזור של הפעלת האפליקציה.

הוספה של פרופיל הפעלה תגדיל את גודל ה-APK של האפליקציה, לכן לפני שמוסיפים פרופיל כזה לגרסת הייצור, חשוב להעריך את האיזון בין גודל ה-APK לבין זמן האחזור של ההפעלה.

כדי להתחיל, קוראים את המאמר יצירת פרופיל סטארט-אפ.

R8

משתמשים בקומפיילר R8 כדי לצמצם ולבצע אופטימיזציה של אפליקציות. ‫R8 מסיר קוד ומשאבים שלא בשימוש, משכתב קוד כדי לבצע אופטימיזציה של ביצועי זמן הריצה ועוד.

במדריכים בנושא שיפור הביצועים – מבט כולל, כדאי לקרוא את ההמלצות לגבי R8, כולל השלבים העיקריים להסרת משאבים שלא נעשה בהם שימוש.

מדידת ביצועים ואימות

כדי לקרוא על אסטרטגיות כלליות למדידת ביצועים ב-Android, אפשר לעיין במאמר סקירה כללית של מדידת הביצועים של אפליקציות. בקטע הזה מתוארות כמה מהטכניקות שמוזכרות במסמכי התיעוד האלה.

בחירת וריאציית build למדידות

מצב ניפוי הבאגים שימושי לזיהוי בעיות רבות, אבל הוא כרוך בעלויות ביצועים משמעותיות, לא משתמש בפרופילים של קו בסיס ויכול להקשות על זיהוי בעיות בקוד שעשויות להשפיע על הביצועים.

כדי להבין בצורה מדויקת את הביצועים של האפליקציה, צריך להריץ אותה במצב הפצה.

אפשר להסיק מסקנות סופיות לגבי הביצועים רק מבדיקות שבוצעו באפליקציות שפועלות עם אפשרויות של גרסת ייצור ובמכשירים אמיתיים.

עם זאת, כשמבצעים בדיקות השוואה, צריך להשתמש בווריאנט של בניית ההשוואה, שיש בו כמה הבדלים משמעותיים לעומת ניפוי באגים בגרסת ההפצה. פרטים נוספים זמינים במדריך להגדרת בדיקות מאקרו.

אימות פרופילי הבסיס של האפליקציה

מתחילים בבדיקת הסטטוס של הפרופיל:

adb shell dumpsys package dexopt | grep -A 1 $PACKAGE_NAME

אם הסטטוס הוא לא status=speed-profile, כללי הפרופיל עדיין לא הוחלו כדי לבצע אופטימיזציה של האפליקציה.

הכללים מוחלים באמצעות עבודת רקע שמופעלת כשהמכשיר נטען ולא פעיל. כדי להפעיל את התהליך הזה באופן ידני, מריצים את הפקודה הבאה אחרי שהאפליקציה מופעלת ועובר מספיק זמן כדי שכלי ההתקנה של הפרופיל יאתחל את הפרופיל ברקע. התהליך הזה נמשך בדרך כלל כ-40 שניות.

adb shell cmd package bg-dexopt-job

לאחר מכן, מריצים שוב את הפקודה הקודמת כדי לוודא שהסטטוס הוא speed-profile.

במקרים שבהם האופטימיזציה מתבצעת במהלך ההתקנה, אפשר לעיין במאמר בנושא העברה צדדית של פרופיל הבסיס.

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, אפשר לעיין בחדשות ובסרטונים האחרונים במדריך לביצועי האפליקציה.