HTML5會取代App應用嗎?

大量新生移動設備的興起,改變了互聯網的未來。在技術的發展上,HTML5會取代App應用嗎?或者說能夠在多大程度上取代呢?在HTML5規範中,已經加入了相機、磁力羅盤、GPS信息的支持。很多新興瀏覽器也已經開始支持這些新特性。能否用一個統一的HTML5來替代android和ios並行開發的雙重成本呢?以下譯自Michael Mahemoff的一篇文章,詳細分析了HTML5能否取代Android和iOS應用程序。
 
 
 
介紹
 
移動應用程序(App)和HTML5都是目前最火的技術,二者之間也有不少重疊之處。在移動設備瀏覽器裏運行的html5的web頁面,也可以重新打包成不同平臺上運行的app。目前很多瀏覽器都有很好的跨平臺支持,(譯註:firefox居然可以在android中使用和windows下同樣的瀏覽器內核),HTML5的web方案,對開發者來說更爲方便。完成一次,即可多平臺使用。但這確實可行嗎?仍然有許多必要原因,使得開發者選擇了app開發。很明顯,很多人已經在這麼做了。本文將詳細分析兩種方案的優劣。
 
 
 
功能豐富
 
正方:App裏可以開發出更豐富的功能
 
我們把移動功能分成兩類。程序本身和程序與系統的結合。比如android裏,加入widget圖標或者通知提醒之類的。App對這兩者都沒問題。不用多說,這是肯定的。
 
 
 
反方:APP是挺強,但Web也正在迎頭跟進
 
確實很多原生app實現的功能是HTML5望塵莫及的。不管你的web做的再牛,如果停留在一個沒有攝像頭支持的沙盒中,很多場合還是玩不轉。幸運的是,現在沒有這樣的沙盒限制了。如果你需要你的web照相片,可以做一個負責照像的app,再把你的web打包進這個應用裏面。開源的PhoneGap框架是這麼幹的。這樣widget,手機提醒也都沒問題了。
 
但這種混合開發的問題在於,增加了複雜性,而且不象傳統web那樣可以直接在瀏覽器裏運行。這個問題短時間內恐怕沒轍。好在現在網絡標準在不斷的高速擴充,先進的瀏覽器也在一直跟進。Android 3.1已經支持camera了。iOS瀏覽器也支持WebSocket和設備方向檢測了。
 
總得來說,移動設備在發展,而web也同樣在快速變化。桌面瀏覽器本身,有5家主要瀏覽器開發商在改進現有標準,豐富新的功能。所以原生App在快速前進,同時,web也在縮小差距。
 
 
 
運行效率
 
正方:原生APP速度更快
 
原生APP沒有瓶頸,而且可以直接調用GPU加速、使用多線程。
 
 
 
反方:現如今Web已經快多了,而且多數應用也用不着那麼快。
 
這說法有點落伍了。Chrome發佈之時帶來的Javascript V8,給Web速度帶來的飛躍。而現在,計算速度變得更快了:
 
圖片處理引擎已經使用web加速。現在硬件加速也已經開始應用了。看看用上硬件加速的canvas(圖表來源)
 
 
 
要開發3D遊戲的就不用擡槓了,但對於平而來說,新聞、郵件、時間管理、社交網絡,這些用Web都夠用了。試試Steve Souders的手機性能測試工具。 另外,越來越多的框架結合WebGL,可以發揮OpenGL的優勢了。比如ImpactJS,幫助開發JS遊戲。
 
 
 
 
開發感受
 
正方:原生APP好寫
 
原生APP使用強壯的程序語言(Java, Objective C, C++)。適合寫複雜程序,經過歷史驗證,API豐富。在桌面環境可以方便的用模擬器測試。而Web程序的runtimes和亂七八糟的各路瀏覽器讓人頭大。
 
 
反方:一般都是Web更簡單,特別是需要兼容不同設備的時候。
 
Web最初的功能只限於文檔展示,而不是程序應用,貌似最近倆星期纔有了JS。但有了JS後,web的世界馬上就不一樣了。更何況web不只是靜止的,HTML5,CSS3,EcmaScript Harmony(誰知道這是什麼?)都給開發者極大幫助。你是喜歡C++,java, JavaScript,那你的個人愛好,也是基於你已經攢下的代碼。但是現在沒人能否認JavaScript也和前者站在同一擂臺上。
 
 
瀏覽器/runtime的互不兼容(碎片),反過來看做APP也是一樣。用Java寫了Android app,然後又要面對iOS的Objective C。如果能寫一個程序,馬上能在Android和iOS上運行,多省事啊。這咱還沒提WebOS, BlackBerry,Windows Mobile呢。當然,這是理論上的。要是想讓程序在每個平臺都跑得很漂亮,得做不少調試和妥協。這對很多原生APP也是一樣的。不同OS版本,不同的設備。。。
 
 
所謂的Web碎片化,一直都是如此。但好消息是現在已經有很多不錯的解決辦法。Modernizr庫,用得好的話,可以幫你兼容一大批主流設備,不管是啥系統,哪個牌子的。看看我們2011年的Google IO演示。
 
 
 
用戶體驗
 
 
正方:原生APP更切合原有平臺
 
操作感受的定義之一,就是用戶希望在你的程序裏,用與系統連貫統一的方式來操作。不同的平臺,都有一些約定俗成的習慣。比如長按按鈕會有啥反應。你不能指望用一套統一的HTML5 App去滿足所有用戶。
 
 
此外,整個平臺的操作感受都由用平臺自有的軟件庫協調。直接調用平臺工具包就能直接免費獲得完整支持。
 
 
反方:我們Web有自己的傳統,你要特想做原有平臺那種感覺的web,也一樣能做出來
 
 
前面說了,Web開發的方式,是先做一個大體適合所有平臺的版本,然後再針對不同平臺不斷改進。當這些改進主要是針對功能時,你可以選擇幾個你最關心的平臺做優化。類似於瀏覽器檢測。技術論壇裏的悲催技術員們,經常抱怨這事。太多不同的瀏覽器版本了。不過如果你優先關注兩三種主流平臺,是值得爲他們多花點時間做做優化。
 
 
web本來就有自己的操作感受。我們也可以說,不同的默認瀏覽器以及運行環境造就了獨特的”Web感受”。從更廣的角度看,這本身就是一種用戶公認的方式。此外,還有很多成功的案例並不遵循移動設備的原生操作習慣,人家也成功了。想想你最喜歡的手機遊戲的界面?很多更傳統的app也是一樣,比如Twitter客戶端。
 
 
 
傳播途徑
 
正方:原生應用更容易接觸客戶
 
象Google Play和Apple Store這樣的app發佈機制這幾年勢不可擋,推動了整個移動行業。每個程序員都能在市場裏發佈自己的應用。用戶都擠在市場裏瀏覽,搜索,接受推薦。不僅如此,只要你的程序夠好,現有用戶的打分會幫助你說服更多新的客戶。
 
 
反方:其實web才容易接觸到客戶
 
通過web找到內容,這是經過論證的可靠途徑。利用URL,每一項發佈的內容都有一個獨立的地址,包括在網站上發佈的應用程序。搜索引擎幫助發現內容,其他網站提供鏈接,還有一些類似應用市場的分類網站。用戶還可以郵件、短信、在社交網站分享你的鏈接。你的應用鏈接可以直接在不同設備上直接打開。
 
web上還沒有一個統一的評分系統,但這個情況也在發生改變。往下看。。。
 
 
 
收費
 
正方:App收費:應天意,順民生
 
“六歲孩子午飯時做app,$3一個,賣出幾百萬”。最近常聽看到這樣的新聞。各種大小廠商也跟着蜂擁而至,等着圈錢。應用商點幫開發商直接收費。最簡單的辦法,一次性收費。也有在app裏再另行收費或者做訂閱收費的,這幫助開發商贏得長期穩定的回報。
 
 
此外,傳統網站的廣告、贊助,在app裏也同樣適用。
 
 
 
反方:網站賺錢,從來都不是問題。現在機會還越來越多
 
Web能成爲現在社會的推動力,有能力用多種方式取得回報,這是基本條件。雖然使用付費並不普遍。但SaaS的模式已經相當普及了。成功案例包括Google Apps,37Signals的系列產品,各類郵件的收費版。另外,直接收費並不是web應用的唯一模式。廣告、會員鏈接,贊助,其他產品服務的交叉推廣都是可選的模式。
 
看着能在應用市場裏直接賺錢而眼紅的Web開發商們,你們不能直接把你的URL發進市場,但是做一個瀏覽web的app的殼子來連到自己的web上怎麼樣?現在市場中如果不說數以千計,至少也有上百的app這麼幹了。有些包裝的好的,你甚至察覺不到他是一個web程序。
 
以後應用市場會直接支持web程序嗎?這個現在還不好說,但去年Google已經建了個Chrome web store。雖然還只能從桌面電腦放問,但這已經挑起了瀏覽器廠商的興趣。現在還只是個初步概念,但看起來挺有前途。
 
 
 
結論
 
現在還看不出完勝的一方。有些應用適合做app,有一些適合用html5。目前的情況,原生APP肯定是一個很重要的選擇。上面提到的混合式開發,可能是一個不錯的妥協方案。能用web的時候用app調用web。web實現不了的功能用app開發。
 
如果你選擇web方式,要在web標準和不斷的改進上用心。web技術本身的優點就是能兼容大批不同的操作系統和設備。消極的看,你也可以這是碎片,但web就是一切通吃。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章