מדריכים

מדריך להתקדמות ברמות בתוכנית 'המסע לשיפור הביצועים'

משך הקריאה: 9 דקות
Alice Yuan
מהנדס קשרי מפתחים

מדריך לרמות שונות בתהליך השימוש בקמפיינים למיקסום הביצועים

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

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

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

 
אפשר לדלג לרמה שהכי רלוונטית לכם:

רמה 1:  שימוש במעקב אחר שדות שמופיע ב-Play Console

מומלץ קודם להשתמש בנתוני תפקוד האפליקציה ב-Android ב-Play Console כדי לראות נתונים שנאספים אוטומטית מניטור השדה, וכך לקבל תובנות לגבי האפליקציה במאמץ מינימלי.

‫תפקוד האפליקציה הוא יוזמה של Google לאיסוף אוטומטי של נתוני השדות האלה ולהצגתם.

כך אנחנו מספקים את הנתונים האלה:

  1. איסוף נתונים: כשמשתמש מצטרף לתוכנית, מכשיר Android שלו מתעד באופן אוטומטי אירועים מרכזיים של ביצועים ויציבות מכל האפליקציות, כולל האפליקציה שלכם.
  2. נתונים מצטברים: מערכת Google Play אוספת את הנתונים האלה מהמשתמשים באפליקציה ומבצעת אנונימיזציה שלהם.
  3. הצגת תובנות: הנתונים מוצגים בלוח הבקרה של תפקוד האפליקציה ל-Android ב-Google Play Console.

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

הנתונים הבסיסיים של תפקוד האפליקציה

מדדי האיכות הטכנית העיקריים של Google Play

כדי למקסם את החשיפה ב-Google Play, חשוב שהערכים של המדדים האלה באפליקציה יהיו מתחת לסף ההתנהגות הלא תקינה.

שיעור הקריסות שבהן הבחינו המשתמשיםאחוז המשתמשים הפעילים ביום (DAU) שקריסה אחת לפחות השפיעה עליהם, וסביר להניח שהמשתמשים הבחינו בה
שיעור מקרי ה-ANR שבהם הבחינו המשתמשיםאחוז המשתמשים הפעילים ביום (DAU) שמקרה ANR אחד לפחות השפיע עליהם, וסביר להניח שהמשתמשים הבחינו בו
שימוש מופרז בסוללהאחוז הסשנים של תצוגת השעון שבהם שיעור השימוש בסוללה חורג מ-4.44% בשעה
חדש: שימוש מוגזם בחסימה חלקית של מצב השינהאחוז הסשנים של המשתמשים שבהם השימוש המצטבר בחסימת מצב שינה (שלא פטורה) חורג משעתיים

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

שיעור מקרי ה-ANR שהשפיעו על המשתמשים

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

crashesAnrs.png

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

insights.png

כדאי גם לעיין בהנחיות שלנו בנושא ANR כדי לאבחן ולפתור תרחישים נפוצים שבהם עלולות להתרחש שגיאות ANR. 

שיעור הקריסות שהשפיעו על המשתמשים

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

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

שימוש מופרז בסוללה 

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

‫[new] שימוש מוגזם בחסימה חלקית של מצב השינה

 

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

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

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

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

רמה 2: ביצוע הפעולות לשיפור הביצועים שמופיעות בציון הביצועים של האפליקציה

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

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

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

שלב 1: ביצוע הערכה סטטית

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

עוברים אל הקטע 'ציון סטטי' בדף לוח התוצאות ומבצעים את הפעולות הבאות:

  1. בדיקת הגרסה של פלאגין של Android Gradle‏ (AGP).
  2. מומלץ להשתמש ב-R8 במצב מלא כדי לבצע מיניפיקציה של קוד האפליקציה ולבצע בו אופטימיזציה, או להשתמש ב-R8 Minification בהדרגה.
  3. כדאי להשתמש בפרופילים של Baseline כדי לשפר את מהירות הרצת הקוד מההפעלה הראשונה, וכך לשפר את הביצועים לכל התקנה חדשה של האפליקציה ולכל עדכון לאפליקציה.
  4. כדאי להשתמש בפרופילים להפעלה כדי לשפר את פריסת ה-Dex. פרופילים של הפעלה משמשים את מערכת ה-Build כדי לבצע אופטימיזציה נוספת של המחלקות והשיטות שהם מכילים, על ידי שיפור הפריסה של הקוד בקובצי ה-DEX של ה-APK.
  5. שדרוג לגרסה החדשה ביותר של Jetpack פיתוח נייטיב

שלב 2: ביצוע הערכה דינמית

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

עוברים אל הקטע 'ניקוד דינמי' בדף לוח התוצאות ומבצעים את הפעולות הבאות:

  1. הגדרת סביבת בדיקה עם מכשיר פיזי. כדאי להשתמש במכשיר פשוט יותר כדי להבליט את בעיות הביצועים, וכך יהיה קל יותר לזהות אותן.
  2. מדידת זמן ההפעלה ממרכז האפליקציות. מפעילים את האפליקציה ממצב התחלתי (cold start) באמצעות סמל מרכז האפליקציות ומודדים את הזמן עד שהיא הופכת לאינטראקטיבית.
  3. מדידת זמן ההפעלה של האפליקציה מתוך התראה, במטרה לצמצם את זמן ההפעלה של ההתראה כך שיהיה מתחת לכמה שניות.
  4. כדי למדוד את ביצועי העיבוד, גוללים בין המסכים והאנימציות העיקריים.

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

רמה 3: שימוש במסגרות לבדיקת ביצועים מקומיים

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

‫Macrobenchmark 💚 UiAutomator

אפשר לחשוב על Macrobenchmark ו-UiAutomator כשני כלים שפועלים יחד: Macrobenchmark הוא כלי המדידה. הכלי הזה פועל מחוץ לאפליקציה, כמו שעון עצר ומונה קצב פריימים. הוא אחראי להפעלת האפליקציה, לתיעוד מדדים (כמו זמן ההפעלה או פריימים שהושמטו) ולהפסקת האפליקציה. UiAutomator הוא המשתמש הרובוטי. הספרייה מאפשרת לכתוב קוד כדי לבצע פעולות במסך המכשיר. הוא יכול למצוא סמל, ללחוץ על לחצן,  לגלול ברשימה ועוד.

איך כותבים מבחן

כשכותבים בדיקה, עוטפים את הקוד של UiAutomator בבלוק Macrobenchmark.

  1. הגדרת הבדיקה: משתמשים ב@MacrobenchmarkRule
  2. מתחילים למדוד: מתקשרים אל benchmarkRule.measureRepeated.
  3. הפעלת ממשק המשתמש: בתוך הבלוק הזה, משתמשים בקוד UiAutomator כדי להפעיל את האפליקציה, למצוא רכיבים בממשק המשתמש וליצור איתם אינטראקציה.

הנה קטע קוד לדוגמה שמראה איך בודקים אם יש בעיות בממשק (jank) גלילה ברשימת פיתוח נייטיב.

  benchmarkRule.measureRepeated(

    // ...

    metrics = listOf(

        FrameTimingMetric(),

    ),

    startupMode = StartupMode.COLD,

    iterations = 10,

) {

    // 1. Launch the app's main activity

    startApp()

    // 2. Find the list using its resource ID and scroll down

    onElement { viewIdResourceName == "$packageName.my_list" }

        .fling(Direction.DOWN)

}

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

  timeToInitialDisplayMs  min  1894.4,   median 2847.4,   max  3355.6


frameOverrunMs          P50 -3.2,  P90  6.2, P95  10.4, P99  119.5

תרחישים נפוצים לדוגמה

המדד Macrobenchmark מספק כמה מדדי ליבה מוכנים לשימוש. StartupTimingMetric מאפשרת לכם למדוד בצורה מדויקת את הפעלת האפליקציה. המדד FrameTimingMetric מאפשר לכם להבין את ביצועי העיבוד של האפליקציה במהלך הבדיקה.

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

רמה 4: שימוש בכלים לניתוח עקבות כמו Perfetto 

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

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

איך משתמשים ב-Perfetto כדי לנפות באגים בביצועים

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

שלב 1: הקלטת נתוני מעקב

יש כמה דרכים להקליט עקבות מערכת: 

שלב 2: טעינת נתוני המעקב

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

  1. פותחים את Chrome ועוברים אל ui.perfetto.dev.
  2. גוררים ומשחררים את קובץ .perfetto-trace (או .pftrace) ישירות לחלון הדפדפן.
  3. ממשק המשתמש יעבד את הקובץ ויציג את ציר הזמן.

שלב 3: ניתוח של נתוני המעקב

כדי לחקור בעיות בביצועים, אפשר להשתמש בממשק המשתמש של Perfetto או ב-Android Studio Profiler. כדאי לצפות בפרק הזה בסדרת MAD Skills בנושא ביצועים, שבו מהנדסת הביצועים שלנו, כרמן ג'קסון, מדברת על הכלי Perfetto traceviewer.

תרחישים לבדיקת נתוני מעקב של המערכת באמצעות Perfetto

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

ניפוי באגים של Jank (מסגרות שהושמטו)

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

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

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

ניתוח של הפעלה איטית של אפליקציה

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

אתם יכולים לראות אם אתם ממתינים לשיחות Binder (תקשורת בין תהליכים). אם onCreate ממתין זמן רב לתגובה מהמערכת PackageManager, Perfetto יציג את מצב החסימה הזה בצורה ברורה. 

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

בדיקה של התרוקנות הסוללה ושימוש במעבד

מכיוון ש-Perfetto רואה את כל המערכת, היא מושלמת לאיתור של ניקוזים בלתי נראים של הסוללה.

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

רמה 5: בניית מסגרת משלכם למעקב אחר ביצועים

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

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

באמצעות ApplicationStartInfo, ProfilingManager ו-ApplicationExitInfo, תוכלו ליצור מערכת טלמטריה חזקה שמדווחת על אופן ההפעלה של האפליקציה, על פעולות שבוצעו בזמן ההפעלה ועל הסיבה לסגירה שלה.

ApplicationStartInfo: מעקב אחרי אופן הפעלת האפליקציה

החל מ-Android 15‏ (API 35), ApplicationStartInfo מספק מדדים מפורטים על הפעלת האפליקציה בשטח. הנתונים כוללים מידע על סוג ההפעלה (cold, warm או הפעלה מתוך הזיכרון (Hot start)) ועל משך השלבים השונים של ההפעלה. 

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

המטרה היא לתעד בצורה מדויקת את מדדי ההשקה בלי להגדיר ידנית כל שלב של אתחול.

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

‫ProfilingManager: תיעוד הסיבות לאיטיות

‫ProfilingManager (API 35) מאפשר לאפליקציה להפעיל באופן פרוגרמטי מעקב אחר המערכת במכשירי משתמשים. האפשרות הזו שימושית מאוד לזיהוי בעיות ביצועים זמניות שמתרחשות בפועל ולא ניתן לשחזר אותן באופן מקומי.

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

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

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

ApplicationExitInfo: מעקב אחרי הסיבות לסגירת האפליקציה

‫ApplicationExitInfo (API 30) – מידע על הסיבה לסיום התהליך הקודם. הפעולה הזו חיונית כדי למצוא קריסות מקוריות, ANR או סגירות מערכת בגלל שימוש מוגזם בזיכרון (OOM). תוכלו גם לקבל מעקב מפורט של ה-tombstone באמצעות ה-API getTraceInputStream.

מטרת ה-API היא להבין בעיות יציבות שלא מפעילות דוחות קריסה רגילים של Java (כמו Low Memory Kills).

צריך להפעיל את ה-API הזה בהפעלה הבאה של האפליקציה.

השלבים הבאים

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

כדאי לחזור מחר כדי לצפות ב-Ask Android

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

אתם מוזמנים להצטרף אלינו מחר למפגש שאלות ותשובות בשידור חי בנושא Android. אתם יכולים לשאול שאלות באמצעות ההאשטאג #AskAndroid ולקבל תשובות מהמומחים.

נכתב על ידי:

להמשך הקריאה