Confrontare le metriche di Scrivi e Visualizza

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

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 mostra le best practice per la migrazione di un'app basata su View a Compose.

Dimensioni dell'APK

L'aggiunta di librerie al progetto ne 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 Strumento di analisi APK.

Quando è stato aggiunto Compose a Sunflower, le dimensioni dell'APK sono aumentate da 2252 KB a 3034 KB, con un aumento di 782 KB. L'APK generato era costituito dalla build dell'interfaccia utente con un mix di Views e Compose. Questo aumento è prevedibile in quanto sono state aggiunte dipendenze aggiuntive 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 riduzione di 68 KB. Questa diminuzione è dovuta alla rimozione delle dipendenze di visualizzazione inutilizzate, come AppCompat e ConstraintLayout.

Durata della build

L'aggiunta di Compose aumenta il tempo di compilazione dell'app, poiché il compilatore Compose elabora i composable 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 compilazione 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, 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, ad esempio 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 in termini di 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 alle prestazioni di runtime in Jetpack Compose per aiutarti a capire come si confrontano le prestazioni di Jetpack Compose con quelle del sistema View e come misurarle.

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 Ciclo di vita dei composables e Fasi di Jetpack Compose.

Profili di baseline

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 baseline 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 baseline 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 viene disegnato sullo schermo, ad esempio 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 componente 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 UI sono semplici funzioni componibili le cui informazioni vengono scritte nella composizione in modo riproducibile. Ciò contribuisce a ridurre 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 delle startup

Il sistema di visualizzazione deve gonfiare 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, ci sono 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 di 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 scattosità nelle app Compose.