背景

自2017年微信推出小程序以来，它瞬间成为了新晋网红，用户不再像过去一样需要下载笨重的APP才能体验某些功能，而是触手可及，即用即走，大大提升了用户体验。

从产品形态来看，电商、社交、平台、工具等各个行业也利用小程序找到了自己新的商业模式，获客、引流能力得到大幅提升。

技术层面，生态也在蓬勃发展。自微信小程序上线以来，支付宝、今日头条、百度等也纷纷推出了自己的小程序。与之相对应的是，为了在各个终端迎接小程序，开发框架也是层出不穷，但目的都是为了使开发更高效、更快捷，提供更好的开发体验。

注意事项

随着小程序越来越火爆，流利说少儿业务自然而然的在活动、拉新、工具等方面都有着非常多的小程序场景。作为前端技术团队，我们需要考虑如何在不影响自身开发体验的情况下，快速支撑业务的开发。因此需要综合考虑以下几个因素：

1. 小程序性能与质量

小程序最终还是要交付给用户，如果用户打开的小程序问题太多或者性能不佳，必然会影响用户体验，造成用户流失。

2. 开发经历

作为开发者，开发体验本身也尤为重要，比如IDE提示、构建打包速度、API文档的完备程度等。

3. 多终端支持

随着业务的发展，很多需求已经不局限于微信小程序本身，还可能放在公众号H5页面或者其他平台的小程序中，因此如果能够实现一次甚至一次Run，绝对能节省不少开发成本。

框架原理

以微信小程序为例，其底层框架体系分为逻辑层（App）和视图层（View）两部分，逻辑层主要负责JS运行，视图层主要负责页面渲染，它们主要进行Data通信和调用原生API。

从上图可以看出，无论小程序开发框架如何设计，都需要底层调用来通知视图的变化。根据实现方式不同，开发框架可以分为两种架构。

1.静态编译+运行时

将基于Ast技术的代码编译成小程序可以直接运行的代码，从而达到跨端开发的效果。

由于小程序的DSL与Vue语法类似，很多类Vue框架也是基于此架构，通过Ast解析，可以很轻松的将其转化为小程序的DSL，只需要修改Vue代码，处理好数据逻辑即可，比如Wepy等。

但由于 Jsx 语法的复杂性（写法有千万种），在被 Ast 编译到小程序的 DSL 中时，其复杂度要远大于 Vu​​e-like 框架，例如 ，这也是大部分小程序框架采用 Vue-like 语法的一大原因。

2. 重新运行时

整个生命周期直接在 Vue 框架本身中运行，突破了 DSL 的限制，因此理论上可以使用完整的框架 API，比如 等等。

这个架构的关键在于如何动态的将视图渲染到小程序页面，比如中间的库维护了创建、更新、删除虚拟 DOM 的指令，因此只需要重新实现其内部配置，然后调用对应的配置就可以达到与小程序交互的目的。

发展历程

儿童前端团队在小程序开发过程中经历了以下几个阶段

本国的

一开始只有比较简单的小程序需求，而且刚开始使用小程序，所以直接按照微信开发文档，选择了原生开发。

韦皮

使用原生方案开发小程序之后会发现，作为前端开发，npm 包管理等受到限制，当需求越来越复杂时，很多第三方库无法直接使用，影响开发效率和体验。

因此我们前期选择了腾讯自己的类Vue框架Wepy，基本解决了上述痛点。

芋头

作为一个追求开发体验和效率的前端团队，我们所有的项目都全面拥抱了它，包括小程序项目。Wepy 支持非常不友好，IDE 的提示和跳转能力几乎为零。

我们以 H5 框架为主，逐渐发展多端需求，所以决定尝试 Taro（3.0）作为小程序开发框架。Taro 3.0 是一个全新的架构体系，打着一次运行的口号，突破了基础 DSL 限制，几乎可以完全运行，并且动态构建模板，开发流程和写一个普通项目几乎一模一样。

由于运行时间较长以及微信底层模板渲染能力的限制，目前用其开发的小程序页面在低端机器上存在明显的性能问题。基于上一节提到的以用户体验为首要考虑因素，经过进一步调研，最终选择了该框架。

并且拥有once Run的理念，以及近乎完善的Vue生态和IDE支持，目前来说是一款比较适合我们团队的小程序框架。

对每个框架进行深入评估和比较

除了以上实际体验之外，还包含一些更详细的对比，以 6 Pro 手机为例。

跨端支持

生态系统支持

长列表点赞响应速度评估

PS.0中，wepy由于列表过大导致页面无法再渲染，导致数据不完整，而且wepy这两个框架已经停止维护。

.0 是因为节点是动态渲染的，当页面复杂时，节点数会超过微信的限制，同时因为接近全运行时实现， 的响应速度远高于其他框架，当采用渲染时，页面复杂度会导致层级过深，页面更新性能会有所下降，如下：

page.setData({ "root.cn.[0].cn.[0].cn.[0].cn.[0].markers": []})

更详细的分析请参见附录中的评论文章。

解决方案

随着深入使用，结合我们业务本身，我们逐渐形成了一套符合我们业务的标准化小程序解决方案，目录结构如下

├── README.md├── babel.config.js├── build // 构建配置├── dist // 输出目录├── package.json├── postcss.config.js // postcss├── public // H5模板│ └── index.html├── resource // 静态资源├── src│ ├── App.vue│ ├── common │ ├── components│ ├── config│ │ ├── dev.ts│ │ ├── index.ts│ │ └── prod.ts│ ├── custom-tab-bar // 自定义tabbar│ ├── main.ts // 入口文件│ ├── manifest.json // uniapp应用配置│ ├── mixins // 公共功能模块│ ├── pages // 页面│ ├── pages.json // uniapp全局页面配置│ ├── services // 接口│ ├── sfc.d.ts // 缺失的库定义文件│ ├── static // 静态图片│ ├── store // vuex数据流│ │ ├── index.ts│ │ └── modules│ └── utils // 工具包├── tsconfig.json // typescript配置├── vue.config.js // webpack配置└── yarn.lock

由于团队提供的cli构建的项目过于通用，配置不够完善，因此团队在此基础上构建了自己的解决方案，包含完整配置和通用IDE配置，以及基础组件和工具包，进一步提升了开发体验。

融合的

所需插件、、-、并打开、、属性。

最后的想法

俗话说“单线不成线，单木不成林”。小程序技术的积累是团队全体同学共同努力、不断总结的结果。目前这套小程序解决方案可以快速响应各类小程序或跨端开发需求，并且对开发者友好，提升研发效率，节省开发成本。

我们会持续关注小程序的发展和变化，不断优化小程序解决方案，适应需求和框架的快速变化。

参考