הערכת הביצועים

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

יש שני מדדי ביצועים גלויים למשתמש:

• ביצועים ניתנים לחיזוי ומורשים. האם המשתמש ממשק (UI) להוריד את הפריימים או מעובד במהירות של 60FPS בעקביות? האם מופעל אודיו בלי ארטיפקטים או חלונות קופצים? כמה זמן נמשך העיכוב בין הנגיעה של המשתמש ואת האפקט שמופיע במסך?
• משך הזמן הנדרש לפעולות ארוכות יותר (כמו פתיחת אפליקציות).

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

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

קיבולת לעומת רעידות

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

קיבולת

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

הקיבולת של מערכת משתנה בהתאם למשאבי המחשוב באינטרנט. שינוי התדר של המעבד (CPU) או ה-GPU הוא האמצעי העיקרי לשינוי הקיבולת, אבל יש תכונות אחרות, כמו שינוי מספר הליבות של המעבד (CPU) באינטרנט. בהתאם לכך, הקיבולת של המערכת תואמת לצריכת החשמל; שינוי הקיבולת תמיד תגרום לשינוי דומה בצריכת החשמל.

הקיבולת הנדרשת בזמן נתון נקבעת במידה רבה על ידי האפליקציה שפועלת. לכן, הפלטפורמה לא יכולה לעשות מספיק שינויים לעומס עבודה נתון, והאמצעים לעשות זאת מוגבלים שיפורים בזמן ריצה (framework של Android, ART, Bionic, מהדר/מנהלי התקנים של GPU, ליבה (kernel)).

רעידות

אומנם קל לראות את הקיבולת הנדרשת של עומס עבודה, אבל הרעידות תפיסה ערפילית. להיכרות טובה עם רעידות בתור מכשול למהירות המערכות שלנו, אחר כך מקרה של ביצועים חסרים במחשבי על: השגת ביצועים אופטימליים מופעל 8,192 המעבדים של ASCl Q. (המחקר בודק למה ה-ASCI מחשב-העל Q לא השיג את הביצועים הצפויים שלו והוא מעולה של אופטימיזציה של מערכות גדולות.)

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

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

• השהיה בתזמון
• רכיבי handler של הפרעות
• קוד הנהג פועל יותר מדי זמן עם אזהרה מוקדמת או הפרעות מושבתות
• מקלות רכים ותיקים
• תחרות על נעילה (אפליקציה, framework, מנהל התקן ליבה, נעילת binder, mmap מנעול)
• תחרות על מתאר הקובץ שבה שרשור בעדיפות נמוכה מכיל את הנעילה וכך מונע הרצה של שרשור עם עדיפות גבוהה
• הרצת קוד קריטי לממשק המשתמש בתאי עבודה שבהם הדבר עלול להתעכב
• מעברים במצב לא פעיל של מעבד (CPU)
• רישום
• עיכובים בקלט/פלט (I/O)
• יצירת תהליכים מיותרים (לדוגמה, שידורי CONNECTIVITY_CHANGE)
• עומס יתר של מטמון הדפים בגלל מחסור בזיכרון פנוי

משך הזמן הנדרש לפרק זמן של רעידות יכול להיות או לא הקיבולת פוחתת ככל שהקיבולת גדלה. לדוגמה, אם נהג עוזב שמפריע בזמן ההמתנה לקריאה מכל אוטובוס i2c, הפעולה תיקח כמה זמן הם צריכים, בין אם המעבד (CPU) הוא במהירות של 384MHz או של 2GHz. במגמת עלייה הקיבולת היא לא פתרון מעשי לשיפור הביצועים כשהרעידות מעורבות. כתוצאה מכך, מעבדים מהירים יותר לא ישפרו בדרך כלל הביצועים במצבים שמוגבלים על ידי רעידות.

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

צריכת זיכרון

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

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

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

במקום זאת, כדאי להשתמש בגישה הכללית הבאה כשיוצרים המכשיר:

1. אתחול המערכת לממשק המשתמש כשכל מנהלי ההתקנים פועלים וחלק ממנהלי ההתקנים הבסיסיים הגדרות של מנהל התדרים (אם משנים את ההגדרות של מפקח התדרים, חוזרים על כל השלבים הבאים).
2. מוודאים שהליבה תומכת בנקודת המעקב sched_blocked_reason וגם נקודות מעקב אחרות בצינור עיבוד הנתונים לתצוגה שמציינות מתי הפריים מוצג במסך.
3. עוקבים אחרי כל צינור עיבוד הנתונים של ממשק המשתמש (החל מקבלת קלט דרך IRQ). עד לסריקת פלט סופית) בזמן הרצת עומס עבודה קל ועקבי (לדוגמה, UiBench או בדיקת הכדור ב-TouchLatency).
4. תיקון הפגמים בפריים שזוהו בטווח הקלילות והעקביות עומס עבודה.
5. חוזרים על שלבים 3 עד 4 עד שאפשר לרוץ עם אפס פריימים במשך יותר מ-20 שניות. בכל פעם.
6. עברו למקורות אחרים של jank שגלויים למשתמשים.

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

• מוודאים שהליבה כוללת את sched_blocked_reason תיקון נקודות מעקב. נקודת המעקב הזו מופעלת עם הקטגוריה של מעקב תזמון במערכת והיא מספקת את הפונקציה שאחראית לשינה השרשור נכנס לשינה ללא הפרעות. חשוב מאוד לנתח את הביצועים כי שינה ללא הפרעות הוא סימן נפוץ מאוד לרעידות.
• לוודא שיש לכם מספיק נתוני מעקב ל-GPU ולצינורות עיבוד הנתונים לתצוגה. במצב מופעל נקודות מעקב עדכניות מסוג Qualcomm SOCs, מופעלות באמצעות:

adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

האירועים האלה נשארים פעילים כאשר מריצים מערכת systrace, כדי שתוכלו לראות מידע במעקב על צינור עיבוד הנתונים לתצוגה (MDSS) קטע בנושא mdss_fb0. ב-Qualcomm SOCs לא יופיעו נתונים נוספים מידע על ה-GPU בתצוגת המערכת הרגילה, אבל התוצאות שנמצא במעקב עצמו (לפרטים, אפשר לעיין במאמר הבנה systrace).

מה שאתם רוצים מאותו סוג של מעקב תצוגה הוא אירוע אחד מציין באופן ישיר שהמסגרת נמסרה למסך. מכאן אפשר יכול לקבוע אם זמן הפריים הושלם בהצלחה; אם אירוע Xn מתרחשת פחות מ-16.7 אלפיות השנייה אחרי אירוע Xn-1 (בהנחה שהתצוגה היא 60 Hz), אז תדעו שלא התקשרתם. אם ה-SOC לא מספק אותות כאלה, עם הספק שלכם כדי לקבל אותם. קשה מאוד לנפות באגים ברעידות בלי אות ברור להשלמת פריים.

שימוש בנקודות השוואה סינתטיות

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

על סמך חוויות עם רשתות SOC, הבדלים בנקודת ההשוואה סינתטית אין קשר בין רמת הביצועים של רשתות חברתיות לבין הבדל דומה ביצועים מובחנים של ממשק המשתמש (מספר הפריימים שהושמטו, מסגרת האחוזון ה-99 וכו'). נקודות השוואה סינתטיות הן נקודות השוואה לקיבולת בלבד; השפעות של רעידות את הביצועים שנמדדים של נקודות ההשוואה האלה רק על ידי גניבת זמן מהכמות גדולה הפעולה של נקודת ההשוואה. לכן, הציונים המקובלים בשוק הסינתטי הם בעיקר לא רלוונטיות כמדד לביצועים שהשפיעו על המשתמשים.

נבחן שתי רשתות SOC שמריצים השוואה לשוק X, שמבצעות 1,000 פריימים של ממשק משתמש וגם מדווח על זמן הרינדור הכולל (ציון נמוך יותר טוב יותר).

• העיבוד של כל פריים של נקודת השוואה X מתבצע ב-SOC 1 תוך 10 אלפיות השנייה ויקבל 10,000 נקודות.
• SOC 2 מעבד 99% מהפריימים תוך אלפיות שנייה, אבל 1% מהפריימים ב-100 אלפיות השנייה ומקבלים תוצאות 19,900, ציון טוב יותר באופן דרמטי.

אם ההשוואה לשוק מצביע על ביצועים בפועל של ממשק המשתמש, SOC 2 יהיה שלא ניתן לשימוש. בהנחה שקצב הרענון של 60 Hz, ל-SOC 2 תהיה פריים מוזר פעילות של 1.5 שניות. בינתיים, SOC 1 (ה-SOC האיטי יותר לפי נקודת השוואה X) יהיה נוזלי לחלוטין.

שימוש בדוחות איתור באגים

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

שימוש ב-TouchLatency

יש כמה דוגמאות להתנהגות לא תקינה מ-TouchLatency, עומס עבודה תקופתי מועדף שבו נעשה שימוש במכשירי Pixel ו-Pixel XL. השירות זמין בכתובת frameworks/base/tests/TouchLatency ובשני מצבים: זמן אחזור באמצעות מגע וכדור חוזר (כדי להחליף מצב, לוחצים על הלחצן בפינה השמאלית העליונה) ).

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

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

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

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