談談APP架構選型：React Native仍是HBuilder

原文連接

導讀：最近公司的一款新產品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的Constraint\origin\Center等屬性），再好比動畫。另外，若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還行。