@王利華，vczero
“存在即合理”。凡是存在的，都是合乎規律的。任何新事物的產生總要的它的道理；任何新事物的發展總是有着取代舊事物的能力。React
Native來的正是時候，一則是因爲H5發展到一定程度的受限；二則是移動市場的迅速崛起強調團隊快速響應和迭代；三則是用戶的體驗被放大，用戶要求極致的快感，除非你牛x（例如：12306最近修改手機號需要用戶自己發短信接收驗證碼）。
以下簡單的介紹下H5、React Native、Native的含義：
最近三四年間，國內外的前端與全棧開發者社區都在堅持不懈地追尋使用JavaScript與HTML、CSS技術體系開發App內場景的核心工程技術。這種技術，在國內很多公司與團隊中，被通稱爲H5。——童遙
這段是取自童老師給小二我新書作的序，沒有斷章取義的意思。很清楚，H5並不是狹義的HTML5新標籤和API，而是工程化的“In App” technology。
React Native —— React & Native ，應運而生！
一、React Native的出現
React Native的出現，似乎是扛起的反H5的旗子。就像當年Facebook放棄H5，全部轉向Native一樣。這一點，我們需要認同和保持高度的清醒。那麼，React Native是否又是在吞食Native的領地呢？技術的發展，是用戶風向標的導向起的作用。任何一門技術的出現，都是當時用戶需求的體現。
我們應該從以下幾點看待React Native的出現。
"鑑往知來"——從過去的教訓中總結經驗，從用戶的角度開拓未來
“Html5差強人意，但是與原生應用相比還是有些差距”——爲了更高的追求！ 用戶體驗！
“人才寶貴，快速迭代”——Web開發者相對較多，尋找平衡點
“跨平臺！跨平臺！跨平臺！”——單一技術棧
“xx是世界上最好的語言” ——工程學的範疇，沒有最好，只有最適合
HTML5 vs React Native ? HTML5 : React Native
結論（React Native）：
1、原生應用的用戶體驗
2、跨平臺特性
3、開發人員單一技術棧
4、上手快，入門容易
5、社區繁榮
二、3款應用效果
注：以下所有對比均在iOS平臺下
上面3張圖片，如果去掉第一張圖的“HybirdApp”的字樣，是否分得清哪個是React Native開發？哪個是Native應用。
你的第一感覺是什麼？
三、工程方案
爲了評估3種方案的技術優勢和弱勢。我們需要開發功能大致相似的App。這裏，我們使用了“豆瓣”的API來開發“豆搜”應用。該應用能夠搜索“圖書”、“音樂”、“電影”。想當年，豆瓣以“圖書評論”走紅，尤其是12年當紅！豆瓣是一個清新文藝的社區，一個“慢公司”。最近有一則網傳消息，注意是網傳——“傳京東投1.5億美元控股豆瓣”。今天，不聊豆瓣，我們要聊一個工程化的問題。
我們需要將3款App的功能做到一致，同時需要保持技術要點一致。比如React Native這裏使用了TabBar，那麼Native我們也必須使用TabBar。簡單而言就是：功能一致，組件 & API一致。我們功能如下圖所示：
1、H5方案
在H5/Hybird應用中，我們使用AngularJS開發單頁webApp，然後將該WebApp內嵌入到iOS WebView中，在iOS代碼中，我們使用Navigation稍微控制下跳轉。
WebApp地址：http://vczero.github.io/search/html/index.html
WebApp項目地址：https://github.com/vczero/search （很簡單的一個項目）
H5/Hybird項目地址：https://github.com/vczero/search_Hybird
2、React Native
在React Native中，封裝必要的功能組件。
項目地址：https://github.com/vczero/React-Dou。
項目結構如下圖：
3、Native(iOS)
使用React Native大致相同的組件開發App，不使用任何第三方庫，代碼佈局。
項目地址：https://github.com/vczero/iOS-Dou
四、對比分析
很多時候，新技術的採用最希望看到的是數據，而不是簡單說“用戶體驗棒，開發效率高，維護成本低”。不過，生活中也有這樣的同學，知一二而能窺全貌。當然，本人生性膽小，也沒有那麼多的表哥和隔壁的老王，所以不敢早下定論，不敢太放肆。趙本山在《大笑江湖》中有句名言“May the force be with you”（別太放肆,沒什麼用）。因此，從以下幾個方面做一個簡單的對比。
－－－－－－－－－－提綱－－－－－－－－－－－－
1、開發方式
（1）代碼結構
（2）UI佈局
（3）UI截面圖
（4）路由／Navigation
（5）第三方生態鏈
2、性能 & 體驗
（1）內存
（2）CPU
（3）動畫
（4）安裝包體積
（5）Big ListView
（6）真機體驗
3、更新 & 維護
（1）更新能力
（2）維護成本
－－－－－－－－－－提綱－－－－－－－－－－－－
1、開發方式
很多人說React Native的代碼不好看，不好理解。那是因爲前端工程師都熟悉了Web的開發方式。怎麼解決這個問題呢，可以先看看iOS代碼，斷定不熟悉iOS的同學心裏會默唸“一萬匹**馬奔騰”。那時候，你再看React Native，你會覺得使用React Native開發App是件多麼美好的事！OK，我們先來看下三者在開始“一款簡單App”的代碼結構。
（1）代碼結構
H5/Hybird的開發模式，我們需要維護3套代碼，兩套是Native（iOS/Android）代碼，一套是WebApp版本。這裏，我們使用AngularJS作爲WebApp單頁開發框架。如下圖所示。
在React Native中，同樣需要關注部分的Native代碼，但是大部分還是前端熟悉的JavaScript。在“豆搜”應用中，代碼結構如下：
在Native開發中，更加強調Native開發者的能力。平臺是：iOS/Android。
結論：從前端角度而言，React Native跨平臺特性，不要開發者深入的瞭解各平臺就能開發一款高效App。同時，語言層面而言，JavaScript運用很廣泛，入門門檻相對較低。React Native雖然拋棄了MVC分離實踐，但是從業務角度而言，更爲合理。一切而言：對前端，對移動領域是利好的消息。
（2）UI佈局
“面容姣好”，合理的UI卻總是跟着時間在變。那麼UI佈局就不是小事。
Web開發佈局目前大多是 DIV + CSS。
React Native的佈局方式是Flexbox。
//JSX
<ScrollView style={styles.flex_1}>
<View style={[styles.search, styles.row]}>
<View style={styles.flex_1}>
<Search placeholder="請輸入圖書的名稱" onChangeText={this._changeText}/>
</View>
<TouchableOpacity style={styles.btn} onPress={this._search}>
<Text style={styles.fontFFF}>搜索</Text>
</TouchableOpacity>
</View>
{
this.state.show ?
<ListView
dataSource={this.state.dataSource}
renderRow={this._renderRow}
/>
: Util.loading
}
</ScrollView>
//樣式
var styles = StyleSheet.create({
flex_1:{
flex:1,
marginTop:5
},
search:{
paddingLeft:5,
paddingRight:5,
height:45
},
btn:{
width:50,
backgroundColor:'#0091FF',
justifyContent:'center',
alignItems:'center'
},
fontFFF:{
color:'#fff'
},
row:{
flexDirection:'row'
}
}); 而Native佈局就有種讓你想吐的感覺，尤其是iOS的佈局。這裏不是指採用xib或者Storyboard，而是單純的代碼，例如添加一個文本：
UILabel *publisher = [[UILabel alloc]init];
publisher.frame = CGRectMake(bookImgWidth + 10, 50, 200, 30);
publisher.textColor = [UIColor colorWithRed:0.400 green:0.400 blue:0.435 alpha:1];
publisher.font = [UIFont fontWithName:@"Heiti TC" size:13];
publisher.text = obj[@"publisher"];
[item addSubview:publisher];
總結：React Native既綜合了Web佈局的優勢，採用了FlexBox和JSX，又使用了Native原生組件。比如我們使用一個文本組件。<Text style={{width:100;height:30;backgroundColor:'red'}}>測試</Text>
（3）UI截面圖
Hybrid方式截面圖
可以看到第一層列表頁是完整的佈局，實際上這就是Web頁面；而第二層灰色的是Native的WebView組件。
iOS UI截面圖
可以看到Native頁面的組件特別多，即使是列表頁，其中某一項都是一個組件（控件）。
當然，我們就會想，能夠完全調用原生組件呢？那樣性能是否更好？
React Native UI截面圖
可以清楚的看到React Native調用的全部是Native組件。並且層次更深，因爲React Native做了組件的封裝。如上圖，藍色邊框的就是RCTScrollView組件。
（4）路由／Navigation
在Web單頁面應用中，路由由History API實現。
而React Native採用的路由是原生的UINavigationController導航控制器實現。
React Native NavigatorIOS組件封裝程度高；Navigator可定製化程度高。
Navigator方法如下：
getCurrentRoutes() - returns the current list of routes
jumpBack() - Jump backward without unmounting the current scene
jumpForward() - Jump forward to the next scene in the route stack
jumpTo(route) - Transition to an existing scene without unmounting
push(route) - Navigate forward to a new scene, squashing any scenes that you could jumpForward to
pop() - Transition back and unmount the current scene
replace(route) - Replace the current scene with a new route
replaceAtIndex(route, index) - Replace a scene as specified by an index
replacePrevious(route) - Replace the previous scene
immediatelyResetRouteStack(routeStack) - Reset every scene with an array of routes
popToRoute(route) - Pop to a particular scene, as specified by its route. All scenes after it will be unmounted
popToTop() - Pop to the first scene in the stack, unmounting every other scene 相對Native而言，這些接口更Native還是很相似的。
//iOS UINavigationController
//相對Web而言，不用自己去實現路由，並且路由更加清晰
[self.navigationController pushViewController:detail animated:YES];
"豆搜" WebApp路由（基於AngularJS）如下：
"豆搜" React Native版本導航如下：
"豆搜" iOS版本導航代碼如下：
總結：React Native封裝的導航控制更容易理解。
（5）第三方生態鏈
“我的是我的，你的也是我的。 ”——我不是“瘋狂女友”，我是React Native！
我們缺少“城市列表”組件，OK，使用JSX封裝一個；覺得性能太低，OK，基於React Native方案封裝一個原生組件。
這個iOS圖表庫不錯，拿來用唄！ => 完美！
這一切都是基於React Native提供的模塊擴展方案。
所以說：iOS第三方庫 + 部分JavaScript庫 ＝ React Native 生態庫
2、性能 & 體驗
我們都很關注一款App性能。因此測試和體驗App的性能很重要。以下測試，都是基於相同的case。
測試平臺：模擬器，iphone6，iOS8.4
（1）內存
首先，我們來看下Native應用佔用的內存情況。一開始，原生應用啓動後，佔用內存是20~25M；針對相同的case，跑了2min，結果如下圖：
可以看出，峯值是87.9M，均值是72M；內存釋放比較及時。
我們再來看下Hybird App的情況。App已啓動，佔用內存35~55M;同樣，跑了2min以上，結果如下圖：
可以看出，峯值在137.9M，因爲整個應用在WebView中，內存釋放不明顯，存在緩存。
最後，看下React Native的情況。App啓動佔用內存35～60M，同樣跑2min以上，結果如下圖：
可以看出，峯值在142M，內存相對釋放明顯。
總結：React Native和Web View在簡單App上相差不大。二者主要：內存消耗主要是在網頁數據上。
（2）CPU
我們可以看一下Native應用程序CPU的情況，最高值在41%。
Hybird App的最高值在30%。
React Native的最高值在34%。
總結：CPU使用率大體相近，React Native的佔用率低於Native。
（3）動畫
React Native提供了Animated API實現動畫。簡單效果，基本OK。個人覺得React Native不適合做遊戲，尤其佈局能力。
Native Animation提供UIView動畫
H5/Hybird：採用js動畫能力
總結：React Native Animated API / 封裝Native動畫庫 可以滿足基本需求
（4）安裝包體積
Hybird App:
34(App殼) + 5(HTML) + 125(Angular) + 29(An-route) + 6(min.js) + 4(min.css) = 203 KB。
React Native:
不含bundle: 843KB
含bundle: 995KB
Native
83KB
React Native框架包大小
843(不含bundle) – 32(Hybird_app空殼，初識項目) = 811KB
相比快速迭代和熱更新，比Native多了811KB一點都不重要，我們將圖片素材、靜態資源線上更新緩存起來即可減少很多體積。
總結：犧牲一點體積，換更大的靈活性！（世界上哪有那麼美的事，除非醜，就會想得美，:) ）。
（5）Big ListView & Scroll 性能
循環列表項500次: H5頁面慘不忍睹
React Native還可以接受
Native 採用UITabView更高效，因爲不渲染視圖外部分。
（6）真機體驗
機型：iphone4s，iOS7
Native > React Native > Hybird
如果非要給個數字的話，那我個人主觀感受是：
Native： 95％＋ 流暢度
React Native: 85~90% 流暢度
H5/Hybird： 70% 流暢度
總結：Native／React Native的體驗相對而言更流暢。
3、更新 & 維護
（1）更新能力
H5/Hybird： 隨時更新，適合做營銷頁面，目前攜程一些BU全部都是H5頁面；但是重要的部分還是Native。
React Native：React Native部分可以熱更新，bug及時修復。
Native：隨版本更新，尤其iOS審覈嚴格，需要測試過關，否則影響用戶。
（2）維護成本
H5/Hybird： Web代碼 ＋ iOS/Android平臺支持
React Native：可以一個開發團隊 ＋ iOS/Android工程師；業務組件顆粒度小，不用把握全局即可修改業務代碼。
Native：iOS/Android開發週期長，兩個開發團隊。
總結：React Native 統一了開發人員技術棧，代碼維護相對容易。
五、綜合
1、開發方式
（1）代碼結構： React Native更爲合理，組件化程度高
（2）UI佈局：Web佈局靈活度 > React Native > Native
（3）UI截面圖：React Native使用的是原生組件，
（4）路由／Navigation：React Native & Native更勝一籌
（5）第三方生態鏈：Native modules + js modules = React Native modules
2、性能 & 體驗
（1）內存：Native最少；因爲React Native含有框架，所以相對較高，但是後期平穩後會優於Native。
（2）CPU：React Native居中。
（3）動畫：React Native動畫需求基本滿足。
（4）安裝包體積：React Native框架打包後，811KB。相比熱更新，可以忽略和考慮資源規劃。
（5）Big ListView
（6）真機體驗：Native >= React Native > H5/Hybrid
3、更新 & 維護
（1）更新能力: H5/Hybird > React Native > Native
（2）維護成本: H5/Hybird <= React Native < Native
React Native定製難度相比Native有些大；但是具備跨平臺能力和熱更新能力。