一：RN和H5比较
RN可以看成是一个容器，这个容器负责执行JS代码，并且把UI渲染出来。本质上和浏览器没有区别，相对于H5开发，有以下三大优势
第一：RN所有的UI都是纯Native的，不像WebViw的UI都是Webview渲染，所以RN在效率上比webView高，也更流畅。
第二：RN的UI组件在本地，不像H5需要动态从服务器拉取数据和UI，所以RN界面的反应速度跟H5不在一个档次。跟纯Native的差不了太多，彻底摆脱了Webview让人不
爽的交互和性能问题，所以用户体验方面就比H5好太多了。
第三：可扩展性，用H5开发，实现的功能有限。虽然现在RN的组件库也有限，但是Facebook提供了JS和native之间的桥接方式，你可以很方便的自己封装组件，然后
在JS调用。
第四：h5的内存占用高，贴别是一些列表过长的时候，触控体验不佳。
二：和native开发比较，RN有以下优势： 第一，热更新，版本更新快，发布新版也不需要app store审核，你可以天天上新版本，这个对于产品来说，是不是太惊喜了。 第二，平台适配，facebook提出的是：Learn once,write anywhere。IOS和Android平台本身存在差异，如果要强行write once，run anywhere，反而发挥不出平台 的优势。虽然没有write once，run anywhere。但是，业务逻辑代码完全可以复用，大部分80%的UI组件都是可以复用的。Android和IOS平台的差别并不明显。 第三， 开发效率高，jsx语法简练，比如显示一张远程图片一行代码即可搞定，而在Android或者IOS开发中，先要在UI上设置一个Image控件，指定一个ID，然后在程 序中再根据ID来操作；另外，RN修改了代码，只需要简单的点击“Reload”就可以看到效果，不需要像Native开发那样需要编译，安装后才能开到效果；还有相比于 native的UI布局，RN基于FlexBox的样式可以节省一半的代码，并且更容易理解。 RN开发的挑战： RN学习成本相对比较高的，对于客户端开发来说，js 跟java，objective-c，swif语言完全不是一路的，是一个全新的咚咚，你如果带着java的思想来学习，完全会 懵，必须把自己归0来学习它。对于前端开发来说，虽然你懂js，但挑战也是存在的，ES6，函数式编程思想，新的标签，新的控件，这些就够你喝一壶的。现在RN的 组件库很不完善，如果需要用的的功能，没有组件支持，你就只能干瞪眼了。 最佳的RN开发组合： 鉴于上面的挑战，所以最好是前端和客户端的人一起学习RN开发，前端人员负责业务逻辑，客户端人员主要负责底层支持，重点放在组件支持和性能优化上。即使这 样，挑战依然存在。RN本身不是很完善，去年推出到现在一年多过去了，facebook也还没有发布正式的1.0版本，保持着每两周一个版本的更新速度，很多方面还有许多坑等你来踩。