Czas uruchamiania aplikacji

Czas wymagany do uruchomienia aplikacji WPF może się znacznie różnić. W tym temacie opisano różne techniki zmniejszania postrzeganego i rzeczywistego czasu uruchamiania aplikacji Windows Presentation Foundation (WPF).

Omówienie zimnego uruchamiania i ciepłego uruchamiania

Zimne uruchamianie występuje, gdy aplikacja jest uruchamiana po raz pierwszy po ponownym uruchomieniu systemu lub po uruchomieniu aplikacji, zamknij ją, a następnie uruchom ją ponownie po długim czasie. Po uruchomieniu aplikacji, jeśli wymagane strony (kod, dane statyczne, rejestr itp.) nie są obecne na liście rezerwowej menedżera pamięci systemu Windows, występują błędy strony. Dostęp do dysku jest wymagany do przeniesienia stron do pamięci.

Ciepłe uruchamianie występuje, gdy większość stron dla głównych składników środowiska uruchomieniowego języka wspólnego (CLR) jest już ładowana w pamięci, co pozwala zaoszczędzić kosztowny czas dostępu do dysku. Dlatego aplikacja zarządzana uruchamia się szybciej po drugim uruchomieniu.

Implementowanie ekranu powitalnego

W przypadkach, gdy występuje znaczące, nieuniknione opóźnienie między uruchomieniem aplikacji a wyświetleniem pierwszego interfejsu użytkownika, zoptymalizuj postrzegany czas uruchamiania przy użyciu ekranu powitalnego. To podejście wyświetla obraz niemal natychmiast po uruchomieniu aplikacji przez użytkownika. Gdy aplikacja jest gotowa do wyświetlenia pierwszego interfejsu użytkownika, ekran powitalny zanika. Począwszy od programu .NET Framework 3.5 SP1, można użyć SplashScreen klasy do zaimplementowania ekranu powitalnego. Aby uzyskać więcej informacji, zobacz Dodawanie ekranu powitalnego do aplikacji WPF.

Możesz również zaimplementować własny ekran powitalny przy użyciu natywnej grafiki Win32. Wyświetl implementację przed wywołaną Run metodą .

Analizowanie kodu uruchamiania

Określ przyczynę powolnego uruchamiania zimnego. We/Wy dysku mogą być odpowiedzialne, ale nie zawsze tak jest. Ogólnie rzecz biorąc, należy zminimalizować użycie zasobów zewnętrznych, takich jak sieć, usługi sieci Web lub dysk.

Przed przetestowaniem sprawdź, czy żadne inne uruchomione aplikacje lub usługi nie używają kodu zarządzanego lub kodu WPF.

Uruchom aplikację WPF natychmiast po ponownym uruchomieniu i określ, jak długo trwa wyświetlanie. Jeśli wszystkie kolejne uruchomienia aplikacji (ciepłe uruchomienie) są znacznie szybsze, problem z zimnym uruchamianiem jest najprawdopodobniej spowodowany operacjami we/wy.

Jeśli problem z zimnym uruchamianiem aplikacji nie jest związany z operacjami we/wy, prawdopodobnie aplikacja wykonuje pewne długie inicjowanie lub obliczenia, czeka na ukończenie niektórych zdarzeń lub wymaga dużej kompilacji JIT podczas uruchamiania. W poniższych sekcjach opisano niektóre z tych sytuacji bardziej szczegółowo.

Optymalizowanie ładowania modułu

Użyj narzędzi, takich jak Eksplorator procesów (Procexp.exe) i Tlist.exe, aby określić moduły ładowane przez aplikację. Tlist <pid> Polecenie wyświetla wszystkie moduły ładowane przez proces.

Jeśli na przykład nie łączysz się z siecią Web i widzisz, że System.Web.dll jest załadowany, w aplikacji znajduje się moduł odwołujący się do tego zestawu. Upewnij się, że odwołanie jest niezbędne.

Jeśli aplikacja ma wiele modułów, scal je w jeden moduł. Takie podejście wymaga mniejszego obciążenia związanego z ładowaniem zestawów CLR. Mniejsza liczba zestawów oznacza również, że clR zachowuje mniej stanu.

Odroczenie operacji inicjowania

Rozważ odrożenie kodu inicjowania do momentu renderowania głównego okna aplikacji.

Należy pamiętać, że inicjowanie może być wykonywane wewnątrz konstruktora klasy, a jeśli kod inicjowania odwołuje się do innych klas, może to spowodować efekt kaskadowy, w którym jest wykonywanych wiele konstruktorów klas.

Unikaj konfiguracji aplikacji

Rozważ uniknięcie konfiguracji aplikacji. Jeśli na przykład aplikacja ma proste wymagania dotyczące konfiguracji i ma ścisłe cele czasu uruchamiania, wpisy rejestru lub prosty plik INI może być szybszą alternatywą uruchamiania.

Korzystanie z GAC

Jeśli zestaw nie jest zainstalowany w globalnej pamięci podręcznej zestawów (GAC), występują opóźnienia spowodowane weryfikacją skrótu zestawów o silnych nazwach i weryfikacją obrazu Ngen, jeśli obraz natywny dla tego zestawu jest dostępny na komputerze. Weryfikacja silnej nazwy jest pomijana dla wszystkich zestawów zainstalowanych w usłudze GAC. Aby uzyskać więcej informacji, zobacz Gacutil.exe (globalne narzędzie pamięci podręcznej zestawów).

Użyj Ngen.exe

Rozważ użycie generatora obrazów natywnych (Ngen.exe) w aplikacji. Użycie Ngen.exe oznacza handel użyciem procesora CPU w celu uzyskania większego dostępu do dysku, ponieważ obraz natywny wygenerowany przez Ngen.exe prawdopodobnie będzie większy niż obraz MSIL.

Aby poprawić czas ciepłego uruchamiania, zawsze należy użyć Ngen.exe w aplikacji, ponieważ pozwala to uniknąć kosztu procesora CPU kompilacji kodu aplikacji JIT.

W niektórych scenariuszach zimnego uruchamiania użycie Ngen.exe może być również przydatne. Dzieje się tak, ponieważ kompilator JIT (mscorjit.dll) nie musi być ładowany.

Zastosowanie zarówno modułów Ngen, jak i JIT może mieć najgorszy efekt. Jest to spowodowane tym, że mscorjit.dll należy załadować, a gdy kompilator JIT działa w kodzie, wiele stron na obrazach Ngen musi być dostępnych, gdy kompilator JIT odczytuje metadane zestawów.

Ngen i ClickOnce

Sposób wdrażania aplikacji może również mieć wpływ na czas ładowania. Wdrożenie aplikacji ClickOnce nie obsługuje oprogramowania Ngen. Jeśli zdecydujesz się użyć Ngen.exe dla aplikacji, musisz użyć innego mechanizmu wdrażania, takiego jak Instalator Windows.

Aby uzyskać więcej informacji, zobacz Ngen.exe (Generator obrazów natywnych).

Ponowne łączenie i kolizje adresów DLL

Jeśli używasz Ngen.exe, pamiętaj, że ponowne łączenie może wystąpić, gdy obrazy natywne są ładowane w pamięci. Jeśli biblioteka DLL nie jest ładowana pod preferowanym adresem podstawowym, ponieważ ten zakres adresów jest już przydzielony, moduł ładujący systemu Windows załaduje go pod innym adresem, co może być czasochłonną operacją.

Możesz użyć wirtualnego narzędzia zrzutu adresów (Vadump.exe), aby sprawdzić, czy istnieją moduły, w których wszystkie strony są prywatne. W takim przypadku moduł mógł zostać zmieniony na inny adres. W związku z tym nie można udostępniać jej stron.

Aby uzyskać więcej informacji na temat ustawiania adresu podstawowego, zobacz Ngen.exe (Generator obrazów natywnych).

Optymalizowanie technologii Authenticode

Weryfikacja authenticode dodaje do czasu uruchomienia. Zestawy z podpisem Authenticode muszą zostać zweryfikowane przy użyciu urzędu certyfikacji ( CA). Ta weryfikacja może być czasochłonna, ponieważ może wymagać połączenia z siecią kilka razy w celu pobrania bieżących list odwołania certyfikatów. Zapewnia również pełny łańcuch prawidłowych certyfikatów w ścieżce do zaufanego katalogu głównego. Może to przekładać się na kilka sekund opóźnienia podczas ładowania zestawu.

Rozważ zainstalowanie certyfikatu urzędu certyfikacji na komputerze klienckim lub unikaj używania aplikacji Authenticode, jeśli jest to możliwe. Jeśli wiesz, że aplikacja nie potrzebuje dowodów wydawcy, nie musisz płacić kosztów weryfikacji podpisu.

Począwszy od programu .NET Framework 3.5, istnieje opcja konfiguracji, która umożliwia obejście weryfikacji Authenticode. W tym celu dodaj następujące ustawienie do pliku app.exe.config:

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

Aby uzyskać więcej informacji, zobacz <generatePublisherEvidence> , element.

Porównanie wydajności w systemie Windows Vista

Menedżer pamięci w systemie Windows Vista ma technologię o nazwie SuperFetch. Funkcja SuperFetch analizuje wzorce użycia pamięci w czasie, aby określić optymalną zawartość pamięci dla określonego użytkownika. Cały czas działa w celu utrzymania tej zawartości.

Takie podejście różni się od techniki pobierania wstępnego używanej w systemie Windows XP, która wstępnie ładuje dane do pamięci bez analizowania wzorców użycia. W miarę upływu czasu, jeśli użytkownik często używa aplikacji WPF w systemie Windows Vista, zimny czas uruchamiania aplikacji może się poprawić.

Wydajne korzystanie z domen aplikacji

Jeśli to możliwe, załaduj zestawy do obszaru kodu neutralnego pod względem domeny, aby upewnić się, że obraz natywny, jeśli taki istnieje, jest używany we wszystkich domenach aplikacji utworzonych w aplikacji.

Aby uzyskać najlepszą wydajność, wymuś wydajną komunikację między domenami, zmniejszając liczbę wywołań między domenami. Jeśli to możliwe, użyj wywołań bez argumentów lub argumentów typu pierwotnego.

Używanie atrybutu NeutralResourcesLanguage

Użyj elementu , NeutralResourcesLanguageAttribute aby określić neutralną kulturę dla elementu ResourceManager. Takie podejście pozwala uniknąć nieudanych wyszukiwań zestawów.

Używanie klasy BinaryFormatter do serializacji

Jeśli musisz użyć serializacji, użyj BinaryFormatter klasy zamiast XmlSerializer klasy . Klasa BinaryFormatter jest implementowana w bibliotece klas bazowych (BCL) w zestawie mscorlib.dll. Element XmlSerializer jest implementowany w zestawie System.Xml.dll, który może być dodatkową biblioteką DLL do załadowania.

Jeśli musisz użyć XmlSerializer klasy, możesz osiągnąć lepszą wydajność, jeśli wstępnie wygenerujesz zestaw serializacji.

Konfigurowanie technologii ClickOnce pod kątem sprawdzania Aktualizacje po uruchomieniu

Jeśli aplikacja używa technologii ClickOnce, unikaj dostępu do sieci podczas uruchamiania, konfigurując aplikację ClickOnce w celu sprawdzenia lokacji wdrożenia pod kątem aktualizacji po uruchomieniu aplikacji.

Jeśli używasz modelu aplikacji przeglądarki XAML (XBAP), pamiętaj, że usługa ClickOnce sprawdza witrynę wdrażania pod kątem aktualizacji, nawet jeśli XBAP znajduje się już w pamięci podręcznej ClickOnce. Aby uzyskać więcej informacji, zobacz ClickOnce Security and Deployment (Zabezpieczenia i wdrażanie technologii ClickOnce).

Konfigurowanie usługi PresentationFontCache do automatycznego uruchamiania

Pierwszą aplikacją WPF do uruchomienia po ponownym uruchomieniu jest usługa PresentationFontCache. Usługa buforuje czcionki systemowe, poprawia dostęp do czcionek i poprawia ogólną wydajność. Istnieje obciążenie podczas uruchamiania usługi, a w niektórych kontrolowanych środowiskach należy rozważyć skonfigurowanie usługi do automatycznego uruchamiania po ponownym uruchomieniu systemu.

Programowe ustawianie powiązania danych

Zamiast używać języka XAML do deklaratywnego DataContext ustawiania okna głównego, rozważ ustawienie go programowo w metodzie OnActivated .

Zobacz też

• SplashScreen
• AppDomain
• NeutralResourcesLanguageAttribute
• ResourceManager
• Dodawanie ekranu powitalnego do aplikacji WPF
• Ngen.exe (generator obrazu natywnego)
• <generatePublisherEvidence> , element