有一個(gè)詞"手機(jī)網(wǎng)站"（mobile web），指供手機(jī)瀏覽的網(wǎng)站，但它是不存在的。
人們提到"移動(dòng)互聯(lián)網(wǎng)"的時(shí)候，其實(shí)專(zhuān)指另外一樣?xùn)|西：手機(jī)App。
一、Web App vs. Native App
比起手機(jī)App，網(wǎng)站有一些明顯的優(yōu)點(diǎn)。
- 跨平臺(tái)：所有系統(tǒng)都能運(yùn)行
- 免安裝：打開(kāi)瀏覽器，就能使用
- 快速部署：升級(jí)只需在服務(wù)器更新代碼
- 超鏈接：可以與其他網(wǎng)站互連，可以被搜索引擎檢索
但是，現(xiàn)實(shí)是怎樣呢？
?。?）體驗(yàn)差。手機(jī)App的操作流暢性，遠(yuǎn)超網(wǎng)站。
?。?）業(yè)界不支持。所有公司的移動(dòng)端開(kāi)發(fā)重點(diǎn)，幾乎都是原生app。
?。?）用戶不在乎。大多數(shù)用戶都選擇使用手機(jī)app，而不是網(wǎng)站。
如果將來(lái)有一天，Web app會(huì)成為主流，一定有一個(gè)前提，那就是它的性能可以趕上Native app。
二、為什么Web app有性能瓶頸？
Web app輸給Native app的地方，不是界面（UI），而是操作性能。主要是互動(dòng)（interaction）和動(dòng)畫(huà)（animation）這兩方面，會(huì)出現(xiàn)卡頓（jank），用戶會(huì)感覺(jué)到明顯的時(shí)滯，有時(shí)簡(jiǎn)直慢得難以忍受。
Web app的性能瓶頸，主要有以下原因。
?。?）Web基于DOM，而DOM很慢。瀏覽器打開(kāi)網(wǎng)頁(yè)時(shí)，需要解析文檔，在內(nèi)存中生成DOM結(jié)構(gòu)，如果遇到復(fù)雜的文檔，這個(gè)過(guò)程是很慢的?？梢韵胂笠幌?，如果網(wǎng)頁(yè)上有上萬(wàn)個(gè)、甚至幾十萬(wàn)個(gè)形狀（不管是圖片或CSS），生成DOM需要多久？更不要提與其中某一個(gè)形狀互動(dòng)了。
?。?）DOM拖慢JavaScript。所有的DOM操作都是同步的，會(huì)堵塞瀏覽器。JavaScript操作DOM時(shí)，必須等前一個(gè)操作結(jié)束，才能執(zhí)行后一個(gè)操作。只要一個(gè)操作有卡頓，整個(gè)網(wǎng)頁(yè)就會(huì)短暫失去響應(yīng)。瀏覽器重繪網(wǎng)頁(yè)的頻率是60FPS（即16毫秒/幀），JavaScript做不到在16毫秒內(nèi)完成DOM操作，因此產(chǎn)生了跳幀。用戶體驗(yàn)上的不流暢、不連貫就源于此。
?。?）網(wǎng)頁(yè)是單線程的?，F(xiàn)在的瀏覽器對(duì)于每個(gè)網(wǎng)頁(yè)，只用一個(gè)線程處理。所有工作都在這一個(gè)線程上完成，包括布局、渲染、JavaScript執(zhí)行、圖像解碼等等，怎么可能不慢？
（4）網(wǎng)頁(yè)沒(méi)有硬件加速。網(wǎng)頁(yè)都是由CPU處理的，沒(méi)用GPU進(jìn)行圖形加速。
上面這些原因，對(duì)于PC還不至于造成嚴(yán)重的性能問(wèn)題，但是手機(jī)的硬件資源相對(duì)有限，用戶互動(dòng)又相對(duì)頻繁，結(jié)果跟Native app一比，就完全落在了下風(fēng)。
三、FlipBoard的解決方案
FlipBoard原本是一個(gè)手機(jī)App，最近開(kāi)始部署Web版本，結(jié)果就遇到了上面的問(wèn)題：Web版的體驗(yàn)不佳。
上周，他們將解決方案公布在網(wǎng)站上，結(jié)果引起了業(yè)界轟動(dòng)，因?yàn)檫@是一個(gè)史無(wú)前例的解決方案：
---- 他們沒(méi)有使用DOM，而是將整個(gè)網(wǎng)站用canvas輸出！
你可以用手機(jī)打開(kāi)flipboard.com，體驗(yàn)一下，看看跟Native app有沒(méi)有差別。如果你沒(méi)有帳號(hào)，可以直接打開(kāi)這里或這里。
這個(gè)方案的出發(fā)點(diǎn)是這樣的：如果將網(wǎng)頁(yè)變成了一個(gè)個(gè)canvas，用戶就等于在跟圖片互動(dòng)，這樣就繞開(kāi)了DOM，降低了操作時(shí)滯。而且，canvas可以被硬件加速，這樣就提高了性能。具體的技術(shù)細(xì)節(jié)，可以參考原文。canvas的轉(zhuǎn)化基于React框架實(shí)現(xiàn)，F(xiàn)lipBoard 開(kāi)發(fā)了一個(gè)專(zhuān)門(mén)的庫(kù)React-canvas，已經(jīng)開(kāi)源。
這個(gè)方案引發(fā)了很多爭(zhēng)議（這里和這里），主要是canvas只是一個(gè)位圖，本身沒(méi)有語(yǔ)義，如果要在它上面實(shí)現(xiàn)UI，等于HTML語(yǔ)言已有的東西都要再發(fā)明一遍，比如如何實(shí)現(xiàn)超鏈接、如何實(shí)現(xiàn)CSS效果等等。一些最簡(jiǎn)單的東西都變得很麻煩，因?yàn)閏anvas不是自適應(yīng)的（responsive），文字在哪里斷行，都要自己計(jì)算，而且用戶也無(wú)法選中文本。另外，怎么讓搜索引擎檢索網(wǎng)頁(yè)，解決起來(lái)也不是很容易。
但是不管怎樣，這是一個(gè)有意義的嘗試。
四、未來(lái)的路
James Long對(duì)FlipBoard的嘗試，寫(xiě)了一篇評(píng)論《Radical Statements about the Mobile Web》。本文就受到了那篇文章的啟發(fā)。
在文中，James Long對(duì)未來(lái)的Web app提出了幾點(diǎn)預(yù)測(cè)，我認(rèn)為很值得分享。
?。?）多線程瀏覽器。每個(gè)網(wǎng)頁(yè)應(yīng)該由多個(gè)線程進(jìn)行處理，主線程只負(fù)責(zé)布局和渲染，而且應(yīng)該在16毫秒內(nèi)完成，JavaScript由worker線程執(zhí)行，這樣就不會(huì)發(fā)生堵塞了。Mozilla正在開(kāi)發(fā)的Servo就是這樣一個(gè)項(xiàng)目。
?。?）DOM的異步操作。JavaScript對(duì)DOM的操作不再是同步的，而是觸發(fā)后，交給Event Loop機(jī)制進(jìn)行監(jiān)聽(tīng)。
?。?）非DOM方案。瀏覽器不再將網(wǎng)頁(yè)處理成DOM結(jié)構(gòu)，而是變?yōu)槠渌Y(jié)構(gòu)。React的Virtual DOM方案就是這一類(lèi)的嘗試，還有更激進(jìn)的方案，比如用數(shù)據(jù)庫(kù)取代DOM。
哈爾濱品用軟件有限公司致力于為哈爾濱的中小企業(yè)制作大氣、美觀的優(yōu)秀網(wǎng)站，并且能夠搭建符合百度排名規(guī)范的網(wǎng)站基底，使您的網(wǎng)站無(wú)需額外費(fèi)用，即可穩(wěn)步提升排名至首頁(yè)。歡迎體驗(yàn)最佳的哈爾濱網(wǎng)站建設(shè)。