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

מומלץ להשתמש ב-Jetpack Macrobenchmark כדי לבדוק את הביצועים של אפליקציה כשפרופילי Baseline מופעלים, ואז להשוות את התוצאות האלה לתוצאות של בדיקת ביצועים כשפרופילי Baseline מושבתים. בגישה הזו אפשר למדוד את זמן ההפעלה של האפליקציה – גם את הזמן עד לתצוגה הראשונית וגם את הזמן עד לתצוגה המלאה – או את ביצועי העיבוד בזמן הריצה, כדי לראות אם הפריימים שנוצרו עלולים לגרום לבעיות.

בעזרת מדדי ביצועים רחבים אפשר לשלוט בהידור לפני המדידה באמצעות CompilationMode API. אפשר להשתמש בערכים שונים של CompilationMode כדי להשוות את הביצועים במצבי קימפול שונים. קטע הקוד הבא מראה איך משתמשים בפרמטר CompilationMode כדי למדוד את היתרון של פרופילי Baseline:

@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()
        }
    ) {
        uiAutomator {
            startApp(packageName)
            onElement(5_000) { viewIdResourceName == "my-content"}
        }
    }
}

בצילום המסך הבא אפשר לראות את התוצאות ישירות ב-Android Studio עבור אפליקציית הדוגמה Now in Android שהופעלה ב-Google Pixel 7. התוצאות מראות שהפעלת האפליקציה היא הכי מהירה כשמשתמשים בפרופילים של Baseline‏ (229.0ms) לעומת מצב שבו לא מתבצע קימפול (324.8ms).

תוצאות של ColdstartupBenchmark
איור 1. תוצאות של ColdStartupBenchmark הצגת הזמן עד להצגה הראשונית ללא קומפילציה (324ms), קומפילציה מלאה (315ms), קומפילציה חלקית (312ms) ופרופילים בסיסיים (229ms).

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

הזמן עד להצגה מלאה

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

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

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

הקודם
הגדרת היצירה של פרופיל הבסיס