Ho notato che l'avvio dell'applicazione WPF a volte è piuttosto lento. Qualcuno sa se la causa è l'inizializzazione degli elementi o il caricamento delle DLL o qualcos'altro?Cosa rende lento l'avvio dell'applicazione WPF?
Il testo che segue è stato estratto da this MSDN article on Improving WPF applications startup time (Edit: ora incorporata in WPF Application Startup Time)
La quantità di tempo che è necessario per un'applicazione WPF per iniziare può variare notevolmente. Questo argomento descrive varie tecniche per ridurre il tempo di avvio effettivo e percepito per un'applicazione Windows Presentation Foundation (WPF).
La comprensione di avvio a freddo e WarmStartup
freddo di avvio si verifica quando l'applicazione viene avviata per la prima volta dopo un riavvio del sistema, o quando si avvia l'applicazione, chiuderlo, quindi avviare di nuovo dopo un lungo periodo di tempo. Quando si avvia un'applicazione, se le pagine richieste (codice, dati statici, registro, ecc.) Non sono presenti nell'elenco di standby del gestore memoria di Windows, si verificano errori di pagina. L'accesso al disco è necessario per portare le pagine in memoria.
L'avvio a caldo si verifica quando la maggior parte delle pagine per i componenti Common Language Runtime (CLR) sono già caricate in memoria, il che consente di risparmiare tempo di accesso al disco. Ecco perché un'applicazione gestita si avvia più velocemente quando viene eseguita una seconda volta.
Implementare una schermata iniziale
Nei casi in cui v'è una significativa, inevitabile ritardo tra l'avvio di un'applicazione e la visualizzazione la prima interfaccia utente, ottimizzare il tempo di avvio percepito utilizzando uno schermo iniziale. Questo approccio visualizza un'immagine quasi immediatamente dopo che l'utente ha avviato l'applicazione. Quando l'applicazione è pronta a mostrare la sua prima interfaccia utente, la schermata iniziale si affievolisce. A partire da .NET Framework 3.5 SP1, è possibile utilizzare la classe SplashScreen per implementare una schermata iniziale. Per ulteriori informazioni, vedere How to: Add a Splash Screen to a WPF Application.
È inoltre possibile implementare la propria schermata iniziale utilizzando la grafica nativa di Win32. Mostra la tua implementazione prima che venga chiamato il metodo Run.
analizzare il codice di avvio
Determinare il motivo di un avvio a freddo lento. Disk I/O può essere responsabile, ma questo non è sempre il caso. In generale, è necessario ridurre al minimo l'utilizzo di risorse esterne, quali rete, servizi Web o disco.
Prima di eseguire il test, verificare che nessun'altra applicazione o servizio in esecuzione utilizzi codice gestito o codice WPF.
Avviare l'applicazione WPF subito dopo il riavvio e determinare il tempo necessario per la visualizzazione. Se tutti i lanci successivi dell'applicazione (avvio a caldo) sono molto più veloci, il problema di avvio a freddo è probabilmente causato dall'I/O.
Se il problema di avvio a freddo dell'applicazione non è correlato all'I/O, è probabile che l'applicazione esegua una lunga inizializzazione o computazione, aspetti che alcuni eventi vengano completati o che richieda molta compilazione JIT all'avvio. Le sezioni seguenti descrivono alcune di queste situazioni in modo più dettagliato.
Ottimizzare caricamento del modulo
Utilizzare strumenti come Process Explorer (Procexp.exe) e Tlist.exe per determinare quali moduli i carichi applicativi. Il comando Tlist <pid> mostra tutti i moduli che vengono caricati da un processo.
Ad esempio, se non si sta effettuando la connessione al Web e si vede che System.Web.dll è stato caricato, nell'applicazione è presente un modulo che fa riferimento a questo assieme. Verificare che il riferimento sia necessario.
Se l'applicazione ha più moduli, unirli in un unico modulo. Questo approccio richiede un sovraccarico di carico dell'assieme CLR inferiore. Meno assemblaggi significano anche che il CLR mantiene meno stato.
Defer inizializzazione Operations
Considerate rinviare codice di inizializzazione fino a dopo la finestra principale dell'applicazione è reso.
Tenere presente che l'inizializzazione può essere eseguita all'interno di un costruttore di classi e se il codice di inizializzazione fa riferimento ad altre classi, può causare un effetto a catena in cui vengono eseguiti molti costruttori di classi.
Configurazione evitare l'applicazione
Considerate evitando di configurazione dell'applicazione. Ad esempio, se un'applicazione presenta semplici requisiti di configurazione e ha obiettivi di avvio orari rigorosi, le voci del Registro di sistema o un semplice file INI potrebbero essere un'alternativa di avvio più rapida.
Utilizzare GAC
Se un assembly non è installato nella Global Assembly Cache (GAC), ci sono ritardi causati dalla verifica hash di assembly con nome e Ngen convalida immagine se l'immagine di un nativo per quell'assieme è disponibile sul computer. La verifica del nome sicuro viene ignorata per tutti gli assembly installati nel GAC. Per ulteriori informazioni, vedere Gacutil.exe (Global Assembly Cache Tool).
Usa Ngen.exe
Si consiglia di utilizzare il Native Image Generator (Ngen.exe) sulla vostra applicazione. L'utilizzo di Ngen.exe significa il consumo della CPU di trading per un maggiore accesso al disco, poiché l'immagine nativa generata da Ngen.exe è probabilmente più grande dell'immagine MSIL.
Per migliorare il tempo di avvio, è necessario utilizzare sempre Ngen.exe sull'applicazione, poiché ciò evita il costo della CPU per la compilazione JIT del codice dell'applicazione.
In alcuni scenari di avvio a freddo, anche l'utilizzo di Ngen.exe può essere utile. Questo perché il compilatore JIT (mscorjit.dll) non deve essere caricato.
Avere entrambi i moduli Ngen e JIT può avere l'effetto peggiore. Questo perché mscorjit.dll deve essere caricato e quando il compilatore JIT funziona sul tuo codice, è necessario accedere a molte pagine nelle immagini Ngen quando il compilatore JIT legge i metadati degli assembly.
Ngen e ClickOnce
Il modo in cui si prevede di distribuire l'applicazione può anche fare la differenza nel tempo di caricamento. La distribuzione delle applicazioni ClickOnce non supporta Ngen. Se si decide di utilizzare Ngen.exe per l'applicazione, sarà necessario utilizzare un altro meccanismo di distribuzione, ad esempio Windows Installer.
Per ulteriori informazioni, vedere Ngen.exe (Native Image Generator).
ribasamento e DLL Indirizzo Collisioni
Se si utilizza Ngen.exe, essere consapevoli che rebasing può verificarsi quando le immagini native vengono caricati in memoria. Se una DLL non viene caricata al suo indirizzo di base preferito poiché tale intervallo di indirizzi è già allocato, il caricatore di Windows lo caricherà su un altro indirizzo, operazione che può richiedere molto tempo.
È possibile utilizzare lo strumento Virtual Address Dump (Vadump.exe) per verificare se esistono moduli in cui tutte le pagine sono private. Se questo è il caso, il modulo potrebbe essere stato ridisposto a un indirizzo diverso. Pertanto, le sue pagine non possono essere condivise.
Per ulteriori informazioni su come impostare l'indirizzo di base, vedere Ngen.exe (Native Image Generator).
Ottimizzare Authenticode
verifica Authenticode aggiunge al tempo di avvio. Gli assembly con firma Authenticode devono essere verificati con l'autorità di certificazione (CA). Questa verifica può richiedere molto tempo, perché può richiedere la connessione alla rete più volte per scaricare gli elenchi di revoca dei certificati correnti. Garantisce inoltre l'esistenza di una catena completa di certificati validi sul percorso di una radice attendibile. Questo può tradursi in diversi secondi di ritardo durante il caricamento del gruppo.
Considerare l'installazione del certificato CA sul computer client o evitare l'uso di Authenticode quando è possibile. Se sai che la tua domanda non ha bisogno della prova dell'editore, non devi pagare il costo della verifica della firma.
Avvio in .NET Framework 3.5, esiste un'opzione di configurazione che consente di ignorare la verifica Authenticode. Per fare questo, aggiungere la seguente impostazione al file App.exe.config:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
confrontare le prestazioni su Windows Vista
Il gestore della memoria in Windows Vista dispone di una tecnologia chiamata SuperFetch. SuperFetch analizza i modelli di utilizzo della memoria nel tempo per determinare il contenuto di memoria ottimale per un utente specifico. Funziona continuamente per mantenere quel contenuto in ogni momento.
Questo approccio differisce dalla tecnica di prelavaggio utilizzata in Windows XP, che precarica i dati in memoria senza analizzare i modelli di utilizzo. Nel tempo, se l'utente utilizza frequentemente l'applicazione WPF su Windows Vista, il tempo di avvio a freddo dell'applicazione potrebbe migliorare.
Usa AppDomain efficiente
Se possibile, assiemi di carico in una zona codice di dominio neutro per assicurarsi che l'immagine originaria, se presente, è utilizzato in tutti AppDomain creati nell'applicazione.
Per prestazioni ottimali, imporre efficienti comunicazioni tra domini riducendo le chiamate tra domini. Quando possibile, usa le chiamate senza argomenti o con argomenti di tipo primitivo.
Utilizzare l'attributo NeutralResourcesLanguage
Utilizzare il NeutralResourcesLanguageAttribute per specificare la cultura neutra per il ResourceManager. Questo approccio evita ricerche di assemblaggio infruttuose.
Utilizzare la classe BinaryFormatter per la serializzazione
Se è necessario utilizzare la serializzazione, utilizzare la classe BinaryFormatter anziché la classe XmlSerializer. La classe BinaryFormatter è implementata nella Base Class Library (BCL) nell'assembly mscorlib.dll. Il XmlSerializer è implementato nell'assembly System.Xml.dll, che potrebbe essere una DLL aggiuntiva da caricare.
Se è necessario utilizzare la classe XmlSerializer, è possibile ottenere prestazioni migliori se si pre-genera il gruppo di serializzazione.
Configura ClickOnce per controllare gli aggiornamenti dopo l'avvio
Se l'applicazione utilizza ClickOnce, evitare l'accesso alla rete all'avvio configurando ClickOnce di controllare il sito di distribuzione per gli aggiornamenti dopo l'avvio dell'applicazione.
Se si utilizza il modello XAML del browser (XBAP), tenere presente che ClickOnce controlla gli aggiornamenti del sito di distribuzione anche se XBAP si trova già nella cache ClickOnce. Per ulteriori informazioni, vedere ClickOnce Security and Deployment.
configurare il servizio PresentationFontCache per l'avvio automatico
La prima applicazione WPF a correre dopo un riavvio è il servizio PresentationFontCache. Il servizio memorizza nella cache i caratteri di sistema, migliora l'accesso ai caratteri e migliora le prestazioni generali. C'è un sovraccarico nell'avvio del servizio, e in alcuni ambienti controllati, si consideri la configurazione del servizio per l'avvio automatico al riavvio del sistema.
Set Associazione dati di programmazione
Invece di usare XAML per impostare la DataContext dichiarativo per la finestra principale, considerare la creazione a livello di codice nel metodo OnActivated.
Il tempo di avvio di un'applicazione WPF può essere molto più veloce se si utilizza Framework 3.51 e non 3.5 o 3.0. Il 3.51 è davvero un miglioramento.
Ciò che mi ha aiutato di più dall'eccellente articolo a cui Stuart si collegava era il trucco XmlSerializer. Quello si è veramente rasato per alcuni secondi.Inoltre non sottovalutare la deframmentazione del HD :-)
Il consiglio più utile che fissa prestazioni di avvio WPF che abbia mai visto è stato dato in this other question: run "ngen aggiornamento" in ogni cartella quadro.
Sembra che Microsoft non sia in grado di mantenere aggiornata la cache di ngen, il che si traduce in una ricapitolazione quasi completa della metà del framework .NET ad ogni singolo avvio.
Difficile da credere, ma sembra essere vero.
Questo è un thread vecchio, ma sono finito qui diverse volte mentre cercavo di risolvere un problema di prestazioni di avvio con app WPF sul mio sistema Win10, quindi ho pensato di dire una risposta che potrebbe aiutare gli altri - un risposta che richiede un orribile tempo di avvio di 5 secondi per tutte le app WPF su questo sistema fino a pochi millisecondi. Rimuovere il driver nVidia "3d Vision". Ho una scheda GeForce GTX 650, e il driver "3D Vision" non sembra offrire nulla di utile, quindi rimuoverlo non è un problema per me. Lo strumento di analisi delle prestazioni VisualStudio2015 ha infine dimostrato che quasi tutti i 5 secondi di tempo di avvio sono stati spesi in IDLE dopo una chiamata tramite nvapi64.dll, il driver nVidia. Wow.
Questo articolo è stato unito alla documentazione WPF MSDN ufficiale - http://msdn.microsoft.com/en-us/library/cc656914.aspx – splintor