小程序多端框架评测：优缺点是什么？应该使用哪一个？

多端框架经常出现在前端领域。相信很多需要在多个终端上运行代码的开发者都会有一些疑问：这些框架的优缺点是什么？应该使用哪一个？

本文表达的观点可能存在偏见。您可以用批判的眼光看待它们并将它们用作建议。

那么当我们谈论多端框架时，我们在谈论什么：

多端

笔者认为目前流行的多端框架大致可以分为三类：

1 . 全面

这类框架最大的特点就是从底层的渲染引擎、布局引擎到中间层的DSL再到顶层的框架，全部都是自己开发的。代表框架是Qt和Flutter。这类框架的优点很明显：性能高（上限）；跨平台一致的显示结果。缺点也非常明显：需要彻底重新学习DSL（QML/Dart），而且很难适应中国特色的终端：小程序。

该类型框架是最原始、最纯粹的多终端开发框架。因为从底层到顶层的每一个环节都由你掌控，也能保证最大可能的一致开发和跨终端体验。然而，框架开发的成本是巨大的。渲染引擎、布局引擎、DSL和overlay框架的每个部分都需要大量的人力来开发和维护。

2。 Web技术类型

此类框架将Web技术（JavaScript、CSS）带入移动开发，自研布局引擎处理CSS，使用JavaScript编写业务逻辑，并使用DSL等流行的前端框架。每端都使用自己的本机组件进行渲染。代表框架是React Native和Weex。这样做的优点是：

1. 开发速度快
2. 前端生态的复用
3. 易学易用，无论前端还是后端移动端，你或多或少都会了解 JS 和CSS

缺点是：

1. 当交互复杂时，很难编写出高质量的代码。这类框架的设计必然会导致JS和Native之间需要进行通信。频繁激活通信，例如手势操作，很可能会导致用户界面无法在 16 毫秒内实时绘制。 React Native有一些声明式组件可以避免这个问题，但是声明式的编写方式很难满足复杂交互的需求。
2. 由于没有渲染引擎，且使用各端原有组件进行渲染，因此相同代码的渲染一致性没有前者高。

3。 JavaScript编译

这类框架就是我们这篇文章的主角：Taro、WePY、uni-app、mpvue、chameleon。它们的原理也类似：首先以JavaScript为基础选择一个DSL框架，默认使用这个DSL框架，并在两端编译成不同的代码。每端都有一个运行时框架或兼容的组件库，以保证代码正确运行。

创建此类框架的最大优点和原因是程序小，因为第一和第二框架不仅可以在系统平台之间工作，还可以在浏览器中编译和运行。 （Qt有Qt for WebAssembly，Flutter有Hummingbird，React Native有react-native-web，Weex有原生支持）

还有一个好处就是移动端一般都是编译成React Native/Weex的，所以他们也有Web技术类型框架的优点。这看起来很棒，但实际上 React Native/Weex 编译框架的缺点是无法避免的。而且，编译框架的抽象并不是免费的：如果出现bug，问题的根源可能在于运行时、编译时、组件库以及三者所依赖的库等。在 Taro 开源的过程中，我们遇到了 Babel bug、React Native bug、JavaScript 引擎 bug，当然还有 Taro 本身的 bug。我相信其他具有相同原理的框架也无法避免这个问题。

但这并不意味着这种为小程序设计的多端框架不能使用。首先，现在有数百个巨型超级应用程序的小程序。框架会做很多工作来平滑小程序。在大多数情况下，开发人员不需要费心处理这些任务。其次，很多业务类型并不需要复杂的逻辑和交互，框架的底层依赖也不是那么容易产生bug。

所以如果你的公司适合选择编译式框架，根据作者的说法，首先要考虑的是选择DSL时的出发点。由于具有多端需求的公司通常希望快速开发，因此能够快速适应团队开发节奏的DSL至关重要。 React 和 Vue（或类似 Vue）都有各自的优点和缺点，您可以根据团队的技术堆栈和偏好进行选择。

如果有什么DSL可以接受的话，可以继续看以下链接：

生态

以下内容是基于目前各个框架已经发布稳定版本（2019年3月11日）的情况来讨论的。

开发工具

就开发工具而言，uni-app 应该是最好的。该文档信息最丰富。它还附带图形化IDE开发工具，只需点击几下鼠标即可编译、测试和发布。

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

至于语法支持，mpvue、uni-app、Taro、WePY 都支持 TypeScript，而且这四个还可以通过打字实现编辑器自动补全。除了 API 补全之外，得益于 TypeScript 对 JSX 的良好支持，Taro 还可以自动补全组件。

至于CSS，所有框架都支持SASS、LESS和Stylus，Taro还有一个对CSS模块的支持。

所以本轮比赛的结果应该是：

uni-app

多终端支持

如果只看数量的话支持的终端数量上，Taro 和 uni-app 六大终端略领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），紧随其后的是没有头条小程序的变色龙。

但值得一提的是，Chameleon拥有自研的多态协议，使得多终端编写代码的体验变得更好。可以说是一个可以消除多终端开发痛点的功能。 uni-app有一套独立的条件编译语法，可以同时应用于js、样式和模板文件。 Taro 可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用条件编译文件（类似于 React Native）。

在移动端，uni-app基于weex适配了NVUE解决方案，以弥补weex API的不足； Taro暂时基于expo来达到同样的效果； chameleon 在移动端有一个 SDK，可以支持多终端协议和本地语言。沟通。

在H5方面，chameleon也有多态协议实现的支持，uni-app和Taro都有一系列兼容H5实现的组件库和API。

mpvue和WePY都提供了不同终端上小程序转换的功能，但都不支持h5和移动端。

所以最后一轮比较的结果是：

chameleon

组件库/工具库/demo

作为框架开源时间最长的WePY有demo，组件库数量和工具库都有一定的优势。

uni应用程序有自己的插件市场和UI库。如果包含付费框架和插件，它与 WePy 相当。

Taro 还有官方维护的跨终端 UI 库 taro-ui。此外，它还有非常丰富的状态管理工具选择（Redux、MobX、dva），但演示数量不如前两者。但Taro有一个将微信小程序代码转换为Taro代码的工具，可以弥补这个问题。

而且mpvue没有官方维护的UI库，Chameleon的demo和第三方工具库也基本还没有。

所以本轮的排名是：

WePY

访问成本

访问成本有两个方面：

第一个是框架的访问。原创微信小程序生态。由于现在微信小程序占主导地位，开源组件和库（如wxparse、echart、zan-ui等）通常是基于微信小程序框架的原生语法编写的。目前看来，uni-app、Taro 和 mpvue 都有直接在框架中使用原生小程序组件/库的文档或演示。由于WePY运行机制的问题，很多情况下需要对目标库的源代码进行细微的修改，而Chameleon提供了分步迁移的方法，可以大幅改变目标库的源代码。

二是对原有微信小程序项目的接入框架进行重构。对此，太郎在京东购物小程序上进行了大胆的实践。详情请参阅文章《Taro 在京东购物小程序上的实践》。其他框架没有列出相关内容。

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

所以本轮的排名是：

Taro 人气

从 GitHub 上的 star 来看，mpvue 的差距， Taro 和 WePY 都很小。根据 NPM 和 CNPM CLI 工具的下载量来看，Taro（3k/周）uni-app号称有上万个案例，但并没有像其他框架那样有一些来自大厂商的应用案例。此外，uni-app在开发者数量方面也处于领先地位。拥有20多个QQ交流群（最大人数：2000人）。

所以从受欢迎程度来看应该是：

uni-app