H5、ReactNative、Native應用對比分析

每日更新關注:http://weibo.com/hanjunqiang 
新浪微博！iOS開發者交流QQ群： 446310206

“存在即合理”。凡是存在的，都是合乎規律的。任何新事物的產生總要的它的道理；任何新事物的發展總是有著取代舊事物的能力。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的旗子。就像當年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平臺下

每日更新關注:http://weibo.com/hanjunqiang 
新浪微博！

上面3張圖片，如果去掉第一張圖的“HybirdApp”的字樣，是否分得清哪個是React Native開發？哪個是Native應用。
你的第一感覺是什麼？

三、工程方案

為了評估3種方案的技術優勢和弱勢。我們需要開發功能大致相似的App。這裡，我們使用了“豆瓣”的API來開發“豆搜”應用。該應用能夠搜尋“圖書”、“音樂”、“電影”。想當年，豆瓣以“圖書評論”走紅，尤其是12年當紅！豆瓣是一個清新文藝的社群，一個“慢公司”。最近有一則網傳訊息，注意是網傳——“傳京東投1.5億美元控股豆瓣”。今天，不聊豆瓣，我們要聊一個工程化的問題。

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

每日更新關注:http://weibo.com/hanjunqiang 
新浪微博！

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”（別太放肆,沒什麼用）。因此，從以下幾個方面做一個簡單的對比。

－－－－－－－－－－提綱－－－－－－－－－－－－

每日更新關注:http://weibo.com/hanjunqiang 
新浪微博！

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方式截面圖

每日更新關注:http://weibo.com/hanjunqiang 
新浪微博！

可以看到第一層列表頁是完整的佈局，實際上這就是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封裝的導航控制更容易理解。

每日更新關注:http://weibo.com/hanjunqiang 
新浪微博！

（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。

每日更新關注:http://weibo.com/hanjunqiang 
新浪微博！

（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有些大；但是具備跨平臺能力和熱更新能力。
最後硬廣一下我的書：

每日更新關注:http://weibo.com/hanjunqiang 
新浪微博！

iOS開發者交流QQ群： 446310206