视频内容为什么选择React Native?
React Native的优势
ReactNative天生就提供了两端共享的一套业务代码。
具有接近原生的性能。
社区活跃,很多团队都选择React Native作为解决方案。
React Native的劣势
Learnonce write anywhere。
部分组件性能不好。
会产生一些早期开发成本和融合开发成本。
沪江应用现状
沪江应用现在大部分是三端独立完成的,整体的复用率很低。
通过Web容器接入在线页面来实现多端复用的需求。
问题-原生
原生最大的优势就是它的体验非常好。
它的缺点也很明显,一旦有需求要频繁发版,android和iOS需要维护两套代码,整体代码的复用率会很低。
问题-在线页面
业务方需要写大量兼容代码进行判断。比如在hybrid里需要调用容器暴露的方法,在H5里要调用原生的方法。
体验性相较于原生来说要差很多。
使用在线页面经常会有运营方劫持CDN的问题,遇到网络问题展示不出代码,令大家非常头疼。
三端融合
三端融合就是希望一套代码可以三端复用。但从我们的角度来讲,并不是所有页面都需要做三端融合,我们会通过一些限定来控制页面的复杂度。
思路与方案
我们考虑使用React Web组件,底层配合React。
第二种方案是直接用Bable从React Native代码直接编译到React的代码。
还有一种方案就是我们提供一套完整的Web框架,去完成从React Native代码到浏览器上的展现,都通过一套框架去实现。
React Web组件+React
如果使用React Web组件+React,初次开发的成本比较低。
ReactWeb的组件非常复杂,在开发每一个组件和API的时候成本还是比较高的,也会造成组件代码冗余。
API不确定,隐藏的风险就是如果React做了调整,整套框架都要做相应的调整。
底层的优化会很复杂。React是很难控制的,有些业务场景中需要优化,我们只是在React Web这一层做优化,但这一层的优化未必能很好地映射到下一层。
Bable编译+React
这个方案其实是一个有些莽撞的想法,它的业务复杂度会非常高,因为无法控制业务方写的代码。
它最大的优势就在于业务方后期可以做过转化之后再进行下一次的调整。但目前来看这个方案的成本还是过高。
Web组件+定制化框架
最后我们选择了Web组件+定制化框架。
我们把React Native代码视作一套DSL语言,中间放了一层我们自己的React框架,保证提供部分组件三端的兼容性,也会使用部分社区三端组件进行一些改造来达到我们的业务需求。
这个方案摆脱了组件和框架依赖关系中的不确定性。
有很多本来要在组件中完成的功能可以放到框架层去做,减少了组件中的冗余代码。
React内部调用可能只用了一个providesModule进行模块之间的调用,但Web组件是无法通过这种方式直接调用框架里这些能力的。我们可以把这些API从底层抛出来,在Web组件+定制化框架这套方案里直接引入这些API。
我们还需要做的功能就是确保组件的兼容性,要让组件在Native端和Web端都能使用。
API还会扩展到hybrid的方案中。可以在API层面做hybrid的判断,提供出在Web中更丰富的一些API能力,然后根据实际开发中的情况进行调整。
常用组件及API
在我们的业务中把React Native当作一个体验更好的H5页面来处理。
大多数开发React Native代码的人原来都是做Web开发的,Web思路下的开发大量组件和API并不会使用。对于不会使用的这些组件和API,我们会写一个空方法然后做一个提示。