[技術翻譯]Web網頁內容是如何影響電池使用壽命的？

本周再來翻譯一些技術文章，本次預計翻譯三篇文章如下： "04.[譯]使用Nuxt生成靜態網站" ( "Generate Static Websites with Nuxt" ) "05.[譯]Web網頁內容是如何影響電池功耗的" ( "How Web Content Can Affect Power ...

本周再來翻譯一些技術文章，本次預計翻譯三篇文章如下：

我翻譯的技術文章都放在一個github倉庫中，如果覺得有用請點擊star收藏。我為什麼要創建這個git倉庫？目的是通過翻譯國外的web相關的技術文章來學習和跟進web發展的新思想和新技術。git倉庫地址：https://github.com/yzsunlei/javascript-article-translate

用戶將大部分的網路線上時間花費在移動設備上，其餘的大部分是使用不受限制的攜帶型電腦。對於兩者而言，電池壽命都是至關重要的。在這篇文章中，我們將討論影響電池壽命的因素，以及你作為一名Web開發人員如何使你的頁面更節能，以便用戶可以花更多時間與你的內容互動。

什麼消耗電量？

移動設備上的大部分電量由這幾個主要組件消耗：

CPU（主處理器）
GPU（圖形處理）
聯網（Wi-Fi和蜂窩無線晶元）
屏幕

屏幕功耗相對恆定，並且大多在用戶的控制下（通過屏幕的開啟時間和亮度），但是其他組件（CPU，GPU和網路硬體）在功耗方面具有很高的動態範圍。

系統會根據當前正在處理的任務來調整CPU和GPU的性能，這些任務當然包括渲染用戶正在使用其Web瀏覽器和其他使用Web內容的應用程式與之交互的網頁。這可以通過打開或關閉某些組件並更改其時鐘頻率來完成。廣義上講，晶元要求的性能越高，其功率效率就越低。硬體可以非常快速地提升到高性能（但是要付出很高的功耗），然後可以迅速返回到更有效的低功耗狀態。

良好用電的一般原則

因此，為了最大程度地延長電池壽命，你需要減少在高功率狀態下花費的時間，並使硬體儘可能多地回到空閑狀態。

對於Web開發人員，需要考慮三種交互狀態：

用戶正在與內容進行交互時。
當頁面位於最前面，但未與之交互時。
頁面不是最前面的內容時。

高效的用戶互動

顯然，在用戶與頁面進行交互時消耗電量是很正常的。你希望頁面快速載入並快速響應觸摸交互。在許多情況下，減少首次渲染時間和與用戶互動的時間的相同優化也將減少功耗。但是，對於在初始頁面載入後繼續載入資源和運行腳本要謹慎。目標應該是儘快回到空閑狀態。通常，運行的JavaScript越少，頁面的效率就越高，因為腳本是在瀏覽器已經完成的佈局和繪製頁面的基礎上工作的。

頁面載入完成後，諸如滾動和點擊之類的用戶交互也將增加硬體功耗（主要是CPU和GPU），這再次有意義，但是請確保在用戶停止交互後立即回到空閑狀態。另外，請嘗試停留在瀏覽器的“快速路徑”上-例如，內置的頁面滾動將比JavaScript中實現的自定義滾動更加節能。

將閑置電源使用率降至零

當用戶不與頁面交互時，請嘗試使頁面使用儘可能少的電量。例如：

儘量減少使用計時器，以免喚醒CPU。嘗試將基於計時器的工作合併為幾個不經常使用的計時器。許多不協調的計時器會頻繁的觸發CPU喚醒，這比將工作收集成更少的塊要糟糕得多。

儘量減少動畫內容，例如動畫圖像和自動播放的視頻。特別要避免“載入”GIF或CSS動畫，這些GIF或CSS動畫會不斷觸發繪製，即使你看不到它們也是如此。IntersectionObserver用於僅可在可見時運行動畫。

儘可能使用聲明性動畫（CSS Animations和Transitions）。當動畫內容不可見時，瀏覽器可以優化這些內容，並且它們比腳本驅動的動畫更有效。

避免進行網路輪詢以從伺服器獲取定期更新。推薦使用具有持久連接的WebSockets或Fetch，而不是輪詢。

在應處於空閑狀態時正在工作的頁面也將對用戶交互的響應降低，因此將後臺活動最小化也可以提高響應速度和電池壽命。

後臺時CPU使用率為零

在多種情況下，頁面變為非活動狀態（不是用戶的焦點時），例如：

用戶切換到其他選項卡。
用戶切換到其他應用程式。
瀏覽器視窗最小化。
瀏覽器視窗是可見的，但不是焦點視窗。
瀏覽器視窗在另一個視窗後面。
視窗所在的空間不是當前空間。

當頁面變為非活動狀態時，WebKit會自動採取動作來節省電量：

requestAnimationFrame 已停止。
CSS和SVG動畫已暫停。
計時器受到限制。

另外，WebKit會利用操作系統提供的功能來最大化效率：

在iOS上，如果可能，選項卡將完全掛起。
在macOS上，標簽頁會進入App Nap，這意味著未進行視覺更新的標簽頁的Web進程的優先順序較低，並且計時器受到限制。

但是，頁面可以通過計時器（setTimeout和setInterval），消息，網路事件等觸發CPU喚醒。在後臺時，應儘可能避免這些事件。有兩個對此有用的API：

Page Visibility API提供了一種方法來響應頁面轉換為後臺還是前臺。這是避免在頁面處於後臺時更新UI的好方法，然後在頁面可見時使用visibilitychange事件來更新內容。
blur每當頁面不再處理焦點時，都會觸發事件。在這種情況下，頁面可能仍然可見，但不是當前聚焦的視窗。根據頁面的不同，停止動畫可能是一個好主意。

查找問題的最簡單方法是Web Inspector的時間軸。該記錄不應顯示頁面在後臺時發生的任何事件。

降低網頁耗電

既然我們知道了網頁耗電的主要原因，並給出了一些有關創建節能網頁的一般規則，那麼讓我們來談談如何識別和修複導致耗電量過多的問題。

腳本

如上所述，現代CPU可以將設備閑置時的耗電量從非常低的坡度提高到非常高的水平，以滿足用戶交互和其他任務的需求。因此，CPU成為電池壽命變化的主要原因。頁面載入期間的CPU使用率是瀏覽器引擎在載入，解析和渲染資源以及執行JavaScript時所做的工作的組合。在許多最新瀏覽器的網頁上，執行JavaScript所花費的時間遠遠超過了瀏覽器在其餘載入過程中所花費的時間，因此，最小化JavaScript執行時間將最大程度地降低功耗。

衡量CPU使用率的最佳方法是使用Web Inspector。如我們在上一篇文章中所示，時間軸可以顯示任何選定時間範圍內的CPU活動：

為了有效地使用CPU，WebKit在可能的情況下將工作分配到多個內核上（使用Workers的頁面也將能夠使用多個內核）。Web Inspector提供了與頁面主線程同時運行的線程的細分。例如，以下屏幕截圖顯示了滾動具有複雜渲染和視頻播放功能的頁面時的線程：

在尋找要優化的東西時，請專註於主線程，因為那是你的JavaScript運行的地方（除非你使用的是Workers），然後使用“JavaScript And Event”時間軸來瞭解觸發腳本的原因。也許你在響應用戶或滾動事件方面做了太多工作，或者觸發了requestAnimationFrame中隱藏元素的更新。瞭解頁面上使用的JavaScript庫和第三方腳本所完成的工作。要進行更深入的研究，可以使用Web Inspector的JavaScript探查器來查看在哪裡花費時間。

“WebKit線程”中的活動主要是由與JavaScript相關的工作觸發的：JIT編譯和垃圾回收，因此減少運行的腳本數量並減少JavaScript對象的創建和銷毀可以降低這種情況。

WebKit調用的其他各種系統框架都使用線程，因此“其他線程”包括那些線程完成的工作；繪畫是“其他線程”活動中使用最多的，接下來我們將討論繪畫。

繪畫

主線程CPU使用率也可以由大量佈局和繪畫觸發；這些通常是由腳本觸發，但比其他屬性的CSS動畫transform，opacity並且filter還可能導致他們觸發。查看“Layout and Rendering”時間軸將幫助你瞭解導致觸發活動的原因。

如果“Layout and Rendering”時間軸顯示繪畫，但你無法確定正在發生的變化，請啟用“Paint Flashing”：

這將使這些繪畫用紅色標記突出顯示。你可能需要滾動頁面才能看到它們。請註意，WebKit會保留一些“過度繪製(overdraw)”的圖塊，以實現平滑的滾動，因此在視口中不可見的繪製仍可以繼續工作，以使屏幕外的圖塊保持最新狀態。如果時間軸上顯示繪畫，則說明它在做實際的工作。

除了導致CPU耗電外，繪畫通常還會觸發GPU工作。macOS和iOS上的WebKit使用GPU進行繪畫，因此觸發繪畫可能會導致功耗顯著增加。額外的CPU使用率通常會顯示在CPU使用率時間軸的“其他線程”下。

GPU還用於

許多Mac筆記本電腦有兩個GPU，一個與CPU在同一個晶元上的“集成”GPU，功能不強但功耗更高，還有一個功能更強大但功耗更高的“獨立”GPU。WebKit預設情況下將使用集成GPU。你可以使用powerPreference上下文創建參數請求獨立GPU ，但是只有在你可以證明功耗成本合理的情況下，才可以這樣做。