此抽奖助手非大家熟知的抽奖助手小程序，而是目前我在开发的抽奖助手小程序，该小程序在之前开源的抽奖小程序改造而来，目前也是开源状态

本文背景

是这样的，我先介绍下目前的用户数据，小程序当前日活在5000左右，单个抽奖参加人数在900人，所以当历史数据过大的时候，首页的奖项列表经常由于云函数超时而展示不出来，所以我计划优化下

优化之前我必须对奖项里面的状态非常熟悉，就有了这篇文章的需求

抽奖助手小程序里面很多字段代表不同的状态，每次优化，都要梳理一遍，趁机会，我把梳理的内容整理出来，写成文章，方便我自己也对开源小程序做一个文档补充

界面截图

从当前抽奖人数可以大概推断小程序的日活数据

f

f

f

本文内容

该开源项目核心集合有以下几个

（1）lottery，奖项集合

（2）participate，用户参与集合

（3）broadcast，中奖集合

（4）user，用户集合

首先看第一个核心集合Lottery，截图如下所示

下面截图是集合lottery的数据集合，当前状态未开奖，我简单列一下

（1）status，代表当前是否已开奖，1代表未开奖、-1代表已开奖，由云函数run控制，初始值为1

（2）lottery，代表当前奖项是否已开奖，就是是否已确定中奖人，0代表未开奖；1代表已开奖，由云函数draw控制，初始值为0

（3）send，代表是否已推送开奖消息，0代表未推送，1代表已推送，由云函数sendmore控制，初始值为0

因为后面两个状态是我加的，第一个状态是开源项目里面的，所以对于-1、0、1的状态定义不一样，这个地方需要注意

第二个集合participate

该集合是参与集合，主要记录了每个奖项的参与情况，也不需要额外介绍，每个字段，按照英文命名非常容易理解

f

f

第三个集合broadcast

该集合为中奖记录集合，存放了每个奖项，具体哪个用户中奖了，看截图便明白每个字段的意思，不需要额外再展开

f

f

第四个集合user

该集合主要记录了用户的头像、昵称、授权时间等信息

f

f

优化事项

f

当抽奖记录多的情况下，首页会由于云函数超时，导致不能正常展示抽奖奖项列表，也就是小程序的核心入口，

目前的写法是联表，

我将计划把这里单独优化下，优化的方向是，分别读取当前个人的参与记录和当前奖项记录，然后这两个集合做对应的逻辑，求得当前用户哪些奖项是参与过的，哪些没有参与过，从而根据状态做不同的展现形式

优化过程

在这次优化过程中，新接触了两个生命周期函数

（1）onPullDownRefresh 监听用户下拉动作

（2）onReachBottom 页面上拉触底事件的处理函数

这两个一个是下拉，一个是上拉，这两个我之前 没有接触过，也算是新收获

本文总结

ff

通过这种总结，让我对目前的抽奖助手更熟悉，在以后优化的时候，可以更轻松回顾目前已有的逻辑，本文不存在最终定稿，随着梳理的过程，会不断完善