最近公司的一款新產品APP要進行研發，老大的意思想用H5來做混合APP以達到高效敏捷開發的目的。我自然就開始進行各種技術選型的調研，這裡重點想說的是我最後挑選出的2款hybrid app開發技術方案：RN(react native)，HBuilder。React Native是大名鼎鼎的Facebo...
導讀：最近公司的一款新產品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還行。
