React Native与原生关系理解与对比

##00关系理解

这个是我对RN和原生关系的理解。简单解释下这个图。

RN js编写完业务代码后，经过react-native bundle命令，将代码分别编译成一个index.ios.bundle和index.android.bundle文件，固然仍是资源文件。而后放到Android、iOS的原生工程里，经过黄色说明块里的示例代码，将js写的全部逻辑业务读成一个View来展现在原生里，固然这个View须要Activity/Fragment/ViewController来承载。而后原生App打开相应承载的页面就能够看到RN写的业务了。因此，正常状况下，对于原生来讲，全部的RN页面都是在一个原生页面里的。

顶部还有有个node_modules，它其实在工程里是一个文件夹，里面存放了全部的js，Android，iOS都须要的一个共同类库以及源码，全部的通讯、组件都在这个里面。因此，三个工程里都须要读这个文件夹里的东西，可是咱们不用关心具体，这个是由npm来自动下载的。只须要安装文档提示配置好这个文件夹的路径就ok了。

01性能问题

这里，个人理解是，性能必定不如纯原生写的。

关于RN写出来的应用的性能问题其实一直都是全部开发人员所关心的问题。RN一直说的是全都是调用的是原生的控件，因此理论上和原生写的App是不存在性能差别的。

原生封装的控件，在RN这边以组件的方式来使用。我有一篇文章以WebView为例讲述了一下原生控件和RN组件的关系(React Native Android从源码看WebView 没有OverrideUrl解决办法，以及高度自适应)。用RN调用的全部组件的属性参数都是通过了js到java/objective-c/swift的转换后，才最终渲染成原生封装的控件。而控件在运行中的事件回调也是通过了语言通讯，才将信息回调给js。我对语言通讯这一块的性能耗时不太了解，可是应该能够确定的是，原本直接就能够完成的事情，通过了语言转换，确定是有损耗的。只是Facebook把这个性能作了很大的优化，再加上如今手机硬件的性能愈来愈强大，因此，在大部分手机上这个损耗能够忽略。

02我认为的缺点

• **能作的事情不如原生灵活。**我前面说过，RN用的组件虽然是原生控件，可是是通过原生封装过的控件，有必定的局限性。为了作到跨平台，他并无把原生该控件的全部属性参数回调都暴露给js端。

• **坑会比原生开发更多。**原生开发，特别是Android有不少适配问题要考虑，这些大部分都是经验才能解决的坑，facebook开发人员在封装控件的时候若是没遇到过相关的坑，可能会解决的不完全，而js那边若是不了解原生的话，可能不能彻底明白问题出在哪了。因此，原生会遇到的坑，若是facebook没解决，理论上RN都会遇到。

• **技术栈会要求更高。**这个是确定的，最好是Android/iOS都要有点了解，这样写出来的应用才会更健壮。设计js与原生通讯的方案通用性才会更强。问题的排查也会更准确。

03我理解的优势

最后我才来讲优势，是由于虽然有前面的肯定，但这个技术自己确定是值得学习和发扬的。

• **js与原生的通讯机制比较完善。**注意我说的是比较完善，实际编码过程当中仍是有不少不如意的地方。可是知足绝大部分业务需求是没问题的。

• **能够支持自定义原生控件给RN用。**前面我说到，原生封装的控件若是不能知足你的业务需求，你能够本身封装控件，并选择性的暴露接口给RN用，固然这个适用于较为复杂的业务需求，若是大部分都控件都须要从新封装，还不如直接就原生写了。

• **支持热更新。**这无疑是比较重要的一个优势了，开始我就提到，对于原生了来讲，重要的是js编译的bundle文件，而热更新的方案也就能够从这点入手。将bundle文件和资源文件打成包，当成一个普通的文件下载，而后让原生指定读取路径就能够了。固然这个须要原生支持。

• **跨平台。**这也是一个很是重要的有点了。可是打包iOS，仍是须要必须的硬件配置，好比mac电脑。

• 可让更多的前端开发人员来写App。

04

至此！ 感谢阅读！