L'ottimizzazione delle performance in .NET MAUI nel 2026 si gioca su quattro leve principali: compilazione AOT (Ahead-of-Time), virtualizzazione corretta delle liste, gestione efficiente delle immagini e disconnessione esplicita degli handler per evitare memory leak. Con il rilascio di .NET 10 e il supporto NativeAOT stabile su iOS, un'app MAUI ben configurata può ridurre lo startup time del 40-60% rispetto a una build di default e mantenere uno scroll fluido a 60fps anche con migliaia di elementi. In questa guida vedremo come ottenere questi risultati con codice reale e misurabile.
NativeAOT su iOS in .NET 9 e .NET 10 riduce lo startup time fino al 50% e la dimensione dell'app del 30-40%.
L'uso corretto di CollectionView con x:DataType e binding compilati è la differenza tra 60fps e jank visibile.
I memory leak in MAUI provengono quasi sempre da event handler non disconnessi e da riferimenti agli handler nativi non rilasciati.
L'image caching con downsample automatico riduce il consumo di memoria fino al 70% in liste con immagini ad alta risoluzione.
Il MauiProgram.cs è il punto critico per lo startup: registrazioni lazy e ConfigureFonts minimale fanno la differenza.
Strumenti come dotnet-trace, dotMemory e Xcode Instruments sono indispensabili per profilare in modo oggettivo.
Perché la mia app .NET MAUI è lenta all'avvio?
Quando un'app .NET MAUI è lenta all'avvio, le cause più frequenti sono tre: assenza di compilazione AOT, registrazione eager di troppi servizi nel container DI, e caricamento sincrono di risorse pesanti (font, immagini, dizionari) prima del primo frame. In una build Debug su Android, l'inizializzazione del runtime Mono e il JIT possono aggiungere 800ms-1.5s solo per arrivare al MauiProgram.CreateMauiApp(). In Release con AOT, lo stesso percorso scende sotto i 300ms su un dispositivo di fascia media.
Una metrica utile da monitorare è il time-to-first-meaningful-paint: il tempo che intercorre tra il tap sull'icona dell'app e il momento in cui la prima schermata interattiva è visibile. Su iOS è misurabile con Xcode Instruments → App Launch; su Android con adb shell am start -W. Sotto il secondo è l'obiettivo realistico per il 2026; sotto i 500ms è eccellente. Se la tua app è sopra i due secondi, il problema quasi sempre è nel MauiProgram.cs, non nel codice della prima pagina.
Il secondo collo di bottiglia è il numero di assembly caricati. Ogni pacchetto NuGet aggiunto al progetto MAUI viene risolto a runtime e impatta sia la dimensione del binario sia il warm-up della VM. Controlla periodicamente le dipendenze con dotnet list package --include-transitive e rimuovi tutto ciò che non è effettivamente referenziato, un classico esempio è System.Reactive incluso da una libreria di logging ma mai usato.
AOT e NativeAOT in .NET MAUI 10
Con .NET 9 il supporto NativeAOT per iOS è diventato stabile e in .NET 10 è arrivato anche un solido Full AOT per Android via RunAOTCompilation. Per gli obiettivi di performance del 2026, la configurazione minima consigliata in .csproj per le build Release è la seguente.
L'opzione AndroidEnableProfiledAot usa un profilo di esecuzione per compilare in anticipo solo i metodi effettivamente eseguiti durante lo startup, riducendo la dimensione dell'APK rispetto a un Full AOT puro. Su iOS, PublishAot attiva la nuova pipeline NativeAOT documentata nei documenti ufficiali NativeAOT per .NET MAUI.
Come ridurre lo startup time
Lo startup di un'app MAUI passa attraverso MauiProgram.CreateMauiApp(). Tutto ciò che fai qui ritarda il primo frame. Mi è capitato, su un progetto retail dell'anno scorso, di scoprire che 600ms di startup time venivano da un semplice File.ReadAllText piazzato nel costruttore di un servizio singleton: spostarlo in un task asincrono dopo il primo render ha reso l'app praticamente istantanea. La regola d'oro è: registra, non istanziare. Usa AddTransient/AddSingleton per i servizi, ma evita di chiamare metodi che fanno I/O, leggono file di configurazione o inizializzano database. Quel lavoro va spostato dopo il primo frame visibile.
public static MauiApp CreateMauiApp()
{
var builder = MauiApp.CreateBuilder();
builder
.UseMauiApp<App>()
.ConfigureFonts(fonts =>
{
// Caricare SOLO i font realmente usati nella prima schermata
fonts.AddFont("Inter-Regular.ttf", "InterRegular");
fonts.AddFont("Inter-Bold.ttf", "InterBold");
});
// Registrazioni lazy: i servizi vengono creati al primo Resolve
builder.Services.AddSingleton<IDatabaseService, SqliteDatabaseService>();
builder.Services.AddSingleton<IApiClient, HttpApiClient>();
builder.Services.AddTransient<MainPageViewModel>();
// NIENTE I/O qui: niente File.ReadAllText, niente HttpClient.GetAsync,
// niente connection.Open(): tutto va in un Task.Run() dopo OnAppearing.
return builder.Build();
}
Il database SQLite, per esempio, non deve essere aperto in MauiProgram. Implementa l'apertura lazy nel servizio e chiama InitializeAsync() da OnAppearing della prima pagina, in un Task.Run che non blocchi la UI. Lo stesso vale per il caricamento di preferenze utente e per il warm-up dell'HttpClient.
Un'altra ottimizzazione spesso trascurata è la splash screen statica: una SplashScreen definita nel .csproj con BaseSize e Color viene mostrata istantaneamente dal sistema operativo, prima ancora che il runtime .NET parta. Questo nasconde percettivamente lo startup al utente. Se hai bisogno di animazioni, fai partire l'animazione vera solo quando la prima pagina è caricata. Evita di sovrapporre Lottie animation alla splash nativa.
CollectionView ad alte prestazioni
Il CollectionView è il controllo più usato e quello con più trappole. Per garantire 60fps con migliaia di elementi, devi attivare tre cose: virtualizzazione corretta, x:DataType per binding compilati e ItemSizingStrategy="MeasureFirstItem" quando gli elementi hanno tutti la stessa altezza. La documentazione ufficiale dei controlli è disponibile sui docs Microsoft di CollectionView.
x:DataType è cruciale: senza di esso, MAUI usa reflection per risolvere ogni binding a runtime. Con x:DataType attivo e MauiEnableXamlCBindingWithSourceCompilation impostato su true nel .csproj, i binding diventano metodi C# generati al compile time, letteralmente 5-10x più veloci di quelli con reflection. Per pagine complesse questo è il singolo cambio che produce il guadagno più grande. Quando l'ho applicato su una lista di transazioni di un'app fintech, lo scroll è passato da 35-40fps a un solido 60fps senza toccare altro.
Evita assolutamente di usare ListView nel 2026: è deprecato e mantiene la vecchia architettura con renderer; le sue performance sono incomparabili rispetto a CollectionView. Se stai migrando da Xamarin.Forms, sostituire ListView con CollectionView è un'attività che ripaga da sola in termini di fluidità di scroll.
Gestione e caching delle immagini
Le immagini sono la prima causa di OutOfMemory su Android e di rallentamenti su iOS. .NET MAUI ha un caching integrato, ma di default non fa downsample: se carichi una JPEG da 4000x3000px in una Image di 64x64, in memoria occupa comunque circa 48MB di bitmap. In una lista di 50 prodotti, sono 2.4GB di RAM consumati per niente.
La soluzione del 2026 è FFImageLoading.Maui oppure il nuovissimo CachedImage in CommunityToolkit.Maui, entrambi con downsample automatico. Esempio con il toolkit:
Con DownsampleToViewSize attivo, l'immagine viene decodificata alla risoluzione effettiva del controllo, non a quella originale. La CacheDuration di 7 giorni evita download ripetuti per immagini stabili (cataloghi prodotti, avatar). Per asset locali invece, usa sempre formati vettoriali (SVG) per icone e raster compressi (WebP) per foto. Su Android WebP è supportato nativamente, su iOS dal 14 in poi.
Per maggiore controllo, evita di caricare immagini durante lo scroll: implementa un ScrollView.Scrolled handler che pausa il decoding durante il fling e lo riprende quando lo scroll si ferma. Questo elimina il jank visibile su dispositivi di fascia bassa. La nostra guida a Shell Navigation in .NET MAUI spiega come strutturare la navigazione in modo da non ricaricare immagini quando l'utente torna indietro.
Memory leak e disconnessione degli handler
Onestamente, in .NET MAUI i memory leak hanno una causa principale: gli handler nativi che mantengono un riferimento alla view managed anche dopo che la pagina è stata chiusa. Il sintomo è classico: navighi tra le pagine, l'uso di memoria cresce monotonamente, e dopo 20-30 navigazioni l'app crasha o diventa lentissima.
Dal .NET 9 in poi esiste il pattern DisconnectHandler() esplicito che va chiamato quando una pagina o un controllo non sono più necessari. Microsoft non lo chiama automaticamente per retrocompatibilità: spetta a te.
public partial class ProductDetailPage : ContentPage
{
private readonly ProductDetailViewModel _viewModel;
public ProductDetailPage(ProductDetailViewModel viewModel)
{
InitializeComponent();
BindingContext = _viewModel = viewModel;
}
protected override void OnDisappearing()
{
base.OnDisappearing();
// Solo se la pagina sta veramente uscendo dallo stack, non se
// l'utente sta solo navigando in avanti (caso modal/Shell).
if (!Navigation.NavigationStack.Contains(this))
{
// Disconnetti tutti gli handler dei controlli figli
this.DisconnectHandlers();
// Cancella event handler manuali
_viewModel.PropertyChanged -= OnViewModelPropertyChanged;
// Rilascia risorse pesanti del ViewModel
_viewModel.Dispose();
}
}
}
public static class VisualElementExtensions
{
public static void DisconnectHandlers(this Element element)
{
if (element is IVisualTreeElement vte)
{
foreach (var child in vte.GetVisualChildren())
if (child is Element e) e.DisconnectHandlers();
}
element.Handler?.DisconnectHandler();
}
}
Verifica i leak con dotMemory o con il Memory Graph Debugger di Xcode: se vedi istanze di ContentPage ancora vive dopo navigazione, hai un leak. Le cause comuni sono: event handler statici (MessagingCenter globale), WeakReference mancanti nei subscriber, closures che catturano this dentro task long-running. L'approccio MVVM corretto, descritto nella nostra guida a MVVM e Dependency Injection in .NET MAUI, riduce drasticamente questi problemi grazie all'uso di ObservableObject e messaggistica weak-reference.
Binding compilati e XAML ottimizzato
I binding compilati sono la differenza tra una UI reattiva e una UI che sembra "ingessata". Per attivarli globalmente, aggiungi al .csproj:
Con MauiStrictXamlCompilation attivo, qualsiasi errore XAML diventa errore di build invece che warning. Forzati a sistemarli: ogni warning XAML è un'occasione persa per il compilatore di generare codice ottimizzato. Aggiungi x:DataType a TUTTI i DataTemplate e a tutti i ContentPage:
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:vm="clr-namespace:MyApp.ViewModels"
x:DataType="vm:MainPageViewModel"
x:Class="MyApp.Views.MainPage">
<!-- Tutti i binding qui dentro sono compilati -->
</ContentPage>
Riduci anche il numero di nidificazioni nel visual tree: ogni StackLayout annidato è un layout pass aggiuntivo. Grid piatto con RowDefinitions e ColumnDefinitions è quasi sempre più performante di tre StackLayout annidati. Per layout complessi che cambiano dinamicamente, considera FlexLayout ma misura, perché gratis non è.
Infine, evita di usare StackLayout dentro ScrollView per liste lunghe: non virtualizza nulla. Usa sempre CollectionView. Lo so, sembra ovvio, ma in code review di progetti reali questo errore lo vedo ancora una volta su tre.
Profilare un'app MAUI: gli strumenti giusti
Senza misure oggettive, ogni ottimizzazione è solo un'intuizione (e nella mia esperienza, spesso si rivela sbagliata). Gli strumenti che uso quotidianamente sul mio team sono:
dotnet-trace: profiling CPU cross-platform. dotnet trace collect --process-id <pid> --profile cpu-sampling. Apri il file .nettrace con PerfView o speedscope.app.
dotMemory (JetBrains): per memory leak e snapshot diff. Indispensabile per scovare istanze di pagine non rilasciate.
Xcode Instruments (iOS): Time Profiler per CPU, Allocations per memoria, Energy Log per consumo batteria. Funziona anche su build .NET MAUI tramite il file .app generato.
Android Studio Profiler: CPU, Memory, Network in tempo reale. Collegabile a una build MAUI Android Debug.
MAUI Logging: la nuova API ILogger integrata con builder.Logging.AddDebug() in Debug. Usa categorie e log strutturati per misurare tempi di operazioni reali in produzione.
Per build di rilascio, integra le release notes ufficiali di .NET MAUI nel tuo workflow: ogni versione introduce miglioramenti di performance documentati. Il salto da .NET 8 a .NET 9 ha portato, da solo, miglioramenti misurabili del 15-25% sullo startup time grazie alle ottimizzazioni del rendering tree.
Checklist di performance prima del rilascio
Prima di pubblicare una nuova versione su App Store o Play Store, esegui questa checklist:
AOT abilitato: verifica con dotnet publish -c Release -f net10.0-android che RunAOTCompilation=true sia attivo nei log di build.
Trimming senza warning: nessun IL2026, IL2104, IL3050 nei log di publish.
Startup time misurato: adb shell am start -W su Android, Xcode Instruments su iOS. Target: < 1s su hardware di fascia media.
Memory baseline: dopo 10 navigazioni avanti/indietro, la memoria deve tornare entro +5% del baseline iniziale.
APK/IPA size: con full trim e AOT profilato, una MAUI app media sta sotto i 25MB su Android e 35MB su iOS nel 2026.
60fps su scroll: profila la pagina con la lista più lunga e verifica frame time < 16.6ms.
Cold start vs warm start: misura entrambi. Il warm start dovrebbe essere < 300ms.
Network calls in startup: zero. Se ci sono, spostali dopo il primo frame.
Mantieni questi numeri in un foglio di calcolo versionato release per release. La regressione di performance silenziosa è il bug più subdolo: nessuno la nota fino a quando un cliente chiama a lamentarsi che "l'app ultimamente è lenta". Una baseline misurabile evita questo scenario.
Domande Frequenti
Cos'è AOT in .NET MAUI e quando dovrei attivarlo?
AOT (Ahead-of-Time) è la compilazione del codice IL in codice nativo a build time, anziché a runtime tramite JIT. In .NET MAUI 10 dovresti attivarlo sempre nelle build Release: riduce lo startup time del 30-50% e migliora il throughput. NativeAOT su iOS e Full AOT su Android sono ormai stabili e raccomandati per produzione.
Perché il mio CollectionView in .NET MAUI è lento?
Le tre cause più comuni sono: mancanza di x:DataType nel DataTemplate (forza l'uso di reflection per i binding), uso di ItemSizingStrategy="MeasureAllItems" con liste eterogenee, e immagini non virtualizzate con risoluzione piena. Aggiungere x:DataType e usare un image loader con downsample automatico risolve il 90% dei casi.
Come evito i memory leak in .NET MAUI?
Disconnetti esplicitamente gli handler con DisconnectHandler() in OnDisappearing, evita event handler statici globali, e usa WeakReferenceMessenger al posto del vecchio MessagingCenter. Profila regolarmente con dotMemory o Xcode Memory Graph per verificare che le pagine vengano effettivamente collezionate dal GC dopo la navigazione.
Quanto migliora le performance passare da Xamarin.Forms a .NET MAUI?
Dipende dal codice, ma su benchmark standard una app MAUI ben configurata mostra startup time 25-40% più rapido di Xamarin.Forms, scroll del 30-50% più fluido grazie alla nuova architettura degli Handler, e consumo di memoria 15-25% inferiore. La differenza maggiore si vede su Android di fascia media e bassa.
Quali strumenti uso per profilare un'app .NET MAUI?
Per CPU: dotnet-trace cross-platform e Xcode Time Profiler su iOS. Per memoria: JetBrains dotMemory e Memory Graph Debugger di Xcode. Per UI rendering: Android Studio Profiler e Instruments di Xcode (Core Animation template). Profila sempre in Release con AOT attivo, mai in Debug.
Tutto su Shell Navigation in .NET MAUI 10: AppShell, rotte assolute e relative, deep linking su Android e iOS, parametri tipizzati e integrazione MVVM, con esempi reali dalla produzione.
Scopri come strutturare app .NET MAUI con architettura MVVM e Dependency Injection. Dal MVVM Toolkit con source generator alla Shell Navigation, dalla messaggistica alla validazione, fino al testing completo dei ViewModel.
