Il problema del consumo di RAM in Windows 11 è finito sotto i riflettori direttamente da chi il sistema operativo lo sviluppa. Microsoft ha ammesso che una parte della memoria non serve solo a far girare programmi, servizi e driver, ma anche a costruire e disegnare le interfacce delle app integrate. E proprio qui si nasconde uno dei limiti più evidenti: le applicazioni basate su WinUI, il framework grafico moderno pensato per rimpiazzare pian piano molte interfacce storiche del sistema, oggi chiedono più memoria del previsto. Il risultato sono ritardi, scatti e tempi di apertura che lasciano un po’ a desiderare.
Le radici del problema sono lontane. Tutto parte con Windows 8 e prosegue nel 2015 con Windows 10, quando Microsoft cominciò ad affiancare alle classiche applicazioni Win32 nuovi modelli basati su XAML e Universal Windows Platform. Con Windows 11 la scelta è caduta sul Windows App SDK e su WinUI 3, separando gran parte delle tecnologie grafiche dal ciclo di aggiornamento del sistema. L’idea era permettere agli sviluppatori di creare app moderne senza abbandonare le API desktop. Peccato che, anni dopo, Windows continui a mescolare componenti Win32, XAML, React Native, contenuti WebView2 e vecchie finestre di sistema. Funziona, certo, ma l’efficienza non è il suo forte. Ora l’azienda conferma di lavorare a una revisione delle fondamenta di WinUI, con occhio di riguardo al consumo di memoria, alla qualità del rendering e all’affidabilità. Nessuna percentuale dichiarata, nessuna quantità precisa di RAM promessa. Il messaggio vero è un altro: prima di spostare altre parti della shell sul framework moderno, bisogna alleggerirlo.
Perché un’app semplice divora centinaia di megabyte
Aprendo il Task Manager può capitare di stupirsi. Un’applicazione con poche finestre e funzioni basilari occupa magari 200 o 300 MB di RAM. Il motivo è che un’app moderna deve caricare il runtime, i componenti XAML, le risorse grafiche, i font, i dizionari degli stili, i servizi di accessibilità e tutti gli oggetti che servono a comporre la finestra. Una fetta di quella memoria, poi, comprende pagine condivise con altri processi, cache che Windows può liberare quando serve e aree riservate che non corrispondono per forza a RAM fisica usata in quel momento.
Per capirci davvero non basta guardare la colonna Memoria nella scheda Processi. Strumenti come Process Explorer aiutano a distinguere il working set, cioè le pagine presenti nella memoria fisica, dalla memoria privata attribuibile solo a quel processo. Il punto è l’overhead introdotto dal framework: se dieci componenti in background chiedono ciascuno decine o centinaia di megabyte, il totale pesa. Su una macchina con 32 GB di RAM la cosa passa quasi inosservata. Su un portatile economico da 8 GB, invece, sale la probabilità che Windows debba spostare pagine poco usate nel file di paging. Un SSD è molto più rapido di un vecchio hard disk, ma resta comunque più lento della RAM. Da lì nascono attese, microblocchi e riaperture meno immediate.
WinUI 3, WebView2 e cosa deve cambiare
WinUI 3 è il livello grafico moderno del Windows App SDK. Permette di realizzare applicazioni desktop con controlli XAML, finestre Win32, integrazione con le API di Windows e distribuzione tradizionale o via pacchetti MSIX. A differenza della vecchia UWP, non costringe lo sviluppatore a eseguire il programma dentro un contenitore ristretto. Questa flessibilità ha però un prezzo tecnico: il processo deve ospitare il framework XAML e un’istanza del sistema di composizione del SDK. Alcuni contenuti, come WebView2, MediaPlayerElement, SwapChainPanel, Mica e Acrylic, seguono percorsi di rendering particolari. L’idea di Microsoft è spostare WinUI verso un compositore di sistema, riducendo il lavoro duplicato nelle singole app e migliorando la fluidità durante ridimensionamento, scorrimento e transizioni.
Attenzione a non confondere WinUI e WebView2. Nel Task Manager compaiono spesso parecchie istanze di msedgewebview2.exe. Microsoft Edge WebView2 permette alle app di incorporare contenuti HTML, CSS e JavaScript usando il motore Chromium di Edge, e lo sfruttano Outlook, Teams, Office, i Widget e tanti programmi di terze parti. Adotta un modello multiprocesso simile a quello di un browser: molte istanze non significano per forza una perdita di memoria, anzi, la separazione migliora sicurezza e stabilità. WinUI, invece, gestisce controlli, finestre e interfacce native basate su XAML. Le due cose possono convivere nella stessa app.
Un banco di prova delicato è il menu Start di Windows 11, che non poggia ancora su una singola tecnologia. Alcune sezioni, come l’elenco delle applicazioni e l’area dei consigliati, usano componenti basati su React Native for Windows, altre dipendono da tecnologie diverse e dialogano con servizi della shell, indicizzazione, account utente e Microsoft Store. Una futura riscrittura con WinUI potrebbe lasciare quasi intatto l’aspetto, cambiando il modo in cui gli elementi si caricano e rispondono all’input.
Per adesso manca il dato che conta davvero: quanto scenderà l’occupazione di memoria. Presentare tutto come la soluzione definitiva alla pesantezza di Windows 11 sarebbe prematuro. Microsoft riconosce che restano lacune, per esempio nella gestione completa dell’area di notifica e in vari scenari desktop avanzati. L’arrivo di controlli integrati come DataGrid e strumenti per i grafici potrebbe ridurre la dipendenza da librerie esterne, soprattutto nelle applicazioni aziendali. Migliorare le prestazioni non basta, però, se lo sviluppatore deve aggiungere una montagna di componenti di terze parti per ottenere funzioni considerate basilari.