מומלץ להשתמש ב-Jetpack Macrobenchmark כדי לבדוק את הביצועים של האפליקציה כשפרופילי הבסיס מופעלים, ולאחר מכן להשוות את התוצאות האלה למדד ביצועים כשפרופילי הבסיס מושבתים. הגישה הזו מאפשרת למדוד את זמן ההפעלה של האפליקציה – גם את הזמן עד לתצוגה הראשונית וגם את הזמן עד לתצוגה המלאה – או את ביצועי העיבוד בזמן הרינדור כדי לראות אם הפריימים שנוצרים עלולים לגרום לתנודות.
מדדי מאקרובנצ'מרקים מאפשרים לשלוט בהידור לפני מדידה באמצעות ה-API של CompilationMode
. אפשר להשתמש בערכי 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 לאפליקציה Now in Android sample שפועלת ב-Google Pixel 7. התוצאות מראות שההפעלה של האפליקציה היא המהירה ביותר כשמשתמשים בפרופילים בסיסיים (229.0ms) בהשוואה ללא הידור (324.8ms).
בדוגמה הקודמת מוצגות תוצאות של הפעלת אפליקציה שצולמו באמצעות StartupTimingMetric
, אבל יש מדדים חשובים אחרים ששווה להביא בחשבון, כמו FrameTimingMetric
. למידע נוסף על כל סוגי המדדים, ראו צילום מדדי מאקרובנצ'מרק.
זמן ההצגה במסך מלא
בדוגמה הקודמת נמדד הזמן להצגה ראשונית (TTID), שהוא הזמן שנדרש לאפליקציה כדי ליצור את הפריים הראשון שלה. עם זאת, המדד הזה לא משקף בהכרח את הזמן עד שהמשתמש יכול להתחיל לקיים אינטראקציה עם האפליקציה. המדד זמן להצגה מלאה (TTFD) שימושי יותר למדידת נתיבי הקוד הנדרשים כדי להגיע למצב שבו האפליקציה זמינה לשימוש, ולביצוע אופטימיזציה שלהם.
מומלץ לבצע אופטימיזציה גם ל-TTID וגם ל-TTFD, כי שניהם חשובים. זמן TTID קצר עוזר למשתמש לראות שהאפליקציה אכן מופעלת. חשוב לשמור על תיאור קצר של 'דברים שאפשר לעשות' כדי להבטיח שהמשתמש יוכל לקיים אינטראקציה עם האפליקציה במהירות.
לקבלת אסטרטגיות לדיווח על השלמת תצוגת ממשק המשתמש של האפליקציה, אפשר לעיין במאמר שיפור הדיוק של תזמון ההפעלה.
מומלץ עבורך
- הערה: טקסט הקישור מוצג כש-JavaScript מושבת
- [כתיבה של Macrobenchmark][11]
- [תיעוד מדדי Macrobenchmark][12]
- [ניתוח ואופטימיזציה של הפעלת האפליקציה {:#app-startup-analysis-optimization}][13]