干货 | 小程序跨端框架实践之Remax篇

作者简介

 

汽车票前端研发团队，致力于提供更便捷更智慧的出行方式，关注前端技术方向的探索和实践。

一、项目背景

随着小程序在用户规模和商业化上取得的极大成功，各大平台都推出了自己的小程序。然而这些平台的小程序开发在语法上又不尽相同，不同平台小程序代码的维护需要投入很大的精力，在逻辑性上也很难达到统一的效果。虽然也有各种转换工具可以基于某一个平台转换出其他平台的代码，但转换的效果也是差强人意，往往还需要人工去修改。使用小程序跨端开发框架来实现一次开发、到处运行以提升效率，已经成为开发者强烈而迫切的需求。

目前，小程序跨端开发框架主要可以按照技术栈和实现原理两个维度进行分类。从技术栈来说，主流的跨端框架基本遵循 React、Vue 这两个前端开发最常使用的框架。由于所在团队主要使用的是React，所以本文主要介绍采用React语法的框架。从实现原理上，开源社区的跨端框架可分为编译时（compile time）和运行时（runtime）。

主流框架及其特点介绍如下表1-1所示：

  表1-1 React语法小程序跨端框架举例

框架	厂家	特征
Kbone	腾讯	不限技术栈，微信小程序和 Web 端同构的运行时解决方案，模拟了一套dom和bom接口，用以兼容现有的前端体系，只能用于Web兼容微信小程序，无法满足其他平台小程序的开发
Taro1/2	京东	类React，静态编译型框架仅在开发时遵循React语法，编译后运行时与React无关
Nanachi	去哪儿	React，静态编译型框架
Rax	阿里巴巴	以运行时方案为基础，支持局部场景使用编译时方案。运行时的支持基于Kbone，使用的是类React语法的Rax框架
Remax	蚂蚁金服	使用原生React来构建小程序，运行时框架，从Remax2.0开始支持Web应用的构建
Taro3	京东	不限技术栈，使用一套runtime层来兼容各种DSL，诞生于Remax之后

compile time编译时的跨端框架，主要的工作量在编译阶段。框架会把用户写的业务代码解析成 AST 树，然后通过语法分析将用户写的原始代码转换成符合小程序规则的代码。运行时模式的跨端框架通过适配层，实现自定义渲染器，是真正的在小程序的逻辑层中运行起React或Vue框架的方式，这种方式比静态编译有天然的优势。

编译时主要存在以下问题：灵活的JSX语法既可以写出非常复杂灵活的组件，同时也增加了编译阶段框架去分析和优化的难度。这就导致适配工作量巨大，维护成本较高，即使这样，也无法适配所有的写法。例如京东的Taro 1/2 用穷举的方式对 JSX 可能的写法进行了一一适配，但依然需要开发者遵循大量的语法约束，避免很多动态写法。否则代码就不能正常编译运行，开发效率难以保证。此外，由于 DOM 和 BOM API 的缺失，Web 上累积的各种前端生态，基本无法在编译时小程序中复用。京东的 Taro 1/2 , 去哪儿的 Nanachi都属于静态编译型的React或类React跨端框架。

与之相比，运行时方案的优势就在于能直接复用现有的前端生态。拿Remax来说，它最大的优势是可以几乎没有限制的使用React的语法完成代码编写，正如它的口号一样——使用真正React来构建跨平台小程序。此外，从Remax2.0开始，remax/one支持Web应用的构建。

我们团队做选型的时候Taro3还是待发布状态，所以没有做太多的考虑，下面着重去比较一下Rax和Remax。Rax和Remax都是出自阿里系但两个框架从设计思路上完全不同。

Remax从诞生之初就是为了支持小程序跨端框架Rax为了能尽量压缩React体积对React进行了重写，又引入了Driver机制来适配多端，这就意味着Rax有额外的学习成本，并且Rax不能随着React的迭代而更新。虽然Rax看似比较完善，提供了一套开箱即用的跨端API和完整的跨端UI控件支持，但它过多的依赖阿里的构建体系，似乎不太适合做为开源框架的选择。

综合以上几点考虑最终我们选择了Remax。

二、效果展示

图2-1到2-3分别为首页，列表页和详情页在Web和微信小程序上的运行效果，实现了一套代码多端运行，同时能做到同步更新。

图2-1 携程船票首页web和微信小程序运行结果

图2-2 携程船票列表页web和微信小程序运行结果