Confrontare le metriche di Scrivi e Visualizza

Jetpack Compose accelera lo sviluppo dell'interfaccia utente e migliora lo sviluppo Android. Tuttavia, tieni presente come l'aggiunta di Compose a un'app esistente può influire su metriche quali dimensioni APK, build e prestazioni di runtime dell'app.

Dimensioni APK e tempi di build

Questa sezione analizza l'impatto sulle dimensioni degli APK e sul tempo di creazione esaminando l'app di esempio Sunflower, un'app che illustra le best practice per la migrazione di un'app basata sulle visualizzazioni a Compose.

Dimensioni APK

L'aggiunta di librerie al progetto aumenta le dimensioni dell'APK. I seguenti risultati sono riferiti all'APK di release minimizzata di ogni progetto in cui è abilitata la riduzione delle risorse e del codice, in modalità completa R8 e misurati mediante lo strumento APK Analyzer.

Solo visualizzazioni Visualizzazioni miste e Compose Solo scrittura
Dimensioni download 2252 kB 3034 kB 2966 kB

Quando hai aggiunto per la prima volta Compose a Sunflower, le dimensioni dell'APK sono aumentate da 2252 kB a 3034 kB, con un aumento di 782 kB. L'APK generato consisteva nella build dell'interfaccia utente con un mix di Visualizzazioni e Compose. Questo aumento è atteso poiché sono state aggiunte ulteriori dipendenze a Sunflower.

Al contrario, quando è stata eseguita la migrazione di Sunflower a un'app solo per Compose, le dimensioni dell'APK sono diminuite da 3034 kB a 2966 kB, con una riduzione di 68 kB. Questa diminuzione è dovuta alla rimozione delle dipendenze View inutilizzate, come AppCompat e ConstraintLayout.

Ora build

L'aggiunta di Compose aumenta il tempo di compilazione dell'app poiché il compilatore di Compose elabora i componenti componibili nell'app. I seguenti risultati sono stati ottenuti utilizzando lo strumento autonomo gradle-profiler, che esegue una build più volte in modo che sia possibile ottenere un tempo medio di compilazione per la durata della build di debug di Girasole:

gradle-profiler --benchmark --project-dir . :app:assembleDebug
Solo visualizzazioni Visualizzazioni miste e Compose Solo scrittura
Tempo medio di compilazione 299,47 ms 399,09 ms 342,16 ms

Quando aggiungi per la prima volta Compose a Sunflower, il tempo medio di compilazione è aumentato da 299 ms a 399 ms, con un aumento di 100 ms. Questa durata è dovuta al fatto che il compilatore di Compose esegue attività aggiuntive per trasformare il codice di Compose definito nel progetto.

Al contrario, il tempo medio di compilazione è sceso a 342 ms, una riduzione di 57 ms, quando è stata completata la migrazione di Girasole a Compose. Questa riduzione può essere attribuita a diversi fattori che collettivamente riducono i tempi di build, come la rimozione dell'associazione di dati, la migrazione delle dipendenze che utilizzano kapt a KSP e l'aggiornamento di diverse dipendenze alle versioni più recenti.

Riepilogo

L'adozione di Compose aumenterà in modo efficace le dimensioni dell'APK dell'app e incrementa anche le prestazioni in termini di tempo di build dell'app a causa del processo di compilazione del codice di Compose. Questi compromessi, tuttavia, devono essere valutati rispetto ai vantaggi di Compose, in particolare in relazione all'aumento della produttività degli sviluppatori quando adotta Compose. Ad esempio, il team del Play Store ha scoperto che l'UI di scrittura richiede molto meno codice, a volte fino al 50%, aumentando così la produttività e la gestibilità del codice.

Puoi leggere altri case study in Adottare Compose per Teams.

Prestazioni del runtime

Questa sezione tratta argomenti relativi alle prestazioni di runtime in Jetpack Compose per comprendere come confrontare Jetpack Compose con le prestazioni del sistema View e come misurarle.

Ricomposizioni intelligenti

Quando alcune parti dell'interfaccia utente non sono valide, Compose prova a ricomporre solo le porzioni che devono essere aggiornate. Scopri di più nella documentazione relativa al ciclo di vita dei componibili e alle fasi di Jetpack Compose.

Profili di riferimento

I profili di riferimento sono un ottimo modo per accelerare i percorsi degli utenti più comuni. L'inclusione di un profilo di riferimento nell'app può migliorare la velocità di esecuzione del codice di circa il 30% dal primo avvio evitando i passaggi di interpretazione e compilazione just-in-time (JIT) per i percorsi di codice inclusi.

La libreria Jetpack Compose include il proprio profilo di riferimento e riceverai automaticamente queste ottimizzazioni quando utilizzi Compose nell'app. Tuttavia, queste ottimizzazioni interessano solo i percorsi di codice all'interno della libreria Compose, quindi ti consigliamo di aggiungere un profilo di riferimento alla tua app per coprire i percorsi di codice al di fuori di Compose.

Confronto con il sistema di visualizzazione

Jetpack Compose offre molti miglioramenti rispetto al sistema View. Questi miglioramenti sono descritti nelle sezioni seguenti.

Tutto estende la visualizzazione

Ogni View disegnato sullo schermo, ad esempio TextView, Button o ImageView, richiede allocazioni della memoria, monitoraggio esplicito dello stato e vari callback per supportare tutti i casi d'uso. Inoltre, il proprietario View personalizzato deve implementare una logica esplicita per impedire il ridisegno quando non è necessario, ad esempio in caso di elaborazioni di dati ripetitive.

Jetpack Compose affronta questo problema in diversi modi. La scrittura non ha oggetti espliciti aggiornabili per le viste del disegno. Gli elementi UI sono semplici funzioni componibili le cui informazioni vengono scritte nella composizione in modo riproducibile. Ciò consente di ridurre il monitoraggio esplicito dello stato, le allocazioni della memoria e i callback solo ai componibili che richiedono tali funzionalità, invece di richiederli per tutte le estensioni di un determinato tipo View.

Inoltre, Compose offre ricomposizioni intelligenti, riproducendo il risultato disegnato in precedenza se non è necessario apportare modifiche.

Più pass per il layout

I gruppi ViewGroups tradizionali hanno un'elevata espressività nelle API di misura e layout che li rendono soggetti a più passaggi di layout. Questi passaggi multipli del layout possono causare un lavoro esponenziale se vengono eseguiti in punti nidificati specifici nella gerarchia delle viste.

Jetpack Compose applica un singolo pass per il layout per tutti gli elementi componibili di layout tramite il relativo contratto API. Ciò consente a Compose di gestire in modo efficiente alberi di interfaccia utente profondi. Se sono necessarie più misurazioni, Compose dispone di misurazioni intrinseche.

Visualizza prestazioni avvio

Il sistema di visualizzazioni deve incrementare i layout XML quando viene mostrato per la prima volta un layout specifico. Questo costo viene salvato in Jetpack Compose, poiché i layout sono scritti in Kotlin e compilati come il resto dell'app.

Scrittura benchmark

In Jetpack Compose 1.0, esistono differenze significative tra le prestazioni di un'app nelle modalità debug e release. Per tempi rappresentativi, utilizza sempre la build release anziché debug durante la profilazione della tua app.

Per controllare le prestazioni del codice Jetpack Compose, puoi utilizzare la libreria Jetpack Macrobenchmark. Per scoprire come utilizzarlo con Jetpack Compose, consulta il progetto MacrobenchmarkSample.

Il team di Jetpack Compose utilizza anche Macrobenchmark per rilevare eventuali regressioni. Ad esempio, consulta il benchmark per la colonna lazy e il relativo dashboard per monitorare le regressioni.

Componi installazione profilo

Poiché Jetpack Compose è una libreria non in bundle, non trarre vantaggio da Zygote che precarica le classi e i disegnabili del toolkit dell'UI del sistema View. Jetpack Compose 1.0 utilizza l'installazione del profilo per le build di release. I programma di installazione dei profili consentono alle app di specificare il codice critico affinché venga compilato in anticipo (AOT) al momento dell'installazione. Compose invia regole di installazione del profilo che riducono i tempi di avvio e il jank delle app Compose.