最近后端届格朗普雷县架构频现，相信很多有标识符格朗普雷县运行市场需求的合作开发人员单厢产生许多困惑：这些架构都有什么优劣？到底应该用别的？那么有请他们那时的主人公：Taro、WePY 、uni-app 、 mpvue 、 chameleon。上面小贴士将从多个视角详尽为大伙儿分析说明各架构的优劣。

何谓格朗普雷县

兰契总型

此类架构最小的特点就是从下层的图形发动机、产业布局发动机，到底层的 DSL，再到下层的架构全部由他们合作开发，代表者架构是 Qt 和 Flutter。此类架构缺点较为明显：操控性（的下限）高；各网络平台图形结果完全一致。缺点也较为明显：须要完全算数 DSL（QML/Dart），以及无法网络连接中国民族特色的端：小流程。

此类架构是最原初也是最正宗的的格朗普雷县合作开发架构，虽然下层到下层每一各环节都掌控在他们手里，也能最小可能将地去保证合作开发和跨端新体验完全一致。但它们的架构研制成本巨大，图形发动机、产业布局发动机、DSL、下层架构每一部分都须要大量物力合作开发保护。

Web 奥皮尔河

此类架构把 Web 技术（JavaScript，CSS）带回终端合作开发中，自研产业布局发动机处理 CSS，采用 JavaScript 写业务方法论，采用盛行的后端架构作为 DSL，各端分别采用各别的原生植物模块图形。代表者架构是 React Native 和 Weex，这种做的缺点有：

合作开发迅速F83E43Se后端自然生态更易学习上手，不管后端后端终端端，或多或少单厢一点 JS、CSS

缺点有：

可视化繁杂时无法写下高效能的标识符，此类架构的设计就必然导致 JS 和 Native 之间须要通讯，近似于表情符号操作这种频密地促发通讯就很可能将使得 UI 无法在 16ms 内及时绘出。React Native 有许多新闻稿式的模块可以避免这个问题，但新闻稿式的读法极难满足繁杂可视化的市场需求。虽然没图形发动机，采用各端原生植物模块图形，相同标识符图形的完全连续性没第二种高。

JavaScript 校对型

像他们那时要介绍的几大架构，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 架构，以这个 DSL 架构为标准在各端分别校对为不同的标识符，各端分别有一个运行时架构或兼容模块库保证标识符正确运行。

此类架构的一个缺点是在移动端一般会校对到 React Native/Weex，所以它们也都拥有 Web 奥皮尔河架构的缺点。这看起来很美好，但实际上 React Native/Weex 的缺点校对型架构也无法避免。除此之外，编译型架构的抽象也不是免费的：当 bug 出现时，问题的根源可能将出在运行时、校对时、模块库以及三者依赖的库等等各方面。

但这并不意味着此类为了小流程而设计的格朗普雷县架构就都不堪大用。首先现在各巨头超级 App 的小流程百花齐放，架构会为了抹平小流程做了许多工作，这些工作在大部分情况下是不须要合作开发人员关心的。其次是许多业务类型并不须要繁杂的方法论和可视化，没那么容易促发到架构下层依赖的 bug。

那么当你的业务适合选择校对型架构时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有格朗普雷县市场需求业务通常都希望能快速合作开发，一个能够快速适应团队合作开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优劣，大家可以根据团队技术栈和偏好自行选择。

自然生态

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

合作开发工具

就合作开发工具而言 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 > WePY、mpvue

上面他们一起来看一张表格：

格朗普雷县支持度

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

但值得一提的是 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 > Taro、uni-app > mpvue、WePY

上面他们一起来看一张表格：

模块库/工具库/demo

作为开源时间最长的架构，WePY 不管从 Demo，模块库数量 ，工具库来看都占有一定优势。

uni-app 则有他们的插件市场和 UI 库，如果算上收费的架构和插件比起 WePy 也是完全不遑多让的。

Taro 也有官方保护的跨端 UI 库 taro-ui ，另外在状态管理工具上也有非常丰富的选择（Redux、MobX、dva），但 demo 的数量不如前两个。但 Taro 有一个转换微信小流程标识符为 Taro 标识符的工具，可以弥补这一问题。

而 mpvue 没官方保护的 UI 库，chameleon 第三方的 demo 和工具库也还基本没。

所以这轮的排序是（排序仅为笔者个人结论）：

WePY > uni-app 、taro > mpvue > chameleon

上面他们一起来看一张表格：

接入成本

接入成本有两个方面：

第一是架构接入原有微信小流程自然生态。虽然目前微信小流程已呈一家独大之势，开源的模块和库（例如 wxparse、echart、zan-ui 等）多是基于原生微信小流程架构语法写成的。目前看来 uni-app 、Taro、mpvue 均有文档或 demo 在架构中直接采用原生植物小流程模块/库，WePY 虽然运行机制的问题，很多情况须要小改一下目标库的源码，chameleon 则是提供了一个按步骤大改目标库源码的迁移方式。

第二是原有微信小流程项目部分接入架构重构。在这个方面 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 会放大招，是一个「对得起合作开发人员」的版本。笔者也非常期待 2.0 正式发布后 WePY 的表现。

区对于 mpvue 不管不顾不更新的质疑。

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

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

快应用和端拓展协议通用模块库和垂直类模块库面向研制的图形化合作开发工具面向非研制的图形化页面搭建工具

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

Taro 的未来也一样值得憧憬。Taro 即将要发布的 1.3 版本就会支持以下功能：快应用支持Taro Doctor，自动化检查项目配置和标识符合法性更多的 JSX 语法支持，1.3 之后限制生产力的语法只有 只能用 map 创造循环模块 一条H5 打包体积大幅精简

同时 Taro 也正在对终端端进行大规模重构；合作开发图形化合作开发工具；合作开发模块/物料网络平台以及图形化页面搭建工具。

结语

那说了那么多，希望能让你在选择架构的同时给你一点意见和启发。小贴士觉得如果不介意尝鲜和学习 DSL 的话，完全可以尝试 WePY 2.0 和 chameleon ，一个是酝酿了很久的 2.0 全新升级，一个有专门针对格朗普雷县合作开发的多态协议。

uni-app 和 Taro 相比起来就更像是水桶型架构，从工具、UI 库，合作开发新体验、格朗普雷县支持等各方面来看都没明显的短板。而 mpvue 虽然合作开发一度停滞，现在看来各方面都不如在小流程端基于它的 uni-app 。