先看看React-Native的介绍。
React Native (简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架，是Facebook早先开源的JS框架 React 在原生移动应用平台的衍生产物，目前支持iOS和安卓两大平台。RN使用Javascript语言，类似于HTML的JSX，以及CSS来开发移动应用，因此熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域。
React Native使你能够在Javascript和React的基础上获得完全一致的开发体验，构建世界一流的原生APP。
React Native着力于提高多平台开发的开发效率 —— 仅需学习一次，编写任何平台。(
Learn once, write anywhere)。
更详细的介绍，请自行百度或者谷歌。
看完介绍感觉好牛逼啊，这么强大，学习一次，编写如何平台，还有关键的一句熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域。吹的天花乱坠，实际用它来开发的时候，你就会发现，TMD的就是一坨翔，一坨想做移动前端，而不想系统学习原生开发的人员吹捧吹来的一坨翔。
假如你真的是熟悉web前端的开发，而不熟悉iOS和Android的原生开发，看了React-native的介绍而选择了使用它开发移动前端，可以实话告诉你，能坑得你吐血，因为你根本不会写两个平台的桥接代码。
实际开发的过程中，需要写很多的桥接代码，才能开发完成一个完整的App。只靠React-native本身是根本完成不了一个复杂的App的。网上的各种吹捧，使用React-native如何如何好，那是因为大部分只是使用React-native快速搭建了一个demo，当然也有使用React-native加很多桥接代码，艰难的开发完成一个App的，但是其中的酸爽，应该只有开发者自己知道吧。
性能方面
性能方面，吹嘘的是很接近原生的性能，我就呵呵了，原生开发完都还需要进行性能检测和调优，所以React-native用了一个婉转的词很接近，实际上呢，就是谁用谁知道。举个常用的组件-列表。React-native中的常用列表有三种ListView,FlatList,SectionList，性能嘛，就不多说了，尤其是长列表，那效果和原生差了不是一点半点，而且TMD的FlatList&SectionList还会出现只渲染第一屏（initialNumToRender设置的第一屏渲染的数据条数）这种灵异事件，低端机上尤其容易出现，性能牛逼的机器出现的少一些。
列表组件是移动开发及其常用的组件了吧，React-native封装那三个组件简直能搞死你。
三方组件参差不齐
开发中，各种属性和方法，只支持一个平台也不少，很多的时候，需要判断平台，写两套代码。要实现的一些功能，辛辛苦苦从网上找到第三方组件，经过一番折腾，最后发现只能再iOS上出效果，不支持Android，或者只支持Android不支持iOS的也时有发生。
开发调试
- 断点调试困难
开发过程中iOS和Android的开发都有断点调试，当然React-native也有，在浏览器里调试，而且有的地方根本打不上断点（我们使用的typescript），难用的要死，只能依靠打印log进行调试。
- 调试的时候，占用空间暴增
连真机调试的时候，React-native 的debug App会快速占掉你手机的存储空间，我曾今就遇到过，早上的时候手机还有接近3G的存储空间，到晚上调试的时候，手机的存储空间就不足了。从空间管理一看，正在开发的App占用了2.7G的存储空间，果断删除了，新装的包才100M左右，调试一整天，体积居然快速增长了27倍左右，不得不说，牛逼至极。如果你用React-native连真机开发App，从开始到App发版，中间不删除重装，会占掉手机的多少存储空间就不得而知了。
背景支持
移动端iOS和Android的爸爸分别是苹果公司和谷歌公司。React-native的爸爸-Facebook，它本身就不是移动开发的原创，而且据了解，他们自己都不怎么用React-native进行移动应用的开发。
至于weex它的爸爸是阿里，没有用过，不做评价。
使用React-native进行移动应用的开发，不可预测性很多，你永远不知道什么时候会掉到坑里，经过艰难的挣扎，爬出那个坑，然后再掉进新的坑里，最后从一个文明的程序员在React-native的开发中，学会了各种脏话。
市场上的应用
国内目前做的牛逼的App，还是使用的原生开发，目前没有听说国内那个牛逼的App是使用的React-native开发。至于国外嘛，曾经用的最好的Airbnb已经公开宣布弃用。
最大的隐患是苹果那天不让用React-native开发的应用上架，那么就彻底凉了。
要做牛逼的App，原生才是王道，才是正道，才可以稳操胜券。
