作者 | 笑在秋风中

责编 | 伍杏玲

前言

从我接触小程序开始，到现在做了差不多有五六个小程序项目，其中小的只有几个页面，大项目有几十个页面。这篇文章是我对之前项目的一个总结，内容涉及到小程序的脚手架、开发框架和后期的优化。

如果你准备开发小程序或者已经在开发小程序，相信这些经验对你会有一定的帮助。

脚手架

小程序开发者工具是可以直接编写小程序的，但是开发工具就像武士手中的剑，经过多年磨炼，可以达到人剑合一了。如果突然换把武器，那势必影响杀敌效率，所以选择自己熟悉的开发工具还是很有必要的。

本人所在的公司是中小型公司，项目开发周期都很短，前期的准备工作最多也就几天时间。如果自己去撸一套脚手架用于项目开发的话，难度会比较大，所以在网上找优质的资源是最好的选择。

脚手架的选择是视项目而定的，如果只有几个页面的项目，搞一套很重的工具未免有点画蛇添足了。我们的做法是小项目的话，直接写，大点的项目选用网络上的优质资源加上自己改写。

1. gulp：

• 监听文件改动，实时编译，支持ES6+语法
  

• 脚手架地址：

  https://github.com/ranshaw/LearningLog/tree/master/weapp/gulp

2. WePY：

• 类Vue的开发风格

• 组件化开发

• 支持加载外部NPM包

• 使用babel编译，支持ES6/7的语法

• 针对原生API进行优化

3. weapp-start：

• 支持 npm 包引入

• 支持 Promise, async/await 等最新语法

• 支持多种编译器，如 pug/less/stylus

• 支持 ESlint

• 支持本地 mock 数据

• 支持一键生成项目，组件模版

• 支持发布前资源压缩

• 支持自定义插件

• 多种工具，加速开发

其中weapp-plugin-require在分析依赖和导入第三方 npm 时存在问题，windows操作系统会出现路径错误，我已修复，并给作者提了PR，但作者并没有修复这个问题，如果有同学要用到这个脚手架，请在文末下载我修改好的文件进行替换。

另推荐我根据weapp-start搭建的环境，目录结构为：

 ├── README.md                 // 说明文档
├── dist                      // 编译后的代码，用小程序开发工具打开此文件夹
├── mock.js                   // 模拟数据的文件
├── package-lock.json
├── package.json
├── project.config.json       // 项目配置文件
├── src                       // 项目代码都在这个文件夹下
│   ├── app.js                // 等同于小程序根目录下的app.js
│   ├── app.json              // 等同于小程序根目录下的app.json
│   ├── app.wxss              // 等同于小程序根目录下的app.wxss
│   ├── assets                // 项目中使用到的静态资源
│   │   └── images
│   │       ├── example
│   │       └── tab
│   ├── components            // 公用的组件
│   ├── page                  // 存放小程序的各个页面文件
│   │   ├── example           // example 页面
│   │   │   ├── components    // example页面中的组件
│   │   │   ├── index.js
│   │   │   ├── index.json
│   │   │   ├── index.wxml
│   │   │   ├── index.wxss
│   │   │   ├── services      // example页面中接口
│   │   │   ├── template      // example页面中的模板
│   │   │   └── wxs           // example页面中的wxs文件
│   │   ├── globalStore.js    // 全局共享的数据
│   │   └── test
│   │       ├── index.js
│   │       ├── index.json
│   │       ├── index.wxml
│   │       └── index.wxss
│   ├── template              // 公用的模板
│   └── utils                 // 公用的方法或工具
│       ├── config.js         // 全局的一些配置信息
│       ├── create.js         // 状态管理插件
│       ├── mitt.js           // 状态管理插件
│       ├── obaa.js           // 状态管理插件
│       ├── util.js           // 公用方法
│       ├── wxRequest.js      // 封装的小程序请求数据方法
│       └── wxapi.js          // 对小程序api进行Promise封装

当然，网上也有很多优秀的脚手架，大家可以根据自己的需要选择哟。

小程序开发框架

17年的项目我没有使用开源的框架，直接使用原生小程序写的。开发过程并没有很多的坑，只记得当时用到了一个富文本的插件，wxParse，现在已5000多个Star了。不过现在小程序有了富文本组件rich-text。

下面是现在比较火热的三大小程序框架WePY、mpvue和Taro的特性：

1. mpvue（美团）

• 彻底的组件化开发能力：提高代码复用性

• 完整的 Vue.js 开发体验

• 方便的 Vuex 数据管理方案：便于构建复杂应用

• 快捷的 webpack 构建机制：自定义构建策略、开发阶段 hotReload

• 支持使用 npm 外部依赖

• 使用 Vue.js 命令行工具 vue-cli 快速初始化项目

• H5 代码转换编译成小程序目标代码的能力

2. Taro （京东）

• React 语法风格

• 支持使用 npm/yarn 安装管理第三方依赖

• 支持使用 ES7/ES8 甚至更加新的 ES 规范，一切都可自行配置

• 支持使用 CSS 预编译器，例如 Sass 等

• 支持使用 Redux 进行状态管理

• 支持使用 Mobx 进行状态管理

• 程序 API 优化，异步 API Promise 化等等

3. WePY （腾讯）

上文已列出，此处不再赘述。

三大框架分别是国内三家大佬的前端团队产物，印象中mpvue和Taro都是18年下半年出来的，WePY出来得最早，几乎和小程序同步。

mpvue拥抱了vue，Taro拥抱了React，WePY握住了vue的手，我没有用过mpvue和Taro。我们只是开发个小程序，不用做到H5和RN共用一套代码，所以在18年开发项目时选择了WePY。

后来了解到，WePY本来是腾讯内部员工的个人项目，后来腾讯看这个项目不错，就由官方来维护了。由此带来了一些问题：WePY前期的一些核心代码存在的缺陷，后期很难修复了，像脏检查机制，据说在2.0这块会有很大的改变。

贴一张WePY其中的一个Issue，我们当时的心情和他是一样一样的：

自己曾经写过一篇《WePy+weappx开发小程序遇到的坑以及解决方案》，文中列举了开发过程中遇到的一些问题和解决方式，感兴趣的同学可以看看。

如果你问我开发小程序选择哪个框架合适？

根据需求来定。

如果只是单纯地做个小程序，就不要用框架了，小程序的语法目前已经很完善了，何必要多学习两套语法呢。如果出了问题，又改不了他们框架，一句话概括下：小程序原生有的问题框架肯定有，原生没的问题，他们可能给你造出来。

当然，如果要写一套代码适用H5和RN,那么可以考虑下mpvue和Taro。作者更新很频繁，有团队维护，至于说能不能提高效率，还得看需求。我们现在已经不用任何框架了，小程序已经玩得很熟，没必要再折腾了。

小程序开发建议

在开发过程中，我们总结了一些比较好的开发经验如下：

1. 目录结构

上文中脚手架第三项中贴出的目录结构，是目前我们觉得比较好的一种形式。

按页面组织代码，将一个页面所需要的内容放在同一个文件夹中，方便日后的维护和复制。所以有公用组件时，统一放到外部的文件夹中。随着项目增大，这种目录结构会很方便。

2. 组件的层级

组件的层级不能太深，2层最好，不能超过3层。因为之前项目有的封装组件过度，层级太深，在后期维护时，根据数据传递一层层地去找代码，费劲。

3. 状态管理

目前小程序能用的状态管理框架是比较多的，像Redux、Mobx、weappx。这些都很好，我推荐使用过的weappx和打算用的omi-mp-create。

项目比较小可以不用，大项目还是用上吧，如果全都放到global中，就不好维护。

4. 频繁setData的功能放到组件中

在电商项目中，少不了类似倒计时这种功能的。

像这种需要频繁setData操作的功能，应该单独放到一个组件中，因为当你setData的时候，小程序会有一个遍历监听了data数据方法的过程，wxs中的函数都会执行，在我上文提到自己的脚手架中有这个例子weapp-quick-start，感兴趣的可以测试一下。

5. 使用WXS

小程序对js表达式的支持并不是很好，我也曾见过这样的代码：

 <block wx:if="{{drawgift.giftDetail.virtualGoods.length>1||((drawgift.giftDetail.realGoods.length>0||drawgift.giftDetail.couponGoods.length>0)&&drawgift.giftDetail.virtualGoods.length>0)}}">

把这些判断的逻辑放到wxs中，统一维护岂不是美哉。还有一点，官方说在 iOS 设备上小程序内的 wxs 会比 javascript 代码快 2 ~ 20 倍，所以能用还是要用起来的。

6. 控制包的大小，分包加载等

不用的包，别偷懒，统统删掉，至于分包加载等，推荐看下这篇文章，CSDN 博客《微信小程序：一些运行细节及针对性的优化策略》。

作者：笑在秋风中，一个享受编码过程的耿直猿人。目前就职于国内某上市房企，追求高效，热爱技术。

项目地址：

https://github.com/ranshaw/weapp-quick-start

本文经授权转自作者博客，原文地址：

https://juejin.im/post/5c41a2d6f265da61380f7c4d

【完】

---

 热 文 推 荐 

☞ 拼多多：“优惠券Bug属网络诈骗”；抖音多闪上架 App Store；任正非不知谁是接班人 | 极客头条

JavaScript 能写一切？Python 不服：盘它！

惊慌 Android！使用 3D 打印的头像可破解多款手机

区块链，会越来越无聊！

女程序员：我负责赚钱养家，老公负责貌美如花

任正非：人工智能就是计算机和统计学

K8S的SDN容器网络解决方案【机制篇】

☞ 心疼！能为程序员男友做些什么吗？

print_r('点个好看吧！');
var_dump('点个好看吧！');
NSLog(@"点个好看吧！");
System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！");
cout << "点个好看吧！" << endl;
Console.WriteLine("点个好看吧！");
fmt.Println("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"

点击“阅读原文”，打开 CSDN App 阅读更贴心！

喜欢就点击“好看”吧