Eseguire il benchmark dei profili di riferimento con la libreria Macrobenchmark

Ti consigliamo di utilizzare Jetpack Macrobenchmark per testare il rendimento di un'app quando i profili di riferimento sono abilitati e poi confrontare i risultati con un benchmark con i profili di riferimento disattivati. Con questo approccio, puoi misurare il tempo di avvio dell'app, sia il tempo necessario per la visualizzazione iniziale che per quella completa, o le prestazioni di rendering in fase di esecuzione per verificare se i frame prodotti possono causare scatti.

I macrobenchmark ti consentono di controllare la compilazione pre-misurazione utilizzando l'API CompilationMode. Utilizza valori CompilationMode diversi per confrontare il rendimento con stati di compilazione diversi. Il seguente snippet di codice mostra come utilizzare il parametro CompilationMode per misurare il vantaggio dei profili di riferimento:

@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)
    }
}

Nello screenshot seguente puoi vedere i risultati direttamente in Android Studio per l'app Now in Android sample eseguita su Google Pixel 7. I risultati mostrano che l'avvio dell'app è più rapido quando si utilizzano i profili di riferimento (229,0 ms) rispetto a quando non viene eseguita la compilazione (324,8 ms).

risultati di ColdstartupBenchmark
Figura 1. Risultati di ColdStartupBenchmark che mostrano il tempo di visualizzazione iniziale per nessuna compilazione (324 ms), compilazione completa (315 ms), compilazione parziale (312 ms) e Profili di riferimento (229 ms).

Sebbene l'esempio precedente mostri i risultati di avvio dell'app acquisiti con StartupTimingMetric, esistono altre metriche importanti da prendere in considerazione, come FrameTimingMetric. Per ulteriori informazioni su tutti i tipi di metriche, consulta Acquisire le metriche dei macrobenchmark.

Tempo di attesa per la visualizzazione completa

L'esempio precedente misura il tempo di attesa per la prima schermata (TTID), ovvero il tempo necessario all'app per produrre il primo frame. Tuttavia, questo non riflette necessariamente il tempo necessario prima che l'utente possa iniziare a interagire con l'app. La metrica tempo di visualizzazione completa (TTFD) è più utile per misurare e ottimizzare i percorsi di codice necessari per avere uno stato dell'app completamente utilizzabile.

Ti consigliamo di eseguire l'ottimizzazione sia per TTID che per TTFD, in quanto entrambi sono importanti. Un valore TTID basso aiuta l'utente a capire che l'app è effettivamente in esecuzione. È importante mantenere breve il TTFD per garantire che l'utente possa interagire rapidamente con l'app.

Per strategie su come generare report quando l'interfaccia utente dell'app è completamente visualizzata, consulta Migliorare la precisione dei tempi di avvio.

  • Nota: il testo del link viene visualizzato quando JavaScript è disattivato
  • [Scrivere un macrobenchmark][11]
  • [Acquisisci le metriche del macrobenchmark][12]
  • [Analisi e ottimizzazione dell'avvio dell'app {:#app-startup-analysis-optimization}][13]