HTML5的明天, 局部有小雨

HTML5的明天,
局部有小雨

Posted by 王淮Harry

HTML5是什麼? 為什麼很多人如此關注它並押上公司的未來? 但為什麼Facebook棄HTML5轉Objective C. HTML的明天, 是晴還是雨, 你該不該給它投懷送抱, 該如何去判斷?

我最近對HTML5產生興趣, 就做了一些粗淺的研究, 並和矽谷的兩位玩弄HTML5多年的大佬<1>電話交流, 總結於此篇文章. 這篇文章不是HTML5的啟蒙貼, 是對其在業界發展的一個觀察和思考吧.

什麼是HTML5?

HTML5, 就像其名字所表示的, 它是HTML的第五個版本. 它將現在大家在各種瀏覽器之中所做的很多很炫的外掛程式或者特殊調準都做到了標準之中. 這樣的好處在於, 大家不需要對於特殊的瀏覽器做特殊的最佳化, 也可以避免了很多由於外掛程式標準不統一帶來的困擾.

比如, 我很驚訝的瞭解到, Adobe的Flash+PDF外掛程式導致的瀏覽器崩潰, 佔到所有瀏覽器崩潰次數的一半以上.

HTML5的出現和推廣, 將通過統一的標準大大改觀這種混亂的局面. 最最主要的原生支援(native support), 是這幾種:

• draw on the fly (隨意拖動組件)
• native video support (原聲的視頻支援 – bye, flash)
• geolocation (地址資訊的擷取)
• offline access support (不線上的支援, 支援local storage)
• semantics with tags that makes SEO friendly (flash content is not indexable – SEO能理解的tags來協助搜尋引擎的加索引)

但對於HTML5標準實現的程度和節奏完全取決於不同瀏覽器的自主選擇, 它想咋的就咋地. html5readiness.com上的這張圖很清楚的總結了不同瀏覽器對於不同功能的實現程度.

                        

你該不該給HTML5投懷送抱?

回答這個問題, 要分成兩步.

• 你在WEB端還是移動端?

  “如果是Web端, 100%保證晴天; 如果是移動端, 看下一條”

  對於Web端而言, HTML5將是一個完整的作業系統. 它在不同的底層系統之上, 藉助於瀏覽器的實現, 封裝了統一標準的API允許開發的程式跨裝置(PC or Mac or Smart Phone), 跨平台 (Windows, MacOS, iOS, Android, whatsoever)的運行.

  最大的好處, 就是一處開發, 多處使用. 審核新版本的發布也不用看蘋果爺爺的臉色.
  直接在伺服器端推送新代碼就好了. 對於開發人員而言, 這對效率的提高, 有著致命的誘惑. 像”你們是先開發Web, 還是移動”之類的問題, 將愉快的失去意義.

  對於Web端的開發而言, 你可以盡情的享受HTML5這種統一封裝帶來的好處, 唯一要等待的就是瀏覽器對其支援的完善. 但這種完善的到來, 無疑是確定的.

  而正是這種好處, 讓很多創業者如此關注它並押上公司的未來.

  但對於移動端而言, 卻沒有那麼簡單純粹.

• 如果是移動端, 取決於你的產品形態.
  因為你的產品需要的功能可能永遠也無法在移動端的瀏覽器的HTML5實現中被很好的實現.

  ”App Store上超過50%的應用已經是用HTML5來開發, 將來可能90%的應用會是HTML5,
  而那10%, 可能永遠也不適合HTML5”.

  HTML5的天氣預報中, 是局部有小雨.

苦逼的開發人員們, 你站的地是晴天還是下雨, 該如何判斷呢?

先介紹一個工具, 動態檢測瀏覽器對HTML支援程度的ringmark.io<2>. , 它將測試你當前的瀏覽器, 將HTML5的規格(spec)當中描述的功能的實現程度會一一測試出來.
不同的ring(環)代表了不同的功能等級. 已經實現的為綠色, 沒實現的是灰色. 發現灰色很多的朋友, 要換瀏覽器囉.

                         

回到剛開始的那個問題, Facebook為什麼在iOS App的實現上棄HTML5選Object C, 就在於Facebook App重度依賴照片, 而照片分享, 瀏覽相關的功能極度依賴CSS Overflow Scrolling, 這一點, iOS上的瀏覽器支援極度不給力. 而換成Object C的Native Implementation之後, 速度快上了2倍之多.

好, 有朋友可能會問, 可能在將來瀏覽器對這些功能的支援會得到改善呢? 那時候不就可以了.

事實是, 那一天可能永遠也不會到來.

因為瀏覽器的編程模型還是90年代流行的單進程單線程 (single process single thread), 但原生實現(比如用Object C)的APP可以用多線程. 這一點帶來的作用是致命的.

移動端編寫APP, 可以使用多個線程, 第一個線程, 被稱作主線程(main thread), 編程的第一原則是don’t do heavy work on main thread. 通常只讓它處理UI事件等, 其他重度的工作讓其他背景線程來做.

但瀏覽器只有一個線程, 所有的事情都是它幹. 瀏覽器編程一上來就破了第一原則.

在台式機上, 瀏覽器編程還沒有太多問題, 因為夠快; 但在移動端, 這個弊端很明顯.

我來舉個例子, 比如你在用瀏覽器看朋友的照片, 你發的評論被發到伺服器端, 此時你接著用手指往下拉屏; 此時, 伺服器端返回資訊, 評論發布成功, 瀏覽器中唯一的線程可能停止處理螢幕滾動(scrolling)而來處理伺服器的返回資訊, 由於行動裝置的處理器(尤其單進程瀏覽器只能用上單核, 即使是多核手機!)和記憶體(處於省電原因使用低耗電的DDR1, 這一點和現在PC使用的DDR3相差甚遠)的不給力, 完全可能造成滾動處理的不連續. 通常手機的重新整理率是60MHZ, 即每一幀不超過15ms; 如果處理的延時大大超過15ms,
那麼就會出現跳幀, 肉眼就能看出來.

這是互動操作(比如拉動, 滾動等)很多的APP, 如果是由HTML5實現, 出現拉動的時候停在那裡一個很重要的原因.

所以, 如果你的APP是相對靜態, 不需要很多對於照片, 多點觸摸, 多向拉動的處理, 那完全可以用HTML5來實現; 如果不是, 比如資訊流的展示, 遊戲等等, 還是乖乖的用原生的去實現.

具體的查看哪種類型的App需要哪些功能, 可以參考<3>.

HTML5究竟在等什麼?

HTML5實現已經是50%以上的iOS APP的選擇. 我相信處理能力的提升, 將讓行動裝置的處理不給力帶來的體驗底下得到改善. 而這種處理能力的提高, 很大程度上將取決於低耗電高效能CPU/記憶體的出現, 或者電池技術的極大改善.

在這一天到來之前, 有可能10%的APP無法應用HTML5來實現.

<1>
* Luke
Shepard, 原Facebook移動平台研發經理
* Feng Qian, Facebook進階工程師, 原Google Chrome的創始團隊成員
<2>
ringmark.io不僅可以測試你當前的瀏覽器, 你也可以在右下角的”Choose a different device”當中選擇不同的移動端的作業系統版本來看看它們對於HTML5的支援程度.
<3>
進入ringmark.io, 點開ring1, 點擊“See how features apply to each type of
app.” 可以看到這個工具對於不同的App的類型做出的總結. 比如, 對於照片功能比較重的App(Camera App), 你會發現他們需要什麼樣的功能, 如果灰色(代表當前瀏覽器沒實現)太多的話, 你的App將不適合在這種瀏覽器中運行.
<4>
參考Facebook
Blog
<5>
一些用HTML5編寫的好玩的網站
* http://mrdoob.com/projects/harmony/#circles
* http://html5demos.com/canvas-grad
* http://hakim.se/experiments/html5/wave/03/
* http://andrew-hoyer.com/andrewhoyer/experiments/cloth/

轉載地址：http://www.nonoidea.com/2012/12/12/html5%e7%9a%84%e6%98%8e%e5%a4%a9-%e5%b1%80%e9%83%a8%e6%9c%89%e5%b0%8f%e9%9b%a8/