Confrontare le metriche di Scrivi e Visualizza

Jetpack Compose accelera lo sviluppo dell'UI e migliora lo sviluppo di Android. Tuttavia, tieni presente che l'aggiunta di Compose a un'app esistente può influire su metriche come le dimensioni dell'APK, la compilazione e il rendimento in fase di esecuzione di un'app.

Dimensioni dell'APK e tempi di compilazione

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

Dimensioni APK

L'aggiunta di librerie al progetto ne aumenta le dimensioni dell'APK. I seguenti risultati fanno riferimento all'APK di release minimizzato di ogni progetto con compressione delle risorse e del codice abilitata, utilizzando la modalità completa di R8 e misurati utilizzando APK Analyzer.

Al primo inserimento di Compose in Sunflower, le dimensioni dell'APK sono aumentate da 2252 KB a 3034 KB, ovvero un aumento di 782 KB. L'APK generato era costituito dalla compilazione dell'interfaccia utente con una combinazione di Views e Compose. Questo aumento è previsto in quanto sono state aggiunte altre dipendenze a Sunflower.

Al contrario, quando è stata eseguita la migrazione di Sunflower a un'app di sola scrittura, le dimensioni dell'APK sono diminuite da 3034 kB a 2966 kB, ovvero una diminuzione di 68 kB. Questo calo è stato causato dalla rimozione di dipendenze della visualizzazione inutilizzate, come AppCompat e ConstraintLayout.

Ora build

L'aggiunta di Compose aumenta il tempo di compilazione dell'app, poiché il compilatore Compose elabora i composable all'interno dell'app. I seguenti risultati sono stati ottenuti utilizzando lo strumento autonomo gradle-profiler, che esegue una compilazione più volte in modo da ottenere un tempo di compilazione medio per la durata della compilazione 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, ovvero un aumento di 100 ms. Questa durata è dovuta al fatto che il compilatore di Compose svolge attività aggiuntive per trasformare il codice di Compose definito nel progetto.

Al contrario, il tempo medio di compilazione è sceso a 342 ms, ovvero una diminuzione 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 versioni più recenti.

Riepilogo

L'adozione di Compose aumenterà in modo efficace le dimensioni dell'APK della tua app e ne aumenterà anche le prestazioni in termini di tempo di creazione dell'app grazie al 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 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 Adottare Compose per Teams.

Prestazioni del runtime

Questa sezione tratta gli argomenti relativi alle prestazioni di runtime in Jetpack Compose per comparare le prestazioni di Jetpack Compose con quelle del sistema di visualizzazione e come misurarle.

Ricostruzioni intelligenti

Quando parti dell'interfaccia utente non sono valide, Compose tenta di ricompilare solo le parti che devono essere aggiornate. Per ulteriori informazioni, consulta la documentazione Ciclo di vita dei componenti componibili e Fasi di Jetpack Compose.

Profili di riferimento

I profili di riferimento sono un ottimo modo per velocizzare i percorsi utente più comuni. L'inclusione di un profilo di riferimento nella tua app può migliorare la velocità di esecuzione del codice di circa il 30% rispetto al primo avvio evitando i passaggi di compilazione just-in-time (JIT) per i percorsi di codice inclusi.

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

Confronto con il sistema View

Jetpack Compose presenta molti miglioramenti rispetto al sistema di visualizzazione. Questi miglioramenti sono descritti nelle sezioni seguenti.

Tutto estende la visualizzazione

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

Jetpack Compose risolve questo problema in diversi modi. Compose non ha oggetti espliciti aggiornati per le visualizzazioni dei disegni. Gli elementi dell'interfaccia utente sono semplici funzioni componibili whose information is written to the composition in a replayable way. Ciò consente di ridurre il monitoraggio dello stato esplicito, le allocazioni della memoria e i callback solo per gli elementi componibili che richiedono tali funzionalità, anziché richiederle da 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 un'elevata espressività nelle API di misura e layout che li rendono soggetti a più passaggi di layout. Queste ripetute passate di layout possono causare un lavoro esponenziale se eseguite in punti nidificati specifici nella gerarchia della vista.

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

Visualizzare il rendimento all'avvio

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

Benchmark Compose

In Jetpack Compose 1.0 esistono differenze significative tra il rendimento di un'app nelle modalità debug e release. Per tempi rappresentativi, sempre utilizza la build release anziché debug quando esegui il profiling della tua app.

Per controllare il rendimento del codice Jetpack Compose, puoi utilizzare la libreria Jetpack Macrobenchmark. Per scoprire come usarlo 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 le colonne lazy e la relativa dashboard per monitorare le regressioni.

Installazione del profilo di composizione

Poiché Jetpack Compose è una libreria non in bundle, non beneficia di Zygote, che precarica le classi e i drawable del toolkit dell'interfaccia utente del sistema View. Jetpack Compose 1.0 utilizza l'installazione del profilo per le build release. I programmi di installazione del profilo consentono alle app di specificare il codice critico da compilare in anticipo (AOT) al momento dell'installazione. Compose fornisce regole di installazione del profilo che riducono i tempi di avvio e i problemi di aggiornamento nelle app Compose.