跨端实践之造轮子

        最近随着使用ReactNative、公众号以及H5项目越来越多，为了统一开发技术及标准、提升逻辑模块的复用性、提升开发效率，于是开始设计一套解决上述问题的开发框架，目标就是一次开发，可以在ReactNative及WebBrowser中运行（未来的目标会支持在更多的容器上运行）。

一、找轮子

        大家看到这里可能会有个疑问，这种框架在世界上最大的男性交友网站上应该有一大堆，为什么还要造轮子？个人觉得技术框架，有能力自己打造还是要自己打造，我们可以去学习别人的思路，最好不要直接使用，即使做出来的轮子可能会有性能不好或者不好用等问题，但是自己打造的轮子是最可控的，正所谓知己知彼、可进可退。在经过一段时间的摸索了解，目前业界主流四种解决方案大致如下。

1. 由React.js转换到ReactNative。

        这个方案比较适合优先考虑H5的开发团队，由于ReactNative的样式是CSS3中的子集，这样子的转换是有损转换，可能会影响布局和功能。目前业界比较少使用这种方案，没找到有相关的资料，但是理论上应该是可以的。

2.封装一套抽象框架。

        这个方案就是在ReactNative及React.js的上层再抽象出一套开发框架，用于抹平两者之间的差异。类似于微软发布的ReactXP。这种方案适合于想要追求三端有较高的用户体验，但相关开发人员较少的团队。但是这个方案有不好的地方，就是增加了开发人员的学习成本，同时很多功能的实现也受限于抽象框架的完善程度，目前ReactXP对ReactNative组件的支持还是比较有限。

3.由ReactNative转换到React.js

        这种方案与第一种相反，它是优先在ReactNative中进行界面开发，优先保证App端的体验及完整性，然后再考虑Web端的可用性。正如上面所说的，由于ReactNative样式是CSS3中的子集，至少在转成H5的时候，不会丢失功能及属性，在可行性及可用性方案都会比较有保障，目前业界较多使用这个解决方案，GitHub上面也有很多开源的框架，例如淘宝的react-web，国外的react-native-web等，特别是react-native-web使用的用户也很多。但是这个方案也有缺点，就是依赖开源框架目前支持转换的组件，有些基础组件或者第三方转换的组件未必能及时跟进。再者，生成的Web页面的样式类名及样式可维护性较差。

4.用JSX语法(VUE也有)，通过编译器编译对应的多平台

        这种方案就是利用JSX语法或者VUE的语法，这样子减少开发人员的学习成本，平台间的差异由编译器抹平解决，这个方案从兼容性、体验性来讲都会比较均衡，类似的框架有阿里的Weex和近期京东开源的Taro，这两个框架还没试用过暂时无法评论，但是从网友的一些反馈来讲，Weex坑多，且得靠自己消化，从Taro的宣传资料来看，Taro是基于京东的Nerv框架（类React.js，据说近期在申请专利，我有一个差不多的框架也在申请专利），对于掌握了React.js的开发技术的人员来讲基本可以无缝对接，但是与第三方组件对接上还未实现支持。

二、造轮子

        通过上面4种轮子的比对分析，结合目前团队需要业务组件及团队的技术结构 ，我想到了另外一种思路，就是接受移动端及Web端的平台间的差异，基于JSX语法（降低学习成本），重点关注复用业务组件层（代码多端复用），按照ReactNative目前已支持的组件及API进行抽象，封装成对应的Web组件、RN组件及API。同时为了保证Web端的体验，Web的样式与RN的样式分离，实现同一源码的页面可以在ReactNative上运行，也可以在WebBrowser上运行，以后如果业务需求需要引入小程序，那么可以通过基础组件库增加小程序组件进行兼容即可。此方案的难点在于如何解决样式问题，这个我将在后面单独写一篇我的踩坑心得来分享。基础架构图如下。

image

1.基础组件库封装

        通过抽象组件，以ReactNative组件为主，统一接口及属性。第三方组件也需要包装成为抽象组件，所有的业务组件都使用基础组件库，保证业务组件层可复用及可跨端。

2.封装基础组件样式

        Web端的样式与ReactNative端的样式是独立两套样式，主要是考虑到Web端的兼容性，RN的样式虽然是CSS3的子集，但是在Web端去应用的话就会有较多的兼容性问题，所以才考虑设计为独立的两套样式，在保证各端的体验性，又不增加过多的工作量。

3.封装API

        为了业务组件层的实现复用，还有一层API层需要处理，主要是像ReactNative中提供了很多Web端没有的API，例如导航、设备调用等，同样的H5中也有一些API是ReactNative中没有的，例如localStorage、sessionStorage等。这里采取与组件类似的处理方式即可，封装一层API抽象层，用于统一API接口调用。

4.封装路由及其他基础插件

        由于路由组件Web及ReactNative的版本的导出对象都不一样，所以也需要通过抽象接口实现统一。Ajax库直接复用我自己写的库，也可以使用第三方的库（ReactNative对这一块的设计比较周全，web的http请求可以平移，所以才可以复用Web上的Ajax库）。

三、结语

        目前这个方案已开始在项目中实施，在造轮子的过程中也总结到了很多有趣的东西，后续将陆续分享出来。