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

1 方案背景

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

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

2 方案调研

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

通过对比目前的多端开发主要有以下几个大方向：

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