読者です 読者をやめる 読者になる 読者になる

がりらぼ

WindowsRuntimeの応援ブログ

Windowsストアアプリのライフサイクルについて

単純化されたWindowsストアアプリのライフサイクルですが結構難しいところが多く、公式さんも間違えたおられたので

Windowsストアアプリのライフサイクルについて書きたいと思います。

もしなんか間違ってるところがあればあとでこっそりDMください

Windowsストアアプリは3つの状態をもつ

まず抑えなければいけない概念として、Windowsストアアプリは3つの状態を持つ(もっと言うと3つの状態しか持たない)ということです。

その3つの状態とは

  • 実行状態
  • 中断状態
  • 終了状態

の3つです。

それらは以下の様な状態遷移図をとります。

f:id:garicchi:20140926105105p:plain

中断状態から終了状態にはなりますが、終了状態から中断状態には移りません。

では、一つのアプリを起動したとき、どのような操作をすればどのような遷移をするのかを見ていきたいと思います。

メインビューアクティブ化

スタート画面からライブタイルをタップしてアプリを起動したり、トースト通知をタップしてアプリを起動したりすることをメインビューアクティブ化と言います。

最初はアプリは「終了状態」ですので、メインビューアクティブ化の操作を行うことによってアプリは④遷移を使って「実行状態」へと遷移します。

これは私達が通常アプリを起動する操作と全く同じです。

アプリを切り替える

では次に、今現在フォアグラウンドで触っているアプリを別のアプリに切り替えてみましょう。

左端からスワイプしてアプリを切り替えたり、Win+Tabでアプリ一覧を出して切り替えたりします。

このとき、アプリは①遷移を使って中断状態へと遷移します

このときOSは、アプリが使用しているCPUやディスクIOなどのリソースをすべて0にします。(ただしメモリは消費している)

文字通り、アプリの実行を中断するわけです。

ちなみにほとんどのアプリのデータはこのタイミングで保存されます。

↑ここ重要!

つまりほとんどのアプリのデータは①遷移が起こった時にストレージに保存されます。

しかし、アプリを切り替えてすぐには中断状態にはならず、アプリを切り替えて数秒後にアプリは中断状態となります。

なぜなら、ユーザーが間違えてアプリを切り替えてしまったとき、いちいち中断処理を繰り返していては十分なエクスペリエンスが得られないからです。

しばらくアプリをつかわないでおく

ではしばらくアプリをつかわないでおいてみましょう。

アプリがしばらく使われてなく、更にパソコンのメモリやCPUリソースなどの資源が少なくなってきた時、アプリは②遷移を使って終了状態へと遷移します

このタイミングはOSが自動で判断するのでパソコンのスペックやその時のリソースの使用状況によって異なります。

終了状態になったアプリは、アプリ一覧でサムネイルがスプラッシュスクリーンの画像になっています。

つまり上図の場合、カレンダーは中断状態でそれ以外は終了状態となります。

このとき初めて、アプリのメモリ使用量が0になります。

サインアウトやシャットダウンをする

ではユーザーがWindowsをサインアウトやシャットダウンしてみます。 すると実行状態のアプリは①→中断状態→②と遷移して、終了状態へと遷移します。

中断状態のアプリは②遷移を使って終了状態へと遷移します。

先ほど、「ほとんどのアプリのデータ保存は①遷移で中断状態になった時に保存される」と言いましたが、ユーザーがサインアウトやシャットダウンをしてアプリがすべて終了しようとしているとき、アプリは必ず中断状態を経由して終了状態へと移っているため、アプリ内のデータがストレージに保存されるのです。

アプリを終了する

ユーザーはアプリを終了することもできます。

操作としては、

  • アプリの上のエッジを画面一番下までドラッグする
  • マウスを使っている時に右上に出てくる✕ボタンを押す
  • 左に出てくるタスクリストを右クリックして閉じる
  • タスクバーに表示してるアプリを右クリックして閉じる

などの操作があります。

この場合、アプリは左からスワイプしてでてくるタスクリスト上では削除されますが、実際は①遷移を使って中断状態になります。

アプリを終了する動作なのだから、アプリは終了状態に遷移すると考えがちですが、実は中断状態になっています。

タスクリストから削除されるのでユーザーからは終了しているようにみえるのです。

中断されたアプリは、しばらくアプリをつかわなかったとき同様、システムがリソースが不足していると判断した時点で終了状態へと遷移します。

アプリを強制終了する

もしアプリの挙動がおかしくなったときや、どうしてもシステムの都合上アプリを強制終了したいばあいがあります。

その場合の操作は、

  • アプリの上のエッジを画面一番下までドラッグして、一番下まで来たらそのまま長押しし、アプリがスプラッシュスクリーンになるまで待つ
  • タスクマネージャーからタスクを終了する
  • Alt+F4を押す

などがあります。

先ほどから、「アプリは中断状態になってから終了状態になるからデータが保存される」としつこく言っていましたが、今回の強制終了はアプリは中断状態を経由しません

⑤遷移を使っていきなり実行状態から終了状態へと遷移します。

すると何がおきるかというと、アプリは①遷移で中断状態になったときにデータが保存されるのに、①遷移をつかわずに終了状態にいくので、データが保存される保証がないということです。

もちろん必ずしもすべてのアプリが①遷移時にデータが保存されてるとは限りませんが、ほとんどのアプリが設計原則に従っているならば①遷移時にデータが保存されます。

また、Windowsストアアプリを作るとわかるのですが、アプリが起動したときに「前回ユーザーがどのようにアプリを終了したか」を見ることができます。

つまり、前回ユーザーがアプリを強制終了したならば、アプリデータを復元しないという設計原則があるので、ほとんどのアプリはデータを復元してくれません。

つまりこのように同じ操作に見えて、Windowsストアアプリの終了と強制終了はこんなにも大きな差があるのです。

ホステッドビューアクティブ化

アプリを別のアプリから共有ターゲットなどで呼び出すことをホステッドビューアクティブ化と言います。

この場合はアプリは実行状態と終了状態の2つの状態をもち、中断状態にはなりません。

バックグラウンドで動くアプリ

Windowsストアアプリは数個だけですがアプリがフォアグラウンドになくても処理を実行できる仕組みがあり、ロック画面に表示するアプリとして設定から選択することができます。

こちらについても状態は実行状態と終了状態の2つだけです。

まとめ

Windowsストアアプリでプロセスモデルは単純化されましたが、終了のあたりがすこしやっかいで、同じ終了に関しても通常終了と強制終了はこんなにも違うんだということを紹介しました。

しかし大事なことは、「システムにとってはアプリは3つの状態をもつが、ユーザーにとってアプリは常に実行状態として見えている」ということです。

例えばアプリを切り替えてアプリが終了状態になって、メモリを専有できなくなったとしてもデータを中断前に保存して、再開時に適切に復元することによって、あたかも常にアプリが実行していたかのように見せかけることがWindowsストアアプリには可能です。*1

このようにタブレットデバイスなどのリソースが少ないシステムの上で、ユーザーに満足できるエクスペリエンスをだすことが可能になっている背景には、このようなWindowsストアアプリのライフサイクルが大きく影響しているというわけです。

*1:スプラッシュスクリーンは出ますが