זיהוי של תקלות בממשק המשתמש

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

כשמתרחשת בעיה בממשק (jank), בדרך כלל הסיבה היא האטה או חסימה של קריאה אסינכרונית בשרשור UI (ברוב האפליקציות, זה ה-thread הראשי). אפשר להשתמש במעקב מערכת כדי לזהות את מקור הבעיה.

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

אם אתם משתמשים באפליקציות Compose, תוכלו להיעזר בשלבים שבמדריך הזה כדי לקבל תצוגה ברמת המאקרו של האפליקציה. עקבות המערכת שמוצגים כאן עוזרים לכם לזהות בעיות בממשק (jank) שנגרמות מבעיות ברמת המערכת שחוסמות את השרשור הראשי, כמו קלט/פלט (I/O) כבד בדיסק, garbage collection אגרסיבי או צווארי בקבוק של עיבוד ב-GPU. אם הצלחתם לבודד את הבעיה לשכבת ממשק המשתמש, תוכלו להיעזר במדריך ביצועים ב-Jetpack Compose. המדריך הזה עוזר לכם לתקן חוסר יעילות שקשור ל-Compose, כמו קומפוזיציות חוזרות מוגזמות, קריאת מצב בשלב הלא נכון או שימוש בפרמטרים לא יציבים.

זיהוי של תקלות ב-Android מגרסה 12 ואילך

במכשירים עם Android 12 (רמת API 31) ומעלה, מעקב שנתפס מוצג במסלול Janky frames בחלונית Display בכלי CPU Profiler.

כדי לזהות בעיות בממשק (jank),

1. ב-Android Studio, בוחרים באפשרות View (תצוגה) > Tool Windows (חלונות כלים) > Profiler (פרופיל) או לוחצים על Profile (פרופיל) בסרגל הכלים.

   אם מוצגת תיבת הדו-שיח Select Deployment Target (בחירת יעד פריסה), בוחרים את המכשיר שבו רוצים לפרוס את האפליקציה לצורך יצירת פרופיל. אם חיברתם מכשיר באמצעות USB אבל הוא לא מופיע ברשימה, ודאו שהפעלתם ניפוי באגים ב-USB.

2. לוחצים במקום כלשהו בציר הזמן של CPU כדי לפתוח את הכלי CPU Profiler.

3. בתפריט ההגדרות של CPU Profiler, בוחרים באפשרות System Trace ולוחצים על Record. אחרי שמסיימים את האינטראקציה עם האפליקציה, לוחצים על עצירה.

4. המסלול Janky frames אמור להופיע בקטע Display. כברירת מחדל, הכלי Profiler מציג רק פריימים עם תנודות כפריטים שאפשר לבדוק. בכל פריים עם ג'יטר, החלק האדום מציין את משך הזמן שחלף מהמועד האחרון לעיבוד הפריים.

5. אחרי שמאתרים פריים עם בעיה, לוחצים עליו. אפשר גם ללחוץ על M כדי לשנות את רמת הזום ולהתמקד בפריים שנבחר. האירועים הרלוונטיים מודגשים ב-threads האלה: ה-thread הראשי, RenderThread ו-GPU completion.

6. אפשר גם לראות את כל המסגרות או פירוט של זמן העיבוד על ידי סימון תיבות הסימון כל המסגרות ומחזור חיים בהתאמה.

זיהוי של תנועה קופצנית ב-Android 11

במכשירים עם Android 11 (רמת API‏ 30), נתוני מעקב שצולמו מוצגים בקטע Frame Lifecycle בכלי CPU Profiler.

הקטע Frame Lifecycle מכיל את שם השכבה וארבעה טראקים. כל רכיב מייצג שלב אחד בצינור הרינדור של המסגרת. הרכיבים של מחזור החיים של מסגרת הם:

1. ‫Frame Lifecycle (Layer name): שם השכבה מופיע בסוגריים בשם הקטע. שכבה היא יחידה אחת של יצירה.
2. אפליקציה: הציר הזה מראה את הזמן שחל מרגע הוצאת המאגר מהתור על ידי האפליקציה ועד לרגע החזרתו לתור. בדרך כלל, זה תואם לאירועי המעקב ב-RenderThread.
3. המתנה ל-GPU: בטראק הזה מוצג משך הזמן שהמאגר היה בבעלות ה-GPU. זהו הזמן שחולף מרגע שליחת המאגר אל ה-GPU ועד שה-GPU מסיים את העבודה על המאגר. הנתון הזה לא מציין שיחידת ה-GPU פעלה רק על המאגר הזה במהלך הזמן הזה. כדי לקבל מידע מפורט על מה שיחידת ה-GPU עושה בזמן נתון, אפשר להשתמש ב-Android GPU Inspector.
4. הרכב: הציר הזה מראה את הזמן שחלף מהרגע שבו SurfaceFlinger מתחבר למאגר ושולח אותו להרכבה, ועד שהמאגר נשלח לתצוגה.
5. פריימים שמוצגים: בטראק הזה מוצג משך הזמן שבו הפריים הוצג במסך.

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

ב-Android Studio מוצגים גם כל הפריימים בטבלת המעקב בפורמט של טבלה בכרטיסייה All Frames.

העמודות Frame #‎,‏ Application,‏ Wait for GPU ו-Composition מייצגות את אותם נתונים כמו הרצועות בקטע Frame Lifecycle שמופיע למעלה. העמודה Frame Duration (משך הפריים) מייצגת את הזמן שחלף מתחילת Application (האפליקציה) ועד לתחילת Frames on Display (הפריימים שמוצגים). זהו משך הזמן שנדרש לעיבוד פריים מקצה לקצה.

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

כדי לזהות ולחקור תופעות של ג'אנק ב-Android 11, פועלים לפי השלבים הבאים:

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

   

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

   

3. מחפשים שרשורים רלוונטיים בקטעים Frame Lifecycle ו-Threads.

   

זיהוי של תנועה קופצנית ב-Android מגרסה 10 ומטה

במכשירים עם Android 10 (רמת API‏ 29) ומטה, מידע רלוונטי על צינור הגרפיקה של מערכת ההפעלה מוצג בקטע יחיד במעקב המערכת של CPU Profiler שנקרא Display.

• מסגרות: בקטע הזה מוצגים שרשור UI וRenderThread אירועי מעקב באפליקציה. אירועים שנמשכים יותר מ-16 אלפיות השנייה צבועים באדום כדי להדגיח מסגרות שעלולות להיות מגומגמות, כי הן חורגות מהמועד האחרון לעיבוד ב-60 מסגרות לשנייה (fps).
• ‫SurfaceFlinger: בקטע הזה מוצג מתי SurfaceFlinger מעבד את מאגרי המסגרות. ‫SurfaceFlinger הוא תהליך מערכת שאחראי לשליחת מאגרי נתונים לתצוגה.
• ‫VSYNC: בקטע הזה מוצג VSYNC, אות שמסנכרן את צינור התצוגה. בקטע הזה מוצג האות VSYNC-app, שמעיד על כך שהאפליקציה מתחילה מאוחר מדי. בדרך כלל, זה קורה כי שרשור ה-UI עמוס. היא גורמת להבהוב גלוי במסך במהלך אנימציה, ומוסיפה חביון קלט נוסף עד שהאנימציה או הגלילה מסתיימות. חשוב במיוחד לבדוק את הנתון הזה במסכים עם קצב רענון גבוה, כי יכול להיות שהאירועים האלה יתרחשו בתדירות גבוהה יותר מ-60 פעמים בשנייה או בקצב משתנה.
• ‫BufferQueue: בקטע הזה מוצג מספר מאגרי הפריימים שנמצאים בתור וממתינים לצריכה על ידי SurfaceFlinger. באפליקציות שמופעלות במכשירים עם Android 9 (רמת API‏ 28) ומעלה, המסלול הזה מציג את מספר המאגרים של BufferQueue (0,‏ 1 או 2) של משטח האפליקציה. BufferQueue יכול לעזור לכם להבין את המצב של מאגרי התמונות כשהם עוברים בין רכיבי הגרפיקה של Android. לדוגמה, ערך של 2 מציין שהאפליקציה עוברת כרגע תהליך של חיץ משולש, שגורם לזמן אחזור נוסף של קלט.

בקטע Display מופיעים אותות שימושיים לזיהוי בעיות בממשק (jank) – לדוגמה, כששרשור UI או RenderThread נמשך יותר מ-16 אלפיות השנייה. כדי לבדוק את הפרטים המדויקים של מה שגרם לבעיה בממשק, אפשר לעיין בקטע Threads, שבו מוצגים השרשורים שרלוונטיים לעיבוד התמונה של ממשק המשתמש.

באיור שלמעלה, בקטע Threads מוצגים שרשור UI (java.com.google.samples.apps.iosched), RenderThread והשרשור GPU completion. אלה השרשורים שרלוונטיים לעיבוד ממשק המשתמש ועשויים לגרום לבעיות.

כדי לזהות תקלות ב-Android מגרסה 10 ומטה, פועלים לפי השלבים הבאים:

1. בודקים את המסלול Frames בDisplay. המסגרות האדומות הן מועמדות לבדיקה.

   

2. כשמוצאים פריים שעלול להיות לא יציב, מגדילים את התצוגה על ידי הקשה על W או גלילה של גלגל העכבר תוך כדי לחיצה על Control (Command ב-macOS). ממשיכים להתקרב עד שמתחילים לראות את אירועי המעקב בשרשור UI וב-RenderThread.

   

   באיור שלמעלה, Choreographer#doFrame מופיע כששרשור UI קורא ל-Choreographer כדי לתאם אנימציה, פריסת תצוגה, ציור תמונה ותהליכים קשורים. ‫DrawFrames מוצג כש-RenderThread שולח פקודות ציור בפועל ל-GPU.

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

בדיקה מתקדמת באמצעות Perfetto

משימת הפרופילים של עקבות המערכת ב-Android Studio מופעלת על ידי Perfetto. אם אתם נתקלים בבעיות מורכבות בעיבוד וצריכים שאילתות SQL מותאמות אישית או ניווט מתקדם בציר הזמן, אתם יכולים לבצע את ניתוח העקבות מחוץ ל-IDE.

כדי לייצא את מעקב המערכת מ-Android Studio, לוחצים על סמל ייצוא המעקב בחלונית Profiler, ואז גוררים את הקובץ שנוצר אל ממשק המשתמש של Perfetto שמבוסס על אינטרנט. כך אפשר לקבל סביבה ייעודית לניתוח ביצועים ברמת המערכת. כדי להבין את הפרטים של צינור הגרפיקה של מערכת ההפעלה, כמו VSYNC,‏ SurfaceFlinger והמסלולים של ציר הזמן של הפריימים, אפשר לעיין בתיעוד הרשמי של Perfetto.

מידע נוסף

כדי ללמוד עוד על איך לצמצם את הבעיה של בעיות בממשק (jank), ראו מקורות נפוצים לבעיות בממשק (jank).