Confrontare le metriche di Scrivi e Visualizza

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

Dimensioni dell'APK e tempi di build

Questa sezione illustra l'impatto sulle dimensioni dell'APK e sul tempo di build esaminando l'app di esempio Sunflower, un'app che mostra le best practice per la migrazione di un'app basata su View a Compose.

Dimensioni dell'APK

L'aggiunta di librerie al progetto aumenta le dimensioni dell'APK. I seguenti risultati riguardano l'APK di release minimizzato di ogni progetto con la riduzione delle risorse e del codice attivata, utilizzando la modalità completa R8 e misurata utilizzando lo Strumento di analisi APK.

Quando abbiamo aggiunto Compose a Sunflower, le dimensioni dell'APK sono aumentate da 2252 kB a 3034 kB, con un incremento di 782 kB. L'APK generato era costituito dalla build della UI con un mix di visualizzazioni e Compose. Questo aumento è prevedibile, poiché sono state aggiunte altre dipendenze a Sunflower.

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

Durata della build

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

gradle-profiler --benchmark --project-dir . :app:assembleDebug

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

Al contrario, il tempo di build medio è sceso a 342 ms, con una diminuzione di 57 ms, quando la migrazione di Sunflower a Compose è stata completata. Questa riduzione può essere attribuita a diversi fattori che, insieme, riducono il tempo 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à effettivamente le dimensioni dell'APK della tua app e anche le prestazioni del tempo di build dell'app a causa del processo di compilazione del codice di Compose. Tuttavia, questi compromessi devono essere valutati rispetto ai vantaggi di Compose, in particolare per quanto riguarda l'aumento della produttività degli sviluppatori quando adottano Compose. Ad esempio, il team del Play Store ha scoperto che la scrittura dell'interfaccia utente richiede molto meno codice, a volte fino al 50%, aumentando così la produttività e la gestibilità del codice.

Puoi leggere altri case study in Adotta Compose per i team.

Prestazioni di runtime

Questa sezione tratta argomenti relativi alle prestazioni di runtime in Jetpack Compose per aiutarti a capire come si confrontano con quelle del sistema View e come puoi misurarle.

Ricomposizioni intelligenti

Quando alcune parti della UI non sono valide, Compose tenta di ricomporre solo le parti 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 velocizzare i percorsi dell'utente comuni. L'inclusione di un profilo Baseline nella tua app può migliorare la velocità di esecuzione del codice di circa il 30% dal primo avvio, evitando i passaggi di interpretazione e compilazione JIT (just-in-time) per i percorsi del codice inclusi.

La libreria Jetpack Compose include il proprio profilo di riferimento e ottieni automaticamente queste ottimizzazioni quando utilizzi Compose nella tua app. Tuttavia, queste ottimizzazioni influiscono solo sui percorsi del codice all'interno della libreria Compose, pertanto ti consigliamo di aggiungere un profilo di riferimento alla tua app per coprire i percorsi del codice al di fuori di Compose.

Confronto con il sistema View

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

Tutto estende View

Ogni View che disegna 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 della View personalizzata deve implementare una logica esplicita per impedire il ridisegno quando non è necessario, ad esempio per l'elaborazione ripetitiva dei dati.

Jetpack Compose risolve questo problema in diversi modi. Compose non dispone di oggetti aggiornabili espliciti per il disegno delle visualizzazioni. Gli elementi UI sono semplici funzioni componibili le cui informazioni vengono scritte nella composizione in modo riproducibile. In questo modo, il monitoraggio dello stato esplicito, le allocazioni della memoria e i callback vengono ridotti solo ai componibili che richiedono queste funzionalità, anziché essere richiesti da tutte le estensioni di un determinato tipo View.

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

Più passaggi di layout

I ViewGroup tradizionali hanno un'elevata espressività nelle API di misurazione e layout, il che li rende soggetti a più passaggi di layout. Questi passaggi di layout multipli possono causare un lavoro esponenziale se eseguiti in punti nidificati specifici della gerarchia di oggetti View.

Jetpack Compose applica un singolo passaggio di layout per tutti i composabili di layout tramite il suo contratto API. In questo modo, Compose può gestire in modo efficiente alberi della UI profondi. Se sono necessarie più misurazioni, Compose dispone di misurazioni intrinseche.

Visualizza le prestazioni di avvio

Il sistema di visualizzazione deve espandere i layout XML quando mostra un determinato layout per la prima volta. Questo costo viene risparmiato in Jetpack Compose, poiché i layout sono scritti in Kotlin e compilati come il resto dell'app.

Benchmark Compose

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

Per verificare il rendimento 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 che possono verificarsi. Ad esempio, consulta il benchmark per la colonna lazy e la relativa dashboard per monitorare le regressioni.

Installazione del profilo di Compose

Poiché Jetpack Compose è una libreria non integrata, non trae vantaggio da Zygote, che precarica le classi e gli elementi drawable del toolkit UI del sistema View. Jetpack Compose 1.0 utilizza l'installazione del profilo per le build di release. I programmi di installazione dei profili consentono alle app di specificare il codice critico da compilare in modalità ahead-of-time (AOT) al momento dell'installazione. Compose include regole di installazione del profilo che riducono il tempo di avvio e i jank nelle app Compose.