Toc
  1. 一、性能问题
    1. 这里,我的理解是,性能一定不如纯原生写的。
  • 二、我认为的缺点
  • 三、我理解的优点
  • Toc
    0 results found
    bbcfive
    React Native与原生关系理解与对比

    零、关系理解
    avatar

    这个是我对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了。

    一、性能问题

    这里,我的理解是,性能一定不如纯原生写的。

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

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

    二、我认为的缺点

    • 能做的事情不如原生灵活。我前面说过,RN用的组件虽然是原生控件,但是是经过原生封装过的控件,有一定的局限性。为了做到跨平台,他并没有把原生该控件的所有属性参数回调都暴露给js端。

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

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

    三、我理解的优点

    最后我才来说优点,是因为虽然有前面的确定,但这个技术本身肯定是值得学习和发扬的。

    • js与原生的通信机制比较完善。注意我说的是比较完善,实际编码过程中还是有很多不如意的地方。但是满足绝大部分业务需求是没问题的。

    • 可以支持自定义原生控件给RN用。前面我说到,原生封装的控件如果不能满足你的业务需求,你可以自己封装控件,并选择性的暴露接口给RN用,当然这个适用于较为复杂的业务需求,如果大部分都控件都需要重新封装,还不如直接就原生写了。

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

    • 跨平台。这也是一个非常重要的有点了。但是打包iOS,还是需要必须的硬件配置,比如mac电脑。

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

    作者:Sunny玄子 链接:https://www.jianshu.com/p/d54bed57b262

    本文作者:bbcfive
    版权声明:本文首发于bbcfive的博客,转载请注明出处!