关于前端:前端进阶Page-Lifecycle

Abstract

当深刻察看浏览器的体现时，咱们常常会遇到这样一些问题：

1. 当关上 / 切换一个 Tab 时，页面往往会有不同的体现：有时能够间接交互，有时须要从新加载页面后能力交互，有时页面间接卡死？
2. 当须要上报 web 利用的剖析数据时，不同的性能指标应该在什么机会进行捕捉和上报？
3. …

实际上，通过对浏览器页面生命周期状态管理机制的钻研，可能帮忙咱们更好的了解上述问题！

Background

系统管理的外围在于资源

利用生命周期治理是零碎用来治理资源的要害形式。在 Andriod, IOS, Windows 零碎内，能够随时开启 / 进行利用，通过重新分配资源，谋求极致的用户体验。

以前在浏览器端，web app 能够始终保留运行状态，直到占用资源超负荷时，被动地被抛弃或者暂停利用。同时，咱们也习惯针对用户引起的生命周期状态的扭转进行响应，比方当咱们关上 / 切换 / 敞开一个 web app 时，会去捕捉 onload, beforeUnload, unload 事件。然而，当初浏览器可能被动地解冻或者开释资源，从而升高资源的耗费（比方内存，CPU，电量），晋升用户体验。

那么问题来了 — 咱们如何觉察浏览器被动对资源执行的动作以及咱们如何捕捉由零碎引起的生命周期状态的扭转？

The answer is Page Lifecycle API — Page Lifecycle 通过提供一系列的生命周期钩子来帮忙咱们更加平安地染指浏览器的不同状态并执行相应的措施，它次要解决了三件事：

1. 引入标准化的页面生命周期状态和概念；
2. 定义新的、由零碎发动的变更状态，容许浏览器在 Tab 暗藏或者不沉闷时限度其占用的系统资源；
3. 创立新的 API 和 Event 来让开发者捕捉和响应由零碎引起的状态变动；

Page Lifecycle States

重要：页面生命周期所有状态都是离散和互相独立的，这意味着页面在某个时刻只能存在一种状态

上图涵盖了页面所有可能的状态及其触发事件，接下来会对其关键点进行剖析：

browser-initiated

两个由零碎引起的状态变动：FROZEN 和 DISCARDED

FROZEN

在解冻状态下，浏览器会进行执行事件队列内的可解冻工作（比方 JavaScript 内的定时器工作，申请工作等），直到页面冻结为止。曾经执行的工作能够继续执行，然而会限度其对资源的应用（作用范畴和执行工夫）。同时，浏览器会放弃肯定的页面 CPU/ 内存的资源应用，从而更快地响应浏览器后退 / 后退事件（Back-Froward Cache 机制），而不须要从新加载整个页面。

DISCARDED

当页面被浏览器齐全卸载时，页面处于废除状态，此状态下页面不会执行任何事件

仔细分析咱们能够看出，当页面从 HIDDEN 状态转变为 FROZEN 状态时，会优先开释 CPU 资源，再从 FROZEN 状态转变为 DISCARDED状态时，会开释内存资源。

DISCARDED vs TERMINATED

DISCARDED

• 当页面被浏览器齐全卸载时，页面将处于废除状态，由浏览器引起状态变动
• 通过 document.wasDiscarded 来判断以后 page 之前是否被抛弃
• 前一个状态是 FROZEN

TERMINATED

• 当页面被浏览器卸载并 将其从内存中进行清理 时，页面将处于终止状态
• 在该状态下，新的工作不会被执行，已执行的工作会被限度资源而强制终止
• 前一个状态是 HIDDEN

Hidden 状态扭转

HIDDEN -> FROZEN 存在两种路径

1. 由系统控制，零碎被动解冻页面来升高 CPU 耗费，通过监听 freeze 捕捉其状态变动
2. 由用户行为触发，用户在以后 tab 切换到其余页面（多页面利用）或者用户敞开以后 tab, window 或者 app。在这个过程中会经验 beforeunload, pagehide 事件，如果 pagehide 事件内的 event.persisted === true（即浏览器判断可能缓存页面资源），则进入解冻状态

HIDDEN -> TERMINATED

由用户行为触发，用户在以后 tab 切换到其余页面（多页面利用）或者用户敞开以后 tab, window 或者 app。在这个过程中会经验 beforeunload, pagehide 事件，如果 pagehide 事件内的 event.persisted === true（即浏览器判断可能缓存页面资源），则会经验 unload 事件，进入终止状态

如何观测 Page Lifecycle 状态变动？

Talk is cheap, show me the code!

// ACTIVE, PASSIVE, HIDDEN
const D = document
const W = window
function getStates() {if (D.visibilityState === 'hidden') return 'hidden'
  if (D.hasFocus()) return 'active'
  return 'passive'
}

// FROZEN 1
W.addEventListener('freeze', () => {console.log('Current State is frozen') }, {capture: true})

// FROZEN 2, TERMINATED
W.addEventListener('pagehide', (e) => {if(e.persisted) return 'frozen'
  return 'terminated'
}, {capture: true})

对于上述代码，咱们须要留神一件事件：所有的事件监听器都挂载到 window 对象，并且都须要设置 {capture: true}，为什么这么做呢？

• 并非所有的页面生命周期事件都具备雷同的指标。pagehide, pageshow 在 window 对象上触发；visibilitychange, freeze 以及 resume 在 document 对象上触发；focus, blur 在相应的 DOM 元素上触发
• 大部分页面生命周期事件都不会冒泡，因而不可能将非捕捉事件侦听器增加到公共先人元素并察看所有事件行为
• 捕捉阶段在指标阶段或者冒泡阶段之前执行，因而在该阶段增加监听器能够确保此时不会被其余代码勾销其执行

在不同的 Page Lifecycle 状态下执行正确的动作

上面整顿了一些针对外围状态和事件的开发倡议

Hidden

Hidden 通常是用户会话的完结状态

• 针对该状态的监听是可信赖的，因为在挪动利用上，用户间接敞开标签页或者浏览器自身，在这种状况下不会触发 beforeunload, pagehide 和 unload 事件
• 进行：1. UI 更新；2. 执行后台任务
• 倡议：1. 保留所有未保留的应用程序状态；2. 发送未发送的剖析数据；

Frozen

• 进行定时器工作
• 断开所有：1. IndexedDB 连贯；2. BroadcastChannel 连贯；3. WebRTC 连贯；4. 网络轮询和 Web Socket 连贯；

unload

许多材料都把 unload 事件作为页面会话完结的牢靠标记，通过其回调来保留状态和发送剖析数据。然而这种行为在手机端是极为不牢靠的，更好的形式是通过监听 visibilitychange 来进行。

即便是在浏览器端，也倡议通过监听 pagehide 事件来响应页面终止状态

beforeunload

当你心愿正告用户如果持续卸载页面，当前页面上未保留的改变将会隐没时，beforeunload 就派上用场了！

然而，beforeunload 和 unload 事件一样，会毁坏浏览器的 Back-Froward Cache 机制，因而倡议仅在提醒有未保留改变时增加 beforeunlaod 监听器，并且一旦用户执行保留操作后，立刻卸载该监听器！

const beforeUnloadListener = (event) => {event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// 当页面有未保留改变时
onPageHasUnsavedChanges(() => {addEventListener('beforeunload', beforeUnloadListener, {capture: true});
});

// 当页面执行完保留动作时
onAllChangesSaved(() => {removeEventListener('beforeunload', beforeUnloadListener, {capture: true});
});

看看浏览器的 Page Lifecycle States

通过 chrome://discards 能够查看以后浏览器内 Tab 的状态信息，话不多说，间接上图！

????Solo with code!????