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

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

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

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

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

 
כדאי לעיין ברמה שהכי רלוונטית לכם:

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

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

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

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

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

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

המדדים הבסיסיים של חוויית המשתמש

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שלב 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) גלילה ברשימת Compose.

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: הקלטת נתונים של מעקב

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

• הקלטת נתוני מעקב באופן ידני במכשיר ישירות מאפשרויות למפתחים.
• שימוש בכלי ליצירת פרופיל של המעבד (CPU) ב-Android Studio
• שימוש בממשק המשתמש של Perfetto

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

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

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

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