網頁生命週期 API

瀏覽器支援

  • Chrome:68。
  • Edge:79。
  • Firefox:不支援。
  • Safari:不支援。

現今的瀏覽器在系統資源有限時,有時會將頁面停權或完全捨棄。日後,瀏覽器會主動執行這項作業,以便減少耗電量和記憶體用量。Page Lifecycle API 提供生命週期鉤子,讓網頁能夠安全地處理這些瀏覽器介入行為,而不影響使用者體驗。請查看這個 API,確認是否應在應用程式中實作這些功能。

背景

應用程式生命週期是新型作業系統管理資源的重要方式。在 Android、iOS 和近期的 Windows 版本中,作業系統可隨時啟動及停止應用程式。如此一來,這些平台就能在對使用者最有幫助的情況下簡化及重新分配資源。

在網頁上,一直沒有這種生命週期,應用程式可無限期保持運作。大量網頁執行時,記憶體、CPU、電池和網路等重要系統資源可能會超訂,導致使用者體驗不佳。

雖然網頁平台早已提供與生命週期狀態相關的事件,例如 loadunloadvisibilitychange,但這些事件只允許開發人員回應使用者啟動的生命週期狀態變更。為了讓網頁在低耗電裝置上運作無虞 (並在所有平台上更注重資源),瀏覽器需要能夠主動回收及重新分配系統資源。

事實上,目前的瀏覽器已針對背景分頁中的網頁採取積極措施來節省資源,許多瀏覽器 (尤其是 Chrome) 都希望能做得更多,以減少整體資源足跡。

問題是,開發人員無法為這類系統啟動的介入措施做好準備,甚至不知道這些措施正在執行。這表示瀏覽器必須採取保守做法,否則可能會導致網頁中斷。

Page Lifecycle API 會嘗試透過下列方式解決這個問題:

  • 在網路上引入並標準化生命週期狀態的概念。
  • 定義系統啟動的全新狀態,讓瀏覽器限制隱藏或閒置分頁可使用的資源。
  • 建立新的 API 和事件,讓網頁開發人員能夠回應這些系統啟動的狀態轉換。

這個解決方案可為網路開發人員提供可預測性,讓他們建構出可抵禦系統干預的應用程式,並讓瀏覽器更積極地最佳化系統資源,最終造福所有網路使用者。

本文的其餘部分將介紹新的頁面生命週期功能,並探索這些功能與所有現有網頁平台狀態和事件的關係。系統也會針對開發人員在各狀態下應 (或不應) 執行的工作類型,提供最佳做法和建議。

網頁生命週期狀態和事件總覽

所有網頁生命週期狀態都是獨立且互斥的,也就是說,網頁一次只能處於一種狀態。而且,大部分的網頁生命週期狀態變更通常可透過 DOM 事件觀察到 (如有例外狀況,請參閱各狀態的開發人員建議)。

如要說明網頁生命週期狀態,以及在這些狀態之間轉換的事件,最簡單的方法或許是使用圖表:

這份文件中所述狀態和事件流程的視覺化呈現。
Page Lifecycle API 狀態和事件流程。

下表詳細說明每個狀態。並列出可能發生在前後的狀態,以及開發人員可用來觀察變更的事件。

說明
進行中

如果頁面可見且已取得輸入焦點,則處於「active」狀態。

可能的先前狀態:
被動 (透過 focus 事件)
已凍結 (透過 resume 事件,然後透過 pageshow 事件)

可能的下一個狀態:
被動 (透過 blur 事件)

Passive

如果網頁可見且沒有輸入焦點,則處於passive 狀態。

可能之前的狀態:
有效 (透過 blur 事件)
隱藏 (透過 visibilitychange 事件)
凍結 (透過 resume 事件,然後 21) pageshow

可能的下一個狀態:
active (透過 focus 事件)
hidden (透過 visibilitychange 事件)

隱藏

如果網頁未顯示 (且未遭到凍結、捨棄或終止),則處於「隱藏」狀態。

可能的先前狀態:
passive (透過 visibilitychange 事件)
frozen (透過 resume 事件,然後透過 pageshow 事件)

可能的後續狀態:
被動 (透過 visibilitychange 事件)
凍結 (透過 freeze 事件)
捨棄 (未觸發任何事件)
已終止的事件 (未觸發任何事件)

凍結

在「已凍結」狀態下,瀏覽器會暫停執行頁面工作佇列中的任務,直到頁面解凍為止。這表示 JavaScript 計時器和擷取回呼等項目不會執行。已執行中的工作可以完成 (最重要的是 freeze 回呼),但可能會受到限制,無法執行某些作業,也無法執行多久。

瀏覽器會凍結網頁來保留 CPU/電池/數據用量,也會藉此加快 往返瀏覽速度,避免系統必須重新載入完整頁面。

可能的先前狀態:
隱藏 (透過 freeze 事件)

可能的下一個狀態:
active (透過 resume 事件,然後是 pageshow 事件)
passive (透過 resume 事件,然後是 pageshow 事件)
hidden (透過 resume 事件)
discarded (未觸發事件)

已終止

網頁開始卸載並從記憶體中清除後,頁面就會處於「已終止」狀態。在這個狀態下,系統無法啟動新任務,且如果進行中的任務執行時間過長,可能會遭到終止。

可能的先前狀態:
隱藏 (透過 pagehide 事件)

可能的後續狀態:
NONE

已捨棄

頁面為了節省資源,而在瀏覽器卸載時,會處於「捨棄」狀態。在這種狀態下,任何工作、事件回呼或 JavaScript 都無法執行,因為資源限制通常會導致棄用,而無法啟動新程序。

在「捨棄」狀態中,即使頁面不再顯示,使用者通常還是會看到分頁本身,包括分頁標題和網站小圖示。

可能的先前狀態:
隱藏 (未觸發任何事件)
凍結 (未觸發任何事件)

可能的下一個狀態:
NONE

活動

瀏覽器會調度許多事件,但只有其中的一小部分會表示網頁生命週期狀態可能發生變更。下表列出與生命週期相關的所有事件,並列出這些事件可能的轉換狀態。

名稱 詳細資料
focus

DOM 元素已收到焦點。

注意:focus 事件不一定會傳送狀態變更信號。只有在網頁先前未獲得輸入焦點時,才會發出狀態變更信號。

可能的先前狀態:
passive

目前可能的狀態:
有效

blur

DOM 元素已失去焦點。

注意:blur 事件不一定會傳送狀態變更信號。只有在頁面不再有輸入焦點 (也就是頁面並未將焦點從一個元素切換至另一個元素) 時,才會發出狀態變更信號。

可能的先前狀態:
active

可能的目前狀態:
passive

visibilitychange

文件的 visibilityState 值已變更。當使用者前往新分頁、切換分頁、關閉分頁、將瀏覽器最小化或關閉,或是切換行動作業系統上的應用程式時,可能就會發生這種情況。

可能的先前狀態:
passive
hidden

可能的目前狀態:
passive
hidden

freeze *

網頁剛才已凍結。系統不會啟動頁面工作佇列中的任何可凍結工作。

可能的先前狀態:
隱藏

可能的目前狀態:
frozen

resume *

瀏覽器已恢復「凍結」的頁面。

可能的先前狀態:
frozen

可能的目前狀態:
有效 (如果後面接著 pageshow 事件)
被動 (如果後面接著 pageshow 事件)
隱藏

pageshow

正在檢索工作階段記錄項目。

這可能是全新的網頁載入作業,也可能是從往返快取中擷取的網頁。如果網頁是從往返快取中擷取,事件的 persisted 屬性為 true,否則為 false

可能的先前狀態:
凍結 (resume 事件也會觸發)

可能的目前狀態:
active
passive
hidden

pagehide

系統正在掃遍工作階段記錄項目。

如果使用者前往其他網頁,且瀏覽器能夠將目前網頁加入前往/返回快取,以便日後重複使用,則事件的 persisted 屬性為 true。如果設為 true,表示頁面進入「凍結」狀態,否則就會進入「終止」狀態。

可能的先前狀態:
隱藏

可能的目前狀態:
凍結 (event.persisted 為 true, freeze 事件如下)
已結束 (event.persisted 為 false,然後顯示 unload 事件後)

beforeunload

視窗、文件及其資源即將卸載。 文件仍會顯示,且事件仍可在此時取消。

重要事項:beforeunload 事件應僅用於提醒使用者未儲存的變更。儲存變更後,系統就會移除事件。請勿在頁面中無條件加入這項屬性,因為這麼做可能會在某些情況下影響效能。詳情請參閱「舊版 API」一節。

可能的先前狀態:
已隱藏

可能的目前狀態:
已終止

unload

正在卸載頁面。

警告:我們不建議使用 unload 事件,因為這不僅不可靠,有時可能會導致效能降低。詳情請參閱舊版 API 一節

可能的先前狀態:
已隱藏

可能的目前狀態:
已終止

* 表示 Page Lifecycle API 定義的新事件

Chrome 68 新增功能

上一個圖表顯示兩種系統啟動的狀態,而非使用者啟動的狀態:凍結捨棄。如先前所述,目前的瀏覽器會不時凍結並捨棄隱藏的分頁 (視情況而定),但開發人員無法得知何時會發生這種情況。

在 Chrome 68 中,開發人員現在可以透過監聽 document 上的 freezeresume 事件,觀察隱藏分頁何時凍結和解凍。

document.addEventListener('freeze', (event) => {
  // The page is now frozen.
});

document.addEventListener('resume', (event) => {
  // The page has been unfrozen.
});

自 Chrome 68 起,document 物件現在會在 Chrome 電腦版中加入 wasDiscarded 屬性 (Android 支援功能正在這個問題中追蹤)。如要判斷網頁是否在隱藏分頁中遭到捨棄,您可以在網頁載入時檢查這個屬性的值 (請注意:必須重新載入遭到捨棄的網頁才能再次使用)。

if (document.wasDiscarded) {
  // Page was previously discarded by the browser while in a hidden tab.
}

如需 freezeresume 事件中的重要操作建議,以及如何處理及準備遭到捨棄的網頁,請參閱各個狀態的開發人員建議

接下來的幾個章節將概略說明這些新功能如何融入現有的網路平台狀態和事件。

如何在程式碼中觀察頁面生命週期狀態

在「active」、「passive」 和「hidden」 狀態下,您可以執行 JavaScript 程式碼,藉此透過現有的網路平台 API 判斷目前的網頁生命週期狀態。

const getState = () => {
  if (document.visibilityState === 'hidden') {
    return 'hidden';
  }
  if (document.hasFocus()) {
    return 'active';
  }
  return 'passive';
};

另一方面,當狀態變更時,您只能在各自的事件監聽器 (freezepagehide) 中偵測到凍結終止狀態。

如何觀察狀態變更

您可以利用先前定義的 getState() 函式,透過以下程式碼觀察所有頁面生命週期狀態變更。

// Stores the initial state using the `getState()` function (defined above).
let state = getState();

// Accepts a next state and, if there's been a state change, logs the
// change to the console. It also updates the `state` value defined above.
const logStateChange = (nextState) => {
  const prevState = state;
  if (nextState !== prevState) {
    console.log(`State change: ${prevState} >>> ${nextState}`);
    state = nextState;
  }
};

// Options used for all event listeners.
const opts = {capture: true};

// These lifecycle events can all use the same listener to observe state
// changes (they call the `getState()` function to determine the next state).
['pageshow', 'focus', 'blur', 'visibilitychange', 'resume'].forEach((type) => {
  window.addEventListener(type, () => logStateChange(getState()), opts);
});

// The next two listeners, on the other hand, can determine the next
// state from the event itself.
window.addEventListener('freeze', () => {
  // In the freeze event, the next state is always frozen.
  logStateChange('frozen');
}, opts);

window.addEventListener('pagehide', (event) => {
  // If the event's persisted property is `true` the page is about
  // to enter the back/forward cache, which is also in the frozen state.
  // If the event's persisted property is not `true` the page is
  // about to be unloaded.
  logStateChange(event.persisted ? 'frozen' : 'terminated');
}, opts);

這段程式碼會執行三項作業:

  • 使用 getState() 函式設定初始狀態。
  • 定義可接受下一個狀態的函式,並在狀態有變更時,將狀態變更記錄到控制台。
  • 為所有必要的生命週期事件新增擷取事件監聽器,這些事件監聽器會依序呼叫 logStateChange(),並傳遞下一個狀態。

關於這段程式碼,有一件值得注意的事是,所有事件監聽器都會新增至 window,且都會傳遞 {capture: true}。原因如下:

  • 並非所有網頁生命週期事件都具有相同的目標。pagehidepageshow 會在 window 上觸發;visibilitychangefreezeresume 會在 document 上觸發;focusblur 會在各自的 DOM 元素上觸發。
  • 這些事件大多不會冒泡,也就是說,您無法將非擷取事件事件監聽器新增至共同的祖系元素,並觀察所有事件。
  • 擷取階段會在目標或泡泡階段之前執行,因此在該階段新增事件監聽器,有助於確保事件監聽器在其他程式碼取消前執行。

各狀態的開發人員建議

開發人員必須瞭解頁面生命週期狀態,瞭解如何在程式碼中觀察這些狀態,因為您應 (或不應) 執行的工作類型,很大程度上取決於頁面處於何種狀態。

舉例來說,如果網頁處於隱藏狀態,向使用者顯示暫時性通知就沒有意義。儘管這個範例看起來很明顯,但還有其他不太明顯值得參考的建議。

開發人員建議
Active

active 狀態是使用者最關鍵的時間,也是網頁回應使用者輸入內容的關鍵時間。

任何可能會封鎖主執行緒的非 UI 工作,都應將優先順序降低為 閒置期間 卸載至網路工作站

Passive

在「passive」狀態下,使用者不會與網頁互動,但仍可查看網頁。這表示使用者介面更新和動畫仍應保持流暢,但更新發生的時機則不那麼重要。

網頁從「有效」變更為「被動」時,是保留未儲存應用程式狀態的好時機。

Hidden

當頁面從「無主動操作」變更為「隱藏」時,使用者可能會在重新載入前,不會再與該頁面互動。

轉換為「隱藏」通常也是開發人員可可靠觀察到的最後狀態變更 (在行動裝置上尤其如此,因為使用者可以關閉分頁或瀏覽器應用程式本身,且在這些情況下不會觸發 beforeunloadpagehideunload 事件)。

這表示您應該將「隱藏」狀態視為使用者工作階段的可能結尾。換句話說,保留所有未儲存的應用程式狀態,並傳送所有未傳送的分析資料。

您也應停止進行 UI 更新 (因為使用者不會看到這些更新),並停止任何使用者不希望在背景執行的工作。

Frozen

在「凍結」狀態下,工作佇列中的可凍結工作會在頁面解凍前暫停,但頁面可能永遠不會解凍 (例如頁面遭到捨棄)。

也就是說,當網頁從「隱藏」變更為「凍結」時,您必須停止任何計時器或卸除任何連線,否則如果凍結,可能會影響其他相同來源開啟的分頁,或影響瀏覽器是否能將網頁放入 往返快取

請特別注意以下事項:

您也應將任何動態檢視畫面狀態 (例如無限清單檢視畫面中的捲動位置) 儲存至 sessionStorage (或 透過 commit() 儲存至 IndexedDB),以便在網頁遭到捨棄並稍後重新載入時還原。

如果頁面從「凍結」變回「隱藏」,您可以重新開啟所有已關閉的連線,或重新啟動先前凍結頁面時停止的輪詢。

Terminated

網頁轉換為「已終止」狀態時,您通常不需要採取任何行動。

由於因使用者操作而卸載的頁面在進入「已終止」狀態前,一律會經過「隱藏」狀態,因此應在「隱藏」狀態下執行工作階段結束邏輯 (例如持續應用程式狀態,並向 Analytics 回報)。

此外 (如「隱藏」狀態的建議中所述),開發人員必須瞭解在許多情況下 (尤其是行動裝置) 無法確實偵測轉換至「終止」狀態,因此仰賴終止事件 (例如 beforeunloadpagehideunload) 的開發人員可能會遺失資料。

Discarded

開發人員無法在頁面遭到捨棄時觀察到「已捨棄」狀態。這是因為網頁通常會在資源受限的情況下遭到捨棄,在大多數情況下,如果只是為了讓指令碼回應捨棄事件而解凍網頁,是不可能的。

因此,您應準備好因應從「隱藏」變更為「凍結」時,可能會捨棄的情況,然後檢查 document.wasDiscarded,以便在網頁載入時回應捨棄網頁的還原作業。

再次提醒,由於生命週期事件的可靠性和順序並未在所有瀏覽器中一致實作,因此要遵循表格中的建議,最簡單的方法就是使用 PageLifecycle.js

應避免使用的舊版生命週期 API

請盡可能避免下列事件。

卸載事件

許多開發人員會將 unload 事件視為保證回呼,並將其用作工作階段結束信號,以便儲存狀態並傳送分析資料,但這麼做極不可靠,特別是在行動裝置上!在許多典型的卸載情況下,unload 事件不會觸發,包括在行動裝置上透過分頁切換器關閉分頁,或透過應用程式切換器關閉瀏覽器應用程式。

因此,建議您一律使用 visibilitychange 事件判斷工作階段結束的時間,並將隱藏狀態視為儲存應用程式和使用者資料的最後可靠時間

此外,只要有註冊的 unload 事件處理常式 (透過 onunloadaddEventListener()),就可能會導致瀏覽器無法將網頁放入往返快取,進而加快前後載入作業。

在所有新式瀏覽器中,建議您一律使用 pagehide 事件來偵測可能的網頁卸載 (又稱為 terminated 狀態),而非 unload 事件。如果您需要支援 Internet Explorer 10 以下版本,請偵測 pagehide 事件,並僅在瀏覽器不支援 pagehide 時使用 unload

const terminationEvent = 'onpagehide' in self ? 'pagehide' : 'unload';

window.addEventListener(terminationEvent, (event) => {
  // Note: if the browser is able to cache the page, `event.persisted`
  // is `true`, and the state is frozen rather than terminated.
});

beforeunload 事件

beforeunload 事件與 unload 事件的問題類似,因為在過去,beforeunload 事件的存在可能會導致頁面無法使用往返快取。新式瀏覽器則沒有這項限制。不過,為防萬一,部分瀏覽器在嘗試將網頁放入前進/後退快取時,不會觸發 beforeunload 事件,這表示該事件無法做為工作階段結束信號。此外,部分瀏覽器 (包括 Chrome) 需要先與網頁使用者互動,才能觸發 beforeunload 事件,進一步影響其可靠性。

beforeunloadunload 之間的一個差異是,beforeunload 有合法的用途。舉例來說,如果您想警告使用者,如果他們繼續卸載頁面,未儲存的變更會遺失,您可以這麼做。

由於 beforeunload 有使用基於正當理由,建議您「只」在使用者有未儲存的變更時新增 beforeunload 事件監聽器,並在儲存後立即移除。

換句話說,請勿這麼做 (因為會無條件新增 beforeunload 事件監聽器):

addEventListener('beforeunload', (event) => {
  // A function that returns `true` if the page has unsaved changes.
  if (pageHasUnsavedChanges()) {
    event.preventDefault();

    // Legacy support for older browsers.
    return (event.returnValue = true);
  }
});

請改用以下做法 (因為這只會在需要時新增 beforeunload 監聽器,並在不需要時移除):

const beforeUnloadListener = (event) => {
  event.preventDefault();
  
  // Legacy support for older browsers.
  return (event.returnValue = true);
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  removeEventListener('beforeunload', beforeUnloadListener);
});

常見問題

為何沒有「loading」狀態?

Page Lifecycle API 定義的狀態是彼此互斥的獨立狀態。由於頁面可在活動、被動或隱藏狀態下載入,且在載入完成前可變更狀態,甚至可終止,因此在這個架構中,單獨的載入狀態就沒有意義。

我的頁面在隱藏時會執行重要工作,如何避免系統將其凍結或捨棄?

有許多正當原因,說明網頁在隱藏狀態下執行時不應凍結。最明顯的例子是播放音樂的應用程式。

在某些情況下,Chrome 捨棄網頁的風險會增加,例如網頁含有未提交的使用者輸入內容表單,或是含有 beforeunload 處理常式,會在網頁卸載時發出警告。

目前,Chrome 在捨棄網頁時會採取保守做法,只有在確信不會影響使用者時才會捨棄網頁。例如,系統觀察到在隱藏狀態中執行下列任一操作的網頁不會遭到捨棄,除非有極大資源限制:

  • 播放音訊
  • 使用 WebRTC
  • 更新資料表標題或 favicon
  • 顯示快訊
  • 傳送推播通知

如要瞭解目前用於判斷分頁是否可安全凍結或捨棄的清單功能,請參閱 Chrome 中的凍結與捨棄的最佳化準則

什麼是往返快取?

往返快取是一種用語,用於描述某些瀏覽器實作的導覽最佳化,提升使用返回和下一頁按鈕的速度。

當使用者離開網頁時,這些瀏覽器會將該網頁的版本凍結,以便在使用者使用返回或前進按鈕時快速恢復。請注意,新增 unload 事件處理常式會導致這項最佳化無法執行

無論目的為何,此凍結功能的運作方式都與瀏覽器為了節省 CPU/電池電量而執行的凍結功能相同,因此被視為凍結生命週期狀態的一部分。

如果無法在凍結或已終止狀態下執行非同步 API,該如何將資料儲存到 IndexedDB?

在凍結和終止狀態中,頁面工作佇列中的可釋放工作會暫停,這表示無法可靠使用非同步和回呼式 API (例如 IndexedDB)。

日後,我們會IDBTransaction 物件中新增 commit() 方法,讓開發人員執行不需要回呼的純寫入交易。換句話說,如果開發人員只是將資料寫入 IndexedDB,而非執行包含讀取和寫入作業的複雜交易,commit() 方法就能在工作佇列暫停前完成 (假設 IndexedDB 資料庫已開啟)。

不過,如果程式碼需要在現階段運作,開發人員有兩種做法:

  • 使用工作階段儲存空間: 工作階段儲存空間會同步,且會在捨棄頁面時保留。
  • 透過 Service Worker 使用 IndexedDB:當頁面終止或捨棄後,Service Worker 就能將資料儲存在 IndexedDB 中。在 freezepagehide 事件監聽器中,您可以透過 postMessage() 將資料傳送至服務工作者,而服務工作者可以處理資料儲存作業。

在凍結和捨棄狀態下測試應用程式

如要測試應用程式在凍結和捨棄狀態下的行為,您可以前往 chrome://discards,實際凍結或捨棄任何已開啟的分頁。

Chrome 捨棄 UI
Chrome Discards UI

這可讓您確保網頁在棄用後重新載入時,正確處理 freezeresume 事件,以及 document.wasDiscarded 標記。

摘要

如果開發人員想要尊重使用者裝置的系統資源,在建構應用程式時應考量頁面生命週期狀態。網頁在使用者意料之外的情況下,不得消耗過多的系統資源

越多開發人員開始導入新的 Page Lifecycle API,瀏覽器就越安全凍結並捨棄未使用的網頁。這表示瀏覽器會耗用較少的記憶體、CPU、電池和網路資源,為使用者創造雙贏局面。