W3CにおけるWeb Lifecycleの議論 (Page Lifecycle API)

20180523 追記

Page Lifecycle API等とも呼ばれているようです。
github.com

下記内容は古く一部ことなっています


W3CでWebPerf Web Performanceで、「Web Lifecycle」というトピックが議論に上っていた。(Agenda URL)

これは、iOSアプリやAndroidアプリのActivityのようなライフサイクルを、Webアプリケーションでも定義しようというものらしい。

まだ具体的な仕様は無いものの面白そうなので簡単に見てみる。ちょうざっくり

背景

  • 30%以上のユーザがタブを10以上開いており、現在表示しているタブのユーザ体験に影響を与えている
  • バックグラウンド(非表示のタブなど)の扱いについて明確なライフサイクルは存在しない(デスクトップとモバイルで扱いが異なる)
  • ライフサイクルやAPIがなく、アプリケーションが自身がどういう状態にあるか分からない(既にイベントはあるが一貫性がない)

提案

f:id:ASnoKaze:20170831231236p:plain
(スライドより)

  • LOADING: 読み込み状態
  • ACTIVE: 見えており、フォーカスがある状態
  • PASSIVE: 見えているがフォーカスはない状態 (例えばアプリケーションはゲームの停止などを行う)
  • BACKGROUNDED: 見えてない状態。例えばUI処理の停止される。
  • STOPPED: 見えてない状態。バックグラウンド実行の停止。
  • DISCARDED: メモリ再利用のためにバックグラウンドタブの廃棄。
  • TERMINATED: ユーザによってタブが閉じられた。

図の通り、BACKGROUNDEDやSTOPPEDからもタブが選択されれば再度、ACTIVEな状態に遷移する。

各状態遷移時にイベントが発火するためアプリケーション側は現在の状態を検知できるようになっている。

この状態遷移によって

  • 各状態のコールバックを用意し、アプリケーションがデータの保存やレポートを送れるようになる
  • アプリケーションはバックグラウンドで行いたい作業を宣言できる(Audio, Network Upload, Updating tab titleなど)
  • 適切なバッググラウンド処理が可能(ServiceWorkerの利用、必要なものにレンダラのリソース配分)
  • アプリケーションに依存するが、リソースの制限によってシステムによってアプリケーションを停止・終了できる

課題

まだまだ議論が始まったばかりだが、幾つかの課題が挙げられている

  • STOP遷移時のコールバック(onStop)の制限事項。ネットワーク利用の制限などどうするか
  • バックグラウンド実行時の処理・レンダリングをどうするか(WebUSB, Updating title and favicon, Notifications)
  • 同一ドメインで複数タブを開いた時に、タブを超えてデータが共有される。STOP時に壊れてしまう
  • ダイアログの表示を保存するか

ただしCurrent Workがあるようなので、Googleとしてはそういう動きがあるんだと思われる