评论

抽奖助手小程序核心数据结构解析

抽奖助手小程序核心数据结构解析

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

本文背景

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

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

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


界面截图

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

f


f

f

本文内容

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

(1)lottery,奖项集合

(2)participate,用户参与集合

(3)broadcast,中奖集合

(4)user,用户集合

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

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

1status,代表当前是否已开奖,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

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

最后一次编辑于  08-05  
点赞 0
收藏
评论

1 个评论

  • 小肥羊
    小肥羊
    08-04

    第一期优化已完成,完善的内容有以下两点,通过新增了两个云函数优化了下面两个场景,解决了历史数据过多导致的云函数查询超时问题

    1、首页,获奖记录逻辑

    2、首页,奖项列表记录逻辑

    08-04
    赞同
    回复
登录 后发表内容