ページライフサイクル

1. はじめに

多数のWebアプリ（およびタブ）が動作していると、メモリ・CPU・バッテリー・ネットワークなどの重要なリソースがすぐに使い過ぎとなり、ユーザー体験が悪化します。アプリケーションのライフサイクルは、現代のOSがリソースを管理する主要な手法です。

プラットフォームがアプリケーションライフサイクルをサポートするには、以下が必要です:

ライフサイクル状態間の遷移について、開発者へ通知（シグナル）を提供すること
アプリがバックグラウンドや停止状態でも主要機能が動作できる、ライフサイクル互換APIを提供すること

この提案は、Webページのライフサイクルが何かを定義し、Webアプリケーションがユーザーエージェントによってよく行われる2つの重要なライフサイクルイベントに応答できる拡張を追加することを目指しています:

タブの破棄（メモリ節約のため）
CPUの一時停止（バッテリー、データ、CPU節約のため）

2. ページライフサイクル状態

この仕様はWebページのライフサイクルが何かを定義し、Webアプリケーションがユーザーエージェントによってよく行われる2つの重要なライフサイクルイベントに応答できる拡張を追加します:

CPUの一時停止（バッテリー・データ・CPUの節約）
タブの破棄（メモリ節約のため）

この仕様では、上記をサポートするために2つの新しいライフサイクル状態を正式化します:

Frozen（凍結）: CPU一時停止のためのライフサイクル状態。これは、freeze steps アルゴリズムが Document の閲覧コンテキストに対して呼び出されたことを意味します。通常、HIDDENページはリソース節約のため凍結状態になります。
Discarded（破棄）: discard アルゴリズムが Document の閲覧コンテキストに対して呼び出されたことを意味します。通常、凍結されたフレームはリソース節約のため破棄状態へ移行します。

TODO(panicker): 図を挿入予定

3. API

ページライフサイクルには以下の追加が含まれます:

partial interface Document {
    attribute EventHandler onfreeze;
    attribute EventHandler onresume;
    readonly attribute boolean wasDiscarded;
};

onfreeze と onresume 属性は、それぞれ freeze および resume イベントのイベントハンドラーIDL属性です。

wasDiscarded 属性のgetterは、この Document の discarded ブール値を返します。

注: これらのAPIは Document に追加されています。 Window ではなく、 Page Visibility APIとの一貫性のためです。これらのAPIは既存APIと組み合わせて使われることを想定しています。[PAGE-VISIBILITY]

注: 加えて clientId および discardedClientId が Window に追加され、破棄後にページを再訪してリロードする際のビュー状態復元をサポートします。これらは本イベントに反応するコードで利用される見込みです。

3.1. 使用例

freezeとresumeのハンドリング例:

const prepareForFreeze = () => {
  // 開いているIndexedDB接続を閉じる。
  // Webロックを解放する。
  // タイマーやポーリングを停止する。
};

const reInitializeApp = () => {
  // IndexedDB接続を復元する。
  // 必要なWebロックを再取得する。
  // タイマーやポーリングを再開する。
};

document.addEventListener('freeze', prepareForFreeze);
document.addEventListener('resume', reInitializeApp);

破棄後にビュー状態を復元する例: ユーザーが同じアプリ・URLで複数タブを開いている場合、両方がバックグラウンドかつ破棄されたとき、アプリは2つのタブを区別して正しい状態を復元する必要があります。この目的でWindowのclientIdとlastClientIdが使えます。

// IndexedDBに状態を保存する際、self.clientIdの現在値をレコードにセットしておくことで
// getPersistedState()で後から取得可能（タブが破棄後リロードされた場合など）。
const persistState = async (state) => {
  const record = {...state, cliendId: self.clientId};

  // レコードをIndexedDBやSessionStorageに保存...
}

// 渡されたクライアントIDに基づき、IndexedDBから状態レコードを取得。
const getPersistedState = async (clientId) => {
  // IndexedDBでレコードを検索...
};

// タブが以前破棄されていれば、self.lastClientId経由でそのクライアントIDの状態を取得。
if (document.wasDiscarded) {
  getPersistedState(self.lastClientId);
}

4. 機能ポリシー

入れ子になった閲覧コンテキストの実行状態を閲覧コンテキストから制御することは、ユーザー体験を制御するために望ましい。アプリケーションは、文書がレンダリングされている状態ではない場合、またはビューポートと交差しない場合に、すべての実行が入れ子になった閲覧コンテキスト内で停止すること（現在再生中の動画、音声を含む）を望む場合がある。すべての実行を停止すると、 CPU 使用率が改善される可能性がある。これらのニーズを満たすため、2 つの機能ポリシーを定義する:

"execution-while-not-rendered"の既定の許可リストは*である
"execution-while-out-of-viewport"の既定の許可リストは*である

"execution-while-not-rendered"ポリシーは、タスクの実行に関して、入れ子になった閲覧コンテキストの閲覧コンテキストコンテナーがレンダリングされている状態ではない場合に、実行すべきかどうかを制御する。

"execution-while-out-of-viewport"ポリシーは、タスクの実行に関して、入れ子になった閲覧コンテキストの閲覧コンテキストコンテナーがビューポートと交差するかどうかを、対象要素とルートの交差を計算するに従って判定した結果、交差しない場合に、実行すべきかどうかを制御する。

§ 5.2 HTML 標準に対する変更は、文書（およびその子孫）を凍結状態に置くことによって、これを実現する。これは次の条件が満たされた場合に行われる:

iframe の読み込みイベント手順が実行済みであること;
文書に対してポリシーが無効であること; および
関連するポリシー条件が適用されること（レンダリングされていない、またはスクロールによって表示領域外にある）。

これらの条件が満たされていない場合、文書は非凍結状態になる。

<!-- iframe は読み込まれた直後に凍結される。 -->

<iframe allow="execution-while-not-rendered 'none'"
  src="subframe.html" style="display:none"></iframe>

文書の凍結状態を更新する手順を、Document document に対して実行するには、次を行う:

document の閲覧コンテキストが入れ子になった閲覧コンテキストでない場合は、返る。
document の準備状態が「complete」でない場合は、返る。
elementを、document の閲覧コンテキストの閲覧コンテキストコンテナーとする。
frozennessを false とする。
auto resume mediaを false とする。
documentが「使用を許可されている」execution-while-not-rendered 機能の使用を許可されていない場合は、次を行う:
1. elementがレンダリングされていない場合は、frozennessを true に設定する。
そうでなく、documentが「使用を許可されている」execution-while-out-of-viewport 機能の使用を許可されていない場合は、次を行う:
1. elementがビューポートと交差するかどうかを、対象要素とルートの交差を計算するに従って判定した結果、交差しない場合は、frozennessを true に設定し、auto resume mediaを true に設定する。
frozennessがdocumentの凍結状態と等しくない場合は、文書の凍結状態を変更するを、document、frozenness、およびauto resume mediaを指定して実行する。

5. 処理モデル

5.1. ワークレット・ワーカーの挙動変更

単一のワークレットエージェントの realm のグローバルオブジェクトの所有ドキュメントが凍結状態の場合、進行停止となる必要があります。単一の専用ワーカーエージェントの realm のグローバルオブジェクトの所有ドキュメントが非nullかつ凍結状態の場合も進行停止となる必要があります。

DedicatedWorkerGlobalScope workerGlobalScope の所有ドキュメント判定手順:

workerGlobalScope の所有セットが1つの Document document なら、document を返す。
workerGlobalScope の所有セットが1つの DedicatedWorkerGlobalScope parentWorkerGlobalScope なら、parentWorkerGlobalScope の所有ドキュメントを返す。
nullを返す。

注: DedicatedWorkerGlobalScope の所有セットは常に1つだけ要素を持ちます。

5.2. HTML標準の修正

5.2.1. ドキュメントのアンロードと履歴トラバーサル

ドキュメントが bfcache（back forward cache）へ出入りする際、凍結状態がtrue/falseに遷移します。

ドキュメントアンロードアルゴリズムで、Step #5後に persisted 属性がtrue（bfcacheへ移動時）、ドキュメントの凍結状態変更をdocument・trueで実行。
履歴トラバーサルアルゴリズムで、Step #4.6.4前に persisted 属性がtrue（bfcacheから出る時）、ドキュメントの凍結状態変更をdocument・falseで実行。

5.2.2. イベントループ: 定義

置き換え: タスクは、その document がnullまたは完全にアクティブな場合、実行可能。

修正後: タスクは、その document がnullまたは完全にアクティブかつ未凍結の場合、実行可能。

5.2.3. イベントループ: 処理モデル

レンダリングの更新中、Step #11後に以下のステップを追加:

完全にアクティブな Document doc それぞれについて、ドキュメント凍結状態更新手順をdocで実行。

5.2.4. 閲覧コンテキストの破棄

閲覧コンテキストやドキュメントの「discard」概念を「destroy」にリネームします。これにより、ユーザー向け属性 wasDiscarded に「discarded」という用語を使えます。

5.2.5. ドキュメントの初期化

Step #3の前に以下を追加:

閲覧コンテキストが以前破棄状態だった場合、Documentの discardedブール値をtrueにセット。

5.2.6. iframe loadイベントの手順

Step #5後に以下を追加:

child document でドキュメント凍結状態更新手順を実行。

5.2.7. `HTMLMediaElement`

各 HTMLMediaElement は resume frozen flag（初期値false）を持ちます。

5.2.8. メッセージの送信

注記追加:

注記: Windowが凍結されているときにメッセージを投稿した場合、投稿メッセージタスクソースにキューされたイベントは、Windowが非凍結になるまで実行されない。あまりに多くのイベントがキューされた場合、ユーザーエージェントが破棄する可能性があるのは、Windowの閲覧コンテキストである（リソースが逼迫した状況で破棄を認める一般規定の一環として）。

5.3. Service Worker標準への修正

5.3.1. `Client`

partial interface Client {
    readonly attribute ClientLifecycleState lifecycleState;
};

enum ClientLifecycleState {
    "active",
    "frozen"
};

Client オブジェクトはライフサイクル状態を持ち、これは ClientLifecycleState 列挙値のいずれかです。

5.3.1.1. `lifecycleState`

lifecycleState のgetter手順は、this のライフサイクル状態を返します。

5.3.1.2. `matchAll(options)`

Step #4 の変数名を変更します。

matchedClientData を新しいリストとする。

Step #2.5.1 の前に挿入

lifecycleState を Get Client Lifecycle State に client を渡して実行した結果とする。

Step #5.3.1 でリストに lifecycleState を追加

windowData を «[ "client" → client, "ancestorOriginsList" → 新しいリスト, "lifecycleState" → lifecycleState ]»とする。

Step #5.4 で matchedClientData に lifecycleState を追加

«[ "client" → client, "lifecycleState" → lifecycleState ]» を matchedClientData に追加する。

Step #6.2 で windowData の lifecycleState を Create Window Clientアルゴリズムに渡す

windowClient を Create Window Clientアルゴリズムに windowData["client"], windowData["frameType"], windowData["visibilityState"], windowData["focusState"], windowData["ancestorOriginsList"], windowData["lifecycleState"] を引数として渡して実行した結果とする。

Step #6.3 の調整

各 clientData を matchedClientData で反復:
1. clientObject を Create Clientアルゴリズムに clientData["client"], clientData["lifecycleState"] を引数として渡して実行した結果とする。
2. clientObject を clientObjects に追加する。

5.3.1.3. `openWindow(url)`

Step #7.5 の前に挿入

lifecycleState を Get Client Lifecycle State に this の関連 service worker client を渡して実行した結果とする。

Step #7.8.2 の調整（lifecycleState を渡す）

client を Create Window Clientに newContext の Window オブジェクトの environment settings object, frameType, visibilityState, focusState, ancestorOriginsList, lifecycleState を引数として実行した結果とする。

5.3.2. アルゴリズム

5.3.2.1. クライアントのライフサイクル状態取得

次のアルゴリズムを追加:

入力: client : service worker client
出力: state : 文字列

state を "active" にする。
もし client の global object の所有ドキュメントが凍結状態なら state を "frozen" にする。
state を返す。

5.3.2.2. Create Client

入力に lifecycleState（文字列）を追加

出力の Step #2 の後に次を追加

clientObject のライフサイクル状態を lifecycleState にセットする。

5.3.2.3. Create Window Client

入力に lifecycleState（文字列）を追加

出力の Step #5 の後に次を追加

windowClient のライフサイクル状態を lifecycleState にセットする。

5.4. ページライフサイクル処理モデル

5.4.1. 凍結状態（FROZENNESS state）

ドキュメントは以下の凍結状態（FROZENNESS）のいずれかになります:

true: 文書は凍結されており、その文書に関連付けられたタスクは一切実行されない
false: 文書は非凍結であり、その文書に関連付けられたタスクは通常どおり実行される

注記: トップレベル文書の凍結状態を変更するアルゴリズムに従い、トップレベル閲覧コンテキストの Document が自身の凍結状態を変更すると、子孫閲覧コンテキストのすべての文書も凍結状態を同じ値に変更する（そして、トップレベル閲覧コンテキストの Document と一致する）。

UA は、特定の状況でトップレベル文書の凍結状態を変更するアルゴリズムに true を指定して実行することを選択してもよい。たとえば、トップレベル閲覧コンテキストがバックグラウンドにあるか非表示であり、猶予期間が経過した場合、 UA はトップレベル文書の凍結状態を変更するアルゴリズムに true を指定して実行することで、リソースを節約し、（フォアグラウンドの）ユーザー体験の品質を維持できる。具体例:

モバイル版 Chrome では、（少なくとも）5 分間バックグラウンドにあったタブは、凍結される場合があり、これはバッテリーとデータ通信量を節約するためである。
デスクトップ版 Chrome では、ユーザーにとって重要でない（しばらく使用されていない）バックグラウンドタブは、破棄される場合があり、これはメモリを節約するためである

注記: ユーザーに代わって能動的に処理を行っているバックグラウンドタブ（たとえば、音声を再生しているもの）は、通常、凍結も破棄もされない。

注記: Chrome で使用されるヒューリスティックおよび除外条件の詳細な一覧については、この文書を参照。

UA は通常、ユーザーがその閲覧コンテキストを再訪したときに、トップレベル文書の凍結状態を変更するアルゴリズムに false を指定して実行する。さらに、UA は、十分なリソースが利用可能な場合、バックグラウンドで定期的にトップレベル文書の凍結状態を変更するアルゴリズムに false を指定して実行することを選択してもよい。

5.4.2. ドキュメントの凍結状態変更

トップレベルドキュメントの凍結状態変更（Document topLevelDoc、boolean frozenness状態frozenness）の手順:

Assert: doc の閲覧コンテキストがトップレベル閲覧コンテキストである。
ドキュメントの凍結状態変更を topLevelDoc, frozenness, false で実行。
descendants を子孫閲覧コンテキストのリスト（doc）とする。
各閲覧コンテキスト b を descendants で反復:
1. descendantDocument をアクティブドキュメント（b）とする。
2. ドキュメントの凍結状態変更を descendantDocument, frozenness, false で実行。

ドキュメントの凍結状態変更（Document doc, boolean frozenness状態frozenness, boolean auto resume frozen media）の手順:

もし frozenness が true なら freeze steps を doc・auto resume frozen media で実行。
そうでなければ resume steps を doc で実行。

freeze steps （Document doc, boolean auto resume frozen media）の手順:

doc の凍結状態を true にセットする。
freezeイベントを doc で発火する。
elements をメディア要素のうち shadow-including descendants で doc をルートとし、shadow-including tree orderで並べたものとする。
各 element を elements で反復:
1. もし element の paused が false なら:
  1. element の resume frozen flag を auto resume frozen media にセットする。
  2. media pause を element に実行。
注: frozenness 状態の代入がイベント発火より先になる順序は意図的です。

resume steps （Document doc）の手順:

elements をメディア要素のうち shadow-including descendants で doc をルートとし、shadow-including tree orderで並べたものとする。
1. 各 element を elements で反復:
  1. もし elements の resume frozen flag が true なら:
    1. elements の resume frozen flag を false にセット。
    2. media play を element に実行。
resumeイベントを doc で発火する。
doc の凍結状態を false にセットする。

注: frozenness 状態の代入がイベント発火の後になる順序は意図的です。

5.4.3. 破棄（Discarding）

各Documentは discarded ブール値（初期値false）を持つ。

discard で閲覧コンテキストを破棄するには、閲覧コンテキストをdestroyし、その理由がdiscardingによるものであることを記録する（子孫も同様）。

注: discardは通常、システムメモリ等のリソース不足時に解放目的で行う。一方destroyはユーザーがページ離脱等で通常の後処理として行う。

閲覧コンテキスト ― バックグラウンドかつ、そのドキュメントが VisibilityState hidden の場合、リソース圧迫時（例：メモリ不足）には discarded され得る。具体例:

デスクトップChromeでは、ユーザーに重要でない（しばらく利用されていない）バックグラウンドタブは破棄され、メモリを節約します。

注: ユーザーのために積極的に動作している（例：音声再生中）バックグラウンドタブは通常破棄されません。

注: Chromeが用いる詳しいヒューリスティック・除外条件はこちらの文書を参照してください。

トップレベル閲覧コンテキスト（ブラウザのタブ）がリソース圧迫や予期せぬ事象（プロセスクラッシュ等）で破棄された後、ユーザーが再度タブを訪れた場合、Document の discarded ブール値が § 5.2.5 ドキュメントの初期化により true となります。

6. 謝辞

この仕様の改善につながる技術的な助言と提案をいただいた Dave Tapuska、 Fadi Meawad、 Ojan Vafai、 Olli Pettay、 Philip Walton、そして Todd Reifsteck に特別な感謝を捧げます。