アプリケーションの起動時間Application Startup Time

WPF アプリケーションの起動に必要な時間には、かなりばらつきがあります。The amount of time that is required for a WPF application to start can vary greatly. このトピックでは、Windows Presentation Foundation (WPF) アプリケーションの認識される起動時間と実際の起動時間を短縮する方法について説明します。This topic describes various techniques for reducing the perceived and actual startup time for a Windows Presentation Foundation (WPF) application.

コールド スタートとウォーム スタートについてUnderstanding Cold Startup and Warm Startup

コールド スタートは、システムの再起動後にアプリケーションを初めて起動するとき、またはアプリケーションを起動して閉じた後、時間をおいて再び起動するときに発生します。Cold startup occurs when your application starts for the first time after a system reboot, or when you start your application, close it, and then start it again after a long period of time. アプリケーションが起動するときに、必要なページ (コード、静的データ、レジストリなど) が Windows メモリ マネージャーのスタンバイ リストに存在しない場合、ページ フォールトが発生します。When an application starts, if the required pages (code, static data, registry, etc) are not present in the Windows memory manager's standby list, page faults occur. そのページをメモリに読み込むには、ディスクにアクセスする必要があります。Disk access is required to bring the pages into memory.

ウォーム スタートは、主要な共通言語ランタイム (CLR) コンポーネント用のページのほとんどが、既にメモリに読み込まれているときに発生し、貴重なディスク アクセス タイムを節約できます。Warm startup occurs when most of the pages for the main common language runtime (CLR) components are already loaded in memory, which saves expensive disk access time. このため、マネージド アプリケーションを再度実行すると、初回よりも短い時間で起動します。That is why a managed application starts faster when it runs a second time.

スプラッシュ スクリーンの実装Implement a Splash Screen

アプリケーションを起動してから最初の UI が表示されるまでに、どうしても多大な時間がかかる場合は、"スプラッシュ スクリーン" を使用して、認識される起動時間を最適化します。In cases where there is a significant, unavoidable delay between starting an application and displaying the first UI, optimize the perceived startup time by using a splash screen. この方法により、ユーザーがアプリケーションを起動すると、すぐにイメージが表示されます。This approach displays an image almost immediately after the user starts the application. アプリケーションが最初の UI を表示する準備が整うと、スプラッシュ スクリーンはフェード アウトします。When the application is ready to display its first UI, the splash screen fades. 以降、.NET Framework 3.5 SP1 を使えば、SplashScreenスプラッシュ スクリーンを実装するクラス。Starting in the .NET Framework 3.5 SP1, you can use the SplashScreen class to implement a splash screen. 詳細については、WPF アプリケーションへのスプラッシュ スクリーンの追加に関するページをご覧ください。For more information, see Add a Splash Screen to a WPF Application.

ネイティブな Win32 グラフィックスを使用して、独自のスプラッシュ スクリーンを実装することもできます。You can also implement your own splash screen by using native Win32 graphics. 表示する前に、実装、Runメソッドが呼び出されます。Display your implementation before the Run method is called.

スタートアップ コードの分析Analyze the Startup Code

コールド スタートに時間がかかる理由を特定します。Determine the reason for a slow cold startup. ディスク I/O が原因である可能性がありますが、常にそうとは限りません。Disk I/O may be responsible, but this is not always the case. 通常、ネットワーク、Web サービス、ディスクなどの外部リソースの使用は最小限に抑えてください。In general, you should minimize the use of external resources, such as network, Web services, or disk.

テストを始める前に、実行中のアプリケーションやサービスが、マネージド コードまたは WPF コードを使用していないことを確認してください。Before you test, verify that no other running applications or services use managed code or WPF code.

再起動の直後に WPF アプリケーションを起動し、表示されるまでの時間を計測します。Start your WPF application immediately after a reboot, and determine how long it takes to display. その後アプリケーションを何回か起動し (ウォーム スタート)、各回の起動時間が初回よりも短ければ、コールド スタートの問題の原因は I/O であると判断できます。If all subsequent launches of your application (warm startup) are much faster, your cold startup issue is most likely caused by I/O.

アプリケーションのコールド スタートの問題に I/O が無関係である場合は、アプリケーションが長時間かかる初期化や計算を実行しているか、イベントの完了を待機しているか、起動時に大量の JIT コンパイルを必要としている可能性があります。If your application's cold startup issue is not related to I/O, it is likely that your application performs some lengthy initialization or computation, waits for some event to complete, or requires a lot of JIT compilation at startup. 以下のセクションでは、こうした状況のいくつかについてさらに詳しく説明します。The following sections describe some of these situations in more detail.

モジュールの読み込みの最適化Optimize Module Loading

プロセス エクスプローラー (Procexp.exe)、Tlist.exe などのツールを使用して、アプリケーションがどのモジュールを読み込むかを調べます。Use tools such as Process Explorer (Procexp.exe) and Tlist.exe to determine which modules your application loads. Tlist <pid> コマンドを実行すると、プロセスによって読み込まれるすべてのモジュールが表示されます。The command Tlist <pid> shows all the modules that are loaded by a process.

たとえば、Web に接続しないにもかかわらず System.Web.dll が読み込まれている場合は、アプリケーション内にこのアセンブリを参照するモジュールが含まれています。For example, if you are not connecting to the Web and you see that System.Web.dll is loaded, then there is a module in your application that references this assembly. この参照が本当に必要かどうかを検討してください。Check to make sure that the reference is necessary.

アプリケーションに複数のモジュールがある場合は、それをマージして単一のモジュールにします。If your application has multiple modules, merge them into a single module. この方法により、CLR によるアセンブリ読み込みのオーバーヘッドが減少します。This approach requires less CLR assembly-loading overhead. アセンブリ数が減少すると、CLR の管理対象となる状態も少なくなります。Fewer assemblies also mean that the CLR maintains less state.

初期化処理の延期Defer Initialization Operations

メイン アプリケーション ウィンドウが表示されるまで、初期化コードの実行を延期することを検討します。Consider postponing initialization code until after the main application window is rendered.

初期化はクラス コンストラクター内で実行される場合があり、初期化コードが他のクラスを参照していと、多数のクラス コンストラクターが次々に実行される可能性があることに注意してください。Be aware that initialization may be performed inside a class constructor, and if the initialization code references other classes, it can cause a cascading effect in which many class constructors are executed.

アプリケーション構成の回避Avoid Application Configuration

アプリケーション構成を回避することを検討してください。Consider avoiding application configuration. たとえば、アプリケーションの構成要件がシンプルで、起動時間の目標が非常に厳しい場合は、構成の代わりに、レジストリ エントリまたはシンプルな INI ファイルを使って起動時間を短縮できます。For example, if an application has simple configuration requirements and has strict startup time goals, registry entries or a simple INI file may be a faster startup alternative.

GAC の活用Utilize the GAC

アセンブリがグローバル アセンブリ キャッシュ (GAC) にインストールされていない場合、厳密な名前付きアセンブリのハッシュ検証と NGen イメージ検証 (コンピューター上でそのアセンブリのネイティブ イメージを使用できる場合) が原因で遅延が発生します。If an assembly is not installed in the Global Assembly Cache (GAC), there are delays caused by hash verification of strong-named assemblies and by Ngen image validation if a native image for that assembly is available on the computer. 厳密な名前の検証は、GAC にインストールされているアセンブリに対してはスキップされます。Strong-name verification is skipped for all assemblies installed in the GAC. 詳細については、「Gacutil.exe (グローバル アセンブリ キャッシュ ツール)」を参照してください。For more information, see Gacutil.exe (Global Assembly Cache Tool).

Ngen.exe の使用Use Ngen.exe

アプリケーションでネイティブ イメージ ジェネレーター (Ngen.exe) を使用することを検討してください。Consider using the Native Image Generator (Ngen.exe) on your application. Ngen.exe を使用すると、CPU 消費は減少しますが、Ngen.exe によって生成されるネイティブ イメージの方が MSIL イメージよりも大きいことが多いため、ディスク アクセスが増えます。Using Ngen.exe means trading CPU consumption for more disk access because the native image generated by Ngen.exe is likely to be larger than the MSIL image.

ウォーム スタートの起動時間を短縮するには、アプリケーションでは必ず Ngen exe を使用します。これにより、アプリケーション コードの JIT コンパイルにかかる CPU コストを回避できます。To improve the warm startup time, you should always use Ngen.exe on your application, because this avoids the CPU cost of JIT compilation of the application code.

コールド スタートでも、Ngen.exe を使用すると有効なことがあります。In some cold startup scenarios, using Ngen.exe can also be helpful. これは、JIT コンパイラ (mscorjit.dll) を読み込む必要がないためです。This is because the JIT compiler (mscorjit.dll) does not have to be loaded.

NGen と JIT モジュールを併用すると、最悪の影響がもたらされる可能性があります。Having both Ngen and JIT modules can have the worst effect. mscorjit.dll を読み込む必要があるほか、JIT コンパイラは、アプリケーション コードを処理するとき、アセンブリのメタデータを読み込む際に NGen イメージ内の多数のページにアクセスする必要があるためです。This is because mscorjit.dll must be loaded, and when the JIT compiler works on your code, many pages in the Ngen images must be accessed when the JIT compiler reads the assemblies' metadata.

NGen と ClickOnceNgen and ClickOnce

アプリケーションの配置方法が、読み込み時間に影響することもあります。The way you plan to deploy your application can also make a difference in load time. ClickOnce アプリケーションの展開は、Ngen をサポートしていません。ClickOnce application deployment does not support Ngen. アプリケーションで Ngen.exe を使用する場合は、Windows インストーラーなど、他の配置機構を使用する必要があります。If you decide to use Ngen.exe for your application, you will have to use another deployment mechanism, such as Windows Installer.

詳細については、「Ngen.exe (ネイティブ イメージ ジェネレーター)」を参照してください。For more information, see Ngen.exe (Native Image Generator).

ベース変更と DLL アドレスの競合Rebasing and DLL Address Collisions

Ngen.exe を使用する場合は、ネイティブ イメージがメモリに読み込まれる際にベース変更が発生する可能性があることに注意してください。If you use Ngen.exe, be aware that rebasing can occur when the native images are loaded in memory. 希望のベース アドレスのアドレス範囲が既に割り当て済みであることが原因で、そのベース アドレスに DLL を読み込めない場合、Windows ローダーは、その DLL を別のアドレスに読み込みますが、これには時間がかかることがあります。If a DLL is not loaded at its preferred base address because that address range is already allocated, the Windows loader will load it at another address, which can be a time-consuming operation.

仮想アドレス ダンプ (Vadump.exe) ツールを使用すると、すべてのページがプライベートであるモジュールが存在するかどうかを調べることができます。You can use the Virtual Address Dump (Vadump.exe) tool to check if there are modules in which all the pages are private. 存在する場合、そのモジュールは、別のアドレスにベース変更されている可能性があります。If this is the case, the module may have been rebased to a different address. したがって、そのページは共有できません。Therefore, its pages cannot be shared.

ベース アドレスを設定する方法の詳細については、「Ngen.exe (ネイティブ イメージ ジェネレーター)」を参照してください。For more information about how to set the base address, see Ngen.exe (Native Image Generator).

Authenticode の最適化Optimize Authenticode

Authenticode 検証によって起動時間は長くなります。Authenticode verification adds to the startup time. Authenticode 署名があるアセンブリは、証明機関 (CA: Certification Authority) を使用して検証する必要があります。Authenticode-signed assemblies have to be verified with the certification authority (CA). この検証では、最新の証明書失効リストをダウンロードするためにネットワークに複数回接続する必要があるので、時間がかかる可能性があります。This verification can be time consuming, because it can require connecting to the network several times to download current certificate revocation lists. また、信頼できるルートへのパスに、有効な証明書すべてが存在することも確認します。It also makes sure that there is a full chain of valid certificates on the path to a trusted root. これにより、アセンブリの読み込み中に、数秒間の遅延が発生する場合があります。This can translate to several seconds of delay while the assembly is being loaded.

CA 証明書をクライアント コンピューターにインストールするか、可能な場合は Authenticode の使用を避けることを検討してください。Consider installing the CA certificate on the client computer, or avoid using Authenticode when it is possible. アプリケーションが発行者の証拠を必要としないことがわかっている場合は、署名を検証する手間をかける必要はありません。If you know that your application does not need the publisher evidence, you do not have to pay the cost of signature verification.

Authenticode の検証をバイパスすることを許可する構成オプションは .NET Framework 3.5 以降です。Starting in .NET Framework 3.5, there is a configuration option that allows the Authenticode verification to be bypassed. これを行うには、次の設定を app.exe.config ファイルに追加します。To do this, add the following setting to the app.exe.config file:

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

詳細については、「<generatePublisherEvidence> 要素」を参照してください。For more information, see <generatePublisherEvidence> Element.

Windows Vista でのパフォーマンスの比較Compare Performance on Windows Vista

Windows Vista のメモリ マネージャーには、SuperFetch というテクノロジが組み込まれています。The memory manager in Windows Vista has a technology called SuperFetch. SuperFetch は、一定期間内のメモリ使用パターンを分析して、そのユーザーに適したメモリの内容を判断します。SuperFetch analyzes memory usage patterns over time to determine the optimal memory content for a specific user. そして、その内容が維持されるよう継続的に動作します。It works continuously to maintain that content at all times.

これは、Windows XP で使用されているプリフェッチ手法とは異なります。プリフェッチでは、使用パターンを分析せずに、データをメモリにプリロードします。This approach differs from the pre-fetch technique used in Windows XP, which preloads data into memory without analyzing usage patterns. ユーザーが WPF アプリケーションを Windows Vista で頻繁に使用すると、アプリケーションのコールド スタートの起動時間は次第に短くなる可能性があります。Over time, if the user uses your WPF application frequently on Windows Vista, the cold startup time of your application may improve.

AppDomains の効率的な使用Use AppDomains Efficiently

可能な場合はアセンブリをドメイン中立コード領域に読み込み、アプリケーションで作成されるすべての AppDomains でネイティブ イメージが使用されるようにします (ネイティブ イメージが存在する場合)。If possible, load assemblies into a domain-neutral code area to make sure that the native image, if one exists, is used in all AppDomains created in the application.

パフォーマンスを最大限に高めるには、ドメイン間呼び出しを減らしてドメイン間の通信を効率化します。For the best performance, enforce efficient cross-domain communication by reducing cross-domain calls. 可能な場合は、引数のない呼び出し、または引数がプリミティブ型である呼び出しを使用します。When possible, use calls without arguments or with primitive type arguments.

NeutralResourcesLanguage 属性の使用Use the NeutralResourcesLanguage Attribute

使用して、NeutralResourcesLanguageAttributeのニュートラル カルチャを指定する、ResourceManagerします。Use the NeutralResourcesLanguageAttribute to specify the neutral culture for the ResourceManager. この方法を使用すると、アセンブリのルックアップの失敗が回避されます。This approach avoids unsuccessful assembly lookups.

シリアル化での BinaryFormatter クラスの使用Use the BinaryFormatter Class for Serialization

シリアル化を使用する場合は、使用、BinaryFormatterクラスの代わりに、XmlSerializerクラス。If you must use serialization, use the BinaryFormatter class instead of the XmlSerializer class. BinaryFormatterクラスは、mscorlib.dll アセンブリの基本クラス ライブラリ (BCL) で実装されます。The BinaryFormatter class is implemented in the Base Class Library (BCL) in the mscorlib.dll assembly. XmlSerializer別の DLL を読み込む可能性のある System.Xml.dll アセンブリに実装します。The XmlSerializer is implemented in the System.Xml.dll assembly, which might be an additional DLL to load.

使用する場合、XmlSerializerクラス、事前にシリアル化アセンブリを生成する場合より優れたパフォーマンスを実現できます。If you must use the XmlSerializer class, you can achieve better performance if you pre-generate the serialization assembly.

起動後に更新プログラムをチェックする ClickOnce の構成Configure ClickOnce to Check for Updates After Startup

アプリケーションでは、ClickOnce を使用する場合は、ClickOnce アプリケーションの起動後に、配置サイトの更新プログラムを確認するを構成することで起動時にネットワーク アクセスを回避します。If your application uses ClickOnce, avoid network access on startup by configuring ClickOnce to check the deployment site for updates after the application starts.

XAML ブラウザー アプリケーション (XBAP) モデルを使用する場合は、XBAP は、ClickOnce キャッシュで既に場合でも、ClickOnce は、配置サイトの更新プログラムを確認します。 注意してください。If you use the XAML browser application (XBAP) model, keep in mind that ClickOnce checks the deployment site for updates even if the XBAP is already in the ClickOnce cache. 詳細については、「 ClickOnce Security and Deployment」を参照してください。For more information, see ClickOnce Security and Deployment.

PresentationFontCache サービスの自動起動の構成Configure the PresentationFontCache Service to Start Automatically

再起動後に最初に実行される WPF アプリケーションは PresentationFontCache サービスです。The first WPF application to run after a reboot is the PresentationFontCache service. このサービスは、システム フォントをキャッシュし、フォント アクセスを高速化して、パフォーマンス全体を向上させます。The service caches the system fonts, improves font access, and improves overall performance. このサービスの起動にはオーバーヘッドが伴うため、一部の制御された環境では、システムの再起動時にこのサービスを自動起動するように構成することを検討してください。There is an overhead in starting the service, and in some controlled environments, consider configuring the service to start automatically when the system reboots.

データ バインディングのプログラムによる設定Set Data Binding Programmatically

XAML を使用して設定するのではなく、DataContext宣言によって、メイン ウィンドウにプログラムで設定することを検討してください、OnActivatedメソッド。Instead of using XAML to set the DataContext declaratively for the main window, consider setting it programmatically in the OnActivated method.

関連項目See also