優雅适配低端移動裝置

本文中所指的低端移動裝置，特指記憶體不足1 GiB。(該數字為作者主觀判定)

理想狀态下，前端工程師都希望一套代碼走天下。可實際情況往往并非如此。

由于低端移動裝置的存在，一些複雜計算、互動，會在使用者那裡導緻卡頓、耗電大的問題。是以，各類 lite 版、極速版的應用（原生 + Web）曾出不窮。

以 Web 應用為例，多版本往往意味着，多套域名/URL，對産品的宣傳頗為不利（例如使用者對多版本的存在感到疑惑；對于同一産品，使用者往往隻會記住一個域名/URL）。

那麼，能否在送出請求後，服務端根據裝置資訊，自動傳回不同版本的頁面資源呢？

答案是：現在不能，未來或許可以。

2018-09-25，一個值得記住的日子。W3C Web Performance 工作小組公開了 Device Memory 工作草案，旨在解決自動适配低端移動裝置的問題。

Device Memory 本質就是将裝置的記憶體大小（RAM）通過請求頭部的方式，通知給服務端。

簡單而言，流程如下：

Server 通過 Accept-CH 表明支援 Device-Memory:

Client 發現 Server 支援後，請求資源時，自動帶上 Device-Memory 請求頭部：

Server 接受到請求後，可以根據 Device-Memory 的值，傳回不同的頁面資源。

該頭部由 Device-Memory + : + #memory-value（純數字，表示記憶體大小）組成。

其中 #memory-value 的預設機關為 GiB。

不足 1 GiB 時，會進行四舍五入。

需要提前設定好一個記憶體值的清單，并且明确記憶體下限和上線。草案推薦的下限、上限分别為：0.25 和 8 。之後真實使用的 #memory-value 隻能來自于清單。

請求頭部 + JS 互動隻适用于 https 環境。

截至到 2018-11-18 日，僅 Chrome 63+ 和 Opera50+ 支援了具體實作。

為了給低端移動裝置提供适合的使用者體驗，往往需要提供一個簡版的服務。對應的，或是産生新的域名，或是維護一個很大的 UA 資料庫，用于傳回對應内容。

随着各大浏覽器支援Device Memory，上面的方式将會終結。根據裝置的記憶體大小，傳回不同資源，一勞永逸。