原生、混合、react-native应用对比分析

原生开发、纯网页开发（H5开发）/混合开发（H5+原生）、React-Native开发

原生开发是系统自带的app开发方式，也是大部分人最熟悉app开发的技术，如android、ios、wp。
H5开发是Html5开发的app，本质上运行在手机浏览器中的页面，一般使用app做一个壳套用浏览器运行H5的页面，由于H5的特性也有很多app使用半原生半H5的hybird app 开发模式。
介绍react-native之前，需要先提下react，react 是facebook在2013年开源的网站ui开发的js库，react-native是用react 进行原生app开发的框架，让广大开发者使用js和react开发应用，提倡组件化开发。react-native提供一个个封装好的组件让开发者使用，也可以相关嵌套形成新的组件。使用react-native可以维护多种平台（Web，Android和IOS）的同一份逻辑核心代码来创建原生app。从代码上看结构类似，细节有差别，facebook强调的是“learn
once,write everywhere”，应用前端使用js和React来开发不同平台的ui，下层核心模块编写复用业务逻辑代码，提高应用的开发效率。react-native的原理。react-native的优点和H5类似，跨平台、低成本开发、开发速度快、动态发布、一套类似代码维护三个平台。

一、React-Native

背景

作为前端小白，我以前对前端的理解是这样的：

用 HTML 创建 DOM，构建整个网页的布局、结构
用 CSS 控制 DOM 的样式，比如字体、字号、颜色、居中等
用 JavaScript 接受用户事件，动态的操控 DOM

在这三者的配合下，几乎所有页面上的功能都能实现。但也有比较不爽地方，比如我想动态修改一个按钮的文字，我需要这样写：

<button type="button" id="button" onclick="onClick()">old button</button>

然后在 JavaScript 中操作 DOM：

<script>
function onClick() {
document.getElementById('button').innerHTML='new button';
}
</script>

可以看到，在 HTML 和 JavaScript 代码中，id 和 onclick 事件触发的函数必须完全对应，否则就无法正确的响应事件。如果想知道一个 HTML 标签会如何被响应，我们还得跑去 JavaScript 代码中查找，这种原始的配置方式让我觉得非常不爽。

React

随着 FaceBook 推出了 React 框架，这个问题得到了大幅度改善。我们可以把一组相关的 HTML 标签，也就是 app 内的 UI 控件，封装进一个组件(Component)中，我从阮一峰的 React
教程中摘录了一段代码：

var MyComponent = React.createClass({
handleClick: function() {
this.refs.myTextInput.focus();
},
render: function() {
return (
<div>
<input type="text" ref="myTextInput" />
<input type="button" value="Focus the text input" onClick={this.handleClick} />
</div>
);
}
});

如果你想问：“为什么 JavaScript 代码里面出现了 HTML 的语法”，那么恭喜你已经初步体会到 React 的奥妙了。这种语法被称为 JSX，它是一种 JavaScript 语法拓展。JSX 允许我们写 HTML 标签或 React 标签，它们终将被转换成原生的 JavaScript 并创建 DOM。

在 React 框架中，除了可以用 JavaScript 写 HTML 以外，我们甚至可以写 CSS，这在后面的例子中可以看到。

理解 React

前端界总是喜欢创造新的概念，仿佛谁说的名词更晦涩，谁的水平就越高。如果你和当时的我一样，听到 React 这个概念一脸懵逼的话，只要记住以下定义即可：

React 是一套可以用简洁的语法高效绘制 DOM 的框架

上文已经解释过了何谓“简洁的语法”，因为我们可以暂时放下 HTML 和 CSS，只关心如何用 JavaScript 构造页面。

所谓的“高效”，是因为 React 独创了 Virtual DOM 机制。Virtual DOM 是一个存在于内存中的 JavaScript 对象，它与 DOM 是一一对应的关系，也就是说只要有 Virtual DOM，我们就能渲染出 DOM。

当界面发生变化时，得益于高效的 DOM Diff 算法，我们能够知道 Virtual DOM 的变化，从而高效的改动 DOM，避免了重新绘制 DOM。

当然，React 并不是前端开发的全部。从之前的描述也能看出，它专注于 UI 部分，对应到 MVC 结构中就是 View 层。要想实现完整的 MVC 架构，还需要
Model 和 Controller 的结构。在前端开发时，我们可以采用 Flux 和 Redux 架构，它们并非框架(Library)，而是和 MVC 一样都是一种架构设计(Architecture)。

如果不从事前端开发，就不用深入的掌握 Flux 和 Redux 架构，但理解这一套体系结构对于后面理解 React Native 非常重要。

React Native的出现

分别介绍完了移动端和前端的背景知识后，本文的主角——React Native 终于要登场了。

融合

前面我们介绍了移动端通过 JSON 文件传递信息的不足之处：只能传递配置信息，无法表达逻辑。从本质上讲，这是因为 JSON 毕竟只是纯文本，它缺乏像编程语言那样的运行能力。

而 React 在前端取得突破性成功以后，JavaScript 布道者们开始试图一统三端。他们利用了移动平台能够运行 JavaScript 代码的能力，并且发挥了 JavaScript 不仅仅可以传递配置信息，还可以表达逻辑信息的优点。

当痛点遇上特点，两者一拍即合，于是乎：

一个基于 JavaScript，具备动态配置能力，面向前端开发者的移动端开发框架，React Native，诞生了！

看到了么，这是一个面向前端开发者的框架。它的宗旨是让前端开发者像用 React 写网页那样，用 React Native 写移动端应用。这就是为什么 React Native 自称：

Learn once，Write anywhere!

而非很多跨平台语言，项目所说的：

Write once, Run anywhere!

React Native 希望前端开发者学习完 React 后，能够用同样的语法、工具等，分别开发安卓和 iOS 平台的应用并且不用一行原生代码。

如果用一个词概括 React Native，那就是：Native 版本的 React。

原理概述

React Native 不是黑科技，我们写的代码总是以一种非常合理，可以解释的方式的运行着，只是绝大多数人没有理解而已。接下来我以 iOS 平台为例，简单的解释一下 React Native 的原理。

首先要明白的一点是，即使使用了 React Native，我们依然需要 UIKit 等框架，调用的是 Objective-C 代码。总之，JavaScript 只是辅助，它只是提供了配置信息和逻辑的处理结果。React Native 与 Hybrid 完全没有关系，它只不过是以 JavaScript 的形式告诉 Objective-C 该执行什么代码。

其次，React Native 能够运行起来，全靠 Objective-C 和 JavaScript 的交互。对于没有接触过 JavaScript 的人来说，非常有必要理解 JavaScript 代码如何被执行。

我们知道 C 系列的语言，经过编译，链接等操作后，会得到一个二进制格式的可执行文，所谓的运行程序，其实是运行这个二进制程序。

而 JavaScript 是一种脚本语言，它不会经过编译、链接等操作，而是在运行时才动态的进行词法、语法分析，生成抽象语法树(AST)和字节码，然后由解释器负责执行或者使用 JIT 将字节码转化为机器码再执行。整个流程由 JavaScript 引擎负责完成。

苹果提供了一个叫做 JavaScript Core 的框架，这是一个 JavaScript 引擎。通过下面这段代码可以简单的感受一下 Objective-C 如何调用 JavaScript 代码：

JSContext *context = [[JSContext alloc] init];
JSValue *jsVal = [context evaluateScript:@"21+7"];
int iVal = [jsVal toInt32];

这里的 JSContext 指的是 JavaScript 代码的运行环境，通过 evaluateScript 即可执行 JavaScript 代码并获取返回结果。

JavaScript 是一种单线程的语言，它不具备自运行的能力，因此总是被动调用。很多介绍 React Native 的文章都会提到 “JavaScript 线程” 的概念，实际上，它表示的是 Objective-C 创建了一个单独的线程，这个线程只用于执行 JavaScript 代码，而且 JavaScript 代码只会在这个线程中执行。
React Native的出现，似乎是扛起的反H5的旗子。就像当年Facebook放弃H5，全部转向Native一样。这一点，我们需要认同和保持高度的清醒。那么，React Native是否又是在吞食Native的领地呢？技术的发展，是用户风向标的导向起的作用。任何一门技术的出现，都是当时用户需求的体现。
我们应该从以下几点看待React Native的出现。
"鉴往知来"——从过去的教训中总结经验，从用户的角度开拓未来，用户更希望产品迭代和稳定寻求一种平衡

“HTML5差强人意，但是与原生应用相比还是有些差距”——为了更高的追求！ 用户体验！

“人才宝贵，快速迭代”——Web开发者相对较多，寻找平衡点

“跨平台！跨平台！跨平台！”——单一技术栈，开发者的福音

“xx是世界上最好的语言” ——工程学的范畴，没有最好，只有最适合，我还是补充一句，JS还是很好很好的。
HTML5 vs React Native ? HTML5 : React Native

结论（React Native）：

原生应用的用户体验
Native不用WebView，彻底摆脱了WebView让人不爽的交互和性能问题；
跨平台特性
开发人员单一技术栈
上手快，入门容易
社区繁荣

二、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];

"豆搜" WebApp路由（基于AngularJS）如下：



"豆搜" React Native版本导航如下：



"豆搜" iOS版本导航代码如下：



总结：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有些大；但是具备跨平台能力和热更新能力。

六、总结
最后我们总结一下，目前争论不休的原生、H5、react-native问题，在早先前争论CS，BS架构的软件系统是一样一样的。原先BS，CS对用户而言的区别是需不需要安装客户端。BS是通过浏览器来访问，用PC，平板，Win，Mac都能访问，用户不需要下载额外的客户端，同时运维和升级提供很大的便利。CS则需要下载客户端软件，安装，然后登录使用，升级的话，要么升级链接库，要么重新安装升级包，比较不方便，优势是很多算法在本地运行，对服务器要求不高。
CS、BS之争是在PC端，那么现在原生和H5之争是在移动端。
那么评判一个APP用什么技术来开发呢？经过总结，可以有如下判断依据：

如果APP中出现大段文字（如新闻、攻略等），且格式比较丰富（如加粗，字体多样），那么用H5会比较方便。原因是原生开发解析json对字符串格式处理不算很好。
如果讲究APP反应速度（含页面切换流畅性），则选用原生开发，因为H5其本质是网页，换页时，基本要加载整个页面，就像是浏览器打开一个新页面一样，显得较慢，而原生系统则只加载变化部分。
如果APP对有无网络、网络优劣敏感（譬如有离线操作，在线操作），那么，基本选用原生开发，虽然H5可以做到，但是很复杂。
如果APP需要频繁调用硬件（摄像头、麦克风、未来的湿度检测仪等等）那么，基本选用原生开发，这样支持硬件更多，更容易扩展，且调用速度更快，H5就望尘莫及了。
如果APP用户常见页面频换，如（淘宝首页各种不同活动），那么用H5，维护起来更容易。
如果预算有限（H5开发一套可跨平台覆盖安卓、ios，黑莓、塞班），不是很讲究用户体验，不在乎加载速度，那非H5不可。

在实际开发过程中，可以在原生与网页的基础上进行混合，对于固定格式、页面速度要求高，的模块（如PDB的即时通讯、宝典、我的项目）采用原生开发，对于新闻、大段文字、资讯类的（如信息广场、发表、问吧等）用H5页面来加载，将其嵌入到原生框架中那么，可以达到比较良好的体验。

参考：
React Native 从入门到原理

H5、React Native、Native应用对比分析
关于APP，原生和H5开发技术的争论