為什麼扎克伯克說 Facebook 在 web 版本上押注過多,將來把更多的精力放在原生應用上?
Facebook的web版本基於HTML5技術,這項技術在當前有哪些優缺點,它的前景又是如何?
題目有點兒大,簡單講講。
優點是,
Facebook 作為一個 Web 起家的公司,已經擁有大量的 HTML(5)人才,做用 HTML5 渲染的應用可以有效利用現有人力資源和技術積累,項目起步輕快,進展迅速。
另外對於排版有複雜要求的應用,拿 HTML5 作為渲染引擎比自己寫一套原生的解決方案出來要方便、通用得多。
HTML5 還有一個很誘人的特性:跨平台支持。看上去很美,做一個 Web App 就能搞定所有平台,還不用學那麼多種編程語言。
缺點是,
真正做過跨平台的人都知道,一套代碼打天下其實是痴人說夢(做遊戲的同學日子要好過些)。
能夠一套代碼搞定所有平台的應用,通常都是在哪個平台上都不好用的應用。
就算是 Web App 也一樣,例如為不同解析度、DPI 的機器做優化這件事兒就不能省。
其次,目前的主流移動瀏覽器渲染 HTML5、執行 Javascript 還是不夠快。哪怕在支持 Nitro Javascript Engine 的 Mobile Safari 上,載入的 js framework 稍微重點兒也卡,更何況在不支持 Nitro 的 UIWebView 上呢。所以性能是純 HTML5 應用最大的軟肋,而性能差的應用其體驗是好不了的。
另外雖然 HTML5 框架支持了很多新特性,蘋果公開給 Web App 的 API 也越來越多,移動瀏覽器也越來越快,但原生 API 永遠要支持得更多、更好、更快。所以在近期內, HTML5 做的 Web App 要達到或者超過同時期原生 App 的效果,是很難,甚至是不可能的。
很多時候用 HTML5 出原型快,但是隨著需求的增加,想要實現的效果越來越高級,對性能要求越來越嚴格,完全用 HTML5 所花費的代價、對技術人員的要求反而要比用原生方案高很多,得不償失。
最後,各種技術都有其局限性也有其優點,如果能夠把握好各技術的特點,把合適的技術用來解決合適的問題,做成 Hybrid 應用是較好的方案(fb 之前過於偏重 HTML5,我認為這不是我所描述的 hybrid 形式)。
我是做SocialGame的,困擾我們的最大問題就是我們要接入的平台,每個平台都有自己的一套介面,各自有各自的標準,每次新接一個平台,我們都要針對這個平台做特殊定製,花費大量的時間和精力。
有一天Google站了出來,說,我要解決這個問題,我提供一個統一標準,叫做OpenSocial,可以解決這個問題,實現跨平台,減少對平台的依賴。
我們很高興,以為找到了解決方案,於是開始研究它,緊接著憑藉Google的大肆推廣,國內的人人網,http://51.com等平台,全部支持了這種介面方案,但是很快我們發現,這不靠譜,為什麼呢?平台之所以採取自己獨特的介面,是為了提供平台獨有功能的支持。
以新鮮事(首頁的消息)為例,有的平台不支持新鮮事,有的僅支持文字,有的支持文字和圖片,有的支持文字圖片和自定義鏈接,有的支持多媒體。
為此,我們面臨的選擇就是,要麼最小適配,就是我們假定平台都不支持,那麼一勞永逸,我不再關心你到底有什麼亂七八糟的特性。但是這對運營是個大問題,我們無法充分利用平台特性。要麼我們就還是得針對各個平台進行不同實現,其結果是該做的工作我們一樣不落,甚至更多了,因為我們還要照顧到OpenSocial的特性。
於是乎,這種解決方案最終沒有經得起市場考驗,被人們丟到一邊。
回到Html5,和我說的這個現象類似,看似它有了一套嚴格的標準,但是它扛不住不同平台的本地實現的不同,它看起來可以幫我們偷懶,卻很難使我們的產品在一個平台將那個平台的特性發揮到極致。
更深入的,使用Html5可以脫離商店的束縛,你的商店規則對我無效了,這看似自由了,但你相當於同時放棄了對平台資源的利用,這樣的對比下,顯然放棄平台資源並不理智,除非你自己有很強大的渠道。
而且Html5是一個完善中的標準,它隨時產生變化,穩定性還不如平台,為了兼顧這套標準,我的成本非但沒有降低,還增加了。
那麼請告訴我,當你畫的大餅無法實現,我出了狼窩,又進了你這個虎穴,何必呢,我還不如回到我的狼窩,好好的伺候我的狼。最近也負責了一個HTML5產品,這裡分析下HTML5在移動端能力(適合產品經理或開發人員閱讀)
一、HTML5的優勢我想HTML5的優勢早已在行業內被傳的家喻戶曉,例如:
- 多平台
- 支持本地存儲
- 支持三維圖形特效,基於SVG、Canvas、WebGL及CSS3的3D功能
- 支持網頁多媒體播放,例如視頻,音樂都可以直接播放
在項目進展的過程中,驚喜的發現除了網路上流傳的這些能力外,html5還支持上傳圖片,圖片的壓縮甚至非同步拉取等在web端常見的功能。除此之外iOS6對web app支持smart banner和桌面web clip功能,使得web app對native app的下載拉動和模擬native效果的能力更強。
這些能力不是項目開始前就知道的,作為產品經理更多的是關注功能特性和交互流程,但很多時候功能能否實現更多的是依賴於HTML5這個平台能否滿足,這也是後面扎克伯克說的「it just wasn』t there」的意思。
二、HTML5的現狀
前景的確非常美好,但是目前來看HTML5的確存在不少問題:
1.兼容性非常繁瑣。多平台其實是個幌子,多平台意味著需要適配多種手機屏幕解析度,多種不同的系統,多種手機瀏覽器。老實說,android在這方面的貢獻不亞於電腦端ie瀏覽器。
2.載入渲染速度不夠快。儘管這取決於系統本身的性能,但還是比同樣機器的native慢不少,如果一些含有複雜邏輯的頁面就會出現閃屏的狀況。
3.容易誤點。原生應用拇指點擊區域一般比真正點擊區域要大,而且實際體驗上也比較自然舒服。但web來說目前只能通過css來控制觸碰區域,體驗上還是不太能令人滿意的。
4.圖片上傳。極度依賴系統支持能否壓縮,不支持就只能傳原圖,非wifi傳原圖的話,至少5S等待時間
5.本地存儲。ft中文網是使用這個特性最傳神的,但本地存儲還是依賴系統本身,充滿著不確定性和不穩定,如果是專門針對手機瀏覽器的應用或許可以利用起來。
三、HTML5的機會
HTML5和native的對比早期在網路上討論的還是很熱鬧的,例如:
HTML5比原生應用更具長期優勢__萬家熱線
HTML5和原生移動應用誰會贏?_cnBeta 軟體新聞_cnBeta.COM
但我一直認為,這種比較是毫無意義且沒有實踐經驗依據的,往往是一些所謂的技術大牛或者編輯嘩眾取寵的文章。
可以這麼說,HTML5一直沒有釋放其該有的能量,被詬病的「性能」問題是其沒能大範圍使用的根本原因。就像田忌賽馬一樣,你總不能用自己的弱項去跟別人的強項比吧? 所以原生native跟HTML5結合使用是移動端最有力的武器,但遺憾的是國內外一直都沒有人能把他們正確的結合起來,
大家想到的無非是:
- 原生native app外殼裡麵包一層HTML5的頁面。這樣除了一些基本操作菜單外,其他內容還是HTML5,還得更新,讓人抓狂。。
- HTML5直接模擬原生native app。同上,訪問速度和流量是瓶頸。
我一直在思考,到底是什麼產品形態才能充分發揮HTML5和native的優勢呢?什麼用戶會傾向與web?什麼場景下用web會更適合?什麼產品特性不需要更新客戶端也能快速更新?
這些問題延伸下去其實就是答案了。這裡用人物法來分析下思考的過程:
1.用戶:很在意移動流量,沒耐心等待慢的手機頁面,總是在移動中或碎片時間使用手機。
-所以跟用戶直接「接觸」的產品,最好是原生native的,可以保證穩定性和流暢度。
2.第三方開發者:非常需要平台方開放介面,根據這些介面盡量滿足自己的需要,或者是社區傳播自己的產品,或者是吸引更多用戶購買從而盈利等
3.平台:這裡的平台就是這款手機軟體的主開發商。對於經常需要更新,而用戶訪問又不頻繁的,可以使用HTML5來實現,對於第三方開發者想獲取到的能力進行更多自定義特性,HTML5是很適合的。
總結:
HTML5代表著移動web的未來,最適合它的未必是用它來做一個獨立的應用,而是找到最適合的點來使用。html5的增長速度會隨著網路環境和手機硬體的提升而更進一步。
到目前為止任何跨平台都是騙人的,平台有它的獨特性,沒有這些平台的獨特性,那麼這個平台就沒有什魅力會被人遺棄。
第一問小札自己已經回答了,就是說用HTML5來滿足app應用需求, "it just wasn』t there"...直接的意思不是說HTML5不成熟,而是「滿足不了」。
第二問HTML5 在應用開發上有什麼優缺點?個人覺得不是優缺點的問題,而是要判斷什麼時候適合在應用開發上使用HTML5?HTML5不是原生應用開發語言5的縮寫,是HyperText Markup Language 5的縮寫。它本身不是為原生應用設計的,甚至也不是為了web 應用設計的(它還需要JS的幫助吧至少)。我們團隊開發過不少iOS和安卓產品,在蘋果商店就有10多個。我們的經驗是如果內容比較靠近報刊書籍,或者文章、網頁,那麼用HTML框架做主要內容展現比較好。但是如果交互功能很多,比如SNS,行情圖,我們用原生應用框架。不少應用都是比例不同的混搭。
擴大的跨平台都有點兒扯淡
在HTML5還不成熟的情況下,產品要有更好的體驗,更快地佔領市場,還是native的比較靠譜。
感覺HTML5跨平台,必然要妥協,放棄難以兼容的特性,就像流水線作業,native的更像是精雕細琢一些,目前HTML5開發的產品還是難以滿足用戶需求的。
兼容性越好的技術性能越差,兼容性越差的技術性能越強。
在安卓上使用html5做web app動畫不流暢,交互準則和原生app不一樣(尤其是安卓的back),很多高級功能也做不了
回顧PC的歷史,很有趣的是最早都是C/S結構,後來因為網路環境和機器本身的速度因素逐步走向B/S結構。
在Mobile世界也在順應這個潮流,有趣的是小札的反思其實是他走的太快了。當下的Mobile使用環境可能還是在初期必須是App當道。也就是PC時代早期的C/S結構。
長期看必定會走向B/S結構這個趨勢不會改變。只是小札超前了些許。這才有了小扎的這次演講。當然FB全面擁抱移動這是一個大事件。
一句話,HTML5這一WEB技術還不夠適應手機移動平台的一些特性,簡單一點,一套方案很難討好所有平台
都太片面了,真實情況往往考慮的是開發速度,而非質量。跨平台並不是說一行代碼不改,而是更大程度的代碼復用。而那些提性能不佳的更極端,我很好奇,你的應用得有多牛逼,能讓html5明顯卡頓。其實說了這麼多,我覺得大家的問題就是把na與html對立起來,但他們其實是互補的
跨平台都是騙人的
隨著時間的推移,大家會發現越來越多的應用可以通過H5的方式來實現,包括一些複雜的遊戲也可以。上面回答排斥H5的同學,大部分都是原生應用的從業者,而且都是好幾年前,但是2016年以後,大家會發現在手機端H5的表現越來越好。
就好像Flash經歷過,PC端動畫-&>富媒體廣告-&>全站Flash-&>Flex開發遊戲,頁游等多個階段,早期Flash也什麼都做不了,但是後面做的事情越來越多,我個人覺得這個過程也會在H5上重演一次。
怎麼沒有人說說google PNacl和Nacl可以用來開發native的web應用啊, 這個東西未來大家怎麼看 ?
翻譯下,
扎克伯格意思是他很期待將來有著美好前景的HTML5,但不是當前這個尚不成熟的baby版本。所以要停止在web版本上押太多籌碼了。
他們的寶貝用戶更多的是用手機瀏覽器上Facebook而不是用安卓和水果的原生app。所以將來他們還要把重心移回HTML5上面來。但是,這些都是長遠的事情啦。
希望對你有幫助。
When I』m introspective about the last few years I think the bigest mistake that we made, as a company, is betting too much on HTML5 as opposed to native…because it just wasn』t there. And it』s not that HTML5 is bad. I』m actually, on long-term, really excited about it. One of the things that』s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.
——Mark Zuckerberg, Disrupt SF, September 2012
唯技術論是程序員們的愛好,一天到晚爭論哪個語言更好,哪個技術更牛,沒有意義嘛,這個說法明顯是斷章取義了
html5隻是還沒有成熟標準還沒有出來,標準出來了可以就不一樣了。
推薦閱讀:
※Facebook 採用 HBase,對雲資料庫領域的發展會有什麼影響?
※Facebook 相片彈層為什麼選用黑底?
※Facebook 收購 Instagram 的 10 億美元,投資人、創始人、普通員工大約能分到多少?
※如何看待 Instagram 宣布日活躍用戶量已達 5 億?
※Facebook 花10億收購 Instagram,為什麼還要開發 Facebook Camera,這有何意義?
TAG:Facebook | iOS應用 | Android應用 | HTML5 | 應用程序Application |