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

時間 2020-01-09

標籤技術翻譯 web 網頁內容如何影響電池使用壽命欄目 HTML 简体版

原文原文鏈接

本週再來翻譯一些技術文章，本次預計翻譯三篇文章以下：javascript

我翻譯的技術文章都放在一個github倉庫中，若是以爲有用請點擊star收藏。我爲何要建立這個git倉庫？目的是經過翻譯國外的web相關的技術文章來學習和跟進web發展的新思想和新技術。git倉庫地址：https://github.com/yzsunlei/javascript-article-translateweb

用戶將大部分的網絡在線時間花費在移動設備上，其他的大部分是使用不受限制的便攜式計算機。對於二者而言，電池壽命都是相當重要的。在這篇文章中，咱們將討論影響電池壽命的因素，以及你做爲一名Web開發人員如何使你的頁面更節能，以便用戶能夠花更多時間與你的內容互動。canvas

什麼消耗電量？

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

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 ，可是隻有在你能夠證實功耗成本合理的狀況下，才能夠這樣作。