פרופילים בסיסיים של ההשוואה לשוק עם ספריית Macrobenchmark

מומלץ להשתמש ב-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. מידע נוסף על כל סוגי המדדים זמין במאמר תיעוד מדדים של Macrobenchmark.

זמן ההצגה במסך מלא

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

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

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

מומלץ עבורך

• הערה: טקסט הקישור מוצג כש-JavaScript מושבת
• [כתיבה של Macrobenchmark][11]
• [תיעוד מדדי Macrobenchmark][12]
• [ניתוח ואופטימיזציה של הפעלת האפליקציה {:#app-startup-analysis-optimization}][13]