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

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

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

一、Web App vs. Native App

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、FlipBoard的解決方案

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

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

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

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

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

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

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

四、未來的路

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

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

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

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

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