Confrontare le metriche di Scrivi e Visualizza

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

Dimensioni dell'APK e tempi di compilazione

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

Dimensioni APK

L'aggiunta di librerie al progetto aumenta le dimensioni dell'APK. I seguenti risultati si riferiscono all'APK di release ridotto di ogni progetto con riduzione di risorse e codice abilitata, utilizzando la modalità completa R8 e misurati utilizzando APK Analyzer.

Quando è stato 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 dell'interfaccia utente con un mix di View e Compose. Questo aumento è prevedibile in quanto sono state aggiunte dipendenze aggiuntive a Sunflower.

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

Ora build

L'aggiunta di Compose aumenta il tempo di build dell'app, poiché il compilatore Compose elabora i composable nell'app. I seguenti risultati sono stati ottenuti utilizzando lo strumento gradle-profiler autonomo, 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 è stato aggiunto per la prima volta Compose a Sunflower, il tempo di compilazione medio è aumentato da 299 ms a 399 ms, con un aumento di 100 ms. Questa durata è dovuta al compilatore Compose che esegue attività aggiuntive per trasformare il codice Compose definito nel progetto.

Al contrario, il tempo di compilazione medio è sceso a 342 ms, con una riduzione di 57 ms, al termine della migrazione di Sunflower a Compose. Questa riduzione può essere attribuita a diversi fattori che riducono collettivamente il tempo di compilazione, come la rimozione del data binding, la migrazione delle dipendenze che utilizzano kapt a KSP e l'aggiornamento di diverse dipendenze alle loro versioni più recenti.

Riepilogo

L'adozione di Compose aumenterà effettivamente le dimensioni dell'APK della tua app e migliorerà anche le prestazioni del tempo di compilazione dell'app grazie al processo di compilazione del codice Compose. Questi compromessi, tuttavia, devono essere valutati rispetto ai vantaggi di Compose, in particolare per quanto riguarda l'aumento della produttività degli sviluppatori quando si adotta 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 manutenibilità del codice.

Puoi leggere altri case study in Adotta Compose per Teams.

Rendimento del runtime

Questa sezione tratta argomenti relativi al rendimento di runtime in Jetpack Compose per aiutarti a capire come si confronta Jetpack Compose con il rendimento del sistema View e come puoi misurarlo.

Ricompilazioni intelligenti

Quando alcune parti della UI non sono valide, Compose tenta di ricomporre solo le parti che devono essere aggiornate. Scopri di più in merito nella documentazione Ciclo di vita dei componenti componibili e Fasi di Jetpack Compose.

Profili di base

I profili di base sono un ottimo modo per velocizzare i percorsi utente comuni. L'inclusione di un profilo di base 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 just-in-time (JIT) per i percorsi di codice inclusi.

La libreria Jetpack Compose include il proprio profilo di base 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 base alla tua app per coprire i percorsi del 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 View

Ogni View che viene disegnato sullo schermo, come TextView, Button o ImageView, richiede allocazioni di memoria, monitoraggio esplicito dello stato e vari callback per supportare tutti i casi d'uso. Inoltre, il proprietario del View personalizzato deve implementare una logica esplicita per evitare il ridisegno quando non è necessario, ad esempio per l'elaborazione ripetitiva dei dati.

Jetpack Compose risolve questo problema in diversi modi. Compose non ha oggetti aggiornabili espliciti per le viste di disegno. Gli elementi dell'interfaccia utente sono semplici funzioni componibili le cui informazioni vengono scritte nella composizione in modo riproducibile. In questo modo si riducono il monitoraggio esplicito dello stato, le allocazioni di memoria e i callback solo ai composable che richiedono queste funzionalità, anziché richiederle per tutte le estensioni di un determinato tipo View.

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

Più passaggi di layout

I ViewGroup tradizionali hanno molte espressioni nelle API di misurazione e layout che li rendono soggetti a più passaggi di layout. Questi passaggi di layout multipli possono causare un lavoro esponenziale se eseguiti in punti nidificati specifici nella gerarchia della visualizzazione.

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

Visualizzare il rendimento dell'avvio

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

Benchmark Compose

In Jetpack Compose 1.0, esistono differenze notevoli tra il rendimento di un'app in modalità debug e release. Per i 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 pigra e la relativa dashboard per monitorare le regressioni.

Comporre l'installazione del profilo

Poiché Jetpack Compose è una libreria separata, non beneficia di Zygote, che precarica le classi e le risorse disegnabili del toolkit UI del sistema View. Jetpack Compose 1.0 utilizza l'installazione del profilo per le build release. Gli installatori di profili consentono alle app di specificare il codice critico da compilare in anticipo (AOT) al momento dell'installazione. Componi regole di installazione del profilo delle spedizioni che riducono i tempi di avvio e i problemi di prestazioni nelle app Compose.