H五、React Native、Native應用對比分析

時間 2019-11-12

原文原文鏈接

摘要 2015年是React Native發展的一年，2016年一定是React Native蓬勃的一年！2016年React Native極可能成爲最爲成功的開源技術之一。爲何React Native這麼火呢？那麼React Native相比H五、Native又有哪些優點呢？使用React Native的正確姿式又是怎樣呢？javascript

React Native React h5 《React Native入門與實戰》

目錄[-]css

H五、React Native、Native應用對比分析

離上次在北京開源中國盛典已經快一個月了，有點想念@oschina的小夥伴了。我必須認可oschina是國內最大的同性社交網站，這也是無可爭議的事實，可是，我真想的是妹子！！！［偷笑］。從上次演講後，有一些同窗陸陸續續問我演講的PPT在哪，還有很多同窗但願看到［手稿］，這學習精神，在下實在是佩服啊。有着這麼熱情的小夥伴，我激動不已啊，因此在此公佈［手稿］，方便你們能夠將［PPT］和［手稿］雙手齊下，：）。2015年，咱們要一塊兒努力完成之前吹過的牛逼..... 下面是［多圖預警］，請考慮切wifi，土豪請無視我，也可拿紅包砸我，：） html

－－－－－－－－－－－－－－－華麗麗的分割線，主題開始－－－－－－－－－－－－－－－－－－－－－前端

「存在即合理」。凡是存在的，都是合乎規律的。任何新事物的產生總要的它的道理；任何新事物的發展老是有着取代舊事物的能力。React Native來的正是時候，一則是由於H5發展到必定程度的受限；二則是移動市場的迅速崛起強調團隊快速響應和迭代；三則是用戶的體驗被放大，用戶要求極致的快感，除非你牛x（例如：12306最近修改手機號須要用戶本身發短信接收驗證碼）。html5

如下簡單的介紹下H五、React Native、Native的含義：java

最近三四年間，國內外的前端與全棧開發者社區都在堅持不懈地追尋使用JavaScript與HTML、CSS技術體系開發App內場景的核心工程技術。這種技術，在國內不少公司與團隊中，被通稱爲H5。——童遙react

這段是取自@童老師給小二我新書做的序，沒有斷章取義的意思。很清楚，H5並非狹義的HTML5新標籤和API，而是工程化的「In App」 technology。android

iOS/Android ——原生應用（都懂得，不解釋）。ios

React Native —— React & Native ，應運而生！git

1、React Native的出現

React Native的出現，彷佛是扛起的反H5的旗子。就像當年Facebook放棄H5，所有轉向Native同樣。這一點，咱們須要認同和保持高度的清醒。那麼，React Native是否又是在吞食Native的領地呢？技術的發展，是用戶風向標的導向起的做用。任何一門技術的出現，都是當時用戶需求的體現。

咱們應該從如下幾點看待React Native的出現。

"鑑往知來"——從過去的教訓中總結經驗，從用戶的角度開拓將來，用戶更但願產品迭代和穩定尋求一種平衡
「Html5差強人意，可是與原生應用相比仍是有些差距」——爲了更高的追求！用戶體驗！
「人才寶貴，快速迭代」——Web開發者相對較多，尋找平衡點
「跨平臺！跨平臺！跨平臺！」——單一技術棧，開發者的福音
「xx是世界上最好的語言」 ——工程學的範疇，沒有最好，只有最適合，我仍是補充一句，JS仍是很好很好的。

HTML5 vs React Native ? HTML5 : React Native
結論（React Native）：
一、原生應用的用戶體驗
二、跨平臺特性
三、開發人員單一技術棧
四、上手快，入門容易
五、社區繁榮

2、3款應用效果

注：如下全部對比均在iOS平臺下



上面3張圖片，若是去掉第一張圖的「HybirdApp」的字樣，是否分得清哪一個是React Native開發？哪一個是Native應用。
你的第一感受是什麼？

3、工程方案

爲了評估3種方案的技術優點和弱勢。咱們須要開發功能大體類似的App。這裏，咱們使用了「豆瓣」的API來開發「豆搜」應用。該應用可以搜索「圖書」、「音樂」、「電影」。想當年，豆瓣以「圖書評論」走紅，尤爲是12年當紅！豆瓣是一個清新文藝的社區，一個「慢公司」。最近有一則網傳消息，注意是網傳——「傳京東投1.5億美圓控股豆瓣」。今天，不聊豆瓣，咱們要聊一個工程化的問題。

咱們須要將3款App的功能作到一致，同時須要保持技術要點一致。好比React Native這裏使用了TabBar，那麼Native咱們也必須使用TabBar。簡單而言就是：功能一致，組件 & API一致。咱們功能以下圖所示：

一、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

二、React Native
在React Native中，封裝必要的功能組件。
項目地址：https://github.com/vczero/React-Dou。
項目結構以下圖：

三、Native(iOS)
使用React Native大體相同的組件開發App，不使用任何第三方庫，代碼佈局。
項目地址：https://github.com/vczero/iOS-Dou

4、對比分析

不少時候，新技術的採用最但願看到的是數據，而不是簡單說「用戶體驗棒，開發效率高，維護成本低」。不過，生活中也有這樣的同窗，知一二而能窺全貌。固然，本人生性膽小，也沒有那麼多的表哥和隔壁的老王，因此不敢早下定論，不敢太放肆。趙本山在《大笑江湖》中有句名言「May the force be with you」（別太放肆,沒什麼用）。所以，從如下幾個方面作一個簡單的對比。

－－－－－－－－－－－－－－－分析提綱－－－－－－－－－－－－－－－－

一、開發方式

（1）代碼結構
（2）UI佈局
（3）UI截面圖
（4）路由／Navigation
（5）第三方生態鏈

二、性能 & 體驗

（1）內存
（2）CPU
（3）動畫
（4）安裝包體積
（5）Big ListView
（6）真機體驗

三、更新 & 維護

（1）更新能力
（2）維護成本
－－－－－－－－－－－－－－－－－提綱－－－－－－－－－－－－－－－

一、開發方式

不少人說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];

"豆搜" WebApp路由（基於AngularJS）以下：

"豆搜" React Native版本導航以下：

"豆搜" iOS版本導航代碼以下：

總結：React Native封裝的導航控制更容易理解。

（5）第三方生態鏈
「個人是個人，你的也是個人。」——我不是「瘋狂女朋友」，我是React Native！
咱們缺乏「城市列表」組件，OK，使用JSX封裝一個；以爲性能過低，OK，基於React Native方案封裝一個原生組件。
這個iOS圖表庫不錯，拿來用唄！ => 完美！
這一切都是基於React Native提供的模塊擴展方案。
因此說：iOS第三方庫 + 部分JavaScript庫＝ React Native 生態庫（能夠知道，基於React Native的擴展方案是多麼方便）

二、性能 & 體驗

咱們都很關注一款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的體驗相對而言更流暢。

三、更新 & 維護

（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 統一了開發人員技術棧，代碼維護相對容易。

5、綜合

一、開發方式

（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

二、性能 & 體驗

（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