王淮：HTML5的明天，局部有小雨
前言：現在 HTML5 技術很熱，那么作為開發者，你的產品是否可以趕個潮流，可以用 HTML5 來做呢？Facebook 前研發經理王淮（weibo）在博客上發表了一篇文章，專門為開發者們考慮了這個問題。HTML5 的確很有魅力，但它并不是萬靈丹，如果你是 Web 端，那么就是一片晴天，如果是在手機端，那么可能會有小雨。本文由作者授權發表，TECH2IPO 二次編輯。
HTML5 是什么？為什么很多人如此關注它并押上公司的未來？但為什么 Facebook 棄 HTML5 轉 Objective C？ HTML5 的明天, 是晴還是雨，你該不該給它投懷送抱，該如何去判斷？
我最近對 HTML5 產生興趣，就做了一些粗淺的研究，并和硅谷的兩位玩弄 HTML5 多年的大佬 Luke Shepard（原 Facebook 移動平臺研發經理）和 Feng Qian（Facebook 高級工程師, 原 Google Chrome 的創始團隊成員）電話交流，總結于此篇文章。這篇文章不是 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，what so ever)的運行。
***的好處，就是一處開發，多處使用。審核新版本的發布也不用看蘋果爺爺的臉色，直接在服務器端推送新代碼就好了。對于開發人員而言，這對效率的提高，有著致命的誘惑。像“你們是先開發 Web, 還是移動？”之類的問題，將愉快的失去意義。
對于 Web 端的開發而言，你可以盡情的享受 HTML5 這種統一封裝帶來的好處，唯一要等待的就是瀏覽器對其支持的完善。但這種完善的到來, 無疑是確定的。
而正是這種好處，讓很多創業者如此關注它并押上公司的未來。
但對于移動端而言，卻沒有那么簡單純粹。
如果是移動端，取決于你的產品形態。因為你的產品需要的功能可能永遠也無法在移動端的瀏覽器的 HTML5 實現中被很好的實現。
“App Store 上超過 50% 的應用已經是用 HTML5 來開發，將來可能 90% 的應用會是 HTML5，而那 10%，可能永遠也不適合 HTML5。”
HTML5 的天氣預報中，是局部有小雨。
苦逼的開發者們，你站的地是晴天還是下雨，該如何判斷呢？
先介紹一個工具，動態檢測瀏覽器對HTML支持程度的 ringmark.io（該網站不僅可以測試你當前的瀏覽器，你也可以在右下角的“Choose a different device”當中選擇不同的移動端的操作系統版本來看看它們對于HTML5的支持程度）。如下圖所示，它將測試你當前的瀏覽器，將 HTML5 的規格 (spec) 當中描述的功能的實現程度會一一測試出來。不同的 ring (環)代表了不同的功能等級。已經實現的為綠色，沒實現的是灰色。發現灰色很多的朋友，要換瀏覽器啰。
回到剛開始的那個問題，Facebook 為什么在 iOS App 的實現上棄 HTML5 選 Objective C ，就在于 Facebook App 重度依賴照片，而照片分享、瀏覽相關的功能極度依賴 CSS Overflow Scrolling ，這一點, iOS 上的瀏覽器支持極度不給力。而換成 Objective C 的Native Implementation 之后，速度快上了2倍之多。
好，有朋友可能會問，可能在將來瀏覽器對這些功能的支持會得到改善呢？那時候不就可以了。
事實是，那一天可能永遠也不會到來。
因為瀏覽器的編程模型還是90年代流行的單進程單線程 (single process single thread)，但原生實現(比如用 Objective 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 需要哪些功能, 可以參考進入 ringmark.io , 點開 ring1, 點擊“See how features apply to each type of App”，可以看到這個工具對于不同的 App 的類型做出的總結. 比如, 對于照片功能比較重的 App(Camera App), 你會發現他們需要什么樣的功能, 如果灰色（代表當前瀏覽器沒實現）太多的話, 你的 App 將不適合在這種瀏覽器中運行。
HTML5 究竟在等什么？
HTML5 實現已經是 50% 以上的 iOS App 的選擇。我相信處理能力的提升。將讓移動設備的處理不給力帶來的體驗底下得到改善。而這種處理能力的提高，很大程度上將取決于低耗電高性能 CPU /內存的出現，或者電池技術的極大改善。
在這一天到來之前，有可能 10% 的 App 無法應用 HTML5 來實現。
