談談APP架構選型:ReactNative還是HBuilder

suboysugar發表於2016-01-21

原文連結

導讀:最近公司的一款新產品APP要進行研發,老大的意思想用H5來做混合APP以達到高效敏捷開發的目的。我自然就開始進行各種技術選型的調研,這裡重點想說的是我最後挑選出的2款hybrid app開發技術方案:RN(react native),HBuilder。React Native是大名鼎鼎的Facebook的開源技術框架,而HBuilder是國內的H5工具開發公 司DCLOUD的產品。我自己先總結下吧:這兩個技術框架在開發效率上基本上可以媲美WEB開發的速度,RN強調的是“Learn once, write anywhere”,RN不強求一份原生程式碼支援多個平臺;而HBuilder則可以實現類似JAVA的“Write once, run anywhere”,也就是說寫一份程式碼,即可同時釋出多平臺,這個效率比原生開發而言自然會double。兩者的原理其實都是基於JS在做前端開發,用JS去做橋接呼叫原生的API,最大的優點是方便做APP的動態更新而不用頻繁去釋出版本,當然hybrid的這種框架也有弱勢缺點,就是目前原生APP的開發生態已經趨向成熟,一些第三方庫和框架不僅豐富而且穩定,所以如果改用基於JS的Hybrid app方案來做,一定要考慮APP產品是否適合用這種技術來做。

下面我把一些網友對這兩個框架的看法列舉如下供參考:

RN -React Native部分—————————————————

React Native的核心實現:先簡單說幾點,詳細的等回頭更新。1. React Native裡面沒有webview,這貨不是Hybrid app,裡面執行JS是用的

JavascriptCore。2. 再說React Native的核心,iOS Native code提供了十來個最基本核心的類(RCTDeviceEventEmitter、RCTRenderingPerf等)、或元件(RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等),然後由React Native的JS部分,組成二十來個基本元件(Popover、Listview等),交由上層的業務方來使用(THGroupView)。3. 就如他們在宣傳時所說,他們實現了一套類似css的子集,用來解決樣式問題,相當複雜和強大,靠這個才能將Native的核心元件組成JS層的基本元件再組成業務端的業務元件,應該是採用facebook/css-layout · GitHub的C語言版本實現的(在ppt中我們看到了類似flex-direction: column一類的程式碼,這個正是css-layout支援的語法)。4. 在React Native中,寫JS的工程師解決的是「將基本元件拼裝成可用的React元件」的問題,寫Native Code的工程師解決的是「提供核心元件,提供足夠的擴充套件性、靈活性和效能」的問題。

 

React Native是什麼?

其實這東西從Native開發來說,相當於重新發明了一個瀏覽器渲染引擎並且套一個React的殼,從Web開發角度來說,就是把原來React的後端換成了Native code來實現,就跟Flipboard最近搞的React Canvas 一樣: Flipboard · GitHubreact-canvas
React Native的優勢和劣勢::

優勢相對Hybird app或者Webapp:
1. 不用Webview,徹底擺脫了Webview讓人不爽的互動和效能問題
2. 有較強的擴充套件性,這是因為Native端提供的是基本控制元件,JS可以自由組合使用
3. 可以直接使用Native原生的「牛逼」動畫(在FB Group這個app裡面,皮膚滑出帶一點果凍彈動,皮膚基於某個點展開這種動畫隨處可見,這種動畫用Native code來做小菜一碟,但是用Web來做就難上加難)。

優勢相對於Native app:
1. 可以通過更新遠端JS,直接更新app,不過這快成為各家大型Native app的標配了…

劣勢:
1. 擴充套件性仍然遠遠不如web,也遠遠不如直接寫Native code(這個不用廢話解釋了吧)
2. 從Native到Web,要做很多概念轉換,勢必造成雙方都要妥協。比如web要用一套CSS的閹割版,Native通過css-layout拿到最終樣式再轉換成native原生的表達方式(比如iOS的ConstraintoriginCenter等屬性),再比如動畫。另外,若Android和iOS都要做相同的封裝,概念轉換就更復雜了。

HBuilder部分————————————————————-

phonegap出的早,自然用的人多。
phonegap自己的定位是混合開發hybrid,用原生+js;
HBuilder的定位是純js搞定一切。
5+ 和 phonegap在能力、效能、開發便利性上都優於phonegap。

先看能力:
5+ 有HTML5+和Native.js技術,HTML5+包含常用的跨平臺的幾百個API,能滿足常規開發需求,而Native.js把40w原生api對映成js物件,這樣js可以直接調原生。HTML5+和Native.js的組合形成了最強大的能力引擎。 而phonegap需要用原生工程師寫原生外掛並給js開發者封裝介面才能實現js調原生能力,開發成本、對人的要求都不一樣。

當然5+ 也支援原生外掛,這點和phonegap類似。一個已經寫好的原生sdk,無需使用Native.js重寫,也可以通過5+ sdk來整合。詳見文件中心 – 5+ App – 5+ SDK

5+的直接封裝的跨平臺api比較全,二維碼、搖一搖、地圖、微信分享、語音輸入、推送這些常用api都是跨平臺的,使用方便簡單。詳見 http://www.html5plus.org/

再看效能:

phonegap做的app,在低端Android手機上很難流暢執行,否則HTML5早就火了,原生開發早就被擠壓了。Phonegap為了避免HTML5的體驗不佳,採用了spa模式,但這個模式其實在低端機上也玩不轉,而且程式碼非常複雜。
5+ App的效能更高,它的動態效果都是被我們的增強引擎處理的,通過增強的引擎,可以在低端機上流暢的執行各種動態效果,比如側滑選單、下拉重新整理、長列表滾動,見 官網首頁 – App選項卡- 效能視訊

最後看開發便利性:

phonegap沒有專業開發工具,語法提示、除錯、打包都很麻煩。
而在HBuilder裡,5+的語法api提示非常完善;
把手機通過資料線連上電腦,HBuilder可以真機執行,儲存一個頁面立即在手機上看到效果,Android上還可以看console.log。而用phonegap,你改完一個頁面,不得不先打包,然後安裝在手機上,然後發現不對,然後改下程式碼,然後繼續打包。。。
關於打包,phonegap由adobe提供了雲打包,但需要先在本機準備資源,然後提交到國外的伺服器,而HBuilder是一鍵打包,更加方便。當然phonegap和HBuilder都支援本地打包,那樣就需要點原生開發知識了。

除了工具和runtime,還有mui框架

phonegap只是一個手機runtime,沒有HBuilder工具,更沒有Mui框架。
mui是目前最接近原生App的HTML5框架,它的體驗比jqm、bootstrap等框架更接近原生,它的效能遠高於jqm、bootstrap、Ionic、framework7等框架。
這種效能差別原因有2,一方面是設計思路不同,mui堅持用原生js做,不依賴jquery或angularjs,因為框架的依賴越多,App效能越差;另一方面是因為mui呼叫了5+的底層原生加速,這比不帶原生加速的框架更快。
mui詳見:http://dcloudio.github.io/mui/

當然phonegap有一個優勢,就是能支援windows phone、blackberry,這方面5+確實沒有支援。

 

優勢:Dcloud的其他服務沒具體用過,HBuilder用過,還是一個很不錯的編輯器,整體體驗還是不錯,像程式碼提示很智慧,基於Eclipse的二次開發能做出這樣也挺厲害了。特別是對HTML語法支援瀏覽器相容性很好。有個前端框架寫CSS挺省事的。
缺點:HBuilder Size太大,而且還得聯網使用,整體體驗還是Eclipse風格,相比我還是推薦使用Sublime。主要是做出了的應用就是網頁的體驗,這個實在是不適合用來做應用。做個WebApp還行。

如何聯絡我:【萬里虎】www.bravetiger.cn
【QQ】3396726884 (諮詢問題100元起,幫助解決問題500元起)
【部落格】http://www.cnblogs.com/kenshinobiy/


相關文章