Starttid för program
Den tid som krävs för att ett WPF-program ska starta kan variera kraftigt. Det här avsnittet beskriver olika tekniker för att minska den upplevda och faktiska starttiden för ett WPF-program (Windows Presentation Foundation).
Förstå kall start och varm start
Kall start inträffar när programmet startas för första gången efter en systemomstart, eller när du startar programmet stänger du det och startar det sedan igen efter en lång tid. När ett program startar, om de nödvändiga sidorna (kod, statiska data, register osv.) inte finns i Windows minneshanterares väntelägeslista, uppstår sidfel. Diskåtkomst krävs för att föra in sidorna i minnet.
Varm start inträffar när de flesta sidorna för clr-komponenterna (Common Language Runtime) redan har lästs in i minnet, vilket sparar dyr diskåtkomsttid. Därför startar ett hanterat program snabbare när det körs en andra gång.
Implementera en välkomstskärm
I fall där det finns en betydande, oundviklig fördröjning mellan att starta ett program och visa det första användargränssnittet, optimerar du den upplevda starttiden med hjälp av en välkomstskärm. Den här metoden visar en bild nästan omedelbart när användaren startar programmet. När programmet är redo att visa sitt första användargränssnitt tonas välkomstskärmen ned. Från och med .NET Framework 3.5 SP1 kan du använda klassen SplashScreen för att implementera en välkomstskärm. Mer information finns i Lägg till en välkomstskärm i ett WPF-program.
Du kan också implementera en egen välkomstskärm med inbyggd Win32-grafik. Visa implementeringen innan metoden Run anropas.
Analysera startkoden
Fastställa orsaken till en långsam kall start. Disk-I/O kan vara ansvarigt, men så är inte alltid fallet. I allmänhet bör du minimera användningen av externa resurser, till exempel nätverk, webbtjänster eller disk.
Innan du testar kontrollerar du att inga andra program eller tjänster som körs använder hanterad kod eller WPF-kod.
Starta WPF-programmet omedelbart efter en omstart och bestäm hur lång tid det tar att visa. Om alla efterföljande lanseringar av programmet (varm start) är mycket snabbare orsakas ditt kalla startproblem troligen av I/O.
Om programmets problem med kall start inte är relaterat till I/O är det troligt att programmet utför en lång initiering eller beräkning, väntar på att någon händelse ska slutföras eller kräver mycket JIT-kompilering vid start. I följande avsnitt beskrivs några av dessa situationer mer detaljerat.
Optimera modulinläsning
Använd verktyg som Process Explorer (Procexp.exe) och Tlist.exe för att avgöra vilka moduler programmet läser in. Kommandot Tlist <pid> visar alla moduler som läses in av en process.
Om du till exempel inte ansluter till webben och ser att System.Web.dll läses in finns det en modul i programmet som refererar till den här sammansättningen. Kontrollera att referensen är nödvändig.
Om programmet har flera moduler sammanfogar du dem till en enda modul. Den här strategin kräver mindre CLR-belastning vid montering. Färre sammansättningar innebär också att CLR upprätthåller mindre tillstånd.
Skjuta upp initieringsåtgärder
Överväg att skjuta upp initieringskoden tills huvudprogrammets fönster återges.
Tänk på att initieringen kan utföras i en klasskonstruktor, och om initieringskoden refererar till andra klasser kan det orsaka en sammanhängande effekt där många klasskonstruktorer körs.
Undvik programkonfiguration
Överväg att undvika programkonfiguration. Om ett program till exempel har enkla konfigurationskrav och har strikta starttidsmål kan registerposter eller en enkel INI-fil vara ett snabbare startalternativ.
Använd GAC
Om en sammansättning inte är installerad i Global Assembly Cache (GAC) uppstår fördröjningar som orsakas av hash-verifiering av starka namngivna sammansättningar och av Ngen-avbildningsverifiering om en intern avbildning för den sammansättningen är tillgänglig på datorn. Verifiering av starka namn hoppas över för alla sammansättningar som är installerade i GAC. Mer information finns i Gacutil.exe (Global Assembly Cache Tool).
Använd Ngen.exe
Överväg att använda den interna avbildningsgeneratorn (Ngen.exe) i ditt program. Att använda Ngen.exe innebär att du byter cpu-förbrukning för mer diskåtkomst eftersom den interna avbildningen som genereras av Ngen.exe sannolikt är större än MSIL-avbildningen.
För att förbättra den varma starttiden bör du alltid använda Ngen.exe i ditt program, eftersom detta undviker CPU-kostnaden för JIT-kompilering av programkoden.
I vissa kalla startscenarier kan det också vara bra att använda Ngen.exe. Det beror på att JIT-kompilatorn (mscorjit.dll) inte behöver läsas in.
Att ha både Ngen- och JIT-moduler kan ha den värsta effekten. Detta beror på att mscorjit.dll måste läsas in, och när JIT-kompilatorn bearbetar din kod, måste många sidor i Ngen-avbildningarna nås när JIT-kompilatorn läser assemblenas metadata.
Ngen och ClickOnce
Hur du planerar att distribuera ditt program kan också göra skillnad i inläsningstiden. ClickOnce-programdistribution stöder inte Ngen. Om du bestämmer dig för att använda Ngen.exe för ditt program måste du använda en annan distributionsmekanism, till exempel Windows Installer.
Mer information finns i Ngen.exe (Native Image Generator).
Ombasering och DLL-adresskollisioner
Om du använder Ngen.exebör du vara medveten om att ombasering kan ske när de inbyggda bilderna läses in i minnet. Om en DLL inte läses in på den primära basadressen eftersom adressintervallet redan har allokerats läser Windows-inläsaren in den på en annan adress, vilket kan vara en tidskrävande åtgärd.
Du kan använda verktyget Virtuell adressdump (Vadump.exe) för att kontrollera om det finns moduler där alla sidor är privata. Om så är fallet kan modulen ha ombaserats till en annan adress. Därför kan dess sidor inte delas.
Mer information om hur du anger basadressen finns i Ngen.exe (intern avbildningsgenerator).
Optimera Authenticode
Verifiering av authenticode lägger till starttiden. Authenticode-signerade sammansättningar måste verifieras med certifikatutfärdare (CA). Den här verifieringen kan vara tidskrävande eftersom den kan kräva att du ansluter till nätverket flera gånger för att ladda ned aktuella listor över återkallade certifikat. Det ser också till att det finns en fullständig kedja med giltiga certifikat på sökvägen till en betrodd rot. Detta kan översättas till flera sekunders fördröjning medan assemblaget läses in.
Överväg att installera CA-certifikatet på klientdatorn eller undvik att använda Authenticode när det är möjligt. Om du vet att ditt program inte behöver utgivarbeviset behöver du inte betala kostnaden för signaturverifiering.
Från och med .NET Framework 3.5 finns det ett konfigurationsalternativ som gör att Authenticode-verifieringen kan kringgås. Det gör du genom att lägga till följande inställning i filen app.exe.config:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
Mer information finns i <generatePublisherEvidence> Element.
Jämför prestanda i Windows Vista
Minneshanteraren i Windows Vista har en teknik som kallas SuperFetch. SuperFetch analyserar minnesanvändningsmönster över tid för att fastställa det optimala minnesinnehållet för en specifik användare. Det fungerar kontinuerligt för att underhålla innehållet hela tiden.
Den här metoden skiljer sig från förhämtningstekniken som används i Windows XP, som förinstallerar data i minnet utan att analysera användningsmönster. Om användaren använder WPF-programmet ofta i Windows Vista med tiden kan programmets kalla starttid förbättras.
Använda AppDomains effektivt
Om möjligt läser du in sammansättningar i ett domänneutralt kodområde för att se till att den interna avbildningen, om den finns, används i alla AppDomains som skapats i programmet.
För bästa prestanda, framtvinga effektiv kommunikation mellan domäner genom att minska anrop mellan domäner. Använd anrop utan argument eller med primitiva typargument när det är möjligt.
Använda attributet NeutralResourcesLanguage
Använd NeutralResourcesLanguageAttribute för att ange neutral kultur för ResourceManager. Den här metoden undviker misslyckade sammansättningssökningar.
Använda XML Serializer Generator
Om du använder klassen XmlSerializer kan du få bättre prestanda om du förgenererar serialiseringssammansättningen med verktyget XML Serializer Generator (Sgen.exe).
Konfigurera ClickOnce för att söka efter uppdateringar efter start
Om ditt program använder ClickOnce undviker du nätverksåtkomst vid start genom att konfigurera ClickOnce för att kontrollera distributionsplatsen efter uppdateringar när programmet startar.
Om du använder XAML-webbläsarprogrammodellen (XBAP) bör du tänka på att ClickOnce kontrollerar distributionsplatsen efter uppdateringar även om XBAP redan finns i ClickOnce-cachen. Mer information finns i ClickOnce Security and Deployment.
Varning
XBAP:er kräver att äldre webbläsare används, till exempel Internet Explorer och gamla versioner av Firefox. Dessa äldre webbläsare stöds vanligtvis inte i Windows 10 och Windows 11. Moderna webbläsare stöder inte längre den teknik som krävs för XBAP-appar på grund av säkerhetsrisker. Plugin-program som aktiverar XBAP:er stöds inte längre. Mer information finns i Vanliga frågor och svar om WPF-webbläsarbaserade program (XBAP).
Konfigurera PresentationFontCache-tjänsten så att den startar automatiskt
Det första WPF-programmet som ska köras efter en omstart är Tjänsten PresentationFontCache. Tjänsten cachelagrar systemteckensnitten, förbättrar teckensnittsåtkomsten och förbättrar övergripande prestanda. Det finns ett arbete med att starta tjänsten och i vissa kontrollerade miljöer bör du överväga att konfigurera tjänsten så att den startar automatiskt när systemet startas om.
Aktivera databindning programmatiskt
I stället för att använda XAML för att ange DataContext deklarativt för huvudfönstret bör du överväga att ange det programmatiskt i metoden OnActivated.
Se även
.NET Desktop feedback