多端框架的全方位大测评

现如今市面上「端」的形态多种多样，Web、App、小程序等各种端大行其道。

当业务要求我们同时在不同端都有所表现的时候，如果针对不同的端去编写不同的代码，其开发成本显然非常极其的高。因此这个时候，只编写一套代码就能适配到多端的能力，就显得极为需要了 。

正是因为大家对这种「一套代码，多端适配」的需求越来越大，各种各样的多端框架也就顺势而生。

多端框架的分类

现在流行的多端框架可以大致分为三大类：

• 全包型

• Web 技术型

• JavaScript 编译型

全包型

全包型框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL（领域特定语言），再到上层的框架全部由自己开发。

代表框架有 Qt 和 Flutter。

这类框架的优点非常明显：

• 性能（的上限）高；

• 各平台渲染结果一致；

但缺点也非常明显：

• 需要完全重新学习 DSL（QML/Dart）；

• 难以适配中国特色的端 —— 小程序；

这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。

Web 技术型

Web 技术型框架把 Web 技术（JavaScript、CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。

代表框架有 React Native 和 Weex。

这类框架的优点是：

• 开发迅速；

• 复用前端生态；

• 易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS；

缺点：

• 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 JavaScript 和 Native 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。虽然 React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求；

• 由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有全包型框架高；

JavaScript 编译型

JavaScript 编译型框架是先以 JavaScript 作为基础选定一个 DSL 框架，然后以这个 DSL 框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。

代表框架有 Taro、WePY、uni-app 、mpvue、chameleon。

这类框架最大的优点和创造它们最大原因就是适配小程序。

因为「全包型」框架和「Web 技术型」框架虽然可以跨系统平台，同时也都能编译运行在浏览器中（Qt 有 Qt for WebAssembly、Flutter 有 Hummingbird、React Native 有 react-native-web、Weex原生支持），但是都难以适配小程序端。

因此，这篇文章我们也主要是针对 JavaScript 编译型框架进行对比测评。

生态

以下内容均以各框架现在（2019 年 3 月 11 日）已发布的稳定版为标准进行讨论。

开发工具

就开发工具而言，在 JavaScript 编译型框架中 uni-app 应该是最有优势的了。它的文档内容最为详细丰富，还自带了 IDE 图形化开发工具，鼠标点点点就能编译测试发布。

而其它几个框架都是使用 CLI 命令行工具。但值得注意的是其中 chameleon 有独立的语法检查工具，Taro 单独写了 ESLint 规则和规则集。

在语法支持方面，mpvue、uni-app、Taro 、WePY 均支持 TypeScript，四者也都能通过 typing 实现编辑器自动补全。除了 API 补全之外，得益于 TypeScript 对于 JSX 的良好支持，Taro 也能对组件进行自动补全。

CSS 方面，所有框架均支持 SASS、LESS、Stylus，Taro 还多了一个 CSS Modules 的支持。

图表对比：

所以这一轮的对比结果应该是：

uni-app > Taro > chameleon > myvue、WePY

多端支持度

单从支持端的数量来看，Taro 和 uni-app 以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），chameleon 少了一个头条小程序紧随其后。

但值得一提的是：

• chameleon 有一套自研多态协议，编写多端代码的体验会好许多，可以说是一个能戳到多端开发痛点的功能；

• uni-app 则有一套独立的条件编译语法，这套语法能同时作用于 JS、样式和模板文件；

• Taro 可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用条件编译文件（类似 React Native 的方式）；

在移动端方面：

• uni-app 基于 weex 定制了一套 nvue 方案 弥补 weex API 的不足；

• Taro 暂时基于 expo 达到 uni-app 同样的效果；

• chameleon 在移动端有一套 SDK 配合多端协议与原生语言通信；

在 H5 方面：

• chameleon 同样是由多态协议实现支持；

• uni-app 和 Taro 则是都在 H5 实现了一套兼容的组件库和 API；

• mpvue 和 WePY 都提供了转换各端小程序的功能，但都没有 H5 和移动端的支持；

图表对比：

所以这一轮的对比结果应该是：

chameleon > uni-app、Taro > myvue > WePY

组件库 / 工具库 / demo

• WePY 作为开源时间最长的框架，不管从 Demo、组件库数量 、工具库来看都占有一定优势；

• uni-app 有自己的插件市场和 UI 库，如果算上收费的框架和插件，比起 WePY 也是完全不遑多让的；

• Taro 也有官方维护的跨端 UI 库 taro-ui ，另外在状态管理工具上也有非常丰富的选择（Redux、MobX、dva），但 Demo 的数量不如 WePY 和 uni-app。不过 Taro 还有一个转换微信小程序代码为 Taro 代码的工具，可以弥补这一问题；

• mpvue 没有官方维护的 UI 库；

• chameleon 第三方的 Demo 和工具库也基本没有；

图表对比：

所以这一轮的对比结果应该是：

WePY > uni-app、Taro > myvue > chameleon

接入成本

接入成本有两个方面的考虑：

1. 框架接入原有微信小程序生态

   由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 wxparse、echart、zan-ui等）多是基于原生微信小程序框架语法写成的。目前看来：

• uni-app 、Taro、mpvue 均有文档或 demo 在框架中直接使用原生小程序组件 / 库；

• WePY 由于运行机制的问题，很多情况需要小改一下目标库的源码；

• chameleon 则是提供了一个按步骤大改目标库源码的迁移方式；

2. 原有微信小程序项目部分接入框架重构

   在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架暂时没有提到相关内容。

对于两种接入方式 Taro 都提供了 taro convert 功能，既可以将原有微信小程序项目转换为 Taro 多端代码，也可以将微信小程序生态的组件转换为 Taro 组件。

所以这轮的排序是：

Taro > mpvue 、 uni-app > WePY > chameleon

流行度

从 GitHub 的 star 来看，mpvue 、Taro、WePY 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来，因此估计三家的流行程度和案例都差不太多。

uni-app 则号称有上万案例，但不像其它框架有一些大厂应用案例。另外从开发者的数量来看是 uni-app 领先，它拥有 20+ 个 QQ 交流群（最大人数 2000）。

图表对比：

所以从流行程度来看应该是：

uni-app > Taro、WePY、mpvue > chameleon

开源建设

一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架 / 库生命力非常重要的标准。

• 从第三方贡献者数量来看，Taro 在这一方面领先，并且 Taro 的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方开发者贡献的。除此之外，腾讯开源的 omi 框架小程序部分也是基于 Taro 完成的；

• WePY 在腾讯开源计划的加持下在这一方面也有不错的表现；

• mpvue 由于停滞开发了很久就比较落后了；

• 可能是产品策略的原因，uni-app 在开源建设上并不热心，甚至有些部分代码都没有开源；

• chameleon 刚开源不久，但它的代码和测试用例都非常规范，以后或许会有不错的表现；

那么这一轮的对比结果是：

Taro > WePY > mpvue > chameleon > uni-app

生态汇总图表对比

最后补一个总体的生态对比图表：

未来发展

从各框架已经公布的规划来看：

• WePY 已经发布了 v2.0.alpha 版本，虽然没有公开的文档可以查阅到 2.0 版本有什么新功能/特性，但据其作者介绍，WePY 2.0 会放大招，是一个「对得起开发者」的版本；

• mpvue 已经发布了 2.0 的版本，主要是更新了其它端小程序的支持。但从代码提交、issue 的回复 / 解决率来看，mpvue 要想在未来有作为首先要打消社区对于 mpvue 不管不顾不更新的质疑；

• uni-app 已经在生态上建设得很好了，应该会在此基础之上继续稳步发展。如果 uni-app 能加强开源开放，再加强与大厂的合作，相信未来还能更上一层楼；

• chameleon 的规划比较宏大，虽然是最后发的框架，但已经在规划或正在实现的功能有：

  如果 chameleon 把这些功能都做出来，再继续完善生态，争取更多第三方开发者，那么在未来 chameleon 将大有可为。

• 快应用和端拓展协议

• 通用组件库和垂直类组件库

• 面向研发的图形化开发工具

• 面向非研发的图形化页面搭建工具

• Taro 即将要发布的 1.3 版本会支持以下功能：

  同时 Taro 也正在对移动端进行大规模重构、开发图形化开发工具、开发组件 / 物料平台以及图形化页面搭建工具。

• 快应用支持

• Taro Doctor，自动化检查项目配置和代码合法性

• 更多的 JSX 语法支持，1.3 之后限制生产力的语法只有「只能用 map 创造循环组件」一条

• H5 打包体积大幅精简

结语

那说了这么多，到底用哪个呢？

• 如果不介意尝鲜和学习 DSL 的话，完全可以尝试 WePY 2.0 和 chameleon ，一个是酝酿了很久的 2.0 全新升级，一个有专门针对多端开发的多态协议。

• uni-app 和 Taro 相比起来就更像是「水桶型」框架，从工具、UI 库，开发体验、多端支持等各方面来看都没有明显的短板。

• mpvue 由于开发一度停滞，现在看来各个方面都不如在小程序端基于它的 uni-app 。