Eseguire il benchmark dei profili di riferimento con la libreria Macrobenchmark

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

I macrobenchmark consentono di controllare la compilazione della 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 i vantaggi 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 Ora in Android campione 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) al contrario dell'assenza di compilazione (324,8 ms).

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

Mentre l'esempio precedente mostra i risultati relativi all'avvio dell'app acquisiti con StartupTimingMetric, ci sono altre metriche importanti che vale la pena prendere in considerazione, come FrameTimingMetric. Per ulteriori informazioni su tutti i tipi di metriche, consulta Acquisizione delle metriche di Macrobenchmark.

Tempo per la visualizzazione completa

L'esempio precedente misura il tempo alla visualizzazione iniziale (TTID), ovvero il tempo impiegato dall'app per produrre il primo frame. Tuttavia, ciò non riflette necessariamente il tempo che deve trascorrere prima che l'utente inizi a interagire con la tua app. La metrica Tempo per la visualizzazione completa (TTFD) è più utile per misurare e ottimizzare i percorsi di codice necessari per avere uno stato dell'app completamente utilizzabile.

Consigliamo di eseguire l'ottimizzazione sia per il TTID che per il TTFD, poiché entrambi sono importanti. Un TTID basso consente all'utente di capire che l'app è in fase di avvio. È importante mantenere breve la TTFD per garantire che l'utente possa interagire rapidamente con l'app.

Per strategie relative ai report quando l'interfaccia utente dell'app è completamente tracciata, consulta Migliorare l'accuratezza dei tempi di avvio.

  • Nota: il testo del link viene visualizzato quando JavaScript è disattivato
  • [Scrivi un Macrobenchmark][11]
  • [Acquisizione di metriche Macrobenchmark][12]
  • [Analisi e ottimizzazione dell'avvio dell'app {:#app-startup-analysis- responsabile}][13]