網頁

2015年3月3日 星期二

[轉載] 也許,DOM 不是答案

除了轉載這篇文章外,我也說說我對於mobile開發的看法
我認為mobile開發最終還是會走向原生開發

即使HTML app開發的願景良好,還是會碰上許多的問題
首先是規格訂定,HTML的規格是業界的各家廠商間的角力後訂定的
從這裡就可以知道規格制定的速度是比不上由單一廠商(Google、Apple)推動的速度
就像以前的HTML沒有照相相關的API,現在的HTML缺少連結行動支付的API一樣

再者是相容性問題,HTML在XHTML的發展過程已經證明了完全的破壞式發展是行不通的
所以各種瀏覽器為了延續之前的特性,在相容性的實作上都有不少的問題

最後,HTML的執行速度更是一些複雜App的致命傷
如果有辦法解決上述問題,HTML的願景才有實現的可能


以下本篇內容
原文連結:http://www.ruanyifeng.com/blog/2015/02/future-of-dom.html

有一個詞"手機網站"(mobile web),指供手機瀏覽的網站,但它是不存在的。
人們提到"移動互聯網"的時候,其實專指另外一樣東西:手機App。

一、Web App vs. Native App

比起手機App,網站有一些明顯的優點。
跨平台:所有系統都能運行
免安裝:打開瀏覽器,就能使用
快速部署:升級只需在服務器更新程式碼
超鏈接:可以與其他網站互連,可以被搜索引擎檢索
但是,現實是怎樣呢?
(1)體驗差。手機App的操作流暢性,遠超網站
(2)業界不支持。所有公司的移動端開發重點,幾乎都是原生app
(3)用戶不在乎。大多數用戶都選擇使用手機app,而不是網站

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

二、為什麼Web app有性能瓶頸?

Web app輸給Native app的地方,不是界面(UI),而是操作性能
主要是互動(interaction)和動畫(animation)這兩方面,會出現卡頓(jank)
用戶會感覺到明顯的時滯,有時簡直慢得難以忍受
Web app的性能瓶頸,主要有以下原因
(1)Web基於DOM,而DOM很慢
     瀏覽器打開網頁時,需要解析文檔,在內存中生成DOM結構,如果遇到複雜的文檔,這個過程是很慢的
    可以想像一下,如果網頁上有上萬個、甚至幾十萬個形狀(不管是圖片或CSS)生成DOM需要多久?
    更不要提與其中某一個形狀互動了
(2)DOM拖慢JavaScript
     所有的DOM操作都是同步的,會堵塞瀏覽器
    JavaScript操作DOM時,必須等前一個操作結束,才能執行後一個操作
    只要一個操作有卡頓,整個網頁就會短暫失去響應
    瀏覽器重繪網頁的頻率是60FPS(即16毫秒/幀),JavaScript做不到在16毫秒內完成DOM操作
    用戶體驗上的不流暢、不連貫就源於此
(3)網頁是單線程的
     現在的瀏覽器對於每個網頁,只用一個線程處理
    所有工作都在這一個線程上完成,包括佈局、渲染、JavaScript執行、圖像解碼等等,怎麼可能不慢?
(4)網頁沒有硬件加速
     網頁都是由CPU處理的,沒用GPU進行圖形加速

上面這些原因,對於PC還不至於造成嚴重的性能問題
但是手機的硬件資源相對有限,用戶互動又相對頻繁,結果跟Native app一比,就完全落在了下風

三、FlipBoard的解決方案
FlipBoard原本是一個手機App,最近開始部署Web版本,結果就遇到了上面的問題:Web版的體驗不佳
上週,他們將解決方案公佈在網站上,結果引起了業界轟動,因為這是一個史無前例的解決方案:
---- 他們沒有使用DOM,而是將整個網站用canvas輸出!

你可以用手機打開flipboard.com,體驗一下,看看跟Native app有沒有差別
這個方案的出發點是這樣的:
如果將網頁變成了一個個canvas,用戶就等於在跟圖片互動,這樣就繞開了DOM,降低了操作時滯
而且,canvas可以被硬件加速,這樣就提高了性能
具體的技術細節,可以參考原文
canvas的轉化基於React框架實現,FlipBoard 開發了一個專門的庫React-canvas,已經開源
這個方案引發了很多爭議
主要是canvas只是一個位圖,本身沒有語義
如果要在它上面實現UI,等於HTML語言已有的東西都要再發明一遍
比如如何實現超鏈接、如何實現CSS效果等等,一些最簡單的東西都變得很麻煩
因為canvas不是自適應的(responsive),文字在哪裡斷行,都要自己計算
而且用戶也無法選中文本
另外,怎麼讓搜索引擎檢索網頁,解決起來也不是很容易
但是不管怎樣,這是一個有意義的嘗試

四、未來的路

James Long對FlipBoard的嘗試,寫了一篇評論《Radical Statements about the Mobile Web》
本文就受到了那篇文章的啟發
在文中,James Long對未來的Web app提出了幾點預測,我認為很值得分享
(1)多線程瀏覽器
     每個網頁應該由多個線程進行處理,主線程只負責佈局和渲染,而且應該在16毫秒內完成
    JavaScript由worker線程執行,這樣就不會發生堵塞了
Mozilla正在開發的Servo就是這樣一個項目
(2)DOM的異步操作
     JavaScript對DOM的操作不再是同步的,而是觸發後,交給Event Loop機制進行監聽
(3)非DOM方案
     瀏覽器不再將網頁處理成DOM結構,而是變為其他結構
React的Virtual DOM方案就是這一類的嘗試,還有更激進的方案,比如用數據庫取代DOM

沒有留言:

張貼留言