性能優(yōu)化 也許，DOM 不是答案

有一個詞"手機網(wǎng)站"（mobile web），指供手機瀏覽的網(wǎng)站，但它是不存在的。

人們提到"移動互聯(lián)網(wǎng)"的時候，其實專指另外一樣?xùn)|西：手機App。

一、Web App vs. Native App

比起手機App，網(wǎng)站有一些明顯的優(yōu)點。

• 跨平臺：所有系統(tǒng)都能運行
• 免安裝：打開瀏覽器，就能使用
• 快速部署：升級只需在服務(wù)器更新代碼
• 超鏈接：可以與其他網(wǎng)站互連，可以被搜索引擎檢索

但是，現(xiàn)實是怎樣呢？

（1）體驗差。手機App的操作流暢性，遠超網(wǎng)站。

（2）業(yè)界不支持。所有公司的移動端開發(fā)重點，幾乎都是原生app。

（3）用戶不在乎。大多數(shù)用戶都選擇使用手機app，而不是網(wǎng)站。

如果將來有一天，Web app會成為主流，一定有一個前提，那就是它的性能可以趕上Native app。

二、為什么Web app有性能瓶頸？

Web app輸給Native app的地方，不是界面（UI），而是操作性能。主要是互動（interaction）和動畫（animation）這兩方面，會出現(xiàn)卡頓（jank），用戶會感覺到明顯的時滯，有時簡直慢得難以忍受。

Web app的性能瓶頸，主要有以下原因。

（1）Web基于DOM，而DOM很慢。瀏覽器打開網(wǎng)頁時，需要解析文檔，在內(nèi)存中生成DOM結(jié)構(gòu)，如果遇到復(fù)雜的文檔，這個過程是很慢的?？梢韵胂笠幌拢绻W(wǎng)頁上有上萬個、甚至幾十萬個形狀（不管是圖片或CSS），生成DOM需要多久？更不要提與其中某一個形狀互動了。

（2）DOM拖慢JavaScript。所有的DOM操作都是同步的，會堵塞瀏覽器。JavaScript操作DOM時，必須等前一個操作結(jié)束，才能執(zhí)行后一個操作。只要一個操作有卡頓，整個網(wǎng)頁就會短暫失去響應(yīng)。瀏覽器重繪網(wǎng)頁的頻率是60FPS（即16毫秒/幀），JavaScript做不到在16毫秒內(nèi)完成DOM操作，因此產(chǎn)生了跳幀。用戶體驗上的不流暢、不連貫就源于此。

（3）網(wǎng)頁是單線程的。現(xiàn)在的瀏覽器對于每個網(wǎng)頁，只用一個線程處理。所有工作都在這一個線程上完成，包括布局、渲染、JavaScript執(zhí)行、圖像解碼等等，怎么可能不慢？

（4）網(wǎng)頁沒有硬件加速。網(wǎng)頁都是由CPU處理的，沒用GPU進行圖形加速。

上面這些原因，對于PC還不至于造成嚴(yán)重的性能問題，但是手機的硬件資源相對有限，用戶互動又相對頻繁，結(jié)果跟Native app一比，就完全落在了下風(fēng)。

三、FlipBoard的解決方案

FlipBoard原本是一個手機App，最近開始部署Web版本，結(jié)果就遇到了上面的問題：Web版的體驗不佳。

上周，他們將解決方案公布在網(wǎng)站上，結(jié)果引起了業(yè)界轟動，因為這是一個史無前例的解決方案：

---- 他們沒有使用DOM，而是將整個網(wǎng)站用canvas輸出！

你可以用手機打開flipboard.com，體驗一下，看看跟Native app有沒有差別。如果你沒有帳號，可以直接打開這里或這里。

這個方案的出發(fā)點是這樣的：如果將網(wǎng)頁變成了一個個canvas，用戶就等于在跟圖片互動，這樣就繞開了DOM，降低了操作時滯。而且，canvas可以被硬件加速，這樣就提高了性能。具體的技術(shù)細節(jié)，可以參考原文。canvas的轉(zhuǎn)化基于React框架實現(xiàn)，F(xiàn)lipBoard 開發(fā)了一個專門的庫React-canvas，已經(jīng)開源。

這個方案引發(fā)了很多爭議（這里和這里），主要是canvas只是一個位圖，本身沒有語義，如果要在它上面實現(xiàn)UI，等于HTML語言已有的東西都要再發(fā)明一遍，比如如何實現(xiàn)超鏈接、如何實現(xiàn)CSS效果等等。一些最簡單的東西都變得很麻煩，因為canvas不是自適應(yīng)的（responsive），文字在哪里斷行，都要自己計算，而且用戶也無法選中文本。另外，怎么讓搜索引擎檢索網(wǎng)頁，解決起來也不是很容易。

但是不管怎樣，這是一個有意義的嘗試。

四、未來的路

James Long對FlipBoard的嘗試，寫了一篇評論《Radical Statements about the Mobile Web》。本文就受到了那篇文章的啟發(fā)。

在文中，James Long對未來的Web app提出了幾點預(yù)測，我認為很值得分享。

（1）多線程瀏覽器。每個網(wǎng)頁應(yīng)該由多個線程進行處理，主線程只負責(zé)布局和渲染，而且應(yīng)該在16毫秒內(nèi)完成，JavaScript由worker線程執(zhí)行，這樣就不會發(fā)生堵塞了。Mozilla正在開發(fā)的Servo就是這樣一個項目。

（2）DOM的異步操作。JavaScript對DOM的操作不再是同步的，而是觸發(fā)后，交給Event Loop機制進行監(jiān)聽。

（3）非DOM方案。瀏覽器不再將網(wǎng)頁處理成DOM結(jié)構(gòu)，而是變?yōu)槠渌Y(jié)構(gòu)。React的Virtual DOM方案就是這一類的嘗試，還有更激進的方案，比如用數(shù)據(jù)庫取代DOM。