#前端開發技術的調研
標籤（空格分隔）： 未分類
標籤： 移動開發
2018.1.6
文章目錄
| 名詞 | 鏈接 | 描述 |
|---|---|---|
| Cordova | http://cordova.apache.org/ | Hybrid App中間件 |
| ios-deploy | https://github.com/phonegap/ios-deploy | 使用命令行部署iOS項目 |
| PhoneGap | https://phonegap.com/ | 使用Web快速開發、打包Hybrid APP |
| Node.js | https://nodejs.org/en/ | 基於 Chrome V8 引擎的 JavaScript 運行環境。 |
| npm | https://www.npmjs.com/ | Node.js的包管理器 |
| Git | https://git-scm.com/ | 分佈式版本控制庫 |
| ionic | http://ionicframework.com/ | 基於Angular的H5框架 |
| Angular | https://angularjs.org/ | 優秀的前端JS框架 |
| Weex | https://angularjs.org/ | 一個使用 Web 開發體驗來開發高性能原生應用的框架 |
| Vue.js | https://vuejs.org/ | 一套用於構建用戶界面的漸進式框架 |
| Rax | https://alibaba.github.io/rax/ | 一個通用的跨容器的渲染引擎 |
| React.js | https://reactjs.org/ | 構建用戶界面的JavaScript庫 |
| Flex (Flexible Box) | https://www.w3.org/TR/css-flexbox-1/ | 簡便、完整、響應式地實現各種頁面佈局方案 |
| PhoneGap100 | http://www.phonegap100.com/ | Hybrid App社區 |
本文旨在瞭解React Native 、Weex和 Cordova 的差異，評估幾種種前端技術實現的優缺點。關於Cordova我們在之前有過介紹，本篇再簡單介紹ReactNative和Weex。
React.js
概述
React.js 不是一個框架，它只是一個庫。它只提供 UI（view）層面的解決方案。在實際的項目當中，它並不能解決我們所有的問題，需要結合其它的庫，例如 Redux、React-router等來協助提供完整的解決方法。
類似的還有 Vue.js
在web開發中，Facebook認爲現有的MVC框架無法滿足他們的擴展需求，由於他們非常巨大的代碼庫和龐大的組織，使得MVC很快變得非常複復雜，每當需要添加一項新的功能或特性時，系統的複雜度就成級數增長，致使代碼變得脆弱和不可預測，結果導致他們的MVC正在土崩瓦解。所以認爲MVC不適合大規模應用，當系統中有很多的模型和相應的視圖時，其複雜度就會迅速擴大，非常難以理解和調試，特別是模型和視圖間可能存在的雙向數據流動。
於是Facebook推出了Flux 和React.js。
其官方表述：
We built React to solve one problem: building large applications with
data that changes over time.（構建那些數據會隨時間改變的大型應用）
- React不是一個MVC框架
- React不使用模板
- 響應式更新非常簡單
- HTML5僅僅是個開始
React的目的是爲了使前端的V層更具組件化，能更好的複用，它能夠使用簡單的html標籤創建更多的自定義組件標籤，內部綁定事件，同時可以讓你不再需要來回查找某個 DOM 元素，然後再操作 DOM 去更改UI,變成你只需要操作數據就會改變相應的dom。
所以 React 的核心思想是：封裝組件。
各個組件維護自己的狀態和 UI，當狀態變更，自動重新渲染整個組件。
一個簡單的例子：
import React, { Component } from 'React';
import { render } from 'React-dom';
class HelloMessage extends Component {
render() {
return <div>Hello {this.props.name}</div>;
}
}
// 加載組件到 DOM 元素 mountNode
render(<HelloMessage name="John" />, mountNode);
####組件
React 應用都是構建在組件之上。
上面的 HelloMessage 就是一個 React 構建的組件，最後一句 render 會把這個組件顯示到頁面上的某個元素 mountNode 裏面，顯示的內容就是 <div>Hello John</div>。
props 是組件包含的兩個核心概念之一，另一個是 state，一個組件就是通過這兩個屬性的值在 render 方法裏面生成這個組件對應的 HTML 結構。
props
props 就是組件的配置屬性，由外部通過 JSX 屬性傳入設置，一旦初始設置完成，就可以認爲 this.props 是不可更改的，只是在調用這個組件的時候傳入不同的屬性（比如這裏的 name）來定製顯示這個組件。所以不要輕易更改設置 this.props 裏面的值（雖然對於一個 JS 對象你可以做任何事）。
state
state 是組件的當前狀態，可以把組件簡單看成一個“狀態機”，根據狀態 state 呈現不同的 UI 展示。
一旦狀態（數據）更改，組件就會自動調用 render 重新渲染 UI，這個更改的動作會通過 this.setState 方法來觸發。
JSX
從上面的代碼可以看到將 HTML 直接嵌入了 JS 代碼裏面，這個就是 React 提出的一種叫 JSX 的語法，這應該是最開始接觸 React 最不能接受的設定之一，因爲前端被“表現和邏輯層分離”這種思想“洗腦”太久了。但實際上組件的 HTML 是組成一個組件不可分割的一部分，能夠將 HTML 封裝起來纔是組件的完全體，前端才能實現真正意義上的組件化。
爲什麼會有JSX
傳統的 MVC 是將模板放在其他地方，比如 <script> 標籤或者模板文件，再在 JS 中通過某種手段引用模板。按照這種思路，四處分散的模板片段會帶來更多的糾結，糾結模板引擎，糾結模板存放位置，糾結如何引用模板……
React 官方描述說：
We strongly believe that components are the right way to separate
concerns rather than “templates” and “display logic.” We think that
markup and the code that generates it are intimately tied together.
Additionally, display logic is often very complex and using template
languages to express it becomes cumbersome.
React 認爲組件纔是王道，而組件是和模板緊密關聯的，組件模板和組件邏輯分離讓問題複雜化了。
所以就有了 JSX 這種語法，就是爲了把 HTML 模板直接嵌入到 JS 代碼裏面，這樣就做到了模板和組件關聯，但是 JS 不支持這種包含 HTML 的語法，所以需要通過工具將 JSX 編譯輸出成 JS 代碼才能使用。
因爲 JSX 最終是輸出成 JS 代碼來表達的，所以我們可以直接用 React 提供的這些 DOM 構建方法來寫模板，比如一個 JSX 寫的一個鏈接：
Hello!
用 JS 代碼來寫就成這樣了：
React.createElement(‘a’, {href: ‘http://facebook.github.io/React/’}, ‘Hello!’)
Virtual DOM
當組件狀態 state 有更改的時候，React 會自動調用組件的 render 方法重新渲染整個組件的 UI。
傳統的web應用，操作DOM一般是直接更新操作的，當然如果真的這樣大面積的操作 DOM，性能會是一個很大的問題。所以爲了儘可能減少對DOM的操作，React 實現了Virtual DOM。
Virtual DOM是一個輕量級的虛擬的DOM，是React抽象出來的一個對象，組件 DOM 結構就是映射到這個 Virtual DOM 上。
React 在這個 Virtual DOM 上實現了一個 diff 算法，當要重新渲染組件的時候，會通過當前新的DOM表述與之前的作比較，計算出最小的步驟更新真實的DOM。由於 Virtual DOM 是一個純粹的 JS 數據結構，也不是真的渲染整個 DOM 樹所以性能會比原生 DOM 快很多。
更多關於Virtual DOM
####Flux
Unidirectional data flow （單向數據流）是Facebook十分推崇的架構方式。
應用架構的方式，也就是數據如何存放，如何更改數據，如何通知數據更改等等，所以它不是 React 提供的額外的什麼新功能，可以看成是使用 React 構建大型應用的一種最佳實踐。當應用足夠複雜時才能體會到它的好處，雖然在一般應用場景下你可能不會意識到它的存在，也不會影響你開始使用 React。
正因爲它是這樣一種概念，所以涌現了許多實現，比如Facebook官方的 Flux 和更優雅的 Redux。
簡單瞭解下FB官方Flux實現
React 是 MVC 裏面 V 的部分，那麼 Flux 就相當於添加 M 和 C 的部分。
一個 Flux 應用主要包含四個部分：
| 名稱 | 描述 |
|---|---|
| the dispatcher | 處理動作分發，維護 Store 之間的依賴關係 |
| the stores | 數據和邏輯部分 |
| the views | React 組件，這一層可以看作 controller-views，作爲視圖同時響應用戶交互 |
| the actions | 提供給 dispatcher 傳遞數據給 store |
針對上面提到的 Flux 這些概念，需要寫一個簡單的類庫來實現銜接這些功能，市面上有很多種實現，這裏簡單瞭解Facebook 官方的一個實現 Dispatcher.js
單向數據流
先來了解一下 Flux 的核心“單向數據流“怎麼運作的：
Action -> Dispatcher -> Store -> View
更多時候 View 會通過用戶交互觸發 Action，所以一個簡單完整的數據流類似這樣：
整個流程如下：
- 首先要有 action，通過定義一些 action creator 方法根據需要創建 Action 提供給 dispatcher
- View 層通過用戶交互（比如 onClick）會觸發 Action
- Dispatcher 會分發觸發的 Action 給所有註冊的 Store 的回調函數
- Store 回調函數根據接收的 Action 更新自身數據之後會觸發一個 change 事件通知 View 數據更改了
- View 會監聽這個 change 事件，拿到對應的新數據並調用 setState 更新組件 UI
所有的狀態都由 Store 來維護，通過 Action 傳遞數據，構成了如上所述的單向數據流循環，所以應用中的各部分分工就相當明確，高度解耦了。
這種單向數據流使得整個系統都是透明可預測的。
利用單向數據流的React應用程序體系結構:
React Native
React Native其實就是Native版的React，用javascript直接開發原生APP
React 在前端取得突破性成功以後，JavaScript 佈道者們開始試圖一統三端。移動平臺能夠運行 JavaScript 代碼，並且JavaScript不僅可以傳遞配置信息，還可以表達邏輯信息的優點。
於是2015年，Facebook推出了基於 JavaScript 的開源框架 React Native。
這是一個面向前端開發者的框架，它結合了 Web 應用和 Native 應用的優勢，在 JavaScript 中用 React 抽象操作系統原生的 UI 組件，代替 DOM 元素渲染，它的宗旨是讓前端開發者像用 React 寫網頁那樣，用 React Native 寫移動端應用。
不同於跨平臺語言的 Write once, Run anywhere!，React Native追求的是Learn once，Write anywhere!，希望前端開發者學習完 React 後，能夠用同樣的語法、工具等分別開發安卓和 iOS 平臺的應用，而不用再去學習兩個平臺不同的技術。
React Native 印象
當創建完React Native 工程後，app.js文件就是開發者的主要實現文件。
這是一個Hello world的React Native 程序中app.js的內容。
import React, { Component } from 'React';
import { AppRegistry, Text, View } from 'React-Native';
class Greeting extends Component {
render() {
return (
<Text>Hello {this.props.name}!</Text>
);
}
}
export default class LotsOfGreetings extends Component {
render() {
return (
<View style={{alignItems: 'center'}}>
<Greeting name='Rexxar' />
<Greeting name='Jaina' />
<Greeting name='Valeera' />
</View>
);
}
}
// skip this line if using Create React Native App
AppRegistry.registerComponent('AwesomeProject', () => LotsOfGreetings);
正如上面所介紹的React.js ，React Native 和前者十分類似，比如Props和State。
事實上，對於React-Native開發，僅僅有基礎前端開發的知識是不夠的，你還需要了解和掌握的有：
- Node.js的基礎
- JSX語法基礎
- Flexbox的佈局
- 一些iOS或android技術
React Native工作原理
因爲是用JavaScript來寫原生應用，所以要明確的是，即使使用了 React Native，我們依然需要 UIKit 等框架，最終執行的是 Objective-C 代碼。總React Native 只不過是以 JavaScript 的形式告訴 Objective-C 該執行什麼代碼。
所以React Native 能夠運行起來，全靠 Objective-C 和 JavaScript 的交互。
React Native用iOS自帶的JavaScriptCore作爲JS的解析引擎，但並沒有用到JavaScriptCore提供的一些可以讓JS與OC交互的特性，而是自己實現了一套機制，這套機制可以通用於所有JS引擎上。
React Native詳細設計比較複雜，這裏簡單瞭解下是如何調用原生代碼的。
####React Native如何匹配原生API
先看一下React Native啓動流程(iOS)
1.創建RCTRootView -> 設置窗口根控制器的View,把RN的View添加到窗口上顯示。
2.創建RCTBridge -> 橋接對象,管理JS和OC交互。
3.創建RCTBatchedBridge -> 批量橋架對象，JS和OC交互具體實現。
4.執行[RCTBatchedBridge loadSource] -> 加載JS源碼
5.執行[RCTBatchedBridge initModulesWithDispatchGroup] -> 創建OC模塊表
6.執行[RCTJSCExecutor injectJSONText] -> 往JS中插入OC模塊表
7.執行完JS代碼，回調OC，調用OC中的組件
8.完成UI渲染
可以知道React Native會在一開始生成OC模塊配置表，然後把這個模塊配置表傳入JS中。JS調用OC模塊方法時，通過配置表把模塊方法轉爲模塊ID和方法ID傳給OC，OC通過模塊配置表找到對應的方法執行之。
####通訊原理
下面我們簡單瞭解一下iOS端通訊的原理。
1.JS端調用某個OC模塊暴露出來的方法。
2.把上一步的調用分解爲ModuleName,MethodName,arguments，再扔給MessageQueue處理。
在初始化時模塊配置表上的每一個模塊都生成了對應的remoteModule對象，對象裏也生成了跟模塊配置表裏一一對應的方法，這些方法裏可以拿到自身的模塊名，方法名，並對callback進行一些處理，再移交給MessageQueue。
3.在這一步把JS的callback函數緩存在MessageQueue的一個成員變量裏，用CallbackID代表callback。在通過保存在MessageQueue的模塊配置表把上一步傳進來的ModuleName和MethodName轉爲ModuleID和MethodID。
4.把上述步驟得到的ModuleID,MethodId,CallbackID和其他參數argus傳給OC。把ModuleID,MethodID等數據加到一個隊列裏，等OC過來調JS的任意方法時，再把這個隊列返回給OC，此時OC再執行這個隊列裏要調用的方法。
5.OC接收到消息，通過模塊配置表拿到對應的模塊和方法。
6.RCTModuleMethod對JS傳過來的每一個參數進行處理。
RCTModuleMethod可以拿到OC要調用的目標方法的每個參數類型，處理JS類型到目標類型的轉換，所有JS傳過來的數字都是NSNumber，這裏會轉成對應的int/long/double等類型，更重要的是會爲block類型參數的生成一個block。參數組裝完畢後，通過NSInvocation動態調用相應的OC模塊方法。
7.OC模塊方法調用完，執行block回調。
8.調用到第6步說明的RCTModuleMethod生成的block。
9.block裏帶着CallbackID和block傳過來的參數去調JS裏MessageQueue的方法invokeCallbackAndReturnFlushedQueue。
10.MessageQueue通過CallbackID找到相應的JS callback方法。
11.調用callback方法，並把OC帶過來的參數一起傳過去，完成回調。
整個流程就是這樣，簡單概括下：JS函數調用轉ModuleID/MethodID -> callback轉CallbackID -> OC根據ID拿到方法 -> 處理參數 -> 調用OC方法 -> 回調CallbackID -> JS通過CallbackID拿到callback執行。
Weex和Vue.js
###Weex
Weex的官方網站
Weex 是阿里巴巴2016年6月開源的跨平臺開發方案。能以 web 的開發體驗構建高性能、可擴展的 native 應用，Weex 與 Vue 合作，使用 Vue 作爲上層框架，並遵循 W3C 標準實現了統一的 JSEngine 和 DOM API，可以使用其他框架驅動 Weex，打造三端一致的 native 應用。同React Native一樣，有人也將WEEX叫做Vue Native。
所以免不了被拿來同React Native“一決高下”的命運。React Native宣稱「Learn Once, Write Anywhere」，而Weex宣稱「Write Once, Run Everywhere」
對於推出該技術的原因，官方介紹如下
- 今天在技術社區有大量的 web 開發者，Weex 可以賦能更多的 web 開發者構建高性能和高體驗的移動應用。
- Web 開發本身具有非常強的高效率和靈活性，這和 Weex 想解決的移動端動態性問題不謀而合。
- Web 標準和開發體驗是很多頂尖而優秀的科技公司共同討論和建設的結果，本身的設計和理念都有極高的
- 品質保障，同時 Weex 也希望可以藉此機會努力爲標準貢獻一點自己的微薄之力。
- Web 是一種標準化的技術，標準本身就是一種力量，基於標準、尊重標準、貼近標準都意味着擁有更多的可能性。
- Web 今天的生態和社區是非常繁榮的，有很多成熟的工具、庫、工程體系、最佳實踐可以使用、引入和借鑑。
其特點是：
-
web 開發體驗在各端當中是相同的。包括語法設計和工程鏈路。
-
Weex 的組件、模塊設計都是 iOS、Android、Web 的開發者共同討論出來的，有一定的通用性和普遍性。
-
Weex 開發同一份代碼，可以在不同的端上分別執行，避免了多端的重複研發成本。
在同構這條路上，Weex比React Native做得更徹底，他“幾乎”做到了，“你來使用vue寫一個webapp，我順便給你編譯成了ios和android的原生app”
可以認爲WEEX其實是阿里巴巴團隊提高生產效率的產物，在淘寶這類要求多端統一迭代快速的部門，三端約定一種便於統一的規範，在加上時間的發酵，漸漸的就有了此類腳手架的雛形，同時在臉書ReactNative開源帶來的極大轟動後，也有KPI推動的嫌疑
原理
在 Weex 代碼中，您可以使用 <template>，<style> 和 <script> 標籤編寫頁面或組件，然後將它們轉換爲 JS bundle 以進行部署。當服務器返回給客戶端 JS bundle 時，JS bundle 會被客戶端的 JavaScript 引擎處理，並管理渲染 native 視圖，調用原生 API 和用戶交互。
###Vue.js
官網網站
Vue.js是一套用於構建用戶界面的漸進式框架。與其它大型框架不同的是，Vue 被設計爲可以自底向上逐層應用。
Vue 的核心庫只關注視圖層，不僅易於上手，還便於與第三方庫或既有項目整合。另一方面，當與現代化的工具鏈以及各種支持類庫結合使用時，Vue 也完全能夠爲複雜的單頁應用提供驅動。
Weex在迭代的過程中選擇了於Vue2.0握手，因爲該版本的Vue加入了 Virtual-DOM 和預編譯器的設計，使得該框架在運行時能夠脫離 HTML 和 CSS 解析，只依賴 JavaScript，Vue在和WEEX合作後，便獲得了使用JS預編譯原生的組件UI的能力。
和React.js的異同
1.Vue使用模板
Vue應用的默認選項是把markup放在HTML文件中。數據綁定表達式採用的是和Angular相似的mustache語法，而指令（特殊的HTML屬性）用來向模板添加功能。
相比之下，React應用不使用模板，它要求開發者藉助JSX在JavaScript中創建DOM。
對於來自標準Web開發方式的新開發者，模板更容易理解。但是一些資深開發者也喜歡模板，因爲模板可以更好的把佈局和功能分割開來，還可以使用Pug之類的模板引擎。
但是使用模板的代價是不得不學習所有的HTML擴展語法，而渲染函數只需要會標準的HTML和JavaScript。而且比起模板，渲染函數更加容易調試和測試。不過在Vue2.0中提供了使用模板或者渲染函數的選項。
2.Vue相對簡單和易用
一個簡單的Vue項目可以不需要轉譯直接運行在瀏覽器中，所以使用Vue可以像使用jQuery一樣簡單。當然這對於React來說在技術上也是可行的，但是典型的React代碼是重度依賴於JSX和諸如class之類的ES6特性的。
Vue的簡單在程序設計的時候體現更深，
React中是通過比較當前state和前一個state來決定何時在DOM中進行重渲染以及渲染的內容，因此需要不可變（immutable）的state。
Vue中的數據是可變（mutated）的，所以同樣的操作看起來更加簡潔。
3.Vue更加輕量級
當應用程序的狀態改變時，React和Vue都將構建一個虛擬DOM並同步到真實DOM中。 兩者都有各自的方法優化這個過程。
Vue的渲染系統比React的更快。
頁面大小方面Vue再次領先，實現同樣的功能，目前的版本壓縮後只有25.6KB。React需要React DOM（37.4KB）和React with Addon庫（11.4KB），共計44.8KB，幾乎是Vue的兩倍大。雙倍的體積並不能帶來雙倍的功能。
4.React更適合大型應用
因爲基於模板的應用程序第一眼看上去更加好理解，而且能很快跑起來。但是這些好處會阻礙應用擴展到更大的規模。模板容易出現比較難注意到的運行時錯誤，同時也很難去測試，重構和分解。
相比之下，Javascript模板可以組織成具有很好的分解性和代碼組件，組件的可重用性和可測試性更好。Vue也有組件系統和渲染函數，但是React的渲染系統可配置性更強，還有諸如淺（shallow）渲染的特性，和React的測試工具結合起來使用，使代碼的可測試性和可維護性更好。
React的immutable應用狀態可能寫起來不夠簡潔，但它在大型應用中意義非凡，因爲透明度和可測試性在大型項目中變得至關重要。
5.React 生態系統更加成熟完善
React是目前最受歡迎的前端框架。它在NPM上每個月的下載量遠超過Vue。相比Vue有更多的文章，教程和更多Stack Overflow的解答，同事還有更多的工具和插件可以在項目中使用。
這兩個框架都是開源的，但是React誕生於Facebook，Facebook承諾會持續維護React。相比之下，Vue是獨立開發者尤雨溪的作品，也有一些公司資助Vue，但是規模和Facebook有些距離。
React Native、Weex和Cordova對比
跨平臺特性
Cordova > React Native（Weex） > Native
| 名稱 | 跨平臺特性 | 描述 |
|---|---|---|
| Cordova | 基本覆蓋主流移動平臺：write once,run any where。 | 不涉及系統級開發的,基本是一次開發 處處運行，如果涉及到系統級設備調用以及項目配置（如 iOS的 plist文件），同時平臺上也沒有滿足需求的插件，則需要自己手動編寫Cordova插件 |
| React Native | 可以用JS編寫iOS和android。Learn once, write anywhere。 | 統一用JS進行各端開發，但是需要針對iOS 和 android 開發兩套代碼。同時複雜實現仍然需要Native混編 |
| Weex | 可以用JS編寫iOS和android。Write Once, Run Everywhere。 | 統一用JS進行各端開發，雜實現仍然需要Native混編 |
| Native | 無法跨平臺 | - |
開發方式
| 名稱 | 開發方式 | 描述 |
|---|---|---|
| Cordova | html + angularjs + css | 與網頁開發類似，但是基本上都會使用H5框架（比如ionic），一般系統調用可以使用插件解決，特定需求需要編寫原生代碼插件 |
| React Native | React + css | 簡單UI全程使用JS開發，部分情況下需要使用與Native混合的方式,可以用flexbox佈局 沒有統一的UI組件，iOS組件較多，android組件較少。 需要各自編寫JS文件的情況較多，簡單空間和邏輯層可以共用，基本上iOS和android是兩套代碼。 |
| Weex | Vue.js 或 Rax 、CSS | Vue.js 或 Rax編寫UI，可以用flexbox佈局，大部分代碼可複用 |
| Native | java + oc或swift | 不同語言開發 以及適配。 |
###功能支持
| 名稱 | 功能支持 | 描述 |
|---|---|---|
| Cordova | 編寫Cordova插件可達到全部支持 | UI交互 由Web實現，系統級的交互由插件實現，基本涵蓋了大部分系統功能，如攝像頭，設備信息，電池，網絡等，不排除潛在不支持的問題 |
| React Native | 與Native 混編 可達到全部支持 | android高級組件可能需要自己實現，系統級的功能可通過安裝第三方插件或者與Native混編的方式實現 ，基本上可以完全實現 |
| Weex | 與Native 混編 部分支持 | 生態環境有待改善，與原生交互較複雜 |
| Native | 全部支持 | 完全能實現 |
###性能對比
Native > React Native(Weex) > Cordova
| 名稱 | 功能支持 | 描述 |
|---|---|---|
| Cordova | 本質上還是網頁，所以三者之中性能最差，在iOS上體驗不錯 | 由於各平臺的webView引擎不同，所以體驗有差異，android問題較突出。可以添加crosswalk插件優化體驗，但是會導致app打包偏大。程序運行內存佔用較大 |
| React Native | 接近原生性能 | JS 到 Native 需要經過兩層橋接，性能與原生差別不大 |
| Weex | 接近原生性能 | 渲染略優於React Native |
| Native | 性能最好 | 在原生環境有多種優化方式，達到最佳性能 |
###優劣對比 | 名稱 | 優勢 |劣勢| | ------------- |--------------------------------|-------------| | Cordova |1、iOS 和 android 基本上可以共用代碼，純web思維，開發速度快，簡單方便，一次編碼，到處運行，如果熟悉web開發，則開發難度較低。
2、文檔很全，系統級支持封裝較好。H5框架UI組件可以統一使用。
3、可實現在線更新 允許加載動態加載web JS| 1、性能相對較差，內存佔用高，開發插件難度較大。
2、web技術無法解決一切問題，對於比較耗性能的地方無法利用Native的思維實現優勢互補，如高體驗的交互，動畫等。| | React Native |1、雖然不能做到一處編碼到處運行，但是基本上即使是兩套代碼，也是相同的JSx語法，使用JS進行開發。
2、用戶體驗高於html，貼近原生開發。開發效率較高
3、flexbox 佈局,宣稱比Native的自適應佈局更加簡單高效
4、可實現在線更新 | 1、對開發人員要求較高，僅會web技術搞不定，僅會Native更搞不定。當官方封裝的控件、api無法滿足需求時 就必然需要Native去擴展，擴展性仍然遠遠不如web，也遠遠不如直接寫Native code。
2、官方聲稱：learn once, write anywhere，並不是run anywhere。事實上針對不同的平臺會需要寫多套代碼，目前官方的api來看有SliderIOS，SwitchIOS..等控件，之後勢必會出現SliderAndroid，SwitchAndroid..
3、學習曲線偏高| | Weex |1、輕量級，上手容易，vue更接近常用的web開發方式
2、SDK接入的形式，不需要複雜的開發環境
3、可以選擇使用Vue.js 或 Rax
4、學習成本比React Native 低|1、生態環境、社區比活躍不高， 插件不如React Native豐富
2、目前阿里系的使用場景最多，出發點在於針對阿里系的優化，真正使用場景有待驗證
3、開源管理一般，官網甚至有打不開的網頁，有KPI項目 半途而廢的隱患 | | Native| 最好的體驗以及功能實現。完善成熟的開發文檔以及demo。|學習成本高。需要兩個團隊分開開發 很難有iOS,android雙平臺高手。|
###更新 & 維護
| 名稱 | 優勢 | 劣勢 |
|---|---|---|
| Cordova | 隨時更新，適合做營銷頁面，但是重要的部分還是Native。 | Web代碼 ＋ iOS/Android平臺支持 |
| React Native | React Native部分可以熱更新，bug及時修復，業務組件顆粒度小，不用把握全局即可修改業務代碼 | 需要一個開發團隊，前端 ＋ iOS/Android工程師 |
| Weex | 熱更新方便 | 仍然需要前端＋ iOS/Android工程師配合 |
| Native | 隨版本更新，尤其iOS審覈嚴格，需要測試過關，否則影響用戶。 | iOS/Android開發週期長，兩個開發團隊。 |
###使用的APP
Cordova
React Native
使用React Native 的知名APP
React Native 開源APP
Weex
應用
###目前技術儲備
| 名稱 | 前端 | 移動端 |
|---|---|---|
| iOS | × | ○ |
| android | × | ○ |
| Node.js | × | × |
| Angular.js | ○ | × |
| Weex | × | × |
| Vue.js | ○ | × |
| JSX | ○ | × |
| Rax | × | × |
| React.js | × | × |
| Flex (Flexible Box) | × | × |
現在支付APP
APP中的展示頁面比較合適使用Cordova或者React Native 來實現。不過目前APP已經上線穩定運行，React Native 學習成本較高，如果有新的規劃，偏展示的頁面可以考慮嵌入Cordova模塊。
支付插件
由於支付插件已經取消了網關頁面，且在iOS開發中Apple禁止SDK中使用JS動態更新，出於安全考慮 React Native 和Cordova沒有太多使用場景。
不過由於不少Hybrid APP都在使用Cordova,所以可以開發現在支付插件的Cordova插件。
web
React.js 2013年5月開源，作爲Facebook大量應用和推廣的技術，在github上已經收穫了80000+ star。Facebook也承諾會持續投入成本維護該技術，經過4年多的發展已經是十分成熟的JS庫，擁有大量的開發者和豐富的資料。在web項目中十分值得推廣。