React Native 优先的多端统一化方案

1 方案背景

长期以来 APP、H5、小程序等各个端的定位和发展历程都不一样,各端技术栈差异性也较大,基于成本和效率考虑并不追求各端一致性,结果就是各端真的就渐行渐远了。

移动端增量红利越来越少的情况下,产品这边逐渐追求各端的产品体验一致性,多端同时上的需求越来越多,但是由于技术上割裂较大,工时基本都会按端加倍,开发成本奇高,迫切的需要一套减少多端开发成本的方案。

2 方案调研

开始之前我们对业界现有的一些跨端方案进行了简单的调研和了解。

React Native 优先的多端统一化方案_第1张图片
通过对比目前的多端开发主要有以下几个大方向:

  1. 对 IOS 和 ADR 的 native 端 APP 的适配
  2. 中国特色的针对各小程序平台的适配
  3. 都希望可以兼顾到对H5的转换

而实现方向上看起来五花八门,但总体思路上主要还是两个大方向:

  1. 提供自定义 DSL 静态编译转化成目标源代码(运行体验好)
  2. 运行时适配兼容(开发体验好)

这两种方式的优缺点都非常明显(相关框架和方案对比文章都较多,可自行详细了解)。目前社区基本都想在运行上努力,开发当然要自己爽啊,实际体验下来除了在微信小程序上性能问题较大之外,也没啥大毛病。

taro 作为较早的多端方案,适配性和兼容性都不错,自定义 DSL,JSX 由于其转译复杂性限制也较多。

taro-next 和 remax 都是运行时适配的方案,而 remax 的口号是 “使用真正的 react 构建小程序” (好好体会,后面要考)。

Chameleon 是号称兼容性和运行效率上都比较高的,编译和运行时适配的技术都用到了,不过由于他是支持的 weex 就没做深入尝试了。

其他像 alita,KBone,react-native-web 都在自己的小领域内能较好的运行。

3 方案介绍

3.1 解决思路

调研完发现上面的方案其实并不能很好的直接解决我们的问题:

Qunar 整体技术栈以 react 为主,几年前已将 APP 整体迁移到 RN 技术栈上,解决了 IOS

你可能感兴趣的:(大前端,react,native,前端)