אנחנו ממליצים להשתמש ב-Jetpack Macrobenchmark כדי לבדוק את ביצועי האפליקציה במקרים הבאים: פרופילי הבסיס מופעלים ולאחר מכן משווים את התוצאות האלה לנקודת השוואה. כשפרופילי הבסיס מושבתים. כך אפשר למדוד את הפעלת האפליקציה זמן - זמן עד להצגה ראשונית וגם לתצוגה מלאה - או רינדור בזמן הריצה כדי לראות אם הפריימים שהופקו עלולים לגרום לבעיות בממשק.
נקודות מאקרו-בנצ'מרק מאפשרות לשלוט בהידור לפני מדידה באמצעות
CompilationMode
API. אפשר להשתמש בערכים שונים של CompilationMode
כדי להשוות בין הביצועים במצבי הידור שונים. בקטע הקוד הבא מוצג
איך להשתמש בפרמטר CompilationMode
כדי למדוד את התועלת של קבוצת הבסיס
פרופילים:
@RunWith(AndroidJUnit4ClassRunner::class) class ColdStartupBenchmark { @get:Rule val benchmarkRule = MacrobenchmarkRule() // No ahead-of-time (AOT) compilation at all. Represents performance of a // fresh install on a user's device if you don't enable Baseline Profiles— // generally the worst case performance. @Test fun startupNoCompilation() = startup(CompilationMode.None()) // Partial pre-compilation with Baseline Profiles. Represents performance of // a fresh install on a user's device. @Test fun startupPartialWithBaselineProfiles() = startup(CompilationMode.Partial(baselineProfileMode = BaselineProfileMode.Require)) // Partial pre-compilation with some just-in-time (JIT) compilation. // Represents performance after some app usage. @Test fun startupPartialCompilation() = startup( CompilationMode.Partial( baselineProfileMode = BaselineProfileMode.Disable, warmupIteration = 3 ) ) // Full pre-compilation. Generally not representative of real user // experience, but can yield more stable performance metrics by removing // noise from JIT compilation within benchmark runs. @Test fun startupFullCompilation() = startup(CompilationMode.Full()) private fun startup(compilationMode: CompilationMode) = benchmarkRule.measureRepeated( packageName = "com.example.macrobenchmark.target", metrics = listOf(StartupTimingMetric()), compilationMode = compilationMode, iterations = 10, startupMode = StartupMode.COLD, setupBlock = { pressHome() } ) { // Waits for the first rendered frame, which represents time to initial display. startActivityAndWait() // Waits for content to be visible, which represents time to fully drawn. device.wait(Until.hasObject(By.res("my-content")), 5_000) } }
בצילום המסך הבא אפשר לראות את התוצאות ישירות ב-Android Studio עבור האפליקציה עכשיו לדוגמה ב-Android שפועלת על Google Pixel 7. התוצאות מראות שהפעלת האפליקציה היא המהירה ביותר כשמשתמשים בפרופילים בסיסיים (229.0ms) בהשוואה ללא הידור (324.8ms).

ColdStartupBenchmark
מציגות את הזמן להצגה הראשונית ללא הידור (324 אלפיות שנייה), הידור מלא
(315 אלפיות שנייה), הידור חלקי (312 אלפיות שנייה) ופרופילים בסיסיים
(229 אלפיות שנייה).בדוגמה הקודמת רואים תוצאות של הפעלת האפליקציה שנקלטו באמצעות
StartupTimingMetric
, יש מדדים חשובים נוספים שכדאי להביא בחשבון,
כמו FrameTimingMetric
. לקבלת מידע נוסף על כל הסוגים של
מידע נוסף זמין במאמר בנושא תיעוד מדדי מאקרובנצ'מרק.
זמן עד להצגה מלאה
בדוגמה הקודמת נמדד הזמן להצגה ראשונית (TTID), שהוא הזמן שנדרש לאפליקציה כדי ליצור את הפריים הראשון שלה. עם זאת, המדד הזה לא משקף בהכרח את הזמן עד שהמשתמש יכול להתחיל לקיים אינטראקציה עם האפליקציה. המדד זמן להצגה מלאה (TTFD) שימושי יותר למדידת נתיבי הקוד הנדרשים כדי להגיע למצב שבו האפליקציה זמינה לשימוש, ולביצוע אופטימיזציה שלהם.
מומלץ לבצע אופטימיזציה גם לגבי TTID וגם של 'דברים שאפשר לעשות', כי שניהם חשובים. A נמוכה השדה הזה עוזר למשתמשים לראות שהאפליקציה באמת מופעלת. חשוב שהזמן עד לתגובה יהיה קצר כדי שהמשתמש יוכל ליצור אינטראקציה עם האפליקציה במהירות.
כדי ללמוד אסטרטגיות לדיווח כשממשק המשתמש של האפליקציה מוצג במלואו, אפשר לעיין במאמר שיפור הדיוק של תזמון ההפעלה.
מומלץ עבורך
- הערה: טקסט הקישור מוצג כאשר JavaScript מושבת
- [כתיבה של Macrobenchmark][11]
- [תיעוד מדדי מאקרובנצ'מרק][12]
- [ניתוח ואופטימיזציה של הפעלה של האפליקציה {:#app-startup-analysis-optimization}][13]