一、前言
1. 移動應用開發的三種主流方式：Native App 、Web App、Hybrid App
2. 三種移動應用開發方式比較
二、混合開發應用場景
使用 Hybrid 開發方式，能集Native 和web兩者之優點。一方面，Native 讓開發者可以充分利用現代移動設備所提供的全部不同的特性和功能。另一方面，使用 Web 語言編寫的所有代碼都可以在不同的移動平臺之間共享，使得開發和日常維護過程變得集中式、更高效、更經濟。
三、使用JS框架開發Native App
雖然Hybrid開發方式解決了Native App開發成本高、升級繁瑣、無法快速適應業務需求等問題，但web頁面仍然是使用webview來渲染，相比較原生流暢度體驗有差距明顯，于是隨著技術的發展又出現了使用JS引擎來渲染Native的方式開發App，目前這種方式應用較多的框架有ReactNative與Weex。
React Native
簡介:Facebook在2015年3月在F8開發者大會上開源的跨平臺UI框架
核心理念:Learn once, write anywhere
基于JS開發框架:React Native基于React
WEEX
簡介:weex是阿里巴巴公司與2016年6月開源的一種用于構建移動跨平臺的UI框架
核心理念:Write once, run everywhere
基于JS開發框架:WEEX基于vue.js
四、ReactNative&WEEX比較
環境配置：
React Native 需要安裝Android，iOS開發環境，很多依賴，相對復雜。
Weex需要安裝Android，iOS開發環境，安裝cli，相對簡單。
開發：
React Native傾向于web方式，使用JSX語法，熟悉React后學習相對容易，需要理解Native App 中的一些原理與sdk。
Weex也是傾向于web方式，使用vue.js定義的語法，熟悉vue后學習相對容易，需了解原生sdk。
調試：
React Native 支持虛擬機調試，可以在chrome查看調試信息。
Weex可以在chrome查看，支持節點調試查看，不支持虛擬機調試。
性能：
React Native重心比較多，有較多第三方嘗試性能優化方案。
Weex官方內部的項目里使用，性能優化也僅限于官方開發人員。
案例：
React Native比較早，Github上輪子、案例、教程比較多。
Weex起步較晚，使用的大廠少，案例少。
社區：
React Native較早，社區相對成熟，有強大的第三方生態。
Weex較晚，雖已經開放，但第三方代碼貢獻少，成熟需一段時間。
五、選擇React Native來開發APP
React Native 的歷史可以追溯到 2013 年的夏天，React Native 是當時 Facebook 的一個黑客馬拉松項目。雖然 React Native 很新，但在國外，很多巨頭互聯網公司已經使用 React Native 完成 app 開發。早在 2015 年，Facebook 就用 React Native 做了他們的第一個跨平臺 app——Ads Manager，讓在 Facebook 上做廣告的數百萬用戶可以隨時管理自己的賬戶。2016 年初，Instagram 也開始將 React Native 應用到其“推送通知設置”、“編輯個人資料”、“保存”、“評論審核”等功能。
此外，還有 Airbnb、特斯拉（Tesla）、沃爾瑪（Walmart）、UberEATS、Bloomberg 等。在國內，天貓、QQ、手機百度、京東等 app 也已加入 React Native 大軍。
React Native 之所以可以吸引這么多巨頭來應用，是因為其明顯的優勢——幫助開發者快速開發迭代、提高多平臺開發效率，幫助企業節省人力時間。即“Learn once, write anywhere”（僅需學習一次，編寫任何平臺）
React Native 的優勢如下：
原生組件
React Native 采用了原生 UI 組件，相比而言，使用 HTML5/JavaScript 實現的組件比起原生組件總會感覺差一截。
高代碼復用率
比如，Instagram 使用 React Native 開發的上述幾個新功能在 iOS 與 Android 平臺的代碼重用率達到 85% - 99%；沃爾瑪在 iOS 與 Android 平臺的代碼重用率是 95%。因此，開發效率大大提高。
熱加載
React Native 大大縮短了文件修改后和看到修改所產生的變化之間所需的時間。也就是說，開發者可以立即看到其對代碼所做的最新修改結果。如果你打開了兩個窗口，其中一個包含代碼，另一個使用虛擬機顯示代碼的效果，你可以在第二個屏幕上立即看到你在第一個屏幕上所做的變化的效果。
架構分工
項目工作工作中常遇見有個棘手的問題 - 一個超級大項目但是時間又很急給 3 人做如何分工？
這個分工看似合理，但是這個“合理”也僅僅站在研發的角度。但是一個完整的項目設計到的角色很多，PM，UI，甚至還有 BD 一類的。這么一看，問題就來了。這個分工每個研發角色都需要和其他各個角色打交道呀。大公司 + 打交道，你懂的。so，酸爽。那怎么辦呢？這個可不碎片化哦。那 React 能解決嗎？
這個分工讓張三和李四逃出了 PM 和 BD 的魔爪，讓王五一個痛苦去吧。但是呢，來自 UI 的壓力也基本被張三和李四分擔了。這個已經很合理了吧，還有優化空間？咱們仔細看一下。 王五是比較累的，因為張三和李四分擔了他的不同的功能組件。他在整合業務會和這兩人同時打交道。那再來個 Redux？
這下好了，王五負責和 PM，BD 交涉。李四負責做王五和張三的橋梁。張三不管業務，一門心思和 ui 同學搞組件。
這就是 React+Redux 的強大，他能讓你在分工的時候追求碎片化到極致。雖然看似代碼的行數可能沒有精簡，但是無形中把人員的關系解耦了。
規范中的自由
看到上面，有的朋友會質疑了。“你這個東西是強拉著和 React 有關系。說白了就是個項目架構和職責的化分問題。我就是用原生的開發也可以這么劃分呀。”
理論上是這樣沒錯。但是所謂框架，就是架構設計的選型承載。它已經為你的這種設計提供了很好的功能 api 和工程規劃。
React 提供的這些組件的表達方式，Redux 提供的組件和數據之間的綁定方式。雖然看上去表復雜，但它規范后有清晰自由的層級劃分。因為這些看似復雜的狀態對象，生命周期，動作函數。才使得你在組件內部無論什么樣的風格，也不會讓組件和組件之間（其實也就是開發者與開發者之間）的邏輯傳遞有任何阻礙。在這套框架下，組件之間數據共享、action共享，產生的作用就是高代碼復用率。
第三方生態
就算結合了上面兩點，但是還讓你覺得。“無非就是個框架的事兒，不一定非要用 React 呀。” 那接下來我只有弱弱的澄清一下。
確實不一定非要用 React，囧。
據不完全統計，React 有比其他類似框架更龐大的周邊生態。開發者都明白，真正能讓項目開發過程享受便利的一定是好的框架 + 豐富的庫。而這一點，也是 React 對標競品的優勢所在。
PS:文章內容來源于網絡，作者僅重新編輯排版，部分內容修改。
