ניהול ביצועים

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

ביצועים עקביים

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

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

ארכיטקטורה

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

איור 1. ארכיטקטורה של מצב ביצועים יציבים.

הטמעה

כדי לתמוך בביצועים עקביים ב-Android 7.0 ואילך, יצרני ציוד מקורי (OEM) צריכים:

  • מבצעים שינויים ספציפיים למכשיר ב-HAL של צריכת החשמל כדי לנעול את התדרים המקסימליים של המעבד או המעבד הגרפי או לבצע אופטימיזציות אחרות כדי למנוע הגבלת הספק תרמית.
  • הטמעת ההצעה החדשה POWER_HINT_SUSTAINED_PERFORMANCE ב-HAL של צריכת החשמל.
  • כדי להצהיר על תמיכה, מחזירים את הערך TRUE דרך ה-API של isSustainedPerformanceModeSupported().
  • מטמיעים את Window.setSustainedPerformanceMode.

בהטמעת העזר של Nexus, ההצעה לשימוש באנרגיה מגבילה את התדרים המקסימליים של המעבד וה-GPU לרמות הקיימות הגבוהות ביותר. חשוב לזכור שהורדת העמודה MAX בתדירות המעבד (CPU) או המעבד הגרפי (GPU) תגרום להאטה בקצב הפריימים, אבל מומלץ להשתמש בקצב נמוך יותר במצב הזה בגלל העמידה שלו לאורך זמן. לדוגמה, מכשיר שמשתמש בקצב שעון מרבי רגיל יכול לבצע עיבוד ב-60FPS למשך כמה דקות, אבל אחרי שהמכשיר מתחמם, הוא עשוי לצמצם את קצב הפריימים לשנייה ל-30FPS עד סוף 30 הדקות. לדוגמה, כשמשתמשים במצב מתמשך, המכשיר יכול לבצע רינדור באופן עקבי בקצב של 45FPS במשך כל 30 הדקות. המטרה היא להגיע לשיעור פריימים גבוה (או גבוה יותר) כשמשתמשים במצב, בהשוואה לשיעור הפריימים כשלא משתמשים במצב, ושיעמוד בעקביות לאורך זמן כדי שהמפתחים לא יצטרכו לרדוף אחרי יעד נע.

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

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

אימות

יצרני ציוד מקורי יכולים להשתמש בבדיקה של CTS (Android 7.0 ואילך) כדי לאמת את ההטמעה שלהם של API לביצועים עקביים. בבדיקה הזו מריצים עומס עבודה למשך כ-30 דקות ומבצעים השוואה בין הביצועים עם מצב מתמשך מופעל לבין הביצועים ללא מצב מתמשך מופעל:

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

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

ליבות בלעדיות

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

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

כדי לתמוך בליבה בלעדית במכשיר:

  • מפעילים את cpusets ומגדירים cpuset שמכיל רק את האפליקציה העליונה בחזית.
  • חשוב לוודא שליבת מעבד אחת (זוהי הליבה הבלעדית) שמורה לשרשור מ-cpuset הזה.
  • מטמיעים את ה-API getExclusiveCores כדי להחזיר את מספר הליבה של הליבה הבלעדית.

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

כדי לראות הטמעה לדוגמה של Nexus 6P, אפשר לעיין במאמר android//device/huawei/angler/power/power.c.