作者：coldsnap 原文：小程序多端框架全面测评 Fundebug经授权转载，版权归原作者所有。 最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？ 作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。 那么，当我们在讨论多端框架时，我们在谈论什么： 多端 笔者以为，现在流行的多端框架可以大致分为三类： 1. 全包型 这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。 这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。 2. Web 技术型 这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有： 开发迅速 复用前端生态 易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS 缺点有： 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 [代码]JS[代码] 和 [代码]Native[代码] 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。 由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。 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。相信其它原理相同的框架也无法避免这一问题。 但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放，框架会为了抹平小程序做了许多工作，这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互，没那么容易触发到框架底层依赖的 bug。 那么当你的业务适合选择编译型框架时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发，一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优缺点，大家可以根据团队技术栈和偏好自行选择。 如果不管什么 DSL 都能接受，那就可以进入下一个环节： 生态 以下内容均以各框架现在（2019 年 3 月 11 日）已发布稳定版为标准进行讨论。 1. 开发工具 就开发工具而言 [代码]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 [图片] 2. 多端支持度 只从支持端的数量来看，[代码]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 [图片] 3. 组件库/工具库/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 [图片] 4. 接入成本 接入成本有两个方面： 第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 [代码]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 [图片] 5. 开源建设 一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。 从第三方贡献者数量来看，[代码]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[代码] 已经发布了 [代码]2.0[代码] 的版本，主要是更新了其它端小程序的支持。但从代码提交， issue 的回复/解决率来看，[代码]mpvue[代码] 要想在未来有作为首先要打消社区对于 [代码]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[代码] 。 当然，Talk is cheap。如果对这个话题有更多兴趣的同学可以去 GitHub 另行研究，有空看代码，没空看提交： chameleon: https://github.com/didi/chameleon mpvue: https://github.com/Meituan-Dianping/mpvue Taro: https://github.com/NervJS/taro uni-app: https://github.com/dcloudio/uni-app WePY: https://github.com/Tencent/wepy (按字母顺序排序)

背景介绍 有赞微商城包括了 PC 端、H5 端和小程序端，每个端都有绘制分享海报的需求。最早的时候我们是在每个端通过canvas API来绘制的，通过canvas绘制有很多痛点，与本文要讲的海报渲染服务做了一个对比： [图片] 正是因为这些痛点问题，有同事就提出基于Puppeteer实现一个公共的海报渲染服务，使用方只需传入海报图片的html，海报渲染服务绘制一张对应的图片作为返回结果，解决了canvas绘制的各种痛点问题。 一、Puppeteer 是什么 Puppeteer是谷歌官方团队开发的一个 Node 库，它提供了一些高级 API 来通过DevTools协议控制Headless Chrome或Chromium。通俗的说就是提供了一些 API 用来控制浏览器的行为，比如打开网页、模拟输入、点击按钮、屏幕截图等操作，通过这些 API 可以完成很多有趣的事情，比如本文要讲的海报渲染服务，它用到的就是屏幕截图的功能。 二、Puppeteer 能做什么 Puppeteer几乎能实现你能在浏览器上做的任何事情，比如： 生成页面的屏幕截图或pdf 自动化提交表单、模拟键盘输入、自动化单元测试等 网站性能分析：可以抓取并跟踪网站的执行时间轴，帮助分析效率问题 抓取网页内容，也就是我们常说的爬虫 三、海报渲染服务 3.1方案设计 首先我们来看一下海报渲染服务的流程图： [图片] 其实整个流程还是比较简单的，当有一个绘制请求时，首先看之前是否已经绘制过相同的海报了，如果绘制过，就直接从Redis里取出海报图片的 CDN 地址。如果海报未曾绘制过，则先调用Headless Chrome来绘制海报，绘制完后上传到 CDN，最后 CDN 上传完后返回 CDN 地址。整个流程的大致代码实现如下： [代码]const crypto = require('crypto'); const PuppeteerProvider = require('../../lib/PuppeteerProvider'); const oneDay = 24 * 60 * 60; class SnapshotController { /** - 截图接口 * - @param {Object} ctx 上下文 */ async postSnapshotJson(ctx) { const result = await this.handleSnapshot(); ctx.json(0, 'ok', result); } async handleSnapshot() { const { ctx } = this; const { html } = ctx.request.body; // 根据 html 做 sha256 的哈希作为 Redis Key const htmlRedisKey = crypto.createHash('sha256').update(html).digest('hex'); try { // 首先看海报是否有绘制过的 let result = await this.findImageFromCache(htmlRedisKey); // 命中缓存失败 if (!result) { result = await this.generateSnapshot(htmlRedisKey); } return result; } catch (error) { ctx.status = 500; return ctx.throw(500, error.message); } } /** - 判断kv中是否有缓存 * - @param {String} htmlRedisKey kv存储的key */ async findImageFromCache(htmlRedisKey) { } /** - 生成截图 * - @param {String} htmlRedisKey kv存储的key */ async generateSnapshot(htmlRedisKey) { const { ctx } = this; const { html, width = 375, height = 667, quality = 80, ratio = 2, type: imageType = 'jpeg', } = ctx.request.body; this.validator .required(html, '缺少必要参数 html') .required(operatorId, '缺少必要参数 operatorId'); let imgBuffer; try { imgBuffer = await PuppeteerProvider.snapshot({ html, width, height, quality, ratio, imageType }); } catch (err) { // logger } let imgUrl; try { imgUrl = await this.uploadImage(imgBuffer, operatorId); // 将海报图片存在 Redis 里 await ctx.kvdsClient.setex(htmlRedisKey, oneDay, imgUrl); } catch (err) { } return { img: imgUrl || '', type: IMAGE_TYPE_MAP.CDN, }; } /** - 上传图片到七牛 * - @param {Buffer} imgBuffer 图片buffer */ async uploadImage(imgBuffer) { // upload image to cdn and return cdn url } } module.exports = SnapshotController; [代码] 3.2遇到的问题 2.3.1 Chromium启动和执行流程 最开始一个版本我们是直接Puppeteer.launch()返回一个浏览器实例，每次绘制会用单独的一个浏览器实例，这个在使用过程中发现绘制海报会很慢，后面优化时找到了这篇文章：Puppeteer性能优化与执行速度提升，这篇文章提到了两个优化点：1. 优化Chromium启动项；2. 优化Chromium执行流程。 先说优化Chromium启动项，这个就是为了我们启动一个最小化可用的浏览器实例，其他不需要的功能都禁用掉，这样会大大提升启动速度。 [代码]const browser = await puppeteer.launch({ args: [ '–disable-gpu', '–disable-dev-shm-usage', '–disable-setuid-sandbox', '–no-first-run', '–no-sandbox', '–no-zygote', '–single-process' ] }); [代码] 再来说说浏览器的执行流程，最开始我们是每次绘制都会用单独一个浏览器，也就是一对一，这个在压测的时候发现CPU和内存飙升，最后我们改用了复用浏览器标签的方式，每次绘制新建一个标签来绘制。 [代码]const page = await browser.newPage(); page.setContent(html, { waitUntil: 'networkidle0' }); const imageBuffer = await page.screeshot(options); [代码] 3.3.2 networkidle0 最开始我们的海报服务绘制海报时有时候会偶尔出现图片展示不出来的情况，我们排查后发现是因为我们setContent时，使用的是默认的load事件来判断设置内容成功，而我们期望的是所有网络请求成功后才算设置内容成功。 [代码]page.setContent(html); [代码] Puppeteer在setContent和goto等方法里提供了一个waitUntil的参数，它就是用来配置这个判断成功的标准，它提供了四个可选值： load：默认值，load事件触发就算成功 domcontentloaded：domcontentloaded事件触发就算成功 networkidle0：在500ms内没有网络连接时就算成功 networkidle2：在500ms内有不超过2个网络连接时就算成功 我们这里需要用到的就是networkidle0： [代码]page.setContent(html, { waitUntil: 'networkidle0' }); [代码] 当改成networkidle0后，使用方给我们反馈说整个绘制服务变慢了很多，随随便便都2s以上。变慢主要是因为加上networkidle0后，至少需要等待500ms以上，加上绘制的一些其他开销，基本上就需要2s了。所以我们期望这个500ms是可配置的，因为500ms实在太长了，我们的分享海报一般只有几张图片，不需要这么久。但是Puppeteer没有提供相关的参数，还好在issue中早已经有人提出了这个问题：Control networkidle wait time [代码]function waitForNetworkIdle(page, timeout, maxInflightRequests = 0) { page.on('request', onRequestStarted); page.on('requestfinished', onRequestFinished); page.on('requestfailed', onRequestFinished); let inflight = 0; let fulfill; let promise = new Promise(x => fulfill = x); let timeoutId = setTimeout(onTimeoutDone, timeout); return promise; function onTimeoutDone() { page.removeListener('request', onRequestStarted); page.removeListener('requestfinished', onRequestFinished); page.removeListener('requestfailed', onRequestFinished); fulfill(); } function onRequestStarted() { ++inflight; if (inflight > maxInflightRequests) clearTimeout(timeoutId); } function onRequestFinished() { if (inflight === 0) return; --inflight; if (inflight === maxInflightRequests) timeoutId = setTimeout(onTimeoutDone, timeout); } } // Example await Promise.all([ page.goto('https://google.com'), waitForNetworkIdle(page, 500, 0), // equivalent to 'networkidle0' ]); [代码] 利用这个函数我们就可以传入自己想要的超时时间了。 3.2.3 Chromium定时刷新机制 为什么需要定时刷新Chromium呢？总不可能一直用同一个Chromium实例吧，万一变卡或者crash了，就会影响海报的绘制。所以我们需要定时的去刷新当前的浏览器实例。 [代码]class PuppeteerProvider { constructor() { this.browserList = []; } /** - 初始化`puppeteer`实例 */ initBrowserInstance() { Array.from({ length: browserConcurrency }, () => { this.checkBrowserInstance(); }); // 每隔30分钟刷新一下浏览器 this.refreshTimer = setTimeout(() => this.refreshOneBrowser(), thrityMinutes); } /** - 检查是否还需要浏览器实例 */ async checkBrowserInstance() { if (this.needBrowserInstance) { this.browserList.push(this.launchBrowser()); } } /** - 定时刷新浏览器 */ refreshOneBrowser() { clearTimeout(this.refreshTimer); const browserInstance = this.browserList.shift(); this.replaceBrowserInstance(browserInstance); this.checkBrowserInstance(); // 每隔30分钟刷新一下浏览器 this.refreshTimer = setTimeout(() => this.refreshOneBrowser(), thrityMinutes); } /** - 替换单个浏览器实例 * - @param {String} browserInstance 浏览器promise - @param {String} retries 重试次数，超过这个次数直接关闭浏览器 */ async replaceBrowserInstance(browserInstance, retries = 2) { const browser = await browserInstance; const openPages = await browser.pages(); // 因为浏览器会打开一个空白页，如果当前浏览器还有任务在执行，一分钟后再关闭 if (openPages && openPages.length > 1 && retries > 0) { const nextRetries = retries - 1; setTimeout(() => this.replaceBrowserInstance(browserInstance, nextRetries), oneMinute); return; } browser.close(); } launchBrowser(opts = {}, retries = 1) { return PuppeteerHelper.launchBrowser(opts).then(chrome => { return chrome; }).catch(error => { if (retries > 0) { const nextRetries = retries - 1; return this.launchBrowser(opts, nextRetries); } throw error; }); } } [代码] 这里还有一个点，我们给replaceBrowserInstance这个方法加了个重试次数的限制，当超出这个限制后不管有没有任务在进行都会关闭浏览器。这个是防止在某些特殊情况不能关闭掉浏览器，导致内存无法释放的情况。 四、展望 目前海报渲染服务的问题就是qps比较低，因为Chromium消耗最多的资源是CPU，当并发数变高时，CPU也随之变高，就会导致后面的绘制变慢。在4核8G的情况，大概是20qps左右。后面的主要精力就是如何去提升单机的qps，应该还有比较大的空间。还有就是看看能不能增加定时任务，在凌晨机器比较闲的时候提前绘制好一些常用的海报，这样当需要海报时就是直接从redis里取出来了，充分利用了机器的性能，也可以减少海报服务白天的压力。 五、相关链接： Puppeteer 性能优化与执行速度提升：https://blog.it2048.cn/article-puppeteer-speed-up/ Control networkidle wait time：https://github.com/GoogleChrome/puppeteer/issues/1353