H5、React Native、Native應用對比分析

weixin_34208185發表於2017-08-19

（一）H5、React Native、Native應用對比分析

文章來源：@王利華，vczero

http://vczero.github.io/react_native/H5-React-Native-Native.html

“存在即合理”。凡是存在的，都是合乎規律的。任何新事物的產生總要的它的道理；任何新事物的發展總是有著取代舊事物的能力。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是世界上最好的語言” ——工程學的範疇，沒有最好，只有最適合

HTML5vsReact 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

搜尋

{

this.state.show ?

dataSource={this.state.dataSource}

renderRow={this._renderRow}

: Util.loading

}

//樣式

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原生元件。比如我們使用一個文字元件。

測試

（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有些大；但是具備跨平臺能力和熱更新能力。

（二）Who's using React Native?

來源

https://facebook.github.io/react-native/showcase.html

Thousands of apps are using React Native, from established Fortune 500 companies to hot new startups. If you're curious to see what can be accomplished with React Native, check out these apps!