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

このトピックでは、ユニバーサル Windows プラットフォーム (UWP) アプリのライフサイクル (アプリが起動されたときから、アプリが閉じられるまで) について説明します。This topic describes the lifecycle of a Universal Windows Platform (UWP) app from the time it is launched until it is closed.

簡単な経緯A little history

Windows 8 より前は、アプリのライフサイクルは単純でした。Before Windows 8, apps had a simple lifecycle. Win32 アプリや .NET アプリは、実行されているか、実行されていないかのどちらかです。Win32 and .NET apps are either running or not running. ユーザーがアプリを最小化し、他のアプリに切り替えても、アプリは引き続き実行されています。When a user minimizes them, or switches away from them, they continue to run. ポータブル デバイスが台頭し、電源管理がますます重要になるまでは、これで問題はありませんでした。This was fine until portable devices and power management became increasingly important.

Windows 8 では、UWP アプリにより新しいアプリケーション モデルが導入されました。Windows 8 introduced a new application model with UWP apps. 大まかに言うと、新しい中断状態が追加されました。At a high level, a new suspended state was added. UWP アプリは、ユーザーがアプリを最小化するか、別のアプリに切り替えた後、すぐに中断されます。A UWP app is suspended shortly after the user minimizes it or switches to another app. つまり、アプリのスレッドは停止し、オペレーティング システムがリソースを再利用する必要がある場合を除き、アプリはメモリ内に残ります。This means that the app's threads are stopped and the app is left in memory unless the operating system needs to reclaim resources. ユーザーが元のアプリに切り替えると、アプリはすばやく実行中の状態に復元されます。When the user switches back to the app, it can be quickly restored to a running state.

アプリがバックグラウンドにあるときに、アプリの実行を継続する必要がある場合、さまざまな方法があります。バックグラウンド タスク延長実行、アクティビティ スポンサード実行 (たとえば、アプリがバックグラウンドでのメディアの再生を続行できるようにする BackgroundMediaEnabled 機能) などです。There are various ways for apps that need to continue to run when they are in the background such as background tasks, extended execution, and activity sponsored execution (for example, the BackgroundMediaEnabled capability which allows an app to continue to play media in the background). また、バックグラウンド転送操作は、アプリが中断または終了した場合でも続行できます。Also, background transfer operations can continue even if your app is suspended or even terminated. 詳しくは、「ファイルのダウンロード方法」をご覧ください。For more info, see How to download a file.

既定では、フォアグラウンドにないアプリは中断され、その結果として、電力が節約され、現在フォアグラウンドにあるアプリが利用できるリソースが増加します。By default, apps that are not in the foreground are suspended which results in power savings and more resources available for the app currently in the foreground.

中断状態では、オペレーティング システムはリソースを解放するためには中断中のアプリを終了することがあるため、開発者にとっては新しい要件が追加されます。The suspended state adds new requirements for you as a developer because the operating system may elect to terminate a suspended app in order to free up resources. 終了されたアプリは、引き続きタスク バーに表示されます。The terminated app will still appear in the task bar. ユーザーがこのアプリをクリックした場合、アプリは終了される前の状態を復元する必要があります。ユーザーは、システムがアプリを閉じたことを認識できないためです。When the user click on it, the app must restore the state that it was in before it was terminated because the user will not be aware that the system closed the app. ユーザーは、他の作業を行っている間、アプリがバックグラウンドで待機していたと考え、他のアプリに切り替えたときと同じ状態であることを期待しています。They will think that it has been waiting in the background while they were doing other things and will expect it to be in the same state it was in when they left it. このトピックでは、これを実現する方法について取り上げます。In this topic we will look at how to accomplish that.

Windows 10 バージョン 1607 では、もう 2 つのアプリ モデルの状態が導入されています。フォアグラウンドでの実行バックグラウンドでの実行です。Windows 10, version 1607, introduces two more app model states: Running in foreground and Running in background. 以下のセクションでこれらの新しい状態についても説明します。We will also look at these new states in the sections that follow.

アプリの実行状態App execution state

次の図は、Windows 10、バージョン 1607 以降での、可能なアプリ モデルの状態を表しています。This illustration represents the possible app model states starting in Windows 10, version 1607. UWP アプリの一般的なライフサイクルを順に見ていきましょう。Let's walk through the typical lifecycle of a UWP app.


アプリは、起動またはアクティブ化されると、バックグラウンドでの実行状態になります。Apps enter the running in background state when they are launched or activated. アプリを取得し、アプリがフォアグラウンドで起動したためにフォアグラウンドに移動する必要がある場合、アプリは LeavingBackground イベントを取得します。If the app needs to move into the foreground due to a foreground app launch, the app then gets the LeavingBackground event.

「起動」と「アクティブ化」の用語は似ているように見えますが、オペレーティング システムがアプリを起動する際の異なる方法を示しています。Although "launched" and "activated" may seem like similar terms, they refer to different ways the operating system may start your app. まず、アプリの起動を見てみましょう。Let's first look at launching an app.

アプリの起動App launch

アプリが起動されると、OnLaunched メソッドが呼び出されます。The OnLaunched method is called when an app is launched. このメソッドに LaunchActivatedEventArgs パラメーターが渡されます。このパラメーターは、特に、アプリに渡された引数、アプリを起動したタイルの識別子、アプリの以前の状態を提供します。It is passed a LaunchActivatedEventArgs parameter which provides, among other things, the arguments passed to the app, the identifier of the tile that launched the app, and the previous state that the app was in.

アプリの以前の状態は、ApplicationExecutionState を返す LaunchActivatedEventArgs.PreviousExecutionState から取得します。Get the previous state of your app from LaunchActivatedEventArgs.PreviousExecutionState which returns an ApplicationExecutionState. その値とその状態に対する適切なアクションは次のとおりです。Its values and the appropriate action to take due to that state are as follows:

ApplicationExecutionStateApplicationExecutionState 説明Explanation 実行するアクションAction to take
NotRunningNotRunning アプリがこの状態になるのは、ユーザーが前回再起動するか、ログインしてから、アプリが起動されていないためである可能性があります。An app could be in this state because it hasn't been launched since the last time the user rebooted or logged in. また、アプリが実行中であったがクラッシュした場合や、ユーザーが以前にアプリを閉じたために、この状態になっている可能性もあります。It can also be in this state if it was running but then crashed, or because the user closed it earlier. 現在のユーザー セッションで初めて実行する場合と同様に、アプリを初期化します。Initialize the app as if it is running for the first time in the current user session.
中断済みSuspended ユーザーがアプリを最小化したか、アプリを切り替えてから、数秒以内にそのアプリに戻っていません。The user either minimized or switched away from your app and didn't return to it within a few seconds. アプリが中断されると、アプリの状態はメモリ内に保持されます。When the app was suspended, its state remained in memory. 必要な処理は、アプリが中断されたときに解放したファイル ハンドルやその他のリソースを再取得することだけです。You only need to reacquire any file handles or other resources you released when the app was suspended.
終了Terminated アプリは、以前に中断されましたが、システムがメモリを再利用する必要があったため、ある時点でシャットダウンされました。The app was previously suspended but was then shutdown at some point because the system needed to reclaim memory. ユーザーがアプリを切り替えたときのアプリの状態を復元します。Restore the state that the app was in when the user switched away from it.
ClosedByUserClosedByUser ユーザーは、タブレット モードでの閉じるジェスチャや、Alt キーを押しながら F4 キーを押すことによって、アプリを終了しました。The user closed the app with the close gesture in tablet mode, or with Alt+F4. ユーザーがアプリを閉じた場合、アプリはまず中断され、次に終了します。When the user closes the app, it is first suspended and then terminated. アプリは基本的に Terminated 状態に至る手順と同じ手順に従うため、Terminated 状態と同じ方法でこれを処理します。Because the app has essentially gone through the same steps that lead to the Terminated state, handle this the same way you would the Terminated state.
実行中Running ユーザーがアプリを起動しようとしたときに、アプリは既に開いていました。The app was already open when the user tried to launch it again. 何も起きない。Nothing. アプリの別のインスタンスが起動されないことに注意してください。Note that another instance of your app is not launched. 既に実行中のインスタンスが、単にアクティブ化されます。The already running instance is simply activated.

  現在のユーザー セッションは、Windows ログオンに基づきます。Note  Current user session is based on Windows logon. 現在のユーザーがログオフ、Windows のシャットダウンや再起動を行っていない限り、現在のユーザー セッションは、ロック画面認証やユーザーの切り替えなどのイベント間で保持されます。As long as the current user hasn't logged off, shut down, or restarted Windows, the current user session persists across events such as lock screen authentication, switch-user, and so on. 

注意すべき重要な状況が 1 つあります。デバイスに十分なリソースがある場合、応答性の最適化のために事前起動がオプトインされている、使用頻度の高いアプリをオペレーティング システムが事前起動することです。One important circumstance to be aware of is that if the device has sufficient resources, the operating system will prelaunch frequently used apps that have opted in for that behavior in order to optimize responsiveness. 事前起動されたアプリは、バックグラウンドで起動され、すぐに中断されます。これにより、ユーザーがこれらのアプリに切り替えたときに、アプリを起動するよりも高速に再開することができます。Apps that are prelaunched are launched in the background and then quickly suspended so that when the user switches to them, they can be resumed which is faster than launching the app.

事前起動のために、アプリの OnLaunched() メソッドは、ユーザーではなく、システムによって開始される可能性があります。Because of prelaunch, the app’s OnLaunched() method may be initiated by the system rather than by the user. アプリはバックグラウンドで事前起動されるため、OnLaunched() で異なるアクションが必要になる可能性があります。Because the app is prelaunched in the background you may need to take different action in OnLaunched(). たとえば、アプリが起動時に音楽の再生を開始する場合、アプリはバックグラウンドで事前起動されるため、どこから音楽が再生されているのかわかりません。For example, if your app starts playing music when launched, they will not know where it is coming from because the app is prelaunched in the background. アプリがバックグラウンドで事前起動されたら、続けて Application.Suspending を呼び出します。Once your app is prelaunched in the background, it is followed by a call to Application.Suspending. その後、ユーザーがアプリを起動したときに、OnLaunched() メソッドと共に再開イベントが呼び出されます。Then, when the user does launch the app, the resuming event is invoked as well as the OnLaunched() method. 事前起動のシナリオを処理する方法について詳しくは、「アプリの事前起動の処理」をご覧ください。See Handle app prelaunch for additional information about how to handle the prelaunch scenario. オプトインしているアプリだけが事前起動されます。Only apps that opt-in are prelaunched.

Windows によって、アプリの起動時に、アプリのスプラッシュ画面が表示されます。Windows displays a splash screen for the app when it is launched. スプラッシュ画面を構成するには、「スプラッシュ画面の追加」をご覧ください。To configure the splash screen, see Adding a splash screen.

スプラッシュ画面が表示されているときに、アプリはイベント ハンドラーを登録し、最初のページに必要なカスタム UI を設定する必要があります。While the splash screen is displayed, your app should register event handlers and set up any custom UI it needs for the initial page. アプリのコンストラクターや OnLaunched() で実行されるこれらのタスクが数秒以内に完了することを確認します。数秒以内に完了しない場合、システムはアプリが応答していないと判断し、アプリを終了する可能性があります。See that these tasks running in the application’s constructor and OnLaunched() are completed within a few seconds or the system may think your app is unresponsive and terminate it. アプリがネットワーク経由でデータを要求したり、ディスクから大量のデータを取得したりする必要がある場合、こうしたアクティビティは起動とは別に実行してください。If an app needs to request data from the network or needs to retrieve large amounts of data from disk, these activities should be completed outside of launch. 実行に時間がかかる操作が完了するまでの間、アプリでは、アプリ独自のカスタム読み込み UI や追加のスプラッシュ画面を使うことができます。An app can use its own custom loading UI or an extended splash screen while it waits for long running operations to finish. 詳しくは、「スプラッシュ画面の表示時間の延長」や「スプラッシュ画面のサンプル」をご覧ください。See Display a splash screen for more time and the Splash screen sample for more info.

アプリの起動が完了すると、アプリが Running 状態になり、スプラッシュ画面は消えて、スプラッシュ画面のすべてのリソースとオブジェクトは消去されます。After the app completes launching, it enters the Running state and the splash screen disappears and all splash screen resources and objects are cleared.

アプリのアクティブ化App activation

ユーザーによる起動とは対照的には、システムによってアプリをアクティブ化できます。In contrast to being launched by the user, an app can be activated by the system. アプリは、共有コントラクトなどのコントラクトによってアクティブ化される可能性があります。An app may be activated by a contract such as the share contract. また、カスタム URI プロトコルや、アプリが処理するように登録されている拡張子を持つファイルを処理するためにアクティブ化される可能性があります。Or it may be activated to handle a custom URI protocol or a file with an extension that your app is registered to handle. アプリをアクティブ化する方法の一覧については、「 ActivationKind」を参照してください。For a list of ways your app can be activated, see ActivationKind.

Windows.UI.Xaml.Application クラスで定義されているメソッドをオーバーライドして、アプリをアクティブ化するさまざまな方法に対応することができます。The Windows.UI.Xaml.Application class defines methods you can override to handle the various ways your app may be activated. OnActivated は、発生する可能性があるすべてのアクティブ化の種類を処理できます。OnActivated can handle all possible activation types. ただし、最も一般的なアクティブ化の種類を処理する場合は特定のメソッドを使い、あまり一般的ではないアクティブ化の種類を処理する際の代替手段としてのみ OnActivated を使うことが多くあります。However, it's more common to use specific methods to handle the most common activation types, and use OnActivated as the fallback method for the less common activation types. 特定のアクティブ化については、次のような追加のメソッドがあります。These are the additional methods for specific activations:

OnFileOpenPickerActivated OnFileSavePickerActivatedOnFileOpenPickerActivated OnFileSavePickerActivated

これらのメソッドのイベント データには、既に説明した同じ PreviousExecutionState プロパティが含まれており、アプリがアクティブ化される前の状態を確認することができます。The event data for these methods includes the same PreviousExecutionState property that we saw above, which tells you which state your app was in before it was activated. 前の「アプリの起動」セクションで説明した方法と同じ方法で、状態と対処を解釈します。Interpret the state and what you should do it the same way as described above in the App launch section.

メモ  コンピューターの管理者アカウントを使用してログオンした場合、UWP アプリをアクティブ化することはできません。Note If you log on using the computer's Administrator account, you can't activate UWP apps.

バックグラウンドでの実行Running in the background

Windows 10 バージョン 1607 以降では、アプリは、アプリ自体と同じプロセスでバックグラウンド タスクを実行できます。Starting with Windows 10, version 1607, apps can run background tasks within the same process as the app itself. 詳しくは、シングル プロセス モデルでのバックグラウンド アクティビティに関する記事をご覧ください。Read more about it in Background activity with the Single Process Model. インプロセスのバックグラウンド処理については、この記事では詳しく説明しませんが、アプリのライフサイクルへの影響として、アプリをバックグラウンドで実行する場合に関連する 2 つの新しいイベントが追加されています。We won't go into in-process background processing in this article, but how this impacts the app lifecycle is that two new events have been added related to when your app is in the background. EnteredBackgroundLeavingBackground です。They are: EnteredBackground and LeavingBackground.

これらのイベントは、アプリの UI を表示するかどうかも反映します。These events also reflect whether the user can see your app's UI.

バックグラウンドでの実行は、アプリが起動、アクティブ化、再開されたときの既定の状態です。Running in the background is the default state that an application is launched, activated, or resumed into. この状態では、アプリの UI はまだ表示されません。In this state your application UI is not visible yet.

フォアグラウンドでの実行Running in the foreground

フォアグラウンドでの実行は、アプリの UI が表示されていることを意味します。Running in the foreground means that your app's UI is visible.

LeavingBackground イベントは、アプリの UI が表示される直前で、フォアグラウンドでの実行状態になる前に発生します。The LeavingBackground event is fired just before your application UI is visible and before entering the running in foreground state. また、ユーザーが元のアプリに切り替えるときにも発生します。It also fires when the user switches back to your app.

以前は、UI のアセットを読み込むのに最適な場所が、Activated または Resuming イベント ハンドラーでした。Previously, the best location to load UI assets was in the Activated or Resuming event handlers. 現在は、LeavingBackground が UI の準備ができていることを確認するのに最適な場所です。Now LeavingBackground is the best place to verify that your UI is ready.

この時点でビジュアル アセットの準備が完了していることを確認すること重要です。これが、ユーザーに対してアプリが表示される前に処理を実行する最後の機会であるためです。It is important to check that visual assets are ready by this time because this is the last opportunity to do work before your application is visible to the user. このイベント ハンドラー内でのすべての UI 処理は、迅速に完了する必要があります。これは、ユーザーが経験する起動時間や再開時間に影響を与えるためです。All UI work in this event handler should complete quickly, as it impacts the launch and resume time that the user experiences. LeavingBackground は、UI の最初のフレームの準備ができていることを確認するタイミングです。LeavingBackground is the time to ensure the first frame of UI is ready. その後、このイベント ハンドラーが制御を戻すことができるように、長時間にわたるストレージやネットワークの呼び出し処理を非同期的に処理する必要があります。Then, long-running storage or network calls should be handled asynchronously so that the event handler may return.

ユーザーが他のアプリに切り替えると、元のアプリは再びバックグラウンドでの実行状態に戻ります。When the user switches away from your application, your app reenters the running in background state.

バックグラウンド状態に戻るReentering the background state

EnteredBackgroundイベントは、アプリがフォアグラウンドに表示されなくなったことを示します。The EnteredBackground event indicates that your app is no longer visible in the foreground. デスクトップでは、EnteredBackground はアプリが最小化されたときに発生します。電話では、ホーム画面や別のアプリに切り替えたときに発生します。On the desktop EnteredBackground fires when your app is minimized; on phone, when switching to the home screen or another app.

アプリのメモリ使用量を減らすReduce your app's memory usage

アプリがユーザーに表示されなくなったため、これは UI のレンダリング処理とアニメーションを停止するのに最適な場所です。Since your app is no longer visible to the user, this is the best place to stop UI rendering work and animations. LeavingBackground を使って、もう一度その作業を開始できます。You can use LeavingBackground to start that work again.

バックグラウンドで処理を実行する場合、ここで処理を準備することができます。If you are going to do work in the background, this is the place to prepare for it. MemoryManager.AppMemoryUsageLevel を確認し、必要に応じてバックグラウンドでの実行時のアプリのメモリ使用量を減らすことにより、システムがリソースを解放するためにアプリを終了するリスクを下げることをお勧めします。It is best to check MemoryManager.AppMemoryUsageLevel and, if needed, reduce the amount of memory being used by your app when it is running in the background so that your app doesn't risk being terminated by the system to free up resources.

詳しくは、アプリがバックグラウンドの状態に移行したときにメモリ使用量を減らす方法に関する記事をご覧ください。See Reduce memory usage when your app moves to the background state for more details.

状態を保存するSave your state

中断イベント ハンドラーは、アプリの状態を保存するのに最適な場所です。The suspending event handler is the best place to save your app state. しかし、バックグラウンドでの処理を行う場合 (オーディオの再生、延長実行セッションの使用、インプロセス バックグラウンド タスクなど) は、EnteredBackground イベント ハンドラーから非同期的にデータを保存することもお勧めします。However, if you are doing work in the background (for example, audio playback, using an extended execution session or in-proc background task), it is also a good practice to save your data asynchronously from your EnteredBackground event handler. これは、アプリがバックグラウンドにある間に優先順位が低く、アプリが終了される可能性があるためです。This is because it is possible for your app to be terminated while it is at a lower priority in the background. また、その場合、アプリは中断状態を経ないため、データは失われます。And because the app will not have gone through the suspended state in that case, your data will be lost.

バックグラウンド アクティビティが開始される前に、EnteredBackground イベント ハンドラーでデータを保存することにより、ユーザーがアプリをフォアグラウンドに戻したときに、優れたユーザー エクスペリエンスを提供できます。Saving your data in your EnteredBackground event handler, before background activity begins, ensures a good user experience when the user brings your app back to the foreground. アプリケーション データ API を使用して、データと設定を保存することができます。You can use the application data APIs to save data and settings. 詳細については、「 設定とその他のアプリデータの保存と取得」を参照してください。For more info, see Store and retrieve settings and other app data.

データを保存した後、メモリ使用量の上限を超えている場合、後で再読み込みできるため、メモリからデータを解放できます。After you save your data, if you are over your memory usage limit, then you can release your data from memory since you can reload it later. これによりメモリが解放され、バックグラウンド アクティビティに必要なアセットで使用できます。That will free memory that can be used by the assets needed for background activity.

アプリのバックグラウンド アクティビティで進行中である場合、中断状態を経ずに、バックグラウンドでの実行状態からフォアグラウンドでの実行状態に移行できることに注意してください。Be aware that if your app has background activity in progress that it can move from the running in the background state to the running in the foreground state without ever reaching the suspended state.

非同期処理と保留Asynchronous work and Deferrals

ハンドラー内で非同期呼び出しを行う場合、制御はその非同期呼び出しからすぐに戻ります。If you make an asynchronous call within your handler, control returns immediately from that asynchronous call. つまり、非同期呼び出しがまだ完了していない場合でも、イベント ハンドラーから制御が戻り、アプリを次の状態に移行できます。That means that execution can then return from your event handler and your app will move to the next state even though the asynchronous call hasn't completed yet. イベント ハンドラーに渡される EnteredBackgroundEventArgs オブジェクトの GetDeferral メソッドを使用して、Windows.Foundation.Deferral オブジェクトの Complete メソッドを呼び出した後まで中断を延期することができます。Use the GetDeferral method on the EnteredBackgroundEventArgs object that is passed to your event handler to delay suspension until after you call the Complete method on the returned Windows.Foundation.Deferral object.

遅延では、アプリが終了する前に、実行する必要があるコードの量を増やす必要はありません。A deferral doesn't increase the amount you have to run your code before your app is terminated. 遅延の Complete メソッドが呼び出されるか、または期限になるか、どちらか早い方まで、終了が延期されるだけです。It only delays termination until either the deferral's Complete method is called, or the deadline passes-whichever comes first.

状態を保存するためにより多くの時間が必要な場合は、アプリがバックグラウンドの状態になる前に、段階的に状態を保存し、EnteredBackground イベント ハンドラーで保存する状態の情報を少なくする方法を調べます。If you need more time to save your state, investigate ways to save your state in stages before your app enters the background state so that there is less to save in your EnteredBackground event handler. または、ExtendedExecutionSession を呼び出して、より多くの時間を取得します。Or you may request an ExtendedExecutionSession to get more time. ただし、要求が許可される保証はないため、状態を保存するために必要な時間を最小限に抑える方法を見つけることをお勧めします。There is no guarantee that the request will be granted, however, so it is best to find ways to minimize the amount of time you need to save your state.

アプリの中断App suspend

ユーザーがアプリを最小化したとき、Windows は、ユーザーが再び元のアプリに切り替えるかどうかを確認するために数秒待機します。When the user minimizes an app Windows waits a few seconds to see whether the user will switch back to it. ユーザーがこの時間内に再び元のアプリに切り替えることがなく、延長実行、バックグラウンド タスク、アクティビティ スポンサード実行がどれもアクティブではない場合、Windows はアプリを中断します。If they do not switch back within this time window, and no extended execution, background task, or activity sponsored execution is active, Windows suspends the app. アプリは、延長実行セッションなどがそのアプリでアクティブではない限り、ロック画面が表示されているときにも中断されます。An app is also suspended when the lock screen appears as long as no extended execution session, etc. is active in that app.

アプリは、中断されると、Application.Suspending イベントを呼び出します。When an app is suspended, it invokes the Application.Suspending event. Visual Studio の UWP プロジェクト テンプレートでは、App.xaml.csOnSuspending と呼ばれるこのイベントのハンドラーが用意されています。Visual Studio’s UWP project templates provide a handler for this event called OnSuspending in App.xaml.cs. Windows 10 バージョン 1607 より前のバージョンでは、状態を保存するコードをここに記述していました。Prior to Windows 10, version 1607, you would put the code to save your state here. 現在は、前述のように、バックグラウンド状態に移行するときにアプリの状態を保存することをお勧めします。Now the recommendation is to save your state when you enter the background state, as described above.

また、排他リソースとファイル ハンドルを、自分のアプリが中断されているときに他のアプリがアクセスできるように解放することをお勧めします。You should release exclusive resources and file handles so that other apps can access them while your app is suspended. 排他リソースには、カメラ、I/O デバイス、外部デバイス、ネットワーク リソースなどがあります。Examples of exclusive resources include cameras, I/O devices, external devices, and network resources. 排他リソースとファイル ハンドルを明示的に解放すると、自分のアプリが中断されているときに他のアプリが排他リソースとファイル ハンドルにアクセスできるようになります。Explicitly releasing exclusive resources and file handles helps to ensure that other apps can access them while your app is suspended. アプリが再開されるときに、排他リソースとファイル ハンドルを再取得する必要があります。When the app is resumed, it should reacquire its exclusive resources and file handles.

期限に注意するBe aware of the deadline

高速で応答性の高いデバイスを実現するために、中断イベント ハンドラーでコードを実行する時間には制限があります。In order to ensure a fast and responsive device, there is a limit for the amount of time you have to run your code in your suspending event handler. この制限はデバイスごとに異なり、SuspendingOperation オブジェクトの Deadline と呼ばれるプロパティを使って制限を確認できます。It is different for each device, and you can find out what it is using a property of the SuspendingOperation object called the deadline.

EnteredBackground イベント ハンドラーと同様に、ハンドラーから非同期呼び出しを行う場合、制御はその非同期呼び出しからすぐに戻ります。As with the EnteredBackground event handler, if you make an asynchronous call from your handler, control returns immediately from that asynchronous call. つまり、非同期呼び出しがまだ完了していない場合でも、イベント ハンドラーから制御が戻り、アプリを中断状態に移行できます。That means that execution can then return from your event handler and your app will move to the suspend state even though the asynchronous call hasn't completed yet. 返された SuspendingDeferral オブジェクトに Complete メソッドを呼び出すまで中断状態への移行を遅らせるには、SuspendingOperation オブジェクト (イベント引数経由で利用可能) に対して GetDeferral メソッドを使います。Use the GetDeferral method on the SuspendingOperation object (available via the event args) to delay entering the suspended state until after you call the Complete method on the returned SuspendingDeferral object.

さらに多くの時間が必要な場合は、ExtendedExecutionSession を要求することができます。If you need more time, you may request an ExtendedExecutionSession. ただし、要求が許可される保証はないため、Suspended イベント ハンドラーで必要な時間を最小限に抑える方法を見つけることをお勧めします。There is no guarantee that the request will be granted, however, so it is best to find ways to minimize the amount of time you need in your Suspended event handler.

アプリの終了App terminate

システムは、アプリの一時停止中、アプリとそのデータをメモリに保持するよう試みます。The system attempts to keep your app and its data in memory while it's suspended. ただし、アプリをメモリに保持するためのリソースがシステムにない場合、システムはアプリを終了します。However, if the system does not have the resources to keep your app in memory, it will terminate your app. アプリは終了通知を受け取らないため、アプリのデータを保存するには、OnSuspension イベント ハンドラーで行うか、EnteredBackground ハンドラーで非同期的に行う必要があります。Apps don't receive a notification that they are being terminated, so the only opportunity you have to save your app's data is in your OnSuspension event handler, or asynchronously from your EnteredBackground handler.

終了されたアプリをアクティブ化するとき、アプリが終了する前と同じ状態になるように、保存したアプリのデータを読み込む必要があります。When your app determines that it has been activated after being terminated, it should load the application data that it saved so that the app is in the same state it was in before it was terminated. 中断されてから終了されたアプリにユーザーが戻るとき、アプリは OnLaunched メソッドでアプリケーション データを復元する必要があります。When the user switches back to a suspended app that has been terminated, the app should restore its application data in its OnLaunched method. アプリが終了されるときは、システムはアプリに通知を送らないので、アプリは中断される前にアプリケーション データを保存し、排他リソースとファイル ハンドルを解放して、アプリが終了後アクティブ化されるときにそれらを復元する必要があります。The system doesn't notify an app when it is terminated, so your app must save its application data and release exclusive resources and file handles before it is suspended, and restore them when the app is activated after termination.

Visual Studio を使用したデバッグに関する注意事項: Visual Studio は、デバッガーにアタッチされているアプリを Windows が中断できないようにします。A note about debugging using Visual Studio: Visual Studio prevents Windows from suspending an app that is attached to the debugger. これは、アプリが実行されている間、ユーザーが Visual Studio デバッグの UI を確認できるようにするためです。This is to allow the user to view the Visual Studio debug UI while the app is running. アプリのデバッグ中は、Visual Studio を使ってそのアプリに中断イベントを送信できます。When you're debugging an app, you can send it a suspend event using Visual Studio. [デバッグの場所] ツール バーが表示されていることを確認し、[中断] アイコンをクリックします。Make sure the Debug Location toolbar is being shown, then click the Suspend icon.

アプリの再開App resume

中断中のアプリは、ユーザーがそのアプリに切り替えた場合、またはデバイスが低電力状態から復帰してアクティブなアプリになった場合に再開されます。A suspended app is resumed when the user switches to it or when it is the active app when the device comes out of a low power state.

Suspended 状態からアプリを再開するとき、アプリはバックグラウンドでの実行状態に移行し、システムはアプリを中断前の状態に復元するので、ユーザーからはアプリがバックグラウンドでずっと実行されていたように見えます。When an app is resumed from the Suspended state, it enters the Running in background state and the system restores the app where it left off so that it appears to the user as if it has been running all along. メモリに格納されているアプリのデータは失われません。No app data stored in memory is lost. したがって、アプリは中断されたときに解放したファイル ハンドルやデバイス ハンドルを再取得し、中断されたときに明示的に解放された状態を復元する必要はありますが、ほとんどのアプリでは再開時に状態を復元する必要はありません。Therefore, most apps don't need to restore state when they are resumed though they should reacquire any file or device handles that they released when they were suspended, and restore any state that was explicitly released when the app was suspended.

アプリは、数時間から数日間中断される場合があります。You app may be suspended for hours or days. そのため、アプリのコンテンツやネットワーク接続が無効になっていると考えられる場合は、アプリの再開時にコンテンツやネットワーク接続を更新する必要があります。If your app has content or network connections that may have gone stale, these should be refreshed when the app resumes. アプリに Application.Resuming イベントのイベント ハンドラーが登録されている場合は、アプリが Suspended 状態から再開されるとこのイベント ハンドラーが呼び出されます。If an app registered an event handler for the Application.Resuming event, it is called when the app is resumed from the Suspended state. このイベント ハンドラーでアプリのコンテンツやデータを更新できます。You can refresh your app content and data in this event handler.

中断中のアプリがアクティブ化されてアプリ コントラクトまたは拡張機能に参加する場合は、まず Resuming イベントを受け取り、次に Activated イベントを受け取ります。If a suspended app is activated to participate in an app contract or extension, it receives the Resuming event first, then the Activated event.

中断中のアプリが終了されていた場合、Resuming イベントはなく、代わりに TerminatedApplicationExecutionState を使って OnLaunched() が呼び出されます。If the suspended app was terminated, there is no Resuming event and instead OnLaunched() is called with an ApplicationExecutionState of Terminated. アプリが中断されたときに状態を保存しているため、ユーザーからはそのアプリから他に切り替えたときと同じに見えるように、OnLaunched() でその状態を復元できます。Because you saved your state when the app was suspended, you can restore that state during OnLaunched() so that your app appears to the user as it was when they switched away from it.

アプリは、中断されている間、受信登録したネットワーク イベントを受け取りません。While an app is suspended, it does not receive any network events that it registered to receive. これらのネットワーク イベントはキューに入れられず、受け取ることができません。These network events are not queued--they are simply missed. そのため、再開時にアプリでネットワーク ステータスをテストする必要があります。Therefore, your app should test the network status when it is resumed.

メモ   再開イベントはui スレッドからは発生しないため、再開ハンドラーのコードが ui と通信する場合は、ディスパッチャーを使用する必要があります。Note  Because the Resuming event is not raised from the UI thread, a dispatcher must be used if the code in your resume handler communicates with your UI. これを行う方法のコード例については、バックグラウンド スレッドからの UI スレッドの更新に関するページをご覧ください。See Update the UI thread from a background thread for a code example of how to do this.

一般的なガイドラインについては、アプリの中断と再開のガイドラインに関するページをご覧ください。For general guidelines, see Guidelines for app suspend and resume.

アプリを閉じるApp close

一般に、アプリを閉じる処理はユーザーが行う必要はなく、Windows で管理されます。Generally, users don't need to close apps, they can let Windows manage them. ただし、ユーザーはジェスチャを使うか、Alt + F4 キーを押すか、Windows Phone でタスク スイッチャーを使って、アプリを閉じることができます。However, users can choose to close an app using the close gesture or by pressing Alt+F4 or by using the task switcher on Windows Phone.

ユーザーがアプリを閉じたことを示すイベントはありません。There is not an event to indicate that the user closed the app. アプリがユーザーによって閉じられたとき、その状態を保存する機会を提供するために、アプリはまず中断されます。When an app is closed by the user, it is first suspended to give you an opportunity to save its state. Windows 8.1 以降では、ユーザーがアプリを閉じても、アプリは明示的に終了されるのではなく、画面と切り替えリストから消えるだけです。In Windows 8.1 and later, after an app has been closed by the user, the app is removed from the screen and switch list but not explicitly terminated.

終了したユーザーの動作:   アプリが Windows によって閉じられたときとは別の方法でアプリケーションを終了する必要がある場合は、アクティベーションイベントハンドラーを使用して、アプリがユーザーによって、または Windows によって終了されたかどうかを判断できます。Closed-by-user behavior:  If your app needs to do something different when it is closed by the user than when it is closed by Windows, you can use the activation event handler to determine whether the app was terminated by the user or by Windows. ApplicationExecutionState 列挙体に関するリファレンスの ClosedByUser 状態と Terminated 状態の説明をご覧ください。See the descriptions of ClosedByUser and Terminated states in the reference for the ApplicationExecutionState enumeration.

必要でない限り、アプリをプログラムで閉じないことをお勧めします。We recommend that apps not close themselves programmatically unless absolutely necessary. たとえば、メモリ リークが検出された場合などは、ユーザーの個人データのセキュリティを確保するためにアプリ自体で閉じてもかまいません。For example, if an app detects a memory leak, it can close itself to ensure the security of the user's personal data.

アプリのクラッシュApp crash

システム クラッシュのエクスペリエンスは、ユーザーがそれまで行っていた作業にできるだけ迅速に戻れるようにすることを目的としています。The system crash experience is designed to get users back to what they were doing as quickly as possible. ユーザーを待たせることがないように、警告ダイアログなどによる通知は行わないでください。You shouldn't provide a warning dialog or other notification because that will delay the user.

アプリがクラッシュしたり、応答しなくなったり、例外が生成されたりすると、ユーザーの フィードバックと診断の設定 に従って、マイクロソフトに問題レポートが送られます。If your app crashes, stops responding, or generates an exception, a problem report is sent to Microsoft per the user's feedback and diagnostics settings. Microsoft は、アプリの改善に役立つように、問題レポートに含まれるエラー データの一部を提供しています。Microsoft provides a subset of the error data in the problem report to you so that you can use it to improve your app. このデータは、ダッシュボードに表示されるアプリの [品質] ページで確認できます。You'll be able to see this data in your app's Quality page in your Dashboard.

アプリがクラッシュした後にユーザーがアプリをアクティブ化すると、アクティブ化イベント ハンドラーは ApplicationExecutionState の値として NotRunning を受け取り、アプリの最初の UI とデータを表示します。When the user activates an app after it crashes, its activation event handler receives an ApplicationExecutionState value of NotRunning, and should display its initial UI and data. クラッシュの後、Suspended に基づく Resuming で使ったアプリ データはそのまま使わないでください。これは、そのデータが破損している可能性があるためです。「アプリの中断と再開のガイドライン」をご覧ください。After a crash, don't routinely use the app data you would have used for Resuming with Suspended because that data could be corrupt; see Guidelines for app suspend and resume.

アプリの削除App removal

ユーザーがアプリを削除すると、アプリはすべてのローカル データと共に削除されます。When a user deletes your app, the app is removed, along with all its local data. アプリの削除は、一般的な場所 (ドキュメント ライブラリやピクチャ ライブラリ内など) に格納されているユーザーのデータには影響しません。Removing an app doesn't affect the user's data that was stored in common locations such as the Documents or Pictures libraries.

アプリのライフサイクルと Visual Studio のプロジェクト テンプレートApp lifecycle and the Visual Studio project templates

アプリのライフサイクルに関連する基本的なコードは、Visual Studio のプロジェクト テンプレートに用意されています。The basic code that is relevant to the app lifecycle is provided in the Visual Studio project templates. 基本的なアプリでは、起動アクティブ化を処理し、アプリ データを復元するための場所を提供して、独自のコードを追加する前であってもプライマリ UI を表示します。The basic app handles launch activation, provides a place for you to restore your app data, and displays the primary UI even before you've added any of your own code. 詳しくは、「アプリ用の C#、VB、C++ プロジェクト テンプレート」をご覧ください。For more info, see C#, VB, and C++ project templates for apps.

主要なアプリケーション ライフサイクル APIKey application lifecycle APIs