ユニバーサル Windows プラットフォーム (UWP) アプリのライフサイクル

  • [アーティクル]

このトピックでは、ユニバーサル Windows プラットフォーム (UWP) アプリが起動されてから終了するまでのライフサイクルについて説明します。

少しの歴史

Windows 8 より前は、アプリのライフサイクルは単純でした。 Win32 アプリと .NET アプリが実行されているか、実行されていません。 ユーザーが最小化したり、ユーザーから切り替えたりすると、ユーザーは引き続き実行されます。 ポータブル デバイスと電源管理がますます重要になるまで、これは問題ありません。

Windows 8 では、UWP アプリを使用した新しいアプリケーション モデルが導入されました。 大まかに言うと、新しい中断状態が追加されました。 UWP アプリは、ユーザーがアプリを最小化するか、別のアプリに切り替えた直後に中断されます。 つまり、オペレーティング システムでリソースを再利用する必要がない限り、アプリのスレッドは停止され、アプリはメモリに残ります。 ユーザーがアプリに戻ると、すぐに実行中の状態に復元できます。

バックグラウンド タスク、拡張実行、アクティビティスポンサー実行など、バックグラウンドで実行を継続する必要があるアプリには、さまざまな方法があります (たとえば、アプリがバックグラウンドでメディアを再生し続ける BackgroundMediaEnabled 機能)。 また、アプリが中断または終了した場合でも、バックグラウンド転送操作を続行できます。 詳細については、「ファイルをダウンロードする方法」を参照してください。

既定では、フォアグラウンドにないアプリは中断されます。 これにより、現在フォアグラウンドのアプリで使用できるリソースが削減され、リソースが増えます。

中断状態では、リソースを解放するためにオペレーティング システムが中断されたアプリを終了する場合があるため、開発者にとって新しい要件が追加されます。 終了したアプリは引き続きタスク バーに表示されます。 ユーザーがそれをクリックすると、ユーザーはシステムがアプリを閉じたことに気付かないので、アプリは終了前の状態を復元する必要があります。 彼らは、他のことをしている間、バックグラウンドで待機していると考え、それを離れたときと同じ状態になると予想します。 このトピックでは、これを実現する方法について説明します。

Windows 10 バージョン 1607 では、さらに 2 つのアプリ モデル状態が導入されました。 フォアグラウンド での実行と バックグラウンドでの実行です。 以下のセクションでは、これらの追加の状態について説明します。

アプリの実行状態

この図は、Windows 10 バージョン 1607 以降で可能なアプリ モデルの状態を表しています。 UWP アプリの一般的なライフサイクルを見てみましょう。

state diagram showing transitions between app execution states

アプリは、起動またはアクティブ化されると、実行中の状態になります。 フォアグラウンド アプリの起動のためにアプリをフォアグラウンドに移動する必要がある場合、アプリは LeavingBackground イベントを取得します。

"起動済み" と "アクティブ化済み" は似た用語のように見えるかもしれませんが、オペレーティング システムがアプリを起動するさまざまな方法を指します。 まず、アプリの起動を見てみましょう。

アプリの起動

OnLaunched メソッドは、アプリの起動時に呼び出されます。 これは、特に、アプリに 渡される引数、アプリを起動したタイルの識別子、およびアプリが存在していた以前の状態を提供する LaunchActivatedEventArgs パラメーターを渡されます。

ApplicationExecutionState を返す LaunchActivatedEventArgs.PreviousExecutionState からアプリの以前の状態を取得します。 その値と、その状態のために実行する適切なアクションは次のとおりです。

ApplicationExecutionState 説明 実行するアクション
NotRunning アプリは、ユーザーが前回再起動またはログインしてから起動されていないため、この状態になる可能性があります。 また、実行中であってもクラッシュした場合や、ユーザーが以前に閉じたために、この状態になる場合もあります。 現在のユーザー セッションで初めて実行されているかのようにアプリを初期化します。
一時停止 ユーザーはアプリを最小化または切り替えたが、数秒以内にアプリに戻らなかった。 アプリが中断されると、その状態がメモリにメインされます。 必要なのは、アプリが中断されたときに解放したファイル ハンドルまたはその他のリソースを再取得することだけです。
終了 アプリは以前は中断されていましたが、システムがメモリを再利用する必要があるため、ある時点でシャットダウンされました。 ユーザーが切り替えたときにアプリが存在していた状態を復元します。
ClosedByUser ユーザーが、システムの [閉じる] ボタンまたは Alt + F4 キーを使用してアプリを閉じました。 ユーザーがアプリを閉じると、アプリは最初に中断され、次に終了されます。 アプリは基本的に終了状態に至るのと同じ手順を実行しているため、終了状態と同じように処理します。
実行中 ユーザーがもう一度起動しようとしたときに、アプリは既に開かれていました。 何も起きない。 アプリの別のインスタンスが起動されないことに注意してください。 既に実行中のインスタンスは、単にアクティブ化されます。

Note

現在のユーザー セッション は、Windows ログオンに基づいています。 現在のユーザーが Windows をログオフ、シャットダウン、または再起動していない限り、現在のユーザー セッションは、ロック画面認証、ユーザー切り替えなどのイベント間で保持されます。

注意すべき重要な状況の 1 つは、デバイスに十分なリソースがある場合、オペレーティング システムは、応答性を最適化するために、その動作をオプトインした頻繁に使用されるアプリを事前に起動することです。 事前起動されたアプリはバックグラウンドで起動された後、ユーザーがアプリに切り替えたときに再開できるように、アプリを起動するよりも迅速に中断されます。

事前起動のため、アプリの OnLaunched() メソッドはユーザーではなく、システムによって開始される可能性があります。 アプリはバックグラウンドで事前起動されるため、OnLaunched() で別のアクションを実行する必要がある場合があります。 たとえば、アプリの起動時に音楽の再生を開始した場合、アプリはバックグラウンドで事前起動されるため、どこから来たのかはわかりません。 アプリがバックグラウンドで事前起動されると、その後に Application.Suspending の呼び出しが行われます。 次に、ユーザーがアプリを起動すると、再開イベントと OnLaunched() メソッドが呼び出されます。 事前起動シナリオを処理する方法の詳細については、「 アプリの事前起動 の処理」を参照してください。 オプトインするアプリのみが事前起動されます。

Windows を起動すると、アプリのスプラッシュ画面が表示されます。 スプラッシュ画面を構成するには、「スプラッシュ画面の追加」を参照してください。

スプラッシュ画面が表示されている間、アプリはイベント ハンドラーを登録し、初期ページに必要なカスタム UI を設定する必要があります。 アプリケーションのコンストラクターや OnLaunched() で実行されているこれらのタスクが数秒以内に完了することを確認してください。さもないと、システムはアプリを無応答と見なして終了する可能性があります。 アプリがネットワークからデータを要求する必要がある場合、またはディスクから大量のデータを取得する必要がある場合は、起動の外部でこれらのアクティビティを完了する必要があります。 アプリは、実行時間の長い操作が完了するまで待機している間、独自のカスタム読み込み UI または拡張スプラッシュ画面を使用できます。 詳しくは 、スプラッシュ画面の表示に関するページ とスプラッシュ 画面のサンプル をご覧ください。

アプリの起動が完了すると、実行中の状態になり、スプラッシュ画面が消え、スプラッシュ画面のすべてのリソースとオブジェクトがクリアされます。

アプリのアクティブ化

ユーザーが起動するのとは対照的に、アプリはシステムによってアクティブ化できます。 アプリは、共有コントラクトなどのコントラクトによってアクティブ化される場合があります。 または、カスタム URI プロトコルまたはアプリが処理するために登録されている拡張子を持つファイルを処理するようにアクティブ化することもできます。 アプリをアクティブ化する方法の一覧については、「ActivationKind」を参照してください。

Windows.UI.Xaml.Application クラスは、アプリをアクティブ化するさまざまな方法を処理するためにオーバーライドできるメソッドを定義します。 OnActivated では、使用可能なすべてのアクティブ化の種類を処理できます。 ただし、最も一般的なアクティブ化の種類を処理するために特定のメソッドを使用し、あまり一般的でないアクティブ化の種類のフォールバック メソッドとして OnActivated を使用する方が一般的です。 特定のアクティブ化のための追加の方法を次に示します。

OnCachedFileUpdaterActivated
OnFileActivated
OnFileOpenPickerActivatedOnFileSavePickerActivated
OnSearchActivated
OnShareTargetActivated

これらのメソッドのイベント データには、上で見たのと同じ PreviousExecutionState プロパティが含まれています。これは、アクティブ化される前のアプリの状態を示しています。 状態と、アプリの起動セクションで上記と同じ方法で行う必要がある内容を解釈します。

注: コンピューターの 管理istrator アカウントを使用してログオンする場合、UWP アプリをアクティブ化することはできません。

バックグラウンドでの実行

Windows 10 バージョン 1607 以降では、アプリはアプリ自体と同じプロセス内でバックグラウンド タスクを実行できます。 詳細については、単一プロセス モデルを 使用したバックグラウンド アクティビティを参照してください。 この記事ではインプロセスバックグラウンド処理を行いませんが、これがアプリのライフサイクルにどのように影響するかは、アプリがバックグラウンドにあるときに関連する 2 つの新しいイベントが追加されていることです。 EnteredBackground と LeavingBackground です。

これらのイベントには、ユーザーがアプリの UI を表示できるかどうかも反映されます。

バックグラウンドでの実行は、アプリケーションが起動、アクティブ化、または再開される既定の状態です。 この状態では、アプリケーション UI はまだ表示されません。

フォアグラウンドでの実行

フォアグラウンドで実行すると、アプリの UI が表示されます。

LeavingBackground イベントは、アプリケーション UI が表示される直前、およびフォアグラウンド状態で実行中に入る直前に発生します。 また、ユーザーがアプリに戻ったときにも発生します。

以前は、UI アセットを読み込むのに最適な場所は、アクティブ化または再開イベント ハンドラーでした。 これで 、LEAVINGBackground が UI の準備ができていることを確認するのに最適な場所です。

アプリケーションがユーザーに表示される前に作業を行う最後の機会であるため、ビジュアルアセットの準備が完了していることをチェックすることが重要です。 このイベント ハンドラーのすべての UI 作業は、ユーザーが経験する起動時間と再開時間に影響を与えるため、迅速に完了する必要があります。 LeavingBackground は、UI の最初のフレームの準備が整っていることを確認する時間です。 その後、イベント ハンドラーが返されるように、実行時間の長いストレージまたはネットワーク呼び出しを非同期的に処理する必要があります。

ユーザーがアプリケーションから切り替えると、アプリはバックグラウンド状態で実行中を再入力します。

バックグラウンド状態の再入力

EnteredBackground イベントは、アプリがフォアグラウンドで表示されなくなったことを示します。 デスクトップ の EnteredBackground は、アプリが最小化されているときに起動します。電話では、ホーム画面または別のアプリに切り替えるときに発生します。

アプリのメモリ使用量を減らす

アプリはユーザーに表示されなくなったため、UI のレンダリング作業とアニメーションを停止するのに最適な場所です。 LeavingBackground を使用して、その作業をもう一度開始できます。

バックグラウンドで作業を行う場合は、ここで準備します。 MemoryManager.AppMemoryUsageLevel をチェックすることをお勧めします。また、必要に応じて、アプリがバックグラウンドで実行されているときに使用されるメモリの量を減らして、リソースを解放するためにシステムによって終了されるリスクがないようにすることをお勧めします。

詳細については、 アプリがバックグラウンド状態 に移行したときのメモリ使用量の削減に関するページを参照してください。

状態を保存する

中断イベント ハンドラーは、アプリの状態を保存するのに最適な場所です。 ただし、バックグラウンドで作業を行う場合 (たとえば、オーディオ再生、拡張実行セッションやインプロセス バックグラウンド タスクを使用)、EnteredBackground イベント ハンドラーから非同期的にデータを保存することをお勧めします。 これは、バックグラウンドで優先度が低い状態でアプリが終了する可能性があるためです。 その場合、アプリは中断状態を通過しないため、データは失われます。

バックグラウンド アクティビティが開始される前に、EnteredBackground イベント ハンドラーにデータを保存することで、ユーザーがアプリをフォアグラウンドに戻すときの優れたユーザー エクスペリエンスが保証されます。 アプリケーション データ API を使用して、データと設定を保存できます。 詳細については、「設定とその他のアプリ データを格納および取得する」を参照してください。

データを保存した後、メモリ使用量の上限を超えている場合は、後で再読み込みできるため、メモリからデータを解放できます。 これによって、バックグラウンド アクティビティに必要な資産で使用できるメモリが解放されます。

アプリにバックグラウンド アクティビティが進行中の場合、中断状態に達することなく、バックグラウンド状態の実行中からフォアグラウンド状態の実行中に移動できることに注意してください。

Note

アプリがユーザーによって閉じられると、EnteredBackground イベントの 前に OnSuspending イベントが 発生する可能性 があります。 場合によっては、アプリが終了する 前に EnteredBackground イベントが発生しないことがあります。 OnSuspending イベント ハンドラーにデータを保存することが重要です。

非同期作業と遅延

ハンドラー内で非同期呼び出しを行うと、その非同期呼び出しから直ちに制御が返されます。 つまり、非同期呼び出しがまだ完了していない場合でも、実行はイベント ハンドラーから戻り、アプリは次の状態に移行します。 イベント ハンドラーに渡される EnteredBackgroundEventArgs オブジェクトで GetDeferral メソッドを使用して、返された Windows.Foundation.Deferral オブジェクトで Complete メソッドを呼び出すまで中断を遅延させます。

遅延によって、アプリが終了するまでにコードを実行する必要がある時間は長くならありません。 遅延の Complete メソッドが呼び出されるか、期限が過ぎるかのどちらか早い方に達するまで、終了を遅延するだけです。

状態を保存するためにさらに時間が必要な場合は、アプリがバックグラウンド状態に入る前に状態を段階的に保存する方法を調査して、OnSuspending イベント ハンドラーに保存する時間を減らします。 または、より多くの時間を 取得するために ExtendedExecutionSession を要求することもできます。 ただし、要求が許可される保証はないため、状態を保存するために必要な時間を最小限に抑える方法を見つけることをお勧めします。

アプリの中断

ユーザーがアプリを最小化すると、Windows は数秒待って、ユーザーがアプリに切り替えるかどうかを確認します。 この時間枠内に戻らず、拡張実行、バックグラウンド タスク、またはアクティビティスポンサー実行がアクティブでない場合、Windows はアプリを中断します。 そのアプリで拡張実行セッションなどがアクティブでない限り、ロック画面が表示されると、アプリも一時停止されます。

アプリが中断されると、Application.Suspending イベントが呼び出されます。 Visual Studio の UWP プロジェクト テンプレートは、App.xaml.cs で OnSuspending と呼ばれるこのイベントのハンドラーを提供しています。 ここにアプリケーションの状態を保存するコードを配置する必要があります。

アプリが中断されている間に他のアプリからアクセスできるように、排他的なリソースとファイル ハンドルを解放する必要があります。 排他的リソースの例としては、カメラ、I/O デバイス、外部デバイス、ネットワーク リソースなどがあります。 排他リソースとファイル ハンドルを明示的に解放すると、アプリが中断されている間に他のアプリからアクセスできるようになります。 アプリが再開されるときに、排他リソースとファイル ハンドルを再取得する必要があります。

期限に注意する

高速で応答性の高いデバイスを確保するために、中断中のイベント ハンドラーでコードを実行する必要がある時間には制限があります。 これはデバイスごとに異なり、期限と呼ばれる SuspendingOperation オブジェクトのプロパティを使用して何が使用されているかを確認できます。

EnteredBackground イベント ハンドラーと同様に、ハンドラーから非同期呼び出しを行うと、その非同期呼び出しから直ちに制御が返されます。 つまり、非同期呼び出しがまだ完了していない場合でも、実行はイベント ハンドラーから戻り、アプリは中断状態に移行します。 SuspendingOperation オブジェクトの GetDeferral メソッド (イベント引数を介して使用可能) を使用して、返された SuspendingDeferral オブジェクトで Complete メソッドを呼び出すまで中断状態の入力を遅延させます。

さらに時間が必要な場合は、ExtendedExecutionSession を要求できます。 ただし、要求が許可される保証はないため、Suspended イベント ハンドラーで必要な時間を最小限に抑える方法を見つけることをお勧めします。

アプリの終了

システムは、アプリの一時停止中、アプリとそのデータをメモリに保持するよう試みます。 ただし、システムにアプリをメモリに保持するリソースがない場合は、アプリが終了します。 アプリは終了中であるという通知を受け取らないので、アプリのデータを保存する必要がある唯一の機会は 、OnSuspending イベント ハンドラーにあります。

アプリが終了後にアクティブ化されたと判断した場合は、アプリが終了する前と同じ状態になるように、保存したアプリケーション データを読み込む必要があります。 ユーザーが終了した中断されたアプリに戻ると、アプリは OnLaunched メソッドでアプリケーション データを復元する必要があります。 システムは終了時にアプリに通知しないため、アプリはアプリケーション データを保存し、中断される前に排他リソースとファイル ハンドルを解放し、終了後にアプリがアクティブ化されたときに復元する必要があります。

Visual Studio を使用したデバッグに関する注意事項: Visual Studio では、デバッガーにアタッチされているアプリが Windows によって中断されなくなります。 これは、アプリの実行中にユーザーが Visual Studio デバッグ UI を表示できるようにするためです。 アプリをデバッグする場合は、Visual Studio を使用して一時停止イベントを送信できます。 [デバッグの場所] ツール バーが表示されていることを確認し、[中断] アイコンをクリックします。

アプリの再開

中断されたアプリは、ユーザーがアプリに切り替えたとき、またはデバイスが低電力状態から出たときにアクティブなアプリである場合に再開されます。

アプリが中断状態から再開されると、バックグラウンド状態で実行中に入り、システムは中断したアプリを復元して、アプリが一緒に実行されているかのようにユーザーに表示されるようにします。 メモリに格納されているアプリ データは失われません。 そのため、ほとんどのアプリは再開時に状態を復元する必要はありませんが、中断されたときに解放したファイルまたはデバイス ハンドルを再取得し、アプリが中断されたときに明示的に解放された状態を復元する必要があります。

アプリは何時間も何日も中断される可能性があります。 古くなった可能性のあるコンテンツまたはネットワーク接続がアプリにある場合は、アプリの再開時に更新する必要があります。 アプリケーションが Application.Resuming イベントのイベント ハンドラーを登録した場合、アプリが中断状態から再開されたときに呼び出されます。 このイベント ハンドラーでは、アプリのコンテンツとデータを更新できます。

中断されたアプリがアプリ コントラクトまたは拡張機能に参加するようにアクティブ化されると、最初に再開イベント、次にアクティブ化されたイベントを受け取ります。

中断されたアプリが終了した場合、再開イベントはなく、代わりに OnLaunched() が Terminated の ApplicationExecutionState で呼び出されます。 アプリが中断されたときに状態を保存したため、OnLaunched() 中にその状態を復元して、アプリが切り替え時と同じようにユーザーに表示されるようにすることができます。

アプリは一時停止中に、受信するために登録したネットワーク イベントを受信しません。 これらのネットワーク イベントはキューに登録されません。単に見落とされます。 そのため、アプリは再開時にネットワークの状態をテストする必要があります。

注:Resuming イベントは UI スレッドから生成されないため、再開ハンドラー内のコードが UI と通信する場合は、ディスパッチャーを使用する必要があります。 これを行う方法のコード例については、「バックグラウンド スレッドから UI スレッドを更新する」を参照してください。

一般的なガイドラインについては、「アプリの中断と再開のガイドライン」を参照してください。

アプリを閉じる

一般に、ユーザーはアプリを閉じる必要がなく、Windows でアプリを管理できます。 ただし、ユーザーは、閉じるジェスチャを使用するか、Alt キーを押しながら F4 キーを押すか、Windows 電話のタスク スイッチャーを使用して、アプリを閉じることもできます。

ユーザーがアプリを閉じたことを示すイベントはありません。 ユーザーがアプリを閉じると、状態を保存する機会を与えるために最初に中断されます。 Windows 8.1 以降では、アプリがユーザーによって閉じられた後、アプリは画面と切り替えリストから削除されますが、明示的に終了されません。

ユーザーによって閉じられたときの動作: アプリがユーザーによって閉じられたときに、Windows によって閉じられたときとは異なる動作を実行する必要がある場合は、アクティブ化イベント ハンドラーを使用して、アプリがユーザーまたは Windows のどちらによって終了されたかを判定できます。 ApplicationExecutionState 列挙体のリファレンスで ClosedByUser と Terminated 状態の説明を参照してください。

絶対に必要でない限り、プログラムでアプリを閉じないことをお勧めします。 たとえば、アプリがメモリ リークを検出した場合、アプリ自体を閉じて、ユーザーの個人データのセキュリティを確保できます。

アプリのクラッシュ

システム クラッシュ エクスペリエンスは、ユーザーができるだけ早く実行していた作業に戻るように設計されています。 警告ダイアログやその他の通知はユーザーを遅らせるので、指定しないでください。

アプリがクラッシュしたり、応答を停止したり、例外が生成されたりした場合、ユーザーのフィードバックと診断設定に従って問題レポートが Microsoft に送信されます。 Microsoft では、アプリの改善に使用できるように、問題レポートのエラー データのサブセットを提供しています。 このデータは、ダッシュボードのアプリの [品質] ページで確認できます。

クラッシュ後にユーザーがアプリをアクティブ化すると、アクティブ化イベント ハンドラーは NotRunning の ApplicationExecutionState 値を受け取り、その初期 UI とデータを表示する必要があります。 クラッシュ後、中断された状態で再開するために使用したアプリ データは、データが破損している可能性があるため、定期的に使用しないでください。アプリの中断と再開のガイドラインを参照してください。

アプリの削除

ユーザーがアプリを削除すると、アプリとそのすべてのローカル データが削除されます。 アプリを削除しても、ドキュメントライブラリや画像ライブラリなどの一般的な場所に保存されたユーザーのデータには影響しません。

アプリのライフサイクルと Visual Studio プロジェクト テンプレート

アプリのライフサイクルに関連する基本的なコードは、Visual Studio プロジェクト テンプレートで提供されます。 基本的なアプリは起動のアクティブ化を処理し、アプリ データを復元するための場所を提供し、独自のコードを追加する前でもプライマリ UI を表示します。 詳細については、アプリの C#、VB、および C++ プロジェクト テンプレートを参照してください。

主要なアプリケーション ライフサイクル API