Delen via

Opstarttijd van de applicatie

De hoeveelheid tijd die nodig is om een WPF-toepassing te starten, kan sterk variëren. In dit onderwerp worden verschillende technieken beschreven voor het verminderen van de waargenomen en werkelijke opstarttijd voor een WPF-toepassing (Windows Presentation Foundation).

Begrijpen van Cold Startup en Warm Startup

Koud opstarten treedt op wanneer uw toepassing voor de eerste keer wordt gestart nadat het systeem opnieuw is opgestart, of wanneer u de toepassing start, sluit deze en start deze vervolgens na een lange periode opnieuw. Wanneer een toepassing wordt gestart, als de vereiste pagina's (code, statische gegevens, register, enzovoort) niet aanwezig zijn in de stand-bylijst van Windows-geheugenbeheer, treden er paginafouten op. Schijftoegang is vereist om de pagina's in het geheugen te brengen.

Warm opstarten treedt op wanneer de meeste pagina's voor de belangrijkste CLR-onderdelen (Common Language Runtime) al in het geheugen worden geladen, waardoor dure schijftoegangstijd wordt bespaard. Daarom start een beheerde toepassing sneller wanneer deze een tweede keer wordt uitgevoerd.

Een welkomstscherm implementeren

In gevallen waarin er een aanzienlijke, onvermijdelijke vertraging is tussen het starten van een toepassing en het weergeven van de eerste gebruikersinterface, optimaliseert u de waargenomen opstarttijd met behulp van een welkomstscherm. Met deze methode wordt bijna direct een afbeelding weergegeven nadat de gebruiker de toepassing heeft gestart. Wanneer de toepassing klaar is om de eerste gebruikersinterface weer te geven, vervaagt het welkomstscherm. Vanaf .NET Framework 3.5 SP1 kunt u de SplashScreen klasse gebruiken om een welkomstscherm te implementeren. Zie Een welkomstscherm toevoegen aan een WPF-toepassing voor meer informatie.

U kunt ook uw eigen welkomstscherm implementeren met behulp van systeemeigen Win32-afbeeldingen. Geef uw implementatie weer voordat de Run methode wordt aangeroepen.

De opstartcode analyseren

Bepaal de reden voor een trage koude opstart. Schijf-I/O is mogelijk verantwoordelijk, maar dit is niet altijd het geval. Over het algemeen moet u het gebruik van externe resources minimaliseren, zoals netwerk, webservices of schijf.

Controleer voordat u test of geen andere actieve toepassingen of services beheerde code of WPF-code gebruiken.

Start uw WPF-toepassing direct na het opnieuw opstarten en bepaal hoe lang het duurt om weer te geven. Als alle volgende lanceringen van uw toepassing (warm opstarten) veel sneller zijn, wordt uw koude opstartprobleem waarschijnlijk veroorzaakt door I/O.

Als het koude opstartprobleem van uw toepassing niet is gerelateerd aan I/O, is het waarschijnlijk dat uw toepassing een lange initialisatie of berekening uitvoert, wacht tot een bepaalde gebeurtenis is voltooid of veel JIT-compilatie tijdens het opstarten vereist. In de volgende secties worden enkele van deze situaties in meer detail beschreven.

Optimaliseer het laden van modules

Gebruik hulpprogramma's zoals Process Explorer (Procexp.exe) en Tlist.exe om te bepalen welke modules uw toepassing laadt. Met de opdracht Tlist <pid> worden alle modules weergegeven die door een proces worden geladen.

Als u bijvoorbeeld geen verbinding maakt met het web en u ziet dat System.Web.dll is geladen, is er een module in uw toepassing die verwijst naar deze assembly. Controleer of de verwijzing nodig is.

Als uw toepassing meerdere modules heeft, voegt u deze samen in één module. Voor deze benadering is minder overhead voor het laden van CLR-assemblages vereist. Minder assemblages betekenen ook dat de CLR minder toestand behoudt.

Initialisatiebewerkingen uitstellen

Overweeg initialisatiecode uit te stellen totdat het hoofdtoepassingsvenster is weergegeven.

Houd er rekening mee dat initialisatie kan worden uitgevoerd in een klasseconstructor en als de initialisatiecode verwijst naar andere klassen, kan dit een trapsgewijs effect veroorzaken waarin veel klasseconstructors worden uitgevoerd.

Applicatieconfiguratie vermijden

Overweeg om toepassingsconfiguratie te vermijden. Als een toepassing bijvoorbeeld eenvoudige configuratievereisten heeft en strikte opstarttijddoelen heeft, kunnen registervermeldingen of een eenvoudig INI-bestand een sneller opstartalratief zijn.

De GAC gebruiken

Als een assembly niet is geïnstalleerd in de Global Assembly Cache (GAC), treden er vertragingen op door hash-verificatie van assemblies met een sterke naam en door Ngen-afbeeldingsvalidatie, indien er een systeemeigen afbeelding voor die assembly op de computer beschikbaar is. Verificatie met sterke naam wordt overgeslagen voor alle assembly's die zijn geïnstalleerd in de GAC. Zie Gacutil.exe (Global Assembly Cache Tool)voor meer informatie.

Gebruik Ngen.exe

Overweeg het gebruik van de Native Image Generator (Ngen.exe) voor uw toepassing. Het gebruik van Ngen.exe betekent het inruilen van CPU-verbruik voor meer schijftoegang, omdat de native afbeeldingen die door Ngen.exe worden gegenereerd waarschijnlijk groter zijn dan de MSIL-afbeeldingen.

Als u de warme opstarttijd wilt verbeteren, moet u altijd Ngen.exe in uw toepassing gebruiken, omdat hierdoor de CPU-kosten van JIT-compilatie van de toepassingscode worden vermeden.

In sommige koude opstartscenario's kan het gebruik van Ngen.exe ook nuttig zijn. Dit komt doordat de JIT-compiler (mscorjit.dll) niet hoeft te worden geladen.

Het hebben van zowel Ngen- als JIT-modules kan het slechtste effect hebben. Dit komt doordat mscorjit.dll moet worden geladen en wanneer de JIT-compiler op uw code werkt, moet toegang worden verkregen tot veel pagina's in de Ngen-afbeeldingen wanneer de JIT-compiler de metagegevens van de assemblies leest.

Ngen en ClickOnce

De manier waarop u uw toepassing wilt implementeren, kan ook een verschil maken in de laadtijd. ClickOnce-toepassingsimplementatie biedt geen ondersteuning voor Ngen. Als u besluit om Ngen.exe te gebruiken voor uw toepassing, moet u een ander implementatiemechanisme gebruiken, zoals Windows Installer.

Zie Ngen.exe (Native Image Generator) voor meer informatie.

Rebasing en DLL-adresconflicten

Als u Ngen.exegebruikt, moet u er rekening mee houden dat er een nieuwebasering kan optreden wanneer de systeemeigen installatiekopieën in het geheugen worden geladen. Als een DLL niet op het voorkeursbasisadres wordt geladen omdat dat adresbereik al is toegewezen, wordt het door het Windows-laadprogramma geladen op een ander adres, wat een tijdrovende bewerking kan zijn.

U kunt het hulpprogramma Virtual Address Dump (Vadump.exe) gebruiken om te controleren of er modules zijn waarin alle pagina's privé zijn. Als dit het geval is, is de module mogelijk opnieuw gebaseerd op een ander adres. Daarom kunnen de bijbehorende pagina's niet worden gedeeld.

Zie Ngen.exe (Native Image Generator) voor meer informatie over het instellen van het basisadres.

Authenticode optimaliseren

Verificatie van Authenticode wordt toegevoegd aan de opstarttijd. Authenticode-ondertekende assemblies moeten worden geverifieerd door de certificeringsinstantie (CA). Deze verificatie kan tijdrovend zijn, omdat er meerdere keren verbinding kan worden gemaakt met het netwerk om de huidige certificaatintrekkingslijsten te downloaden. Het zorgt er ook voor dat er een volledige keten van geldige certificaten op het pad naar een vertrouwde basis is. Dit kan leiden tot enkele seconden vertraging terwijl de module wordt geladen.

Overweeg het CA-certificaat op de clientcomputer te installeren of vermijd het gebruik van Authenticode wanneer dit mogelijk is. Als u weet dat uw toepassing geen bewijs van uitgever nodig heeft, hoeft u de kosten van handtekeningverificatie niet te betalen.

Vanaf .NET Framework 3.5 is er een configuratieoptie waarmee verificatie van Authenticode kan worden overgeslagen. Voeg hiervoor de volgende instelling toe aan het app.exe.config-bestand:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

Zie <het element generatePublisherEvidence voor> meer informatie.

Prestaties vergelijken in Windows Vista

De geheugenbeheerder in Windows Vista heeft een technologie genaamd SuperFetch. SuperFetch analyseert patronen voor geheugengebruik in de loop van de tijd om de optimale geheugeninhoud voor een specifieke gebruiker te bepalen. Het werkt continu om die inhoud altijd te onderhouden.

Deze benadering verschilt van de techniek voor vooraf ophalen die wordt gebruikt in Windows XP, waarmee gegevens vooraf in het geheugen worden geladen zonder gebruikspatronen te analyseren. Als de gebruiker na verloop van tijd regelmatig gebruikmaakt van uw WPF-toepassing op Windows Vista, kan de koude opstarttijd van uw toepassing worden verbeterd.

AppDomains efficiënt gebruiken

Laad, indien mogelijk, assemblies in een domeinneutraal codegebied om ervoor te zorgen dat de native image, indien beschikbaar, wordt gebruikt in alle AppDomains die in de toepassing zijn aangemaakt.

Voor de beste prestaties dwingt u efficiënte communicatie tussen domeinen af door het aantal aanroepen tussen domeinen te verminderen. Gebruik indien mogelijk aanroepen zonder argumenten of met primitieve typeargumenten.

Het kenmerk NeutralResourcesLanguage gebruiken

Gebruik de NeutralResourcesLanguageAttribute om de neutrale cultuur voor de ResourceManager op te geven. Deze aanpak voorkomt mislukte assemblagezoekopdrachten.

XML Serializer-generator gebruiken

Als u de XmlSerializer klasse gebruikt, kunt u betere prestaties bereiken als u de serialisatieassembly pregenereert met behulp van het hulpprogramma XML Serializer Generator (Sgen.exe).

ClickOnce configureren om te controleren op updates na het opstarten

Als uw toepassing ClickOnce gebruikt, voorkomt u netwerktoegang bij het opstarten door ClickOnce te configureren om de implementatiesite te controleren op updates nadat de toepassing is gestart.

Als u het XBAP-model (XAML-browsertoepassing) gebruikt, moet u er rekening mee houden dat ClickOnce de implementatiesite controleert op updates, zelfs als de XBAP al in de ClickOnce-cache staat. Zie ClickOnce-beveiliging en -implementatie voor meer informatie.

Waarschuwing

XBAPs vereisen dat verouderde browsers werken, zoals Internet Explorer en oude versies van Firefox. Deze oudere browsers worden meestal niet ondersteund in Windows 10 en Windows 11. Moderne browsers bieden geen ondersteuning meer voor de technologie die is vereist voor XBAP-apps vanwege beveiligingsrisico's. Invoegtoepassingen die XBAPs inschakelen, worden niet meer ondersteund. Zie Veelgestelde vragen over door de WPF-browser gehoste toepassingen (XBAP)voor meer informatie.

De PresentationFontCache-service configureren om automatisch te starten

De eerste WPF-toepassing die moet worden uitgevoerd nadat opnieuw is opgestart, is de PresentationFontCache-service. De service slaat de systeemlettertypen in de cache op, verbetert de toegang tot lettertypen en verbetert de algehele prestaties. Er is een overhead bij het starten van de service en in sommige gecontroleerde omgevingen kunt u overwegen om de service automatisch te starten wanneer het systeem opnieuw wordt opgestart.

Programmatisch gegevensbinding instellen

In plaats van XAML te gebruiken om het DataContext declaratief in te stellen voor het hoofdvenster, kunt u het programmatisch instellen in de OnActivated methode.

Zie ook

  • Last updated on