http://m.blog.csdn.net/article/details?id=
& &&&最近工作中接触到React-Native框架，对其进行一些技术分析，结合之前了解的H5的一部分，加上自己做了很久的原生开发（十几个android app、sdk，包括2个ios）, 总结下目前了解到的这三种移动端应用开发方式的特点和试用范围，作为个人知识的记录，也作作为公司内部互相学习的分享。
一、原生开发
& & & & &原生开发是系统自带的app开发方式，也是大部分人最熟悉app开发的技术，如android、ios、wp。
&&&&&原生开发依然是开发者采用最广泛的开发方式，优点十分显著。相比其他开发方式而言，原生开发可以访问设备中的所有功能，运行速度更快，性能更高，而且可以启用优秀的离线处理和存储能力等等，提供最佳的用户体验，最优质的用户界面，最华丽的交互。原生开发人员众多，开发环境成熟，有许多的开源库提供开发人员调用，可是方便实现各种设计效果。
& & &原生开发的缺点在逐渐的开发、运营过程中显现出来。开发成本高，不同平台需要定制不同的app，也就是android定制apk，ios定制app，开发人员需要多平台多语言，人力成本、时间成本较多，通用性差；上线时间不稳定，需要审核，特别是苹果审核机制，审核时间长短不一，对内容还有控制，国内Android APP市场（百度手机助手，应用宝，360市场等等）也有类似的问题；版本控制能力差，版本发布到达率无法控制，多个版本更新发布，修复bug，无法保证及时送达到用户手中；获得新版本需要重新下载安装，虽然目前有增量升级方式逐渐改变，但是随之而来的其他问题如增量升级多版本控制也是个很头疼的问题；
& & &总结：原生开发虽然有各种缺点，但是在目前所有的开发技术中原生是最成熟，有效，也是开发人数最多，开源库最广泛的。对APP要求各方面性能、响应要求高，人员充足，完整开发、测试流程，适合原生APP开发。
二、H5开发
& & &H5开发是Html5开发的app，本质上运行在手机浏览器中的页面，一般使用app做一个壳套用浏览器运行H5的页面，由于H5的特性也有很多app使用半原生半H5的hybird app 开发模式。
& & &H5有许多优点，特别针对原生开发的缺点。如： 直接在网页上调试和修改，几乎不用考虑用户机型和适配的问题，针对原生开发的平台碎片化、开发人力成本、时间成本高；版本升级优势，网页的升级与用户无关，用户无需下载更新安装，保证实时送达到用户手中；上线时间稳定、快速，不需要通过开发市场的审核，有收入分成的开发市场更是可以绕过收入分成。除此以外在视频媒体方面H5表现也十分优秀的。
& & &H5的缺点有许多，当新技术出现时候许许多多的人都在吹嘘它的优点，到真正实用时才对它的缺点正视。H5加载大图片的时候性能会下降，大量用户访问同一个H5应用时性能会下降，响应速度比不上原生app，上网速度也不及原生app，H5不能自动处理动画上反复交互（网页游戏），需要借助css3、javascript。H5本质上是网页，无论是离线的还是在线的，它本质上是通过浏览器呈现到用户面前的网页，在手机上模拟得像app，网页的缺陷它无可避免。1.软、硬件的支撑问题，现在早已不是问题，这里讲出是由于2012年左右当时H5火起来时，我在FF公司看到宣讲H5时，当时许多的手机依然无法支持h5，几年过去了这个问题基本不存在了；2.性能问题，这才是H5最大的问题，原生开发对性能的支持远超H5，在用户体验上，H5的app绝对是占据下风的，app反应速度、流畅度等；3.功能问题，对某些硬件摄像头、陀螺仪、麦克风等硬件支持较差，频繁调用这些硬件，H5不容易扩展，调用速度也不如人意。
& & &&总结：纯H5 app适合小游戏、媒体、视频、营销产品、介绍等功能，大部分大型app属于原生、H5混合的hybird app。
& & &H5话题的延伸。年H5大火，有许多人认为可以替换原生开发，成为一种“write once,run anywhere”的开发模式，但是在许多公司的案例中就遭遇了失败，但是仅仅过去了3-4年，硬件设备的更新，软件的支持，H5又一次以不同的面目再一次火起来。这个过程十分让人唏嘘。HTML5已经出来很多年了，早在2010年，乔布斯在封杀Flash的言论中，就预言HTML5将取代Flash成为下一波技术浪潮。就算不关心技术的朋友，去翻翻手机也能感受到在pc端一直以来占据统治地位的Flash在手机端几乎不见踪影，这是从2010年以来苹果公司与Adobe公司的战争开始，苹果背后无数开发人员支持研发HTML5技术，让HTML5技术得以普及开来。2011年Adobe自己也放弃了Flash移动端的研发工作，HTML5已经被移动浏览器广泛支持，Flash已经落后于时代了。很多大公司都在推动HTML5的发展，但是也有滑铁卢，Facebook的扎克伯格是最惨痛的教训，他想要用HTML5的web app来打破ios和android的垄断，实用HTML5来代替原生App。在这件事上facebook失败了，具体表现在2013年前facebook在移动端的产品的市场表现非常一般，最后无奈宣布回归原生app的开发。Facebook在html5的试错大大打击了HTML5的实用性，但是HTML5自身的厚积薄发还是让这项技术没有没落。
&&&&&手机硬件的提升和HTML5本身的完善，使得基于HTML5的应用表现更好，iPhone对HTML5的支持更加完善，Google也完成了移动端Chrome浏览器向Chromiumnie内核的切换，大幅提升对HTML支持。很多基于HTML5的应用都在试图替代原生app，但是由于技术限制，用户体验远远不如原生app，但是某些方面HTML5提供了比原生App更好的体验，但这种体验的基础不是单纯的替代原生App，而是做一些最适合HTML5的细分应用，比如小游戏、媒体和营销类的产品。这些细分的方向能够最大程度发挥HTML5跨平台、开发成本低、开发速度快的优点，在整体产品体验上远超过原生app。HTML5和原生app并不是对立的，反而原生app需要HTML5去解决一些核心的问题，让整个移动市场更有效率。很多公司在努力推动HTML5技术，但是让HTML5重新焕发生机的是微信，利用朋友圈的私密社交，以及HTML5自身的跨平台、低成本开发、速度快等特性，不少公司利用HTML5技术在朋友圈做了一次又一次的营销。微信本身没有在HTML5技术上有什么创造性的推动，而是在HTML5的应用场景上做出了自己的不同尝试，形成了附着微信这个超级app的HTML5应用场景。HTML5的优点跨平台、低成本开发、开发速度快等优点不是最终站稳市场的根源，最终成就它的还是它自身比原生app更加优秀的特质，比如小游戏、媒体、视频、营销产品等等。目前许多app都采用hybird app 开发（微信、支付宝等等），在h5适合的地方展示，在其他地方使用原生开发，以规避缺点，发扬优势。
三、react-native框架
& & &介绍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类似，跨平台、低成本开发、开发速度快、动态发布、一套类似代码维护三个平台。代码结构如下图：
程序结构上，有两个工程分别是ios 、android，编译后回在相应文件夹中生成apk和app，界面代码是选中的index.android.js和index.ios.js，右侧的JS代码在这两个JS文件中几乎一模一样。
它与web app很类似，但是绝对不是web app，查看开源代码，你不会发现webview的使用，也就是本质上react-native的app不是web app 或者hybird app，而是原生控件。那它是怎么实现的呢，react-native的原理如下图：
原理上看react-native在js端和java端互相有个映射关系，通过两端的配置表来实现，java端和js端持有同一张表，通信时靠这张表的各个条目的对应进行的。上面提到了facebook实现了组件让开发者调用，就是通过js的配置表调取原生控件，java调用js也是类似的情况。所以当我们使用复杂控件时，可以自己实现java代码，添加入配置表中，即可自定义心新的映射关系，让我们js调用自定义的复杂控件 , 当然web 、ios、androi需要实现不同的控件代码，只是js端的调用代码一样或者类似。
react-native的优点：不用webview,摆脱了webview的交互和性能问题；有较强的扩展性，java端提供了基础控件，js可以自由组合使用也可以自定义组合控件；
react-native的缺点：组件不全，第三方组件也不全，遇到某些特殊功能，需要花大力气写；性能方面也无法媲美原生，还是有一些损耗，特别是交换大数据时；IOS版本略好，androi发展较慢；ios和android代码并非通用，有可能需要维护两套代码或者在代码中做一些判断；开发人员还是需要会原生开发，不然自定义组件无法编码；
个人感受，react-native不是万能药，只是一种高效的解决方案，不要期望它解决所有的问题，要不要使用需要场景衡量；客户端转开发react-native感觉比较简单，比较JS大部分人都有基础，前端人员开发react-native理解原生部分的代码应该十分困难；相比原生海量的第三方控件和第三方包，react-native大部分道路还得靠自己摸索；不同端的代码风格和结构大体类似，但具体标签可能会不一样；目前得到经验是IOS版本比较稳定，android版本还不太成熟，android 版本2015年下半年发布，一直在0.*版本上更新，android1.0版本还没有发布；把把facebook的第三方包网络连接包okhttp和图片下载解析包fresco等一起封装进结果，造成包增加7、8M，但据了解这是可以修改的；只支持IOS7以上和android4.1以上机型，这应该不成问题，比较其他属于少数；听说qzone使用了react-native，但是crash率前10，react-native占8个，前5全是react-native，但是我一朋友项目使用过react-native，虽然有坑，但是不会有如此多
总结：新技术，开发环境和代码编码方面都比较艰涩，有可能有很多坑，但是在界面简单，三端都要求，开发成本需要降低情况下可以使用react-native。
最近在学习react-native，以后可能会有新感受，公司内部最近可以找个项目实战一下。
阅读(...) 评论()只熟练Java和Android开发，想直接上手React Native进行iOS开发坑在哪里？ - 知乎77被浏览4352分享邀请回答123 条评论分享收藏感谢收起52746人阅读
@王利华，vczero“存在即合理”。凡是存在的，都是合乎规律的。任何新事物的产生总要的它的道理；任何新事物的发展总是有着取代旧事物的能力。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平台下上面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.htmlWebApp项目地址：/vczero/search （很简单的一个项目）H5/Hybird项目地址：/vczero/search_Hybird2、React Native在React Native中，封装必要的功能组件。项目地址：/vczero/React-Dou。项目结构如下图：3、Native(iOS)使用React Native大致相同的组件开发App，不使用任何第三方库，代码布局。项目地址：/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。
&ScrollView style={styles.flex_1}&
&View style={[styles.search, styles.row]}&
&View style={styles.flex_1}&
&Search placeholder=&请输入图书的名称& onChangeText={this._changeText}/&
&TouchableOpacity style={styles.btn} onPress={this._search}&
&Text style={styles.fontFFF}&搜索&/Text&
&/TouchableOpacity&
this.state.show ?
dataSource={this.state.dataSource}
renderRow={this._renderRow}
: Util.loading
&/ScrollView&
var styles = StyleSheet.create({
marginTop:5
paddingLeft:5,
paddingRight:5,
backgroundColor:'#0091FF',
justifyContent:'center',
alignItems:'center'
color:'#fff'
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组件。（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: 995KBNative83KBReact Native框架包大小843(不含bundle) – 32(Hybird_app空壳，初识项目) = 811KB相比快速迭代和热更新，比Native多了811KB一点都不重要，我们将图片素材、静态资源线上更新缓存起来即可减少很多体积。总结：牺牲一点体积，换更大的灵活性！（世界上哪有那么美的事，除非丑，就会想得美，:) ）。（5）Big ListView & Scroll 性能循环列表项500次: H5页面惨不忍睹React Native还可以接受Native 采用UITabView更高效，因为不渲染视图外部分。（6）真机体验机型：iphone4s，iOS7Native & 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 modules2、性能 & 体验（1）内存：Native最少；因为React Native含有框架，所以相对较高，但是后期平稳后会优于Native。（2）CPU：React Native居中。（3）动画：React Native动画需求基本满足。（4）安装包体积：React Native框架打包后，811KB。相比热更新，可以忽略和考虑资源规划。（5）Big ListView（6）真机体验：Native &= React Native & H5/Hybrid3、更新 & 维护（1）更新能力: H5/Hybird & React Native & Native（2）维护成本: H5/Hybird &= React Native & NativeReact Native定制难度相比Native有些大；但是具备跨平台能力和热更新能力。最后硬广一下我的书：
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1310591次
积分：13910
积分：13910
排名：第891名
原创：111篇
转载：84篇
评论：808条
作者，早期从事Android移动开发、嵌入式系统开发，连续两次创业，全栈带队开发全球知名校友在线咨询平台。
文章：32篇
阅读：398419
文章：12篇
阅读：65433
(1)(6)(3)(6)(1)(1)(2)(3)(6)(6)(2)(1)(7)(15)(3)(1)(2)(1)(6)(4)(2)(2)(8)(1)(4)(3)(1)(1)(2)(4)(1)(8)(5)(1)(7)(2)(5)(6)(11)(12)(6)(4)(3)(1)(3)(15)(1)(1)