轉載本文需註明出處：EAII企業架構創新研究院（微信號：eaworld），違者必究。如需加入微信羣參與微課堂、架構設計與討論直播請直接回復此公衆號：「加羣 姓名 公司 職位 微信號」。
前端
很高興在今天下午與各位有這樣一次關於驅動原生（React Native） 技術的交流。java
這次交流的內容，主要是我在Pworld2016 大會的講解內容，本想比較真實的還原當時的狀況，在各個設計羣發出預告後，仍是看到了不少不一樣的理解。git
因而我對PPT的內容進行了增長和修改。github
不少工程師，包括前端工程師、甚至是移動前端工程師對於React Native 有不少誤解。瀏覽器
React Native 不是React，並且我認爲Ta比React 技術更被普遍承認。微信
就在不久Github官方發佈的2016 開源報告中（感興趣的，能夠移步：https://octoverse.github.com前端工程師
），React Native的活躍度排名第五，常常被國人搞混在一塊兒的React 並無取得這麼多的關注。架構
同時，《軟件開發時代》雜誌(SDTimes)回顧了2015年Github上十強中，ReactNative 排名第六。ide
分享的主題是《React Native 移動技術在企業中的實踐》。
1、React Native已成移動的技術主流方向
React Native 已成移動的技術主流方向，特別是移動跨平臺領域內。
可能會有人提出疑問，跨平臺技術最主流的不是hybrid技術嗎？
兩年前，這個結論我承認，如今不敢苟同了。
我認爲Hybrid已是上一代的跨平臺技術了。
就在上個月，CSDN舉辦的MDCC移動開發者大會專場上，你們不約而同的所有在分享驅動原生型的跨平臺實戰，而沒有一個講者再多提Hybrid。
而下週InfoQ在上海舉辦的Qcon大會上從題目看，至少有兩三場在分享驅動原生型（包括React Native、Weex）的移動開發，一樣，一場Hybrid的都沒有。
React Native 的緣起
提及React Native，不得不提到Facebook。
Facebook創始人兼CEO馬克·扎克伯格，在TechCrunch舉辦的Disrupt大會上，「專一在HTML5上面是他有史以來犯過的最大的錯誤。」
解讀這句話其實用後面一句更爲客觀：
「Facebook最大錯誤是在 HTML5 上押注過大，在移動平臺上浪費兩年時間」
就是在這種背景下，推出了React Native 的解決方案。
React Native 已經是一種移動前端技術流派
從整個移動App前端技術的演進看，我認爲，React Native成爲一種技術流派。
React Native 已經是一種移動前端技術流派，我稱之爲驅動原生型的。
不管React Native、或者Primeton Mobile以及Weex，他們從架構和實現的思路上不謀而合的走到了一塊兒。基本上具有一下兩個比較鮮明的特色。
·採用原生渲染，摒棄Webkit渲染，提高體驗。
·採用Web語言做爲基礎開發語言，下降學習成本。
事實上，這個技術最近兩年已經獲得了大量企業普遍的驗證。
互聯網行業中，React Native 技術已經在騰訊、阿里、攜程、5八、Facebook等大型互聯網公司核心App中大量採用。
最近更新的案例列表代表，在Baidu(手機百度)、Instagram、JD（手機京東）等大型主流應用的iOS版本、Android中均已經採用。
更有甚者，在VR、遊戲等重體驗的App也採用了，這充分說明了其用戶的良好性。
在企業中，React Native正在成爲移動前端技術的首選。
驅動原生技術在企業客戶中普遍的使用，上圖是部分客戶的App，有興趣能夠自行下載，就不贅述。
甚至，蘋果 AppStore爲此也修改了審覈規則。
在2015年7月28日的蘋果 AppStore審覈政策調整，從以前的不容許JavascriptCore ,而在這天以後刪除此條款。
容許運行JavascriptCore的動態加載代碼，經過App Store 的審覈。
要知道，JavascriptCore 動態加載是驅動原生型（React Native ）的實現原理。
2、React Native 的利和弊
React Native 通信機制原理
React Native的通訊機制，能夠簡單總結爲三句半。
·經過Javascript 的方式調用
·iOS/Android提供了js-Bridge
·最終經過iOS/Android 的控件進行渲染
·全過程，沒有Webkit（瀏覽器）什麼事兒（這半句是爲了更好的解釋其與Hybrid的區別）
在說明其機制後，咱們更加容易理解其優勢。
React Native 技術流派的三大優勢
·體驗好：完全摒棄Webview，擺脫Webview的體驗差、性能差的問題，這也是爲何大量採用Hybrid技術的轉向RN。
·熱更新：支持應用內熱更新與動態顯示，支持AppStore 上應用的熱更新，相對於原生語言開發的App來說，這一點更加的容易和靈活。
·原生能力：本地能力、原生能力調用方便，實現一個真正的MobileNativeApp，而不是一個Web App。
舉例說明上述的優勢在業務上的價值
正是由於RN技術對於體驗上有超過HTML5渲染太多，大量主流核心App中也均採用RN進行了嘗試。
包括，QQ、QQ音樂、全面K歌、攜程、手淘／手貓等主流核心應用均採用驅動原生技術進行了改造。
固然最近5八、美團、手機京東、Instagram、Airbnb，甚至手機百度等也都加入到了React Native的陣容。
這無疑給正在抉擇的人提高了信心。
在保證了體驗的同時，React Native技術讓應用內冷熱更新都成爲可能。
·支持應用內，冷更新、熱更新，減小對應用商店等渠道的依賴。
·Andriod、iOS，AppStore、in-house的全面支持
上圖中，最左側的圖，是手機淘寶的Andriod版的，非應用市場更新的界面，它採用的是應用內冷更新的方式，即，不須要通過市場，須要重啓應用。
實際上，採用驅動原生的方式，徹底能夠作到應用內熱更新的效果，即不須要通過市場，不須要重啓應用。如右圖所示，作過移動App的人估計經過狀態欄和沉浸式的效果就能夠看出這個App是iOS版本的。
本質上，這個優勢能夠大幅下降App的二次推廣成本，全面提高新業務功能的客戶達到率。
隨着移動互聯網的深刻發展，移動端已經不只僅是簡單的信息展現，愈來愈多的應用已經從移動展現發展到移動開展業務的場景。
比較典型的是，銀行的移動辦理貸款、保險公司的移動展業等等，這就須要App端對於原生能力的使用更加深刻，更大發揮移動的優點，強化交互性。
而驅動原生的技術確實可以提供Hybrid方案難以完成的場景。
上面講述了其幾大優勢，實際上在使用React Native 落地的過程當中，不免會遇到一些難道，咱們稍微總結了一些其弊端。
React Native 技術的三大待提高點
·其自己不誇平臺，須要多個平臺、多套代碼，這回致使實施成本和維護成本提升。
·其開發期強依賴於React語法，致使傳統企業人員學習成本增長。實際上正如我以前說的那樣，我認爲React的接受度遠不及React Native的接受度，讓一個超級流行的項目依賴一個不及它的項目，這自己就是一個值得商榷的地方。固然React 也是一個不錯的東西啦。
·React Native從技術緯度，在前端並無提供精細化的能力，缺乏微應用的支持。特別是在企業中，實施企業App，沒法快速響應崗位調整，同時難以針對多供應商、多團隊並行研發。
3、咱們的一些實踐
首先，咱們進行了跨平臺的嘗試，經過一套代碼支持多種操做系統，支持屏幕自動適配的問題。
其實，咱們採用了標準Web語法（HTML／CSS／Javascript），做爲開發期語言，從而低昂迪企業人員學習成本。
再次，不管是開發期，仍是運行態，支持MicroApp，方便麪向崗位、職位，體現App功能。同時也方便進行多開發團隊、多提供商團隊並行工做模型的支持。
咱們經過上層封裝，經過一套代碼能夠支持iOS、Android的而且多屏適配、甚至多屏同時調試的支持。
調試視頻地址：http://video.weibo.com/show?fid=1034:4aa1a7b8e42d1755faa6e0ad5da18d9c
採用標準Web語法（HTML/CSS/javascript），下降學習成本。
·HTML用於佈局、控件及屬性設置等
·CSS用於樣式設置
·Javascript 用於數據設置、交互響應等
全面支持微應用模型，以微應用做爲開發期、運行期的管理單元，更適合企業大規模使用。同時帶來如下的好處：
·採用微應用的方式進行上線運營，能夠有效提升業務響應度、提高運營的精細化
·以微應用的方式進行更新、管理和監控，能夠提高運營效率
·經過微應用市場的方式，用戶自行定義可以使用功能，提高體驗
·微應用的添加方便結合權限控制，提高運營的管控性和功能友好性
同時，支持跨地域拖團隊、多供應商並行工做模式，方便多級創新。
因爲時間和篇幅的限制，上述的特色沒有展開討論，若是你們有興趣能夠補充參考如下我在MDCC（移動開發者大會），跨平臺專場上的分享。
具體的PPT，可從http://special.csdncms.csdn.net/MDCC2016/獲取
4、總結和展望
·不管互聯網公司仍是企業，React Native已經成爲主流
·React Native 具有體驗好、熱更新、原生能力等優點
·基於RN，能夠完善跨平臺、Web語法、微應用等各類能力
·面向大中型企業，React Native 更方便對各種業務的支撐
本次分享結束，感謝你們的參與，謝謝你們！