עיבוד איטי

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

הערה: מידע על אבחון ופתרון הבעיה הזו זמין במאמר בנושא רינדור איטי.

מדדים של תפקוד האפליקציה

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

• פריימים איטיים: פריימים של ממשק המשתמש שזמן הרינדור שלהם ארוך מ-16 אלפיות השנייה.
• פריימים קפואים: פריימים בממשק המשתמש שזמן הרינדור שלהם ארך יותר מ-700 אלפיות השנייה. זו בעיה כי נראה שהאפליקציה נתקעת ולא מגיבה לקלט של המשתמש כמעט למשך שנייה שלמה בזמן שהפריים מוצג. במהלך הפעלת האפליקציה או המעבר למסך אחר, נורמלי שהפריימים הראשונים יימשכו יותר מ-16 אלפיות השנייה, כי האפליקציה צריכה להרחיב את התצוגות, להגדיר את הפריסה של המסך ולבצע את הציור הראשוני מאפס. לכן מערכת Android עוקבת אחרי פריימים קפואים בנפרד מרינדור איטי. הרינדור של אף פריים באפליקציה לא צריך להימשך יותר מ-700 אלפיות השנייה.

הערה: בלוח הבקרה של תפקוד האפליקציה ב-Android ובמערכת Android מתבצע מעקב אחרי זמן הרינדור ונתונים סטטיסטיים של פריימים קפואים באפליקציות שמשתמשות בערכת הכלים לבניית ממשק משתמש שמבוססת על View, שבה החלק של האפליקציה שגלוי למשתמש נלקח מההיררכיה של Canvas או של View. אם האפליקציה לא משתמשת בערכת הכלים של ממשק המשתמש שמבוססת על View, כמו באפליקציות שמבוססות על Vulkan,‏ Unity,‏ Unreal או OpenGL, אז הנתונים הסטטיסטיים של זמן הרינדור והפריימים הקפואים לא זמינים בלוח הבקרה'תפקוד האפליקציה'. כדי לבדוק אם המכשיר מתעד מדדים של זמן רינדור עבור האפליקציה, מריצים את הפקודה adb shell dumpsys gfxinfo <package name>.