Microsoft ammette: Windows 11 consuma troppa RAM e prepara la cura

Windows 11 non occupa memoria soltanto per eseguire programmi, servizi e driver: una parte della RAM serve anche a costruire e disegnare le interfacce delle applicazioni integrate. Proprio qui Microsoft ha individuato uno dei limiti più evidenti del sistema operativo: le app basate su WinUI, il framework grafico moderno destinato a sostituire progressivamente molte interfacce storiche di Windows, richiedono oggi più memoria del previsto e possono mostrare ritardi, scatti o tempi di apertura poco convincenti.

Il problema affonda le radici nella lunga transizione avviata con Windows 8 e proseguita nel 2015 con Windows 10, quando Microsoft iniziò ad affiancare alle tradizionali applicazioni Win32 nuovi modelli basati su XAML e Universal Windows Platform. Con Windows 11 l’azienda ha puntato sul Windows App SDK e su WinUI 3, separando buona parte delle tecnologie grafiche dal ciclo di aggiornamento del sistema operativo. L’obiettivo era permettere agli sviluppatori di creare applicazioni moderne senza rinunciare alle API desktop. A distanza di anni, però, Windows continua a combinare componenti Win32, XAML, React Native, contenuti WebView2 e vecchie finestre di sistema: funziona, ma il risultato non brilla per efficienza.

Microsoft ha ora confermato di lavorare a una revisione delle fondamenta di WinUI, con particolare attenzione al consumo di memoria, alla qualità del rendering e all’affidabilità. I tecnici di Redmond non hanno pubblicato percentuali né promesso una quantità precisa di RAM recuperabile. Il segnale importante è un altro: prima di trasferire ulteriori parti della shell di Windows 11 sul framework moderno, l’azienda vuole ridurne il peso.

Perché un’app apparentemente semplice può occupare centinaia di megabyte

Mettendo mano al Task Manager, può sorprendere che un’applicazione con poche finestre e funzioni elementari occupi 200 o 300 MB in RAM. Un’app moderna deve caricare il runtime, i componenti XAML, le risorse grafiche, i font, i dizionari degli stili, i servizi di accessibilità e gli oggetti necessari alla composizione della finestra.

Una parte della memoria include inoltre pagine condivise con altri processi, cache che Windows può liberare sotto pressione e aree riservate che non corrispondono necessariamente a RAM fisica utilizzata in quel momento. Per una valutazione corretta non basta quindi osservare la colonna Memoria nella scheda Processi del Task Manager: strumenti come Process Explorer permettono di distinguere il working set, cioè le pagine presenti nella memoria fisica, dalla memoria privata attribuibile soltanto al processo.

In un altro articolo abbiamo visto come analizzare l’uso della memoria RAM in Windows e come estenderla in caso di necessità.

Il punto è che l’overhead introdotto dall’uso del framework conta moltissimo: se dieci componenti in background richiedono ciascuno decine o centinaia di megabyte, il totale diventa rilevante. Su una macchina con 32 GB di RAM può passare quasi inosservato; su un portatile economico con 8 GB aumenta invece la probabilità che Windows debba spostare pagine meno usate nel file di paging. Un’unità SSD è molto più veloce di un hard disk tradizionale, ma resta nettamente più lenta della RAM: da qui derivano attese, microblocchi e riaperture meno immediate.

WinUI 3 e Windows App SDK: cosa deve cambiare

WinUI 3 costituisce il livello grafico moderno del Windows App SDK. Consente di realizzare applicazioni desktop con controlli XAML, finestre Win32, integrazione con le API di Windows e distribuzione tradizionale o tramite pacchetti MSIX. A differenza della precedente UWP, non obbliga lo sviluppatore a eseguire il programma dentro un contenitore applicativo ristretto.

La maggiore flessibilità ha però un costo tecnico: il processo deve ospitare il framework XAML e un’istanza del sistema di composizione fornito dal Windows App SDK. La documentazione Microsoft spiega che Microsoft.UI.Composition gestisce rendering, effetti e animazioni appoggiandosi alla GPU e a DirectX. Alcuni contenuti, tra cui WebView2, MediaPlayerElement, SwapChainPanel, Mica e Acrylic, seguono inoltre percorsi di rendering particolari e richiedono superfici esterne alla normale struttura visiva.

Microsoft intende spostare WinUI verso un compositore di sistema, riducendo il lavoro duplicato nelle singole applicazioni. In pratica, una parte delle operazioni necessarie a combinare superfici, animazioni ed effetti potrebbe appoggiarsi più direttamente all’infrastruttura già gestita da Windows. L’intervento dovrebbe diminuire l’overhead di memoria e migliorare la fluidità durante il ridimensionamento delle finestre, lo scorrimento e le transizioni.

Il menu Start è uno dei banchi di prova più delicati

La correzione acquista particolare importanza perché Microsoft vuole ampliare l’uso di WinUI all’interno della shell. Tra i componenti citati figurano il menu Start e la vista Agenda del centro notifiche. Prima di estendere il framework a elementi che rimangono caricati per tutta la sessione, serve però una base più leggera.

Il menu Start di Windows 11 non poggia ancora su una singola tecnologia: alcune sezioni, come l’elenco delle applicazioni e l’area dedicata agli elementi recenti o consigliati, utilizzano componenti basati su React Native for Windows. Altre parti dipendono da tecnologie Microsoft differenti e dialogano con servizi della shell, indicizzazione, account utente e Microsoft Store.

Una futura riscrittura con WinUI potrebbe mantenere quasi intatto l’aspetto, intervenendo sul modo in cui gli elementi si caricano, occupano memoria e rispondono all’input.

WinUI e WebView2 non sono la stessa cosa

La discussione sul consumo di RAM in Windows 11 rischia di generare un po’ di confusione, perché il Task Manager mostra spesso numerose istanze di msedgewebview2.exe. Microsoft Edge WebView2 consente alle applicazioni di incorporare contenuti HTML, CSS e JavaScript usando il motore Chromium di Edge: lo impiegano, tra gli altri, Outlook, Teams, Office, Widget e numerosi programmi di terze parti.

WebView2 adotta un modello multiprocesso simile a quello di un browser: può creare un processo principale, un processo GPU, servizi di rete o audio e uno o più renderer. La presenza di parecchie istanze non indica automaticamente una perdita di memoria. La separazione migliora sicurezza e stabilità, perché il crash di un renderer non deve necessariamente arrestare l’intera applicazione.

WinUI, invece, gestisce controlli, finestre e interfacce native basate su XAML. Le due tecnologie possono convivere nella stessa app: un programma può usare WinUI per barra laterale e pulsanti, incorporando con WebView2 una pagina o un componente scritto con tecnologie Web: in tale scenario il consumo complessivo deriva da entrambi i livelli.

Ottimizzare WinUI non renderà automaticamente più leggero il codice JavaScript caricato dentro WebView2; allo stesso modo, chiudere Edge non elimina il runtime WebView2 richiesto dalle altre applicazioni.

Una correzione necessaria in Windows 11, non ancora valutabile

L’ammissione di Microsoft sul “consumo RAM” in Windows 11 ha un valore tecnico e anche politico. Per anni l’azienda ha promosso ogni nuovo framework come il percorso privilegiato per lo sviluppo Windows, lasciando però agli utenti una piattaforma composta da numerosi livelli sovrapposti. WinUI deve ora dimostrare di poter sostituire le interfacce storiche senza richiedere più RAM e senza rendere meno reattive operazioni elementari.

L’arrivo di controlli integrati come DataGrid e strumenti per i grafici potrebbe inoltre ridurre la dipendenza degli sviluppatori da librerie esterne, soprattutto nelle applicazioni aziendali. Microsoft riconosce però che restano lacune, per esempio nella gestione completa dell’area di notifica e in diversi scenari desktop avanzati. Migliorare le prestazioni non basta se chi sviluppa deve aggiungere numerosi componenti di terze parti per ottenere funzioni considerate basilari.

Per ora manca il dato decisivo: quanto scenderà realmente l’occupazione di memoria: sarebbe quindi prematuro presentare il lavoro come la soluzione definitiva alla pesantezza di Windows 11. La direzione, però, appare corretta: prima di ridisegnare ancora l’interfaccia, Microsoft deve rendere più solide e leggere le fondamenta che la sostengono.