H5、React Native、Native應用對比分析
H5、React Native、Native應用對比分析
離上次在北京開源中國盛典已經快一個月了，有點想念@oschina的小伙伴了。我必須承認oschina是國內最大的同性社交網站，這也是無可爭議的事實，但是，我真想的是妹子！！！［偷笑］。從上次演講后，有一些同學陸陸續續問我演講的PPT在哪，還有不少同學希望看到［手稿］，這學習精神，在下實在是佩服啊。有著這么熱情的小伙伴，我激動不已啊，所以在此公布［手稿］，方便大家可以將［PPT］和［手稿］雙手齊下，：）。2015年，我們要一起努力完成以前吹過的牛逼..... 下面是［多圖預警］，請考慮切wifi，土豪請無視我，也可拿紅包砸我，：）
－－－－－－－－－－－－－－－華麗麗的分割線，主題開始－－－－－－－－－－－－－－－－－－－－－
“存在即合理”。凡是存在的，都是合乎規律的。任何新事物的產生總要的它的道理；任何新事物的發展總是有著取代舊事物的能力。React Native來的正是時候，一則是因為H5發展到一定程度的受限；二則是移動市場的迅速崛起強調團隊快速響應和迭代；三則是用戶的體驗被放大，用戶要求極致的快感，除非你牛x（例如：12306最近修改手機號需要用戶自己發短信接收驗證碼）。
以下簡單的介紹下H5、React Native、Native的含義：
最近三四年間，國內外的前端與全棧開發者社區都在堅持不懈地追尋使用JavaScript與HTML、CSS技術體系開發App內場景的核心工程技術。這種技術，在國內很多公司與團隊中，被通稱為H5。——童遙
這段是取自@童老師給小二我新書作的序，沒有斷章取義的意思。很清楚，H5并不是狹義的HTML5新標簽和API，而是工程化的“In App” technology。
iOS/Android ——原生應用（都懂得，不解釋）。
React Native —— React & Native ，應運而生！
一、React Native的出現
React Native的出現，似乎是扛起的反H5的旗子。就像當年非死book放棄H5，全部轉向Native一樣。這一點，我們需要認同和保持高度的清醒。那么，React Native是否又是在吞食Native的領地呢？技術的發展，是用戶風向標的導向起的作用。任何一門技術的出現，都是當時用戶需求的體現。
我們應該從以下幾點看待React Native的出現。
"鑒往知來"——從過去的教訓中總結經驗，從用戶的角度開拓未來，用戶更希望產品迭代和穩定尋求一種平衡
“HTML5差強人意，但是與原生應用相比還是有些差距”——為了更高的追求！ 用戶體驗！
“人才寶貴，快速迭代”——Web開發者相對較多，尋找平衡點
“跨平臺！跨平臺！跨平臺！”——單一技術棧，開發者的福音
“xx是世界上最好的語言” ——工程學的范疇，沒有最好，只有最適合，我還是補充一句，JS還是很好很好的。
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組件。這就是React Native相比H5更高效的原因。
（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];
總結：React Native封裝的導航控制更容易理解。
（5）第三方生態鏈
“我的是我的，你的也是我的。 ”——我不是“瘋狂女友”，我是React Native！
我們缺少“城市列表”組件，OK，使用JSX封裝一個；覺得性能太低，OK，基于React Native方案封裝一個原生組件。
這個iOS圖表庫不錯，拿來用唄！ => 完美！
這一切都是基于React Native提供的模塊擴展方案。
所以說：iOS第三方庫 + 部分JavaScript庫 ＝ React Native 生態庫（可以知道，基于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有些大；但是具備跨平臺能力和熱更新能力。
說了這么多，最后個人建議：
一個新的App完全可以采用React Native開發，這樣成本會低很多。
關于演講：
PPT: http://www.oschina.net/doc/24007
視頻：http://www.oschina.net/question/865233_2145334 （這個演講在移動專場下半場開場）
六、圖書 & 工作機會
最后說一下圖書《React Native入門與實戰》吧。這是一本［難產］的家伙，15年寫的比較順利，最后因為北京霧霾，印刷廠偶爾停工，一直在難產。前段時間，圖書發往各地書店，到店比較遲，我猜測是因為霧霾，找不到高速出口～～目前該書由人民郵電出版社圖靈原創出版，已經開賣了。本書主要是希望帶領大家一起進入React Native開發領域，針對每個API和組件都有詳細的案例，同時為了更好的實戰，最后3章以實際案例（通訊錄App，LBS App，基于豆瓣OpenAPI的搜索 App）給出，供大家參考。覺得入門是完全沒問題的，后期大家可以一起交流，爭取豐富國內React Native社區。
《React Native入門與實戰》各網站購買地址：
京東：http://item.jd.com/10089810271.html (目前應該都有貨了，微信有同學傳照片給我看了，鐵粉哈)
http://item.jd.com/11844102.html (京東自營，貨源需要跟客服確認哦)
互動：http://product.china-pub.com/4904552 (已經有貨)
天貓：https://detail.tmall.com/item.htm?spm=a220m.1000858.1000725.21.rc0yeu&id=525484671101&cat_id=2&rn=4690ef5b4e06412ffae4d1cc4f4dcc9a&user_id=1020536390&is_b=1 (天貓這家賣的還可以，不知道為啥京東看不到數據，京東應該才是技術買書的最愛啊，聽說也預售了不少呢)
［工作機會］
說了這么多了，都晚上11點30了，困，最近離公司遠啊；對了，有需要考慮上海工作機會的同學可以聯系我，前端、H5、Node.js等都要，Android、java都可以推薦哦。目前負責前端團隊，具體問題的可以郵件(wlhmyit@126.com)或者私信給我。以后可以一起裝逼一起擼代碼。