Rychlejší spuštění aplikace

Článek
11/16/2024

Doba potřebná ke spuštění aplikace WPF se může výrazně lišit. Toto téma popisuje různé techniky pro snížení vnímané a skutečné doby spuštění aplikace WPF (Windows Presentation Foundation).

Principy studeného spouštění a teplého spouštění

Při prvním spuštění aplikace po restartování systému nebo při spuštění aplikace ji zavřete a po dlouhé době ji znovu spusťte. Když se aplikace spustí, v pohotovostním seznamu správce paměti Systému Windows se nenachází požadované stránky (kód, statická data, registr atd.), dojde k chybám stránky. K přenesení stránek do paměti se vyžaduje přístup k disku.

K teplému spuštění dochází, když je většina stránek pro hlavní komponenty CLR (Common Language Runtime) již načtena do paměti, což šetří nákladnou dobu přístupu k disku. Proto se spravovaná aplikace spustí rychleji, když se spustí podruhé.

Implementace úvodní obrazovky

V případech, kdy dochází k významnému, nežádoucímu zpoždění mezi spuštěním aplikace a zobrazením prvního uživatelského rozhraní optimalizujte vnímaný čas spuštění pomocí úvodní obrazovky. Tento přístup zobrazí obrázek téměř okamžitě po spuštění aplikace uživatelem. Jakmile je aplikace připravená k zobrazení prvního uživatelského rozhraní, úvodní obrazovka zmizí. Počínaje rozhraním .NET Framework 3.5 SP1 můžete pomocí SplashScreen třídy implementovat úvodní obrazovku. Další informace naleznete v tématu Přidání úvodní obrazovky do aplikace WPF.

Můžete také implementovat vlastní úvodní obrazovku pomocí nativní grafiky Win32. Zobrazí implementaci před zavolání Run metody.

Analýza spouštěcího kódu

Určete důvod pomalého studeného spouštění. Vstupně-výstupní operace disku můžou být zodpovědné, ale ne vždy se jedná o případ. Obecně byste měli minimalizovat používání externích prostředků, jako je síť, webové služby nebo disk.

Před testováním ověřte, že žádné jiné spuštěné aplikace nebo služby nepoužívají spravovaný kód nebo kód WPF.

Spusťte aplikaci WPF ihned po restartování a určete, jak dlouho trvá zobrazení. Pokud jsou všechna následná spuštění vaší aplikace (teplé spuštění) mnohem rychlejší, příčinou vašeho problému se studeným spuštěním je pravděpodobně vstupně-výstupní operace.

Pokud problém se studeným spuštěním vaší aplikace nesouvisí s vstupně-výstupními operacemi, je pravděpodobné, že vaše aplikace provádí určitou zdlouhavou inicializaci nebo výpočet, čeká na dokončení určité události nebo vyžaduje při spuštění spoustu kompilace JIT. Následující části popisují některé z těchto situací podrobněji.

Optimalizace načítání modulů

Pomocí nástrojů, jako je Průzkumník procesů (Procexp.exe) a Tlist.exe určit, které moduly se aplikace načte. Tlist <pid> Příkaz zobrazí všechny moduly, které jsou načteny procesem.

Pokud se například nepřipojíte k webu a zjistíte, že System.Web.dll je načteno, je ve vaší aplikaci modul, který odkazuje na toto sestavení. Zkontrolujte, jestli je odkaz nezbytný.

Pokud má vaše aplikace více modulů, sloučte je do jednoho modulu. Tento přístup vyžaduje menší režii při načítání sestavení CLR. Méně sestavení také znamená, že CLR udržuje méně stavu.

Odložit inicializační operace

Zvažte odložení inicializačního kódu, dokud se nevykreslí hlavní okno aplikace.

Mějte na paměti, že inicializace může být provedena uvnitř konstruktoru třídy, a pokud inicializační kód odkazuje na jiné třídy, může způsobit kaskádový efekt, ve kterém se provádí mnoho konstruktorů tříd.

Vyhněte se konfiguraci aplikace

Zvažte, že se vyhnete konfiguraci aplikace. Pokud má například aplikace jednoduché požadavky na konfiguraci a má přísné cíle času spuštění, položky registru nebo jednoduchý soubor INI mohou být rychlejší alternativou spuštění.

Využití GAC

Pokud není sestavení nainstalováno v globální mezipaměti sestavení (GAC), jsou zpoždění způsobená ověřením hodnoty hash sestavení se silným názvem a ověřením bitové kopie Ngen, pokud je v počítači k dispozici nativní image pro toto sestavení. Ověření silného názvu se přeskočí pro všechna sestavení nainstalovaná v GAC. Další informace najdete v tématu Gacutil.exe (nástroj globální mezipaměti sestavení).

Použití nástroje Ngen.exe

Zvažte použití generátoru nativních imagí (Ngen.exe) ve vaší aplikaci. Použití Ngen.exe znamená využití procesoru pro větší přístup k disku, protože nativní image generovaná Ngen.exe bude pravděpodobně větší než image MSIL.

Pokud chcete zlepšit dobu teplého spuštění, měli byste vždy používat Ngen.exe ve vaší aplikaci, protože tím se zabrání nákladům na procesor kompilace kódu aplikace JIT.

V některých scénářích studeného spuštění může být užitečné také použití Ngen.exe. Důvodem je to, že kompilátor JIT (mscorjit.dll) nemusí být načten.

Použití modulů Ngen i JIT může mít nejhorší dopad. Důvodem je to, že mscorjit.dll musí být načteny a když kompilátor JIT pracuje na vašem kódu, musí být při čtení metadat sestavení kompilátorem JIT přístup k mnoha stránkám imagí Ngen.

Ngen a ClickOnce

Způsob, jakým plánujete nasadit aplikaci, může také mít vliv na dobu načítání. Nasazení aplikace ClickOnce nepodporuje Ngen. Pokud se rozhodnete použít Ngen.exe pro vaši aplikaci, budete muset použít jiný mechanismus nasazení, například Instalační služba systému Windows.

Další informace najdete v tématu Ngen.exe (generátor nativních imagí).

Rebasing and DLL Address Kolize

Pokud používáte Ngen.exe, mějte na paměti, že při načítání nativních bitových kopií do paměti může dojít k opětovnému obnovení. Pokud knihovna DLL není načtena na upřednostňovanou základní adresu, protože tento rozsah adres je již přidělen, zavaděč systému Windows jej načte na jinou adresu, což může být časově náročná operace.

Pomocí nástroje pro výpis stavu virtuálních adres (Vadump.exe) můžete zkontrolovat, jestli existují moduly, ve kterých jsou všechny stránky soukromé. Pokud se jedná o tento případ, modul byl pravděpodobně znovu na základu na jinou adresu. Proto nelze sdílet jeho stránky.

Další informace o nastavení základní adresy najdete v tématu Ngen.exe (Generátor nativních imagí).

Optimalizace authenticode

Ověření authenticode se přidá do doby spuštění. Sestavení podepsaná službou Authenticode musí být ověřena pomocí certifikační autority (CA). Toto ověření může být časově náročné, protože může vyžadovat připojení k síti několikrát, aby se stáhly aktuální seznamy odvolaných certifikátů. Zajišťuje také, že existuje úplný řetěz platných certifikátů na cestě k důvěryhodnému kořenovému adresáři. Při načítání sestavení se to může přeložit na několik sekund zpoždění.

Pokud je to možné, zvažte instalaci certifikátu certifikační autority na klientský počítač nebo se vyhnete použití služby Authenticode. Pokud víte, že vaše aplikace nepotřebuje důkazy vydavatele, nemusíte platit náklady na ověření podpisu.

Počínaje rozhraním .NET Framework 3.5 existuje možnost konfigurace, která umožňuje obejít ověření authenticode. Uděláte to tak, že do souboru app.exe.config přidáte následující nastavení:

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

Další informace naleznete v tématu <generatePublisherEvidence> – element.

Porovnání výkonu ve Windows Vista

Správce paměti v systému Windows Vista má technologii s názvem SuperFetch. SuperFetch analyzuje vzorce využití paměti v průběhu času, aby určil optimální obsah paměti pro konkrétního uživatele. Tento obsah neustále udržuje.

Tento přístup se liší od techniky předběžného načtení používané v systému Windows XP, která předem načte data do paměti bez analýzy vzorů použití. V průběhu času, pokud uživatel používá vaši aplikaci WPF často v systému Windows Vista, studená doba spuštění aplikace může zlepšit.

Efektivní používání domén AppDomains

Pokud je to možné, načtěte sestavení do oblasti kódu neutrální domény, abyste měli jistotu, že se nativní image( pokud existuje) používá ve všech doménách AppDomains vytvořených v aplikaci.

Nejlepšího výkonu dosáhnete tak, že vynutíte efektivní komunikaci mezi doménovými sítěmi tím, že snížíte počet volání mezi doménou. Pokud je to možné, použijte volání bez argumentů nebo s primitivními argumenty typu.

Použití atributu NeutralResourcesLanguage

NeutralResourcesLanguageAttribute Použijte k určení neutrální jazykové verze pro ResourceManager. Tento přístup zabraňuje neúspěšným vyhledáváním sestavení.

Použití generátoru serializátoru XML

Pokud používáte XmlSerializer třídu, můžete dosáhnout lepšího výkonu, pokud předgenerujete serializace sestavení pomocí xml Serializer Generator nástroj (Sgen.exe).

Konfigurace ClickOnce pro kontrolu aktualizací po spuštění

Pokud vaše aplikace používá ClickOnce, vyhněte se síťovému přístupu při spuštění tím, že nakonfigurujete ClickOnce a zkontrolujete lokalitu nasazení aktualizací po spuštění aplikace.

Pokud používáte model aplikace prohlížeče XAML (XBAP), mějte na paměti, že ClickOnce kontroluje aktualizace webu nasazení i v případě, že XBAP je již v mezipaměti ClickOnce. Další informace naleznete v tématu ClickOnce Zabezpečení a nasazení.

Upozorňující

XBAPs vyžadují, aby fungovaly starší prohlížeče, jako je Internet Explorer a starší verze Firefoxu. Tyto starší prohlížeče jsou obvykle nepodporované ve Windows 10 a Windows 11. Moderní prohlížeče už kvůli rizikům zabezpečení nepodporují technologii potřebnou pro aplikace XBAP. Moduly plug-in, které umožňují XBAPs, se už nepodporují. Další informace najdete v tématu Nejčastější dotazy k aplikacím hostovaným v prohlížeči WPF (XBAP).

Konfigurace služby PresentationFontCache pro automatické spuštění

První aplikace WPF, která se má spustit po restartování, je služba PresentationFontCache. Služba ukládá systémová písma do mezipaměti, zlepšuje přístup k písmům a zlepšuje celkový výkon. Při spouštění služby dochází k režijním nákladům a v některých kontrolovaných prostředích zvažte automatické spuštění služby při restartování systému.

Programové nastavení datových vazeb

Místo použití XAML k nastavení DataContext deklarativního pro hlavní okno zvažte jeho programové nastavení v OnActivated metodě.

Sdílet prostřednictvím