手机版

WePY-小程序敏捷开发实践-掘金开发者大会

时间:2021-12-05 来源:互联网 编辑:宝哥软件园 浏览:

虽然这个话题在其他地方已经谈了很多次,但还是有很多新的内容。因为很多事情正在做或者想做。本次分享主要分为以下几个部分:

WePY  - 小程序敏捷开发实践丨掘金开发者大会(图1)

WePY 的介绍

WePY  - 小程序敏捷开发实践丨掘金开发者大会(图2)

WePY 的用户

WePY  - 小程序敏捷开发实践丨掘金开发者大会(图3)

上面显示的WePY用户并不都是数据。因为WePY用户没有办法自愿举报自己在用WePY,所以我只列出了我知道的在用WePY的公司,数据有限。

据我所知,最近有一个小程序——腾讯疫苗爆了朋友圈。前端使用WePY,后端使用腾讯开源的TARS项目。微信里也有大量使用WePY框架的小程序。

右边贴的聊天记录是我在WePY交流群收集的用户反馈。就反馈内容而言,感谢的话很多,说明WePY框架确实可以帮助开发者提高开发效率。呵呵,没有贴WePY的负面反馈,因为担心一页PPT不够贴:eyes:

WePY 的数据

WePY  - 小程序敏捷开发实践丨掘金开发者大会(图4)

WePY项目现在在Github上有超过13,900个Star。与其他前端框架相比,Vue、REAT等Star的数量可能达到10W,但都是国际项目。WePY是因为微信小程序才做的国内项目,有13000多星还是挺不错的。Star的数量不一定代表WePY是一个好的框架,但可以说明小程序流量很大,小程序的开发很有前景。开发人员需要像WePY这样的框架来帮助他们。这也是Taro、mpvue等类似优秀框架后来出现的原因。

目前有1300多期。这意味着我每天起床时都有10多个待办事项要处理。再加上公司每天还有其他事情需要处理,这个事情还是挺大的。

目前有超过320个拉取请求。和其他开源项目相比,这个PR量还是相当不错的。我非常感谢为WePY做出贡献的开发者。

用户超过4000人。这个数据的来源是我建立的WePY交流群。目前这个交流群有4000多人。

WePY 是什么

WePY  - 小程序敏捷开发实践丨掘金开发者大会(图5)

将网络应用程序与小程序进行比较。Web App的功能与小程序类似。开发Web App时,可以使用Vue.js作为其核心库,并与Webpack一起打包。在微信小程序中,我们可以简单地将WePY理解为Web App中Vue.js Webpack的组合。

WePY 的特点

0922/0U941D63-5.jpg" />

WePY 在开发中到底帮助开发者做了什么事情呢?WePY 又有哪些特点呢?

  1. 脚手架:它提供了一个相当于 vue-cli 的脚手架,一行命令生成简单的 demo 项目。用户可以基于这个 demo 进行开发,省去了启动项目前繁琐的配置。
  2. 编译打包:原生开发小程序缺失了许多能力,比如 LESS、SASS。很多用户面对这个问题都是做一个简单的 Gulp 编译。WePY 自带了编译打包能力,想用 LESS、SASS、NPM 等可以直接使用 WePY 的打包工具输出小程序可以运行的代码。
  3. 核心库:核心库类似 Vue、React 等。WePY 核心库包含一些简单的 API 封装帮助处理一些事情。
  4. 特性与优化:开发上,WePY 提供了一些语法糖,可以简单方便的实现一些复杂功能。性能上,小程序本身的性能有一些问题,WePY 把性能上的问题抹平了,开发者不用关心性能这部分。
  5. 复用与扩展:复用方面,原生小程序使用 npm 资源需要将相对应的资源下载并放到代码目录中,利用 WePY 可以直接安装 npm 包并使用。扩展方面,在编译过程中,可以随意添加和扩展编译手段,比如 LESS、SASS、编译插件等。
  6. 多端:利用 WePY 可以将一份代码运行在小程序、H5 等端。

WePY 的规划

WePY - 小程序敏捷开发实践丨掘金开发者大会(图7)

16年8月参加小程序内测,10月份开始着手代码转换相关的工作。在不停的迭代中,我发现还有很多事情可以做。比如可以将相关的工作抽象出来提供给其它开发者。于是在11月我对代码进行了重构,将 Gulp 编译部分抛弃重写并于 Github 开源1.1版本。

开源之后有很多人关注到这个项目,说明还是有不少人遇到了相应的问题。因此我做了更加具体的优化,在1.1版本上又一次重构,把编译流程抽象,提出了编译器和插件两个概念,方便用户进行扩展。

17年1月份发布1.4版本,对整个开发流程和开发者使用框架时的体验进行了更多优化,包括性能优化等。

1.6 版本开始考虑多端问题:小程序一套代码多端复用。

17年11月左右,小程序推出了原生组件。WePY 本身就是为了解决小程序组件的问题,原生组件发布之后,WePY 的使用场景就没有以前那么强了,所以我开始思考, WePY 需要做一个完全重构的版本。

18年2月份启动了该重构版本,这个版本主要是为了解决小程序原生组件相关的问题,是一个全新的重构版本。但由于各种原因,这个版本还没有正式公布。敬请期待!

WePY 的实现原理

WePY - 小程序敏捷开发实践丨掘金开发者大会(图8)

接下来我会讲一下 WePY 在技术上的实现原理。

WePY 解决的问题

WePY - 小程序敏捷开发实践丨掘金开发者大会(图9)

任何一个项目都是发现问题,解决问题的过程,WePY 要解决的问题就是:

  1. 组件化开发:小程序原生组件出现之前,小程序没有很好的组件化开发模式。比如我自己实现了一套 dialog,别人想使用的时候可能要把我的代码拷贝一份。实现了组件化之后,我只要把这个组件给他就好了。
  2. npm 资源:Web 发展至今,npm 库上有非常庞大的资源。但是原生小程序没有使用 npm 资源的能力,WePY 提供了这个功能。
  3. 前端工程化:前面提及的打包构建部分
  4. 性能优化
  5. 友好的开发体验:体验优化
  6. 跨平台支持:多端这部分

总的来说,WePY 解决的问题就是开发中遇到的痛点问题。

WePY 的架构

WePY - 小程序敏捷开发实践丨掘金开发者大会(图10)

上面是我写的两个核心的部分:CLI 以及 Core。Core 通过 CLI 编译,生成小程序端运行的代码。CLI 部分又分为 wepy、wepy-web ,分别负责 wepy 的编译和 wepy-web 的编译。其上又分为编译器和插件两部分,编译器涉及到目前主流的预处理器,类似 Webpack 的 loader 。插件是在编译之后要做的事情,类似于 Webpack 的 plugin。Core 部分分为 wepy 核心库、小程序核心库和 wepy-web 核心库。wepy-web 核心库比小程序多了 wepy components 和 wepy API 。小程序本身的一些内置组件,比如弹窗组件,想要多端运行都需要封装起来放在 wepy components 。小程序原生 API 需要通过 wepy API 封装。

web 本身还分很多平台种类,比如 browser、微信 h5、QQ h5,这些都需要分别适配,所以 wepy-web 之上是一个适配层。

整个 Core 之上,是用户封装的一些组件,比如上报、异步。还有一些功能组件,比如用户做的弹窗、toast、imageloader 等。

纵观整个 WePY,我的代码会通过 CLI 基于 Core 输出小程序端运行的代码。

WePY 的编译过程

WePY - 小程序敏捷开发实践丨掘金开发者大会(图11)

WePY 本身定义了一个文件后缀 .wpy 。编译时将该文件解析并拆分为 Style、Template、Script。拆分时,会解析并记录组件关系,包括事件、引用等。每个节点的信息都会被记录,在注入时生成到 JS 中,在 JS 中就可以知道组件关系并进行调用。生成完之后进入到 plugin,plugin 是用户自定义的,需要进行图片压缩、JS 混淆、wxml 压缩等处理。依次做完这些处理之后才会得到可以在小程序中运行的代码。

以上就是 WePY 的整个编译过程。

多端的实现

WePY - 小程序敏捷开发实践丨掘金开发者大会(图12)

在实现多端方面,面临着以下问题:

  • 开发模式

    小程序开发模式自成一派,与现有开发模式都不相同。好在使用 WePY 开发时,WePY 使用的是类 Vue 的开发语法,跟 Vue 开发模式很贴近,所以开发模式问题借助 WePY 非常好解决。

  • 标签与样式

    小程序与 H5 的标签不一样,但是可以直接做一些简单的转换处理。比如<view>转换为<div>。样式上小程序有一个 rpx 单位,在 750 px 的情况下直接 /2 将 rpx 转为 px。

  • 模版语法

    小程序有自己的模版语法,比如<wx-if>等,解析时可以做简单的转换。

  • 模块化

    小程序原生可以使用require,但是H5不可以。好在有很多工具值得借鉴,比如 webpack,browserify。

  • 内置组件及内置 API

    WePY 本身使用的是类 Vue 的语法,要转换为 Vue 运行在 Web 端的话,内置组件直接使用 Vue 的形式编写,使用时直接引入这个 Vue 组件。内置 API 使用 WePY 提供的 JSSDK 去模拟微信端、H5等提供的 API。

因此,多端实现完全可行。我们的一些项目完全利用 WePY 实现多端。

生态

WePY - 小程序敏捷开发实践丨掘金开发者大会(图13)

左边是在 Github 上看到的一些 UI 库,大家在使用 WePY 开发的时候可以直接利用这些 UI 库进行二次开发。右边是网上收集到的开发资源,包括开发组件、第三方模块等。Github 上 WePY 关键字搜索结果有900多页。从用户反馈来看,用户选择 WePY 的一个原因也是 WePY 诞生的时间长,生态比较完善。

WePY 的规划

WePY - 小程序敏捷开发实践丨掘金开发者大会(图14)

现有问题

WePY - 小程序敏捷开发实践丨掘金开发者大会(图15)

WePY 目前存在的核心问题是

  • 静态组件编译

    WePY 项目做的比较仓促,花了大概一个多月就上线了。最开始只是为了解决组件化的问题。因此它采用了静态组件编译这套方案,在编译组件时,直接将我写的组件进行静态替换,将我写的组件注入到页面中,做了一些隔离相关的事情。这导致动态 repeat 时会出现比较严重的 BUG。这是设计上的缺陷,也是急需解决的问题。

  • 语法解析

    xml 的解析用了一个存在问题的库,导致 xml 解析时经常出错。js 的解析设计之初没有考虑用语法树解析,而是使用正则进行解析。因为目前仅涉及解析和语法注入,实现起来都比较简单,所以没有考虑用 AST 语法树进行解析,导致用户没有按照规范写的一些代码在解析时会出现错误。

  • 类 Vue 语法

    从用户的反馈来看,大家更希望用 Vue 的语法而不是类 Vue 语法。这两个之间还是有一些差异的。

  • 数据绑定性能优化

    数据绑定时做了一些优化和处理。但这些优化和处理是通过脏数据进行的,帮助用户减少 setDate 的次数。但是后来再看,这块还是有可以优化的空间。

  • 错误处理机制

    目前 WePY 的错误处理还比较简单,没有一个通用的错误处理机制。用户在使用和编译时的报错很难追溯和定位。后面希望能做到在报错时可以定位到报错的文件和代码。

  • 测试用例覆盖度

    WePY 目前只有核心库被测试用例覆盖。CLI 部分很复杂没有做测试用例覆盖。这导致目前大部分问题都和 CLI 相关。在下一个版本要全部被测试用例覆盖。

编译

WePY - 小程序敏捷开发实践丨掘金开发者大会(图16)

上图是2.0版本编译部分的对比。左边是 1.0 的编译,右边是2.0正在做的事。前面有讲到1.0的编译是把.wpy 文件放到 CLI 中进行编译。CLI 本身涉及编译器和插件。在2.0中,将文件编译修改为了入口编译,从 App 入口,通过 CLI 自动解析依赖,CLI 中也只有插件,所有的核心功能都将通过插件实现。最后生成的除了小程序文件,还有 Vendor 文件(Vendor 文件是指所有的 npm 包都会打包到这个文件内)、资源文件以及自己引用的模块的文件。

插件化

WePY - 小程序敏捷开发实践丨掘金开发者大会(图17)

编译的核心部分是参考 Webpack 做的插件化编译。插件化的概念参考我上面做的图:固定一块板子,板子上有固定数量的挂钩,每个挂钩都可以挂不同的东西。每个挂钩放什么不清楚,但是每个挂钩都可以实现不同的功能。我只需要规定编译的流程,通过在挂钩中写不同的内容实现整个编译流程。所以整个编译过程变为:配置初始化:arrow_right:核心编译:arrow_right:输出文件。

插件化可以提供更高的扩展性和可复用性。所有的核心功能都依赖插件进行。用户觉得某个功能不合适的时候,完全可以自己写一个插件替换掉核心功能。用户可以对编译的任何一个环节进行修改。

数据绑定v1

WePY - 小程序敏捷开发实践丨掘金开发者大会(图18)

v1 的数据绑定:在初始化的时候对数据进行深拷贝做数据备份。每个流程都会预置 apply 动作,比如有一个点击事件,点击事件对数据进行修改后进入到 apply 流程,在 apply 流程中进行深比较得到脏数据,脏数据最终进入到 setDate 中。

右边是比较简单易懂的图:小明对文件 B 进行修改得到 B+,老师将 B+ 和 B 进行对比,得到修改的数据。这是一个同步流程。当小明叫小红修改 C 文件时,如果老师不再,需要小红主动叫老师对 C 文件进行对比。即手动调用 apply 流程。

数据绑定v2

WePY - 小程序敏捷开发实践丨掘金开发者大会(图19)

2.0 使用了 Vue 的数据绑定机制。在初始化时生成 Render Watcher,每个数据初始化时都会添加 observer。修改数据时记录修改的 key-path 并加入队列中,所有的修改动作都会触发 Watcher。在一个 nextTick 时间内会清空队列,并在 Render Watcher 中进行 setDate。setDate 环节根据记录的 key-path 进行 setDate。

相比小明和老师的故事:小明在修改文件时会主动记录修改的内容并发起通知,小红的操作方式与小明一致。当老师收到通知时,根据小明、小红的修改记录对修改的内容进行 setDate 的处理。

这种优化方式不需要手动调用 apply,也不需要关心异步流程。

质量

WePY - 小程序敏捷开发实践丨掘金开发者大会(图20)

第二个版本会先在内部项目运用,内部实践之后没有问题再开源。另外2.0版本测试用例覆盖度要完全覆盖。

开源经验分享

WePY - 小程序敏捷开发实践丨掘金开发者大会(图21)

规范

WePY - 小程序敏捷开发实践丨掘金开发者大会(图22)

如何保证开源项目的质量?

第一是文档规范。Readme 部分要言简意赅的讲明这个项目能做什么,一个简单的示例说明如何启动项目。Readme 要简洁,大家一眼能看到他想要的东西。

第二是 CI。将对应的状态放在 Readme,让开发者可以更安心的使用这个项目。

第三是 license。

还有 contributer 文档,代码规范、Git 规范等。

WePY - 小程序敏捷开发实践丨掘金开发者大会(图23)

测试使用了 Mocha 和 Istanbul,集成使用了 TravisCI,部署使用了 npm 和 lerna。

推广运营WePY - 小程序敏捷开发实践丨掘金开发者大会(图24)

推广运营方面主要靠自己发文章,做外链。另外我在公众号和微信群推了自己的文章。微信群做了一个机器人放入群码。

还做了文档监控,官方文档修改之后,我可以第一时间知道官方文档都修改了什么。以及监控报告,每天都会给我的微信推送今天项目有多少 star 、多少 issue 。

版权声明:WePY-小程序敏捷开发实践-掘金开发者大会是由宝哥软件园云端程序自动收集整理而来。如果本文侵犯了你的权益,请联系本站底部QQ或者邮箱删除。