From 16d0f483226d5b301f77de66285a4676c251c0be Mon Sep 17 00:00:00 2001 From: jimczj Date: Mon, 25 Feb 2019 12:35:18 +0800 Subject: [PATCH 01/11] feat: Taro UI 2.0 --- source/_posts/2019-02-25-taro-ui-2.0.md | 122 ++++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 source/_posts/2019-02-25-taro-ui-2.0.md diff --git a/source/_posts/2019-02-25-taro-ui-2.0.md b/source/_posts/2019-02-25-taro-ui-2.0.md new file mode 100644 index 0000000000..7a1b32cb3f --- /dev/null +++ b/source/_posts/2019-02-25-taro-ui-2.0.md @@ -0,0 +1,122 @@ +title: Taro UI 2.0 发布：新增自定义主题功能，适配更多小程序 +subtitle: 新增十一个组件，新增自定义主题功能，适配支付宝小程序、百度小程序 +cover: https://misc.aotu.io/jimczj/2018-08-27taro-ui.jpg +ckey: 2019-02-25-taro-ui-2.0 +categories: 小程序 +tags: + - 小程序 + - Nerv + - React + - Taro +author: + nick: 阿集 + github_name: jimczj +date: 2019-02-25 12:53:41 +wechat: + share_cover: https://misc.aotu.io/jimczj/taro@200x200.jpg + share_title: Taro UI 2.0 发布：新增自定义主题功能，适配更多小程序 + share_desc: 新增十一个组件，新增自定义主题功能，适配支付宝小程序、百度小程序 +--- + + + +## 前言 + +转眼间，Taro UI 发布已有半年，感谢大家的支持，让我们收获了GitHub 1400+ star。在此期间，我们不断完善组件库的功能和特性，新增了许多组件和小工具，包括但不限于: + +* 新增日历、索引选择、区域选择、图片选择等十一个组件 +* 适配支付宝小程序、百度小程序 +* 新增自定义主题功能 +* 新增主题生成器，以帮助开发者更好地使用自定义主题功能 +* 新增 Issue Helper，以帮助开发者更规范地填写 Issue + +## 新增组件 + +在 1.0 版本发布之后，我们又陆续新增了如下十一个组件： + +* 视图组件：页面提示、 分隔符、倒计时、 幕帘 、步骤条 +* 操作反馈：全局信息组件 +* 表单：图片选择器、区域选择器、索引选择器、日历组件、搜索栏 + +其中，在社区里呼声最高的组件，非日历组件所属。由于日历组件复杂度偏高，要适配多端环境难度偏大，纵观市面上的小程序 UI 组件库，包含日历组件的寥寥无几。尽管如此，我们团队的大鱼兄仍独自挑起重担，几乎完美地实现了该组件，此处掌声献给大鱼兄。 + +**日历组件功能预览：** + +![calender](https://misc.aotu.io/jimczj/calender.gif) + +## 适配支付宝小程序、百度小程序 + +在 1.0 版本适配微信小程序时，我们遇到了很多困难。比如： +* 微信小程序自定义组件使用 Shadow DOM 进行渲染，引起了以下几种问题： + - 组件之间无法使用相邻选择器，如组件间加 border 的需求，最终只能通过新增 props 给开发者自行控制 + - 无法自定义 flex 布局组件，最终只能提供样式给开发者自行使用 + +* Component 组件对应 wxss 文件的样式，只对组件 wxml 内的节点生效。经过不断探索，才发现 addGlobalClass 这一属性，需在自定义组件内激活 addGlobalClass 选项，才能使自定义组件被 app.wxss 或页面的 wxss 中的所有的样式定义影响。。 + +* 原生组件的使用限制。由于原生组件脱离在 WebView 渲染流程外，原生组件的层级是最高的，所以页面中的其他组件无论设置 z-index 为多少，都无法盖在原生组件上。由此导致模态框等组件无法遮挡 input、textarea等原生组件，造成穿透效果。 可喜的是，微信官方团队已经在改善该问题，对小程序原生组件引入了同层渲染模式。通过同层渲染，小程序原生组件可与其他内置组件处于相同层级，不再有特殊的使用限制。[详见](https://developers.weixin.qq.com/community/develop/doc/000aa28d030f60a3c4183eecb5d801?from=timeline)。 + +* 小程序不支持 requestAnimationFrame，无法很好地实现 js 动画。 + +克服完上述微信小程序的困难后，支付宝小程序和百度小程序的适配工作大多是解决样式和某些API的差异。得益于 Taro 良好的支持，Taro UI 的适配工作暂时告一段落。 + +## 新增自定义主题功能 + +Taro UI 1.0 发布时只有一套默认的主题配色，为满足业务和品牌上多样化的视觉需求，UI 库支持一定程度的样式定制。 + +Taro UI 的组件样式是使用 SCSS 编写的，如果你的项目中也使用了 SCSS，那么可以直接在项目中改变 Taro UI 的样式变量。 + +新建一个主题样式文件（例如 custom-variables.scss）并覆盖[默认主题变量](https://github.com/NervJS/taro-ui/blob/dev/src/style/variables/default.scss)： + +``` +/* 改变主题变量，具体变量名可查看 taro-ui/dist/style/variables/default.scss 文件 */ +$color-brand: #6190E8; +/* 引入 Taro UI 默认样式 */ +@import "~taro-ui/dist/style/index.scss"; +``` + +之后在项目的入口文件中引入以上的样式文件即可（无需重复引入组件的默认样式）。 + +目前，我们额外定制了京东主题和 7Fresh 主题色，可通过扫描以下二维码查看。 + +**京东主题：** + +![image](https://misc.aotu.io/jimczj/taro-ui-red.png) + + +**7Fresh 主题：** + +![image](https://misc.aotu.io/jimczj/taro-ui-purple.png) + + +## 新增主题生成器 + +为了让开发者更好地使用自定义主题功能，我们还新增了主题生成器。开发者可以使用该工具方便地定制 UI 主题。 + +**主题生成器地址：** https://nervjs.github.io/taro-ui-theme-preview/ + +**效果预览：** + +![theme-preview](https://misc.aotu.io/jimczj/theme-preview.gif) + +## 新增 Issue Helper + +虽然我们配置了 Issue Template，但仍有部分开发者没有根据规范填写 Issue。我们排查问题时经常需要再次询问版本号信息、复现代码等等，这不仅消耗我们维护项目的精力，还降低了 Issue 处理效率。因此我们参考了 Ant 和 iView 团队的做法，制作了 Issue Helper 页面，帮助开发者更规范地填写 Issue。 + +**Taro UI Issue Helper 地址：** https://nervjs.github.io/taro-ui-issue-helper/ + +此外，我们发现重复制作 Issue Helper 页面是一件很浪费劳动力的事情，于是将 Issue Helper 封装成一个命令行工具，开发者可以通过简单配置 `config.js`，执行命令 `issue-helper build` 就可以生成所需要的页面。 + +**Issue Helper 工具仓库地址：** https://github.com/jimczj/issue-helper + +## 未来计划 + +* 适配字节跳动小程序 +* 国际化 i18n + +## 致谢 + +感谢大家对 Taro UI 的使用与反馈，我们会致力于将 Taro UI 打造成高质量组件库，不断丰富组件功能与特性，紧跟 Taro 的步伐适配更多平台。 + +最后，欢迎关注并使用我们的组件库： + +https://github.com/NervJS/taro-ui From be096106163b65ad4328de94bd535bd36a977e97 Mon Sep 17 00:00:00 2001 From: jimczj Date: Mon, 25 Feb 2019 16:08:56 +0800 Subject: [PATCH 02/11] =?UTF-8?q?fix:=20=E4=BF=AE=E6=94=B9=E5=B0=81?= =?UTF-8?q?=E9=9D=A2=E5=9B=BE=E3=80=81=E5=88=86=E4=BA=AB=E5=9B=BE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/_posts/2019-02-25-taro-ui-2.0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/source/_posts/2019-02-25-taro-ui-2.0.md b/source/_posts/2019-02-25-taro-ui-2.0.md index 7a1b32cb3f..d5e604ce1e 100644 --- a/source/_posts/2019-02-25-taro-ui-2.0.md +++ b/source/_posts/2019-02-25-taro-ui-2.0.md @@ -1,6 +1,6 @@ title: Taro UI 2.0 发布：新增自定义主题功能，适配更多小程序 subtitle: 新增十一个组件，新增自定义主题功能，适配支付宝小程序、百度小程序 -cover: https://misc.aotu.io/jimczj/2018-08-27taro-ui.jpg +cover: https://misc.aotu.io/jimczj/taro-ui-2.0.jpg ckey: 2019-02-25-taro-ui-2.0 categories: 小程序 tags: @@ -13,7 +13,7 @@ author: github_name: jimczj date: 2019-02-25 12:53:41 wechat: - share_cover: https://misc.aotu.io/jimczj/taro@200x200.jpg + share_cover: https://misc.aotu.io/jimczj/taro-ui-share.jpg share_title: Taro UI 2.0 发布：新增自定义主题功能，适配更多小程序 share_desc: 新增十一个组件，新增自定义主题功能，适配支付宝小程序、百度小程序 --- From bb5e5c2aace86c628810a4126b66305dc130bfbb Mon Sep 17 00:00:00 2001 From: jimczj Date: Mon, 25 Feb 2019 17:54:15 +0800 Subject: [PATCH 03/11] =?UTF-8?q?fix:=20=E5=A2=9E=E5=8A=A0=20github=20?= =?UTF-8?q?=E8=BF=9E=E6=8E=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/_posts/2019-02-25-taro-ui-2.0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_posts/2019-02-25-taro-ui-2.0.md b/source/_posts/2019-02-25-taro-ui-2.0.md index d5e604ce1e..0440cd7b72 100644 --- a/source/_posts/2019-02-25-taro-ui-2.0.md +++ b/source/_posts/2019-02-25-taro-ui-2.0.md @@ -22,7 +22,7 @@ wechat: ## 前言 -转眼间，Taro UI 发布已有半年，感谢大家的支持，让我们收获了GitHub 1400+ star。在此期间，我们不断完善组件库的功能和特性，新增了许多组件和小工具，包括但不限于: +转眼间，Taro UI 发布已有半年，感谢大家的支持，让我们收获了 [GitHub](https://github.com/NervJS/taro-ui) 1400+ star。在此期间，我们不断完善组件库的功能和特性，新增了许多组件和小工具，包括但不限于: * 新增日历、索引选择、区域选择、图片选择等十一个组件 * 适配支付宝小程序、百度小程序 From 6dd68eb35d7ea33c2c7bde6ec9a824585dd62b1c Mon Sep 17 00:00:00 2001 From: jimczj Date: Tue, 26 Feb 2019 11:07:53 +0800 Subject: [PATCH 04/11] =?UTF-8?q?fix:=20=E6=96=87=E5=AD=97=E9=94=99?= =?UTF-8?q?=E8=AF=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/_posts/2019-02-25-taro-ui-2.0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_posts/2019-02-25-taro-ui-2.0.md b/source/_posts/2019-02-25-taro-ui-2.0.md index 0440cd7b72..00c45d89f3 100644 --- a/source/_posts/2019-02-25-taro-ui-2.0.md +++ b/source/_posts/2019-02-25-taro-ui-2.0.md @@ -38,7 +38,7 @@ wechat: * 操作反馈：全局信息组件 * 表单：图片选择器、区域选择器、索引选择器、日历组件、搜索栏 -其中，在社区里呼声最高的组件，非日历组件所属。由于日历组件复杂度偏高，要适配多端环境难度偏大，纵观市面上的小程序 UI 组件库，包含日历组件的寥寥无几。尽管如此，我们团队的大鱼兄仍独自挑起重担，几乎完美地实现了该组件，此处掌声献给大鱼兄。 +其中，在社区里呼声最高的组件，非日历组件莫属。由于日历组件复杂度偏高，要适配多端环境难度偏大，纵观市面上的小程序 UI 组件库，包含日历组件的寥寥无几。尽管如此，我们团队的大鱼兄仍独自挑起重担，几乎完美地实现了该组件，此处掌声献给大鱼兄。 **日历组件功能预览：** From bd1ec394fb851c2a19adef42d1c51a074cc4daba Mon Sep 17 00:00:00 2001 From: littly <544028951@qq.com> Date: Thu, 28 Feb 2019 23:22:10 +0800 Subject: [PATCH 05/11] =?UTF-8?q?feat:=20=E6=B7=BB=E5=8A=A0taro-h5?= =?UTF-8?q?=E4=BC=98=E5=8C=96=E7=9A=84=E6=96=87=E7=AB=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/_posts/2019-02-28-taro-h5-optimize.md | 241 +++++++++++++++++++ 1 file changed, 241 insertions(+) create mode 100644 source/_posts/2019-02-28-taro-h5-optimize.md diff --git a/source/_posts/2019-02-28-taro-h5-optimize.md b/source/_posts/2019-02-28-taro-h5-optimize.md new file mode 100644 index 0000000000..492f4f469d --- /dev/null +++ b/source/_posts/2019-02-28-taro-h5-optimize.md @@ -0,0 +1,241 @@ +title: 决战性能之巅 - Taro H5 转换与优化升级 +subtitle: 不只是能跑，我们还跑得快 +cover: https://img11.360buyimg.com/img/jfs/t1/11364/36/9481/35805/5c77fb25E6e83faef/1b17da7bcb48f841.jpg +ckey: 2019-02-28-taro-h5-optimize +categories: 小程序 +tags: + - 小程序 + - Nerv + - React + - Taro +author: + nick: 小立 + github_name: Littly +date: 2019-02-28 23:09:41 +wechat: + share_cover: https://img10.360buyimg.com/img/jfs/t1/22405/1/8604/16989/5c77fb25E865fae31/594259c936ac1e12.jpg + share_title: 决战性能之巅 - Taro H5 转换与优化升级 + share_desc: 不只是能跑，我们还跑得快 +--- + + + +## 前言 + +作为一个多端开发框架，Taro 从项目发起时就已经支持编译到 H5 端。随着 Taro 多端能力的不断成熟，我们对 Taro H5 端应用的要求也不断提升。我们已经不再满足于“能跑”，更希望 Taro 能跑得快。 + +我们经常收到用户反馈：为什么使用 Taro 脚手架创建的空项目，打包后代码体积却有 400KB+；也有用户在 Issue 中提到，Taro 的部分 Api 占用空间巨大，事实上功能却并不完美，等等。作为一个开源项目，我们非常重视社区开发者们的意见。所以在最新版本中，我们对 Taro H5 端的性能表现进行了优化。 + +作为运行时的基础，每一个 Taro 的 H5 端应用都需要引入 @tarojs/components 和 @tarojs/taro-h5 等基础依赖包。在编译、打包之后，这些依赖包大约会在首屏占用 400KB 以上的空间。如果开发者还使用了 UI 库，例如 Taro-UI，基础体积还会更大，这严重限制了 Taro H5 端应用的性能优化空间。 + +事实上，我们在 H5 端应用中并不会使用到全部的 Taro 组件和 Api。将这些依赖包全部打包进应用是没有必要，也是不合理的。进行死码删除（Dead code elimination），进一步缩减代码体积，就是我们的优化方向之一。 + +## 效果 + +在介绍具体细节之前，我们先看一看优化的效果，因为这可能会让你更有兴趣了解后面的内容。用一句话来说，效果非常显著。 + +我们建立了一个空项目，在项目配置中加入了`webpack-bundle-analyzer`插件以查看编译分析。下图是优化前的打包文件分析结果： + +![before](https://img11.360buyimg.com/img/jfs/t1/19501/21/8687/76054/5c77fb63E5d040dc5/12bcea35b5b780fb.png) + +而在优化后，对比非常明显： + +![after](https://img12.360buyimg.com/img/jfs/t1/24494/22/8574/92373/5c77fb63E4402b50f/2312218a7dccedf7.png) + +优化前生成的代码总大小为 455KB，而在优化后仅剩约 96KB，仅是原来的 1/5 左右。 + +## 你需要做什么 + +很简单，作为使用者，你不需要做任何代码上的改动，只需要将 Taro 更新到最新版本即可。但在看不见的地方，Taro 却默默地做了许多工作。下面会从原理出发，详细介绍 Taro 的工作。 + +## 原理 + +[死码删除（Dead code elimination）](https://en.wikipedia.org/wiki/Dead_code_elimination)是一种代码优化技术，可以删除对应用程序执行结果没有影响的代码。Web Fundamentals 的一篇文章有提到，treeshaking 是由 Rollup 提出的一种死码删除的形式。 + +> Tree shaking is a form of dead code elimination. The term was popularized by Rollup, but the concept of dead code elimination has existed for some time. +> +> -- [Reduce JavaScript Payloads with Tree Shaking](https://developers.google.com/web/fundamentals/performance/optimizing-javascript/tree-shaking/), Jeremy Wagner + +通过在构建时进行静态分析，编译工具可以分析出我们代码中真正的依赖关系。treeshaking 把我们的代码想象成一棵树，代码的每个依赖项看作树上的节点。将未使用过的依赖项从构建结果中移除，这就是 treeshaking 的基本思想。 + +那么，假设我们手头有一段代码，我们要怎样辨别其中可以删除的部分呢？答案是，通过分析副作用： + +```javascript +// add.js +export default function add（a, b）{ return a + b; } + +// add2.js +console.log('这是一个log') +export default function add2（a, b）{ return a + b; } + +// index.js +import add from './add.js' // 没有副作用，可以删除 +import add2 from './add2.js' // 有副作用，不能直接删除 + +// EOF +``` + +副作用这个名词对于了解函数式编程的同学肯定不陌生。修改外部状态，或者是产生输出等等，都是副作用；而存在副作用的代码，是不能被直接移除的。类似上面这个代码示意，add2 模块就是存在副作用的。 + +### 站在巨人的肩膀上 + +除了 Rollup 之外，支持 treeshaking 的工具/插件还有很多，比如 babel-plugin-transform-dead-code-elimination、uglify、terser等。 webpack 在 v2 之后就内置了对 treeshaking 的支持，并在 webpack@4 中对 treeshaking 功能进行了扩展。 + +Taro H5 端在构建过程中，使用 webpack 作为构建的核心。在 webpack 中使用 treeshaking 功能有几个需要注意的地方： + +1. 如果是 npm 模块，需要`package.json`中存在`sideEffects`字段，并且准确配置了存在副作用的源代码。 +2. 必须使用 ES6 模块语法。由于诸如`babel-preset-env`之类的 babel 预配置包默认会对代码的模块机制进行改写，还需要将`modules`设置为`false`，将模块解析的工作直接交给 webpack。 +3. 需要工作在 webpack 的`production`模式下。 + +webpack 的 treeshaking 工作主要分为两步。第一步是在模块级别移除未使用且无副作用的模块，这一步由 webpack 的内置插件完成；第二步是在文件级别移除未使用的代码，这一步由代码压缩工具 Terser 完成的。 + +### 移除未使用的模块 + +前面我们提到，需要在`package.json`中配置`sideEffects`字段。 + +在 [webpack 文档](https://webpack.js.org/guides/tree-shaking/#mark-the-file-as-side-effect-free) 中有提到，这一举动正是为了让 webpack 正确地识别到没有副作用的代码模块。 + +在 webpack 中，模块依赖分析是由内置插件 [SideEffectsFlagPlugin](https://sourcegraph.com/github.com/webpack/webpack/-/blob/lib/optimize/SideEffectsFlagPlugin.js) 进行的。 + +![image-20190225220418363](https://m.360buyimg.com/img/jfs/t1/14100/24/8582/236551/5c77fbb1Ef1ec35cc/751d4324349728b8.png) + +经过 [SideEffectsFlagPlugin](https://sourcegraph.com/github.com/webpack/webpack/-/blob/lib/optimize/SideEffectsFlagPlugin.js)处理后，没有使用过并且没有副作用的模块都会被打上`sideEffectFree`标记。 + +在 [ModuleConcatenationPlugin](https://sourcegraph.com/github.com/webpack/webpack/-/blob/lib/optimize/ModuleConcatenationPlugin.js) 中，带着`sideEffectFree`标记的模块将不会被打包： + +![image-20190222111301698](https://m.360buyimg.com/img/jfs/t1/16074/5/8686/211783/5c77fbacE50bc5fe1/681ba09abcf55c11.png) + +来到这里，webpack 完成了在模块级别对未使用模块的排除。接下来，依靠 Terser，webpack 可以在文件级别，对未使用、无副作用的代码进行移除。 + +### 移除未使用的代码 + +在 CommonJS 规范中，我们通过`require`函数来引入模块，通过`module.exports`进行导出。这意味着我们可以在代码中的任何地方用任何方式引入和导出模块：可以是在某个需要等待用户输入的回调函数中，或者是在符合某个条件才进行引入等等。所以在使用 ES6 的模块系统之前，对 Javascript 做编译时的依赖关系分析是近乎不可能的（并不是完全不可能。prepack 通过实现一个 JS 解释器，甚至可以在编译时提前进行静态计算）。 + +```javascript +// utils.js +module.exports.add = function (a, b) { return a + b }; +module.exports.minus = function (a, b) { return a - b }; + +// index.js; +var utils = require('./utils.js'); + +utils.add(1, 2); +``` + +像上面这段代码，虽然我们最终只使用了`add`函数，但`minus`函数也会在最终的打包代码中出现，因为在编译时无法快速得知是否使用了`minus`函数。 + +在 ES6 的模块系统中，我们使用`import`/`export`语法来进行模块的引入和导出。与 CommonJS 规范不同的是，这套新的模块系统存在一些限制：`import`/`export`行为只能在代码的顶层、默认使用严格模式等等。这些限制使代码模块的导入与导出变得静态化，模块间的依赖关系在开发时已经确定，编译器也更容易解析我们的代码。 + +```javascript +// utils.js +export function add (a, b) { return a + b }; +export function minus (a, b) { return a - b }; + +// index.js; +import { add } from './utils.js'; +add(1, 2); +``` + +在使用 ES6 模块系统改造后，我们可以清楚地看到，`minus`函数确实没有被使用过，所以可以安全地将其从最终打包代码中移除。 + +当然，具体的分析过程非常复杂。变量提升、object 取值操作、`for(var i in list)` 语句、自执行函数、函数传参（`onClick(function a () {…})`）等等，都有可能导致意料之外的情况，从而导致 treeshaking 失效。如果想了解 Terser 的具体处理过程，百度/Google 会是最好的老师。 + +## Taro 做了什么 + +Taro 需要对依赖包做一些修改。 + +### 组件的 ES 模块化 + +在进行组件库的 ES 模块化改造之前，如果要发布 @tarojs/components 包，Taro 会执行命令 `yarn build`，使用 webpack 对源代码进行打包，输出为`dist/index.js`文件。由于 webpack 并不支持输出为 ES 模块，所以这是个 UMD 模块。 + +![image-20190225154632128](https://m.360buyimg.com/img/jfs/t1/22354/16/8646/21917/5c77fbacEdee5c349/e6af50961d434f09.png) + +这个文件占据了 462KB 的空间，并且由于模块规范等问题，无法进行 treeshaking。所以就算开发者在 Taro 的项目中只引入了两个组件，最终的打包结果也会包含所有的内置组件。 + +事实上，@tarojs/components 的源码本身是使用 ESM 规范的： + +![image-20190225160508956](https://m.360buyimg.com/img/jfs/t1/14453/5/8776/198331/5c77fbacE24aec263/74ceb998fe9f5059.png) + +所以只要让 webpack 直接解析组件库的源码，我们立即就可以享受到 webpack 自带 treeshaking 带来的好处了。 + +![image-20190225162018328](https://m.360buyimg.com/img/jfs/t1/21781/18/8661/46118/5c77fbacE28c35efd/ba6ed6939fa041ba.png) + +同时，我们也在`sideEffects`属性中对样式文件做了标记，帮助 webpack 对样式代码的副作用进行识别，在项目编译的代码中保留样式代码。 + +### Api 的 ES 模块化 + +同样，以前在发布 @tarojs/taro-h5 之前，Taro 也需要执行命令 `yarn build`，使用 Rollup 对源代码进行打包，输出为`dist/index.js`文件： + +![image-20190225162654885](https://m.360buyimg.com/img/jfs/t1/29124/32/8757/41440/5c77fbacEa1b2206c/fba8b10d73136327.png + +这个文件占据了 262KB 的空间。同样，只要是个 Taro 的 H5 端应用，生成的代码都会全量引入这个文件。 + +我们对 @tarojs/taro-h5 进行模块化改造的思路与 @tarojs/components 相同。我们希望 @tarojs/taro-h5 模块本身遵守 ESM 模块规范，那就只需要标记一下`sideEffects`，再修改一下模块入口就好。 + +![image-20190225165957461](https://m.360buyimg.com/img/jfs/t1/16633/12/8583/53807/5c77fbacE239aa77a/0d515de24217f5b5.png) + +粗略一看，@tarojs/taro-h5 还挺 “ESM” 的，但这还不够。我们还需要将这些 Api 以 namedExports 的形式导出，开发者使用`import { XXX } from '@tarojs/taro-h5'`导入 Api 即可。 + +![image-20190225172609369](https://m.360buyimg.com/img/jfs/t1/14351/23/8588/28303/5c77fbacEf0ec647b/0b8652e5a5bb49a7.png) + +那么问题来了。在 Taro 项目中，我们一直使用的是 defaultImport，并不会使用 Api 的 `namedExports` 形式： + +```javascript +import Taro from '@tarojs/taro-h5' + +Taro.navigateTo() +Taro.getSystemInfo() +// Taro.xxx ... +``` + +只要 Api 是通过对`Taro`变量取属性获取，`Taro`变量就需要具备所有的 Api，treeshaking 也就无从谈起。 + +有没有办法把 defaultImport 修改为 namedImports 呢？答案是肯定的。我们写了一个 babel 插件 babel-plugin-transform-taroapi，将指定的 Api 调用替换为 namedImports，未指定的变量则保留属性取值的形式。具体源码可以在__这里__查看。 + +```javascript +// const apis = new Set(['navigateTo', 'navigateBack', ...]) +{ + babel: { + preset: ['babel-preset-env'], + plugins: [ + // ..., + ['babel-plugin-transform-taroapi', { + packageName: '@tarojs/taro-h5', + apis + }] + ] + } +} +``` + +这个插件接受一个对象作为配置参数：`packageName`属性指定需要进行替换的模块名，`apis`接受一个 Set 对象，也就是所有 Api 的列表。 + +为了避免后期手动维护 Api 列表的情况，我们给 @tarojs/taro-h5 模块加了一个编译任务，通过一个简单的Rollup 插件，在执行`yarn build`命令时生成一份 Api 列表： + +![image-20190225210238592](https://m.360buyimg.com/img/jfs/t1/11020/15/9616/262595/5c77fbadE6f554c3f/c4d4bc42d65508cd.png) + +下面是编译前后的代码对比。可以看到，在编译后`setStorage`、`getStorage`的调用都被替换为 namedImports。 + +```javascript +// 编译前 +import Taro from '@tarojs/taro-h5'; +Taro.initPxTransform({}); +Taro.setStorage() +Taro['getStorage']() + +// 编译后 +import Taro, { setStorage as _setStorage, getStorage as _getStorage } from '@tarojs/taro-h5'; +Taro.initPxTransform({}); +_setStorage(); +_getStorage(); +``` + +到这里，虽然过程比较艰辛，但我们对 @tarojs/taro-h5 的模块化改造终于完成了。 + +## 最后 + +截至目前，Taro 在 H5 端的完成度已经很高，但是并不完美。未来，在对已有问题进行修复的同时，我们还将继续为 Taro H5 端带来更多新的特性，比如对社区中呼声相当高的`switchTab`、页面滚动监听`onPageScroll`、下拉刷新`onPullDownRefresh`等 Api 的支持，更加统一的页面切换动画，以及更加稳定的多页面模式等等。 + +Taro 发展到现在，离不开社区的支持。非常感谢在 github、微信群中踊跃反馈的开发者们。如果你对Taro有什么想法或建议，Taro 非常欢迎你来吐槽或观光： + +https://github.com/NervJS/taro From b7694ebf3d7b96a8c8a27b5125c4c5dd137d28eb Mon Sep 17 00:00:00 2001 From: littly <544028951@qq.com> Date: Fri, 1 Mar 2019 18:08:52 +0800 Subject: [PATCH 06/11] =?UTF-8?q?fix:=20=E6=9B=B4=E6=96=B0=E6=96=87?= =?UTF-8?q?=E7=AB=A0=E5=B0=81=E9=9D=A2=E5=9B=BE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/_posts/2019-02-28-taro-h5-optimize.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_posts/2019-02-28-taro-h5-optimize.md b/source/_posts/2019-02-28-taro-h5-optimize.md index 492f4f469d..a52a613762 100644 --- a/source/_posts/2019-02-28-taro-h5-optimize.md +++ b/source/_posts/2019-02-28-taro-h5-optimize.md @@ -1,6 +1,6 @@ title: 决战性能之巅 - Taro H5 转换与优化升级 subtitle: 不只是能跑，我们还跑得快 -cover: https://img11.360buyimg.com/img/jfs/t1/11364/36/9481/35805/5c77fb25E6e83faef/1b17da7bcb48f841.jpg +cover: https://img10.360buyimg.com/img/jfs/t1/21860/12/8740/42390/5c790470E1d0bbce9/9f9bb78d01f7564b.png ckey: 2019-02-28-taro-h5-optimize categories: 小程序 tags: From 91f9b84cee7bd305fa2bcd6797b7927ec00c06d4 Mon Sep 17 00:00:00 2001 From: yuche Date: Tue, 12 Mar 2019 21:34:21 +0800 Subject: [PATCH 07/11] =?UTF-8?q?feat:=20=E5=A2=9E=E5=8A=A0=E5=B0=8F?= =?UTF-8?q?=E7=A8=8B=E5=BA=8F=E6=A1=86=E6=9E=B6=E5=AF=B9=E6=AF=94=E6=96=87?= =?UTF-8?q?=E7=AB=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...3-12-mini-program-framework-full-review.md | 209 ++++++++++++++++++ 1 file changed, 209 insertions(+) create mode 100644 source/_posts/2019-03-12-mini-program-framework-full-review.md diff --git a/source/_posts/2019-03-12-mini-program-framework-full-review.md b/source/_posts/2019-03-12-mini-program-framework-full-review.md new file mode 100644 index 0000000000..9a9a01379a --- /dev/null +++ b/source/_posts/2019-03-12-mini-program-framework-full-review.md @@ -0,0 +1,209 @@ +title: 小程序框架全面测评 +subtitle: 小程序框架到底应该选哪个？ +cover: https://storage.jd.com/taro-resource/review.jpg +ckey: 2019-03-12-mini-program-framework-full-review +categories: 小程序 +tags: + - 小程序 + - Nerv + - React + - Taro +author: + nick: yuche + github_name: yuche +date: 2019-02-28 23:09:41 +wechat: + share_cover: https://img10.360buyimg.com/img/jfs/t1/22405/1/8604/16989/5c77fb25E865fae31/594259c936ac1e12.jpg + share_title: 小程序框架全面测评 + share_desc: 小程序框架到底应该选哪个？ +--- + + + +最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？ + +作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。 + +那么，当我们在讨论多端框架时，我们在谈论什么： + +## 多端 +笔者以为，现在流行的多端框架可以大致分为三类： + +### 1. 全包型 + +这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。 + +这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。 + +### 2. Web 技术型 + +这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有： + +1. 开发迅速 +2. 复用前端生态 +3. 易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS + +缺点有： + +1. 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 `JS` 和 `Native` 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。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。相信其它原理相同的框架也无法避免这一问题。 + +但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放，框架会为了抹平小程序做了许多工作，这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互，没那么容易触发到框架底层依赖的 bug。 + +那么当你的业务适合选择编译型框架时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发，一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优缺点，大家可以根据团队技术栈和偏好自行选择。 + +如果不管什么 DSL 都能接受，那就可以进入下一个环节： + +## 生态 +以下内容均以各框架现在（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` + + ![开发工具](https://storage.jd.com/taro-resource/develop_tools.png) + + +### 多端支持度 + +只从支持端的数量来看，`Taro` 和 `uni-app` 以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），`chameleon ` 少了头条小程序紧随其后。 + +但值得一提的是 `chameleon` 有一套自研[多态协议](//cmljs.org/doc/framework/polymorphism/intro.html)，编写多端代码的体验会好许多，可以说是一个能戳到多端开发痛点的功能。`uni-app` 则有一套独立的[条件编译语法](://uniapp.dcloud.io/platform)，这套语法能同时作用于 `js`、样式和模板文件。`Taro` 可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用[条件编译文件](https://nervjs.github.io/taro/docs/envs.html)（类似 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` + +![多端支持](https://storage.jd.com/taro-resource/duoduan.png) + + +### 组件库/工具库/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` + +![组件库/工具库/demo](https://storage.jd.com/taro-resource/component.png) + +### 接入成本 + +接入成本有两个方面： + +第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 `wxparse`、`echart`、`zan-ui` 等）多是基于原生微信小程序框架语法写成的。目前看来 `uni-app` 、`Taro`、`mpvue` 均有文档或 demo 在框架中使用原生小程序组件/库，`WePY` 由于运行机制的问题，很多情况需要改一下目标库的源码。`chameleon` 则没有相关 demo/文档/issue 提到相关内容。 + +第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章[《Taro 在京东购物小程序上的实践》](//aotu.io/notes/2018/09/11/taro-in-jd/)。其它框架则没有提到相关内容。 + +而对于两种接入方式 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` + + +![流行度](https://storage.jd.com/taro-resource/popluar.png) + + + +### 开源建设 + +一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。 + +从第三方贡献者数量来看，`Taro` 在这一方面领先，并且 `Taro` 的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方开发者贡献的。除此之外，腾讯开源的 `omi` 框架小程序部分也是基于 Taro 完成的。 + +`WePY` 在腾讯开源计划的加持下在这一方面也有不错的表现；`mpvue` 由于停滞开发了很久就比较落后了；可能是产品策略的原因，`uni-app` 在开源建设上并不热心，甚至有些部分代码都没有开源；`chameleon` 刚刚开源不久，但它的代码和测试用例都非常规范，以后或许会有不错的表现。 + +那么这一轮的对比结果是： + +`Taro` > `WePY` > `mpvue` > `chameleon` > `uni-app` + +最后补一个总的生态对比图表： + +![总表](https://storage.jd.com/taro-resource/all.png) + +## 未来 + +从各框架已经公布的规划来看： + +`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](https://github.com/didi/chameleon) +* mpvue: [https://github.com/Meituan-Dianping/mpvue](https://github.com/Meituan-Dianping/mpvue) +* Taro: [https://github.com/NervJS/taro](https://github.com/NervJS/taro) +* uni-app: [https://github.com/dcloudio/uni-app](https://github.com/dcloudio/uni-app) +* WePY: [https://github.com/Tencent/wepy](https://github.com/Tencent/wepy) + +(按字母顺序排序) \ No newline at end of file From 3e628d39e4d62965c19cb1a049a7bde035bff7c8 Mon Sep 17 00:00:00 2001 From: yuche Date: Wed, 13 Mar 2019 09:53:32 +0800 Subject: [PATCH 08/11] =?UTF-8?q?refactor:=20=E6=9B=B4=E6=94=B9=E4=BA=8C?= =?UTF-8?q?=E7=BA=A7=E6=A0=87=E9=A2=98=E5=A4=A7=E5=B0=8F=EF=BC=8C=E5=8F=91?= =?UTF-8?q?=E5=B8=83=E6=97=B6=E9=97=B4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...3-12-mini-program-framework-full-review.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/source/_posts/2019-03-12-mini-program-framework-full-review.md b/source/_posts/2019-03-12-mini-program-framework-full-review.md index 9a9a01379a..4f635efff9 100644 --- a/source/_posts/2019-03-12-mini-program-framework-full-review.md +++ b/source/_posts/2019-03-12-mini-program-framework-full-review.md @@ -11,7 +11,7 @@ tags: author: nick: yuche github_name: yuche -date: 2019-02-28 23:09:41 +date: 2019-03-12 23:09:41 wechat: share_cover: https://img10.360buyimg.com/img/jfs/t1/22405/1/8604/16989/5c77fb25E865fae31/594259c936ac1e12.jpg share_title: 小程序框架全面测评 @@ -29,13 +29,13 @@ wechat: ## 多端 笔者以为，现在流行的多端框架可以大致分为三类： -### 1. 全包型 +#### 1. 全包型 这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。 这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。 -### 2. Web 技术型 +#### 2. Web 技术型 这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有： @@ -48,7 +48,7 @@ wechat: 1. 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 `JS` 和 `Native` 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。 2. 由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。 -### 3. JavaScript 编译型 +#### 3. JavaScript 编译型 这类框架就是我们这篇文章的主角们：`Taro`、`WePY` 、`uni-app` 、 `mpvue` 、 `chameleon`，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 框架，以这个 DSL 框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。 @@ -65,7 +65,7 @@ wechat: ## 生态 以下内容均以各框架现在（2019 年 3 月 11日）已发布稳定版为标准进行讨论。 -### 开发工具 +#### 开发工具 就开发工具而言 `uni-app` 应该是一骑绝尘，它的文档内容最为翔实丰富，还自带了 IDE 图形化开发工具，鼠标点点点就能编译测试发布。 @@ -82,7 +82,7 @@ CSS 方面，所有框架均支持 `SASS`、`LESS`、`Stylus`，Taro 则多一 ![开发工具](https://storage.jd.com/taro-resource/develop_tools.png) -### 多端支持度 +#### 多端支持度 只从支持端的数量来看，`Taro` 和 `uni-app` 以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），`chameleon ` 少了头条小程序紧随其后。 @@ -101,7 +101,7 @@ H5 方面，`chameleon` 同样是由多态协议实现支持，`uni-app` 和 `Ta ![多端支持](https://storage.jd.com/taro-resource/duoduan.png) -### 组件库/工具库/demo +#### 组件库/工具库/demo 作为开源时间最长的框架，`WePY` 不管从 Demo，组件库数量 ，工具库来看都占有一定优势。 @@ -117,7 +117,7 @@ H5 方面，`chameleon` 同样是由多态协议实现支持，`uni-app` 和 `Ta ![组件库/工具库/demo](https://storage.jd.com/taro-resource/component.png) -### 接入成本 +#### 接入成本 接入成本有两个方面： @@ -131,7 +131,7 @@ H5 方面，`chameleon` 同样是由多态协议实现支持，`uni-app` 和 `Ta `Taro` > `mpvue` 、 `uni-app` > `WePY` > `chameleon` -### 流行度 +#### 流行度 从 GitHub 的 star 来看，`mpvue` 、`Taro`、`WePY` 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。 @@ -146,7 +146,7 @@ H5 方面，`chameleon` 同样是由多态协议实现支持，`uni-app` 和 `Ta -### 开源建设 +#### 开源建设 一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。 From cebc5f7cf068e84f822e3dcedeeaa865111c1adb Mon Sep 17 00:00:00 2001 From: yuche Date: Wed, 13 Mar 2019 10:34:33 +0800 Subject: [PATCH 09/11] =?UTF-8?q?=E4=BF=AE=E6=94=B9=20chameleon=20?= =?UTF-8?q?=E7=9A=84=E6=8F=8F=E8=BF=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/_posts/2019-03-12-mini-program-framework-full-review.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_posts/2019-03-12-mini-program-framework-full-review.md b/source/_posts/2019-03-12-mini-program-framework-full-review.md index 4f635efff9..942bee54e5 100644 --- a/source/_posts/2019-03-12-mini-program-framework-full-review.md +++ b/source/_posts/2019-03-12-mini-program-framework-full-review.md @@ -121,7 +121,7 @@ H5 方面，`chameleon` 同样是由多态协议实现支持，`uni-app` 和 `Ta 接入成本有两个方面： -第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 `wxparse`、`echart`、`zan-ui` 等）多是基于原生微信小程序框架语法写成的。目前看来 `uni-app` 、`Taro`、`mpvue` 均有文档或 demo 在框架中使用原生小程序组件/库，`WePY` 由于运行机制的问题，很多情况需要改一下目标库的源码。`chameleon` 则没有相关 demo/文档/issue 提到相关内容。 +第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 `wxparse`、`echart`、`zan-ui` 等）多是基于原生微信小程序框架语法写成的。目前看来 `uni-app` 、`Taro`、`mpvue` 均有文档或 demo 在框架中直接使用原生小程序组件/库，`WePY` 由于运行机制的问题，很多情况需要小改一下目标库的源码，`chameleon` 则是提供了一个按步骤大改目标库源码的迁移方式。 第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章[《Taro 在京东购物小程序上的实践》](//aotu.io/notes/2018/09/11/taro-in-jd/)。其它框架则没有提到相关内容。 From 1f1483d49b7d46350bbde1b4dc127f8a66885c57 Mon Sep 17 00:00:00 2001 From: yuche Date: Fri, 15 Mar 2019 16:18:40 +0800 Subject: [PATCH 10/11] =?UTF-8?q?fix:=20mpvue=20=E5=85=B6=E6=97=B6?= =?UTF-8?q?=E4=BB=A5=E6=94=AF=E6=8C=81=E5=A4=B4=E6=9D=A1=E5=B0=8F=E7=A8=8B?= =?UTF-8?q?=E5=BA=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/_posts/2019-03-12-mini-program-framework-full-review.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_posts/2019-03-12-mini-program-framework-full-review.md b/source/_posts/2019-03-12-mini-program-framework-full-review.md index 942bee54e5..08ffc0c8f3 100644 --- a/source/_posts/2019-03-12-mini-program-framework-full-review.md +++ b/source/_posts/2019-03-12-mini-program-framework-full-review.md @@ -96,7 +96,7 @@ H5 方面，`chameleon` 同样是由多态协议实现支持，`uni-app` 和 `Ta 所以最后一轮对比的结果是： -`chameleon` > `Taro`、`uni-app` > `mpvue`、`WePY` +`chameleon` > `Taro`、`uni-app` > `mpvue` > `WePY` ![多端支持](https://storage.jd.com/taro-resource/duoduan.png) From daac72c6546f078f63c55252994212b05bfa6b28 Mon Sep 17 00:00:00 2001 From: littly <544028951@qq.com> Date: Thu, 4 Apr 2019 10:27:50 +0800 Subject: [PATCH 11/11] =?UTF-8?q?fix:=20=E4=BF=AE=E5=A4=8D=E7=AC=94?= =?UTF-8?q?=E8=AF=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- source/_posts/2019-02-28-taro-h5-optimize.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/_posts/2019-02-28-taro-h5-optimize.md b/source/_posts/2019-02-28-taro-h5-optimize.md index a52a613762..faecccfbd8 100644 --- a/source/_posts/2019-02-28-taro-h5-optimize.md +++ b/source/_posts/2019-02-28-taro-h5-optimize.md @@ -166,7 +166,7 @@ Taro 需要对依赖包做一些修改。 同样，以前在发布 @tarojs/taro-h5 之前，Taro 也需要执行命令 `yarn build`，使用 Rollup 对源代码进行打包，输出为`dist/index.js`文件： -![image-20190225162654885](https://m.360buyimg.com/img/jfs/t1/29124/32/8757/41440/5c77fbacEa1b2206c/fba8b10d73136327.png +![image-20190225162654885](https://m.360buyimg.com/img/jfs/t1/29124/32/8757/41440/5c77fbacEa1b2206c/fba8b10d73136327.png) 这个文件占据了 262KB 的空间。同样，只要是个 Taro 的 H5 端应用，生成的代码都会全量引入这个文件。