קצב רענון דינמי

החל מ-Android 15, התכונה 'קצב רענון דינמי' (ARR) מאפשרת להתאים את קצב הרענון של המסך לקצב הפריימים של התוכן, באמצעות שלבים נפרדים של VSync.

היתרונות של התכונה 'הכנסה חוזרת שנתית':

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

  • הפחתת ה-jank: ARR מבטל את הצורך במעבר בין מצבים, שזו סיבה ידועה ל-jank.

סקירה כללית

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

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

באיור הבא מוצג מסך עם vsyncPeriod של 240 הרץ ו-minFrameIntervalNs (קצב רענון מקסימלי) של 120 הרץ. מתרחש VSync כל 4.16 אלפיות השנייה. אפשר להציג פריים בכל מכפלה של VSync אחרי minFrameIntervalNs מהפריים האחרון.

arr-example

איור 1. דוגמה ל-ARR.

הטמעה

‫Android 15 תומך ב-ARR עם ממשקי API חדשים של Hardware Composer ‏ (HWC) HAL ושינויים בפלטפורמה. כדי להפעיל ARR, יצרני ציוד מקורי (OEM) צריכים לתמוך בשינויים בליבה ובמערכת במכשירים עם Android בגרסה 15 ומעלה, ולהטמיע את גרסה 3 של ממשקי ה-API של android.hardware.graphics.composer3, כמו שמופיע ברשימה בקטעים הבאים.

מידע נוסף זמין במאמר בנושא הטמעה לדוגמה של ממשקי ה-API שתומכים ב-ARR ב-Pixel.

DisplayConfiguration.aidl

ממשק ה-API‏ DisplayConfiguration.aidl מציין את הגדרת התצוגה באמצעות מאפייני תצוגה, יחד עם המאפיינים הבאים של ARR:

  • אופציונלי ‫vrrConfig: אם ההגדרה הזו מוגדרת, ARR מופעל עבור הגדרות ספציפיות. אם ההגדרה היא null, מצב התצוגה מוגדר למצבים שהם לא ARR, כמו קצב רענון משתנה (VRR). באמצעות המאפיין הזה, אפשר להגדיר תצוגה כ-MRR או כ-ARR, אבל לא כשתיהן.

  • ‫vsyncPeriod: קצב ה-VSync של המסך. במסכים עם ARR, הערך הזה משמש לחישוב קצב הרענון הנפרד הנתמך.

    ספקים צריכים להגדיר את הערך DisplayConfiguration.vsyncPeriod לכל המכשירים. בצגים שאינם ARR, ‏ DisplayConfiguration.vsyncPeriod הוא קצב הרענון של הצג. אם מכשיר תומך ב-120 Hz, הערך הזה צריך להיות 8.3 ms.

    בתצוגות של ARR, ‏ DisplayConfiguration.vsyncPeriod הוא התדר של אות ה-TE. אם למכשיר יש minFrameIntervalNs של 8.3 ms אבל ה-TE הוא 240 Hz, הערך הזה צריך להיות 4.16 ms.

VrrConfig.aidl

‫VrrConfig.aidl API כולל את המאפיינים הבאים:

  • ‫minFrameIntervalNs: קצב הרענון המקסימלי שהמסך יכול לתמוך בו.
  • ‫NotifyExpectedPresentConfig: הערך הזה נקבע לפי הזמן שנדרש למסך כדי לקבל הודעה מראש על פריים קרוב.

‫IComposerClient.notifyExpectedPresent מספק רמז לגבי פריים שסביר שיוצג, כדי שהתצוגה תוכל להתאים את תקופת הרענון העצמי שלה בהתאם. הערך frameIntervalNs מייצג את הקצב הנוכחי שמופיע אחרי expectedPresentTime. לדוגמה, אם קוראים ל-notifyExpectedPresent עם expectedPresentTime N ו-frameIntervalNs של 16.6 ms, הפריים הבא יהיה ב-N + 16.6 ms אחרי הזמן הנוכחי N. אחרי הזמן הנוכחי N, קצב הפריימים הוא 16.6 ms עד לשינויים נוספים.

הפונקציה IComposerClient.notifyExpectedPresent נקראת רק אם הערך של DisplayConfiguration.notifyExpectedPresentConfig מוגדר, ואם מתקיים אחד מתנאי התזמון הבאים:

  • זמן ההצגה שחורג מהקצב: זמן ההצגה הצפוי של הפריים הבא חורג מקצב הרענון הרגיל של המסך שמוגדר על ידי frameIntervalNs.
  • פסק זמן: מרווח הזמן בין הפריימים הקודמים גדול מ-notifyExpectedPresentConfig.timeoutNs או שווה לו.

DisplayCommand.frameIntervalNs

‫DisplayCommand.frameIntervalNs מספק רמז לגבי הקצב של המסגרות הקרובות בננו-שניות.

בדיקה

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

כדי לבצע בדיקות ידניות, אפשר להשתמש באפליקציית הבדיקה TouchLatency, כמו שמוצג באיור 2:

touchlatency-app

איור 2. מקישים על אפליקציית הבדיקה TouchLatency.

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