如何评价 React Native？

更新于2018年。
在DCloud新出的uni-app里，同时有小程序引擎和weex引擎。体验良好且拥有最庞大的跨端app生态。
uni-app资料详见：http://uniapp.dcloud.io/。
uni-app和react native、flutter对比，详见：https://ask.dcloud.net.cn/article/36083

aribnb是react native的主力使用者，他们放弃rn时说了一句话：以前我们只需要开发两个平台，有了react native后是3个，这让我们很疲惫。

以下为历史答复================================

facebook在HTML5上的一举一动都是全世界都在关注。2013年放弃HTML5也是产生非常大的影响力。不过这次，它可不是又把HTML5捡起来了，而是拿出了替代HTML5的新的跨平台方案。

整体而言，facebook的大思路和DCloud是差不多的，两家都是W3C会员，深刻清楚HTML5的弱点在于渲染，尤其是动态交互。认清这点并认真解决是做实事。这比cordova、ionic这些产品的思路要靠谱。cordova等产品仍然认为SPA是王道，耐心等待硬件升级就好了。
但是除了渲染，DCloud认为HTML5比原生还有2个关键环节弱就是能力和开发工具，所以在这2方面也做了react native没有做的强化工作。
以及同样是优化动态交互，DCloud和react native也走了不同的路线。

首先声明一点，DCloud并非做不出来react native这样的产品从而鼓吹5+好，抨击react native不好。
恰恰是我们团队之前在08年-12年也走过react native的那条路，使用v8下的js操作原生控件。但是随着时代的发展，我们淘汰了那个技术。
原因是什么？因为手机硬件在快速发展，HTML5起来了。
现在的HTML5，虽然还有虽然有部分场景表现不佳，但不至于被全面否定。
对于HTML5表现不佳的地方，比如窗体切换、区域滚动、下拉刷新等，采用原生强化的方式进行补充，其余HTML5可用部分，仍使用HTML5就好了。
这也就是HTML5+的思路，面向核心问题、改进核心问题，做强化，而不是全面否定重新来一套。
而经过体验强化的部分，DCloud又推出mui前端框架，做标准兼容，让窗体切换、下拉刷新这些强化代码在普通浏览器下也可以兼容降级运行，虽然没有带着5+引擎时那么流畅，但也能用。
这才是有更有效率的解决方案，开发一次、多端发布。
打个比方，一辆车只是轮子不够好，改进轮子就好了，非要整车重做何必呢。
而react native的问题，就是过于否定HTML5的价值。

接下来我们系统的总结下2个产品的区别：

1. 理念的区别：

react native与HTML5无关。
它使用的语言还是javascript，但没有HTML和css。
可以把它称为no HTML5。
也就是使用js语言编程，但不使用浏览器引擎渲染，而是用独立v8引擎解析指定的js语法，然后由js操作绘制界面。
NO HTML5，这对于W3C和浏览器厂商，这是个有点打脸的事情。
这样广大开发者所学的HTML和css知识就用不到了。

而HTML5Plus，看名字就知道是完全不同的路线。
5+是基于HTML5的现状，扩展和完善它的不足。
并且html5plus.org定义的扩展，也都会提交给W3C。
面对HTML5的不足，是打翻重来好，还是增强好？答案肯定是如果有增强的方案且效果一样，何必打翻重来。

2. 平台支持

目前react native在ios上仅支持ios7以上，Android仅支持Android4.1以上。以下的平台，会被转换成普通HTML5运行，效果很差。
而5+的平台支持是iOS5+和Android2.3+。
你的老板可能会问你为什么竞品app的次日留存是30%而你的app是20%，然后风投就投给了你的竞品，其实答案就在于你的app兼容的手机不够多。

3. 编码的区别

先说明一个概念，reactjs之前是facebook推出的一个前端框架。在前端框架层面定义了一套自己的api，然后用js再解析成dom。
刚刚推出的react native，原生实现了之前reactjs的api的解析，不再转换为dom。
之前reactjs前端框架出来时，业内争议就很大，很多人认为这种写法难以理解、不优雅。

React.render(  
        <h1>Hello, world!</h1>,  
        document.getElementById('example')  
      );

有点像使用innerHTML来创建dom，然后注意<h1的左边是没有引号包围，也就是说这个参数并不是字符串。真是把js的动态性发挥的淋漓尽致。
另外React Native的理念是Learn Once , Write Anywhere，ios、Android2个平台很多代码都无法统一。

4. 引擎的体积

react native是自己的渲染引擎，不是webkit或任何我们熟悉的浏览器。相当于是facebook的定制浏览器。
引擎包的体积不小，hello world就是7M。而功能更多的5+基础基座只有几百K大小。原因是5+只是做强化，基础的HTML5处理是os做的。当然由此开发者也得注意编码时不要依赖太新的css，容易引发应用兼容性问题。

5. 性能的区别

其实不管是浏览器，还是react native，还是5+，渲染都是原生语言解析动态语言来渲染，不同的只是谁的原生渲染引擎高效，再往本质说，就是谁的语法简单。越复杂的语法，越灵活，也渲染越慢。
从理论上来讲，reactjs的性能一般，但react native的性能确实好于webkit，但react native与5+的性能谁高谁低？有点复杂，慢慢解释。
5+分HTML5部分和原生扩展部分。

• 使用纯HTML5时，比如用js操作一个动画，那么react native比dom+css3的HTML5方案性能高。
• 但使用5+的原生扩展时，那react native的性能略逊于5+。比如窗体切换，5+提供更为强大的截图切换方案，支持提前对窗体静态截图，移动窗体时不移动webview、只移动静态截图的，此时不会在移动窗体时频繁触发dom和css的重绘，性能是很好的，rn也比不了，rn仍然是要动态渲染绘制的。
  在DCloud的mui里，switch等控件是纯HTML5的，所以性能比react native要差。
  但为何DCloud明知如此也不给switch做native版本？要知道DCloud给很多UI控件做了native版本。
  原因是DCloud的原则是HTML5能做好的事情不动原生。mui的switch理论上比react native性能差，但实际中用户很难感受到动画少几帧的差别，既然已经能满足商用，何必搞原生增加引擎体积？

6. 能力的区别

原生能力调用这个就不是react native的擅长了，几乎没什么原生能力调用。需要原生工程师开发原生代码封装接口给js用。
5+ runtime有几十万原生api可以直接调用，能力远多于react native。大多数常见的功能api都封装在htmlplus的标准规范里，更多api可以灵活的使用Native.js操作，也有大量示例，无需原生工程师就能完成app。
所以目前react native常见的应用是hybrid，不太在意app体积的开发商使用rn做热更新。但没有原生工程师时，如果想纯js完成app，那react native是不行的。这对于创业公司就失去了吸引力，既然要用跨平台技术，就是要省成本，还得再雇佣原生工程师何必呢。

7. 成熟度的区别

开发者肯定喜欢坑少的产品。react native是2015上半年发布ios，下半年发布Android。HTML5+更早一年，是2014年初发布，基于5+已上线数万App，包括360、大众点评、京东、唯品会、携程等众多知名公司都在使用。坑不能说没有，但不会比react native多。

8. 开发工具的区别

facebook没有提供配套的ide，开发调试非常麻烦。没有原生开发基础的话甚至可能搭不起来开发环境。
打包也不方便，没有mac电脑无法调试或打包ios应用

9. 发展方向的区别

作为一个开发者，我仍然认为react native是一个短期的产品。
因为随着硬件、OS和HTML5强化技术的成熟，HTML5的性能已经大幅提升，react native的性能会略好一点点，但不会很明显，为了这一点点要重新学习、重新编码，不值得。
而且随着时间的推移，性能优势会越来越小。
花费很大精力学习一个很短期的过渡产品，我想大多数人不会这么选择。

如果你本来就是reactjs的开发者，且准备进入facebook生态圈，那么react native这步顺利成章。
如果你本来不会reactjs，现在想用react native开发跨平台app，那么没什么意义。
如果你是一个原生开发者，想要利用react native解决热更新和跨部门组件整合，那没问题，实际上目前react native的主要使用场景就在此。
如果你想用HTML5做跨平台开发，不招原生开发，那react native玩不转，只能使用HTML5+。

最后总结下：
HTML5需要强化毋庸置疑，但到底该怎么强化？
一种是打翻重来一套，一种是增强HTML5的不足。如果最终效果差不多，当然是后者的方案靠谱。
一个HTML5移动站，通过5+略加改造就可以变成原生体验的App。但如果是react native，就需要重头学重头写，代价高昂，收益却没有提升多少。
功能：5+远大于react native
性能：两者各有千秋
包体积：5+远小于react native
OS支持范围：5+大于react native
国内开发者支持：5+优于react native
长期演进生命力：react native像过渡产品，随着手机硬件的提升，该项目存在的意义在下降。如果说未来有一天，有谁能替代原生成为移动互联网主流技术，那只能是HTML5，不会是诸如react native这类技术。

光说理论也不够，建议大家亲身体验一下react native的案例和DCloud的案例，装在低端手机上看看。
react native的案例：http://reactnative.cn/cases.html。
DCloud的案例：http://dcloud.io/case/ 推荐使用最新版流应用体验。
我相信大家很难感知到性能差别。

我还以为打开的知乎……

看了评论，怎么发现都是说5+不好的？只想说，不能为了所谓的技术而技术，你弄技术的目的是什么？如果简单的技术已经可以满足需求，干嘛还非要折腾，又不是推动技术进步的基础学科，多有点时间干点更多地事不更好吗？为毛现在it界非得各种语言乱飞，有用吗？就为了让人不明觉历？然后非得学所谓的新东西？绝大部分东东现有技术都能解决，弄点乱七八糟的出来骗小白。google自己放出来的新东西几年就扔掉的也不少了，打脸那是啪啪的，facebook有能如何？专心干点正事吧。真心希望DCloud的产品能继续进步！

官方在与硬件上的交互上一直没有解决方案！！5+能添加蓝牙的API就好了，也不用去学习原生开发了，话说官方真的不打算封装蓝牙吗？

我刚查了一下，没有发现facebook新推出把React Native编译成原生代码的功能。请问你在哪里看到的？那个只是使用了一个新的排版引擎yogo，不是webview渲染而已。但仍然是js运行在v8里，不是真的编译为原生代码。

就像React JS只是一个View的部分，如果React Native 也只是View的部分，那也没啥存在的必要。毕竟抛除能力方面的要求，HTML+CSS在View端能力已经远超原生的页面布局了。

我还是那句话，适合自己的才是最好的。。。。。

还有就是React-Native 也是可以调用原生Api的哦!
官网文档里都写着呢。。

简单点来说,就是做了桥接,让css来格式化原生组件的外观,然后用RJX来控制. 由于没了DOM,所以体验感肯定没问题.

真是不思进取啊，为什么h5+没有火起来，还是性能和体验问题，既然你们早就意识到了，又何必急功近利的去做一些华而不实的东西呢？比如mui，你的性能都不行，还会用mui吗？我早就说过，把性能做好是当务之急，把mui做好想直接面向市场就可以了吗？不行。

其实没有看到Facebook这个框架之前我都有这样的想法，只是个人能力不够而已。

再说h5+，我觉得你们没有吧钢用到刀刃上，要承认没有珍惜这个时间点，你们完全可以早一点并行开发一套适合中国人的 语法和框架，去调用原生态控件。既然有人有理想，现在做出一个四不像的东西，感觉不可理解！

等webview性能强大了，也不见得比原生态强，再说感觉webview什么时候才行呢？

有点同感，官方确实要考虑尽快多地封装一些常用接口API，能少去调用原生的最好，这样的话才能保证真正的跨平台能力和一致的使用体验，对不？
我们一直在思考的是HTML5+和Hbuilder这一套组合是否也可以开发出能安装在PC版Windows10上的软件？没完全想明白真正的技术障碍会在哪，哪位大拿指点指点？多谢。

实际使用过程中ios和android同样的一些mui css也会有大概10%效果不同 ios需要调整 还是觉得这套技术适合做一些业务少 的app 文档方面官方也需要及时更新啊!

别误导人好不，React Native 是编译成原生的代码运行的，所以为什么现在React Native还没有Android版的原因。