136
HTML5 的明天, 局部有小雨
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來實現.
最後更新：2017-04-02 00:06:56