庖丁解牛-小程序版好友对战答题项目实践（一）

序

 

        新的一年已经拉开了序幕，有的忙着离职、有的忙着请求加薪，有的忙着春运，有人忙着相亲。。

        对于绝大多数人来说，新的一年就是新的开始，新的开始也就是雄心壮志立flag的之时，只求不恍惚间到年尾，然后再把去年的flag，copy一次。

        千里之行，始于足下。所以，我的雄心壮志，也从这简简单单的知识分享开始。

        说到知识分享，就不能不提去年年底大火的直播答题app，不过，随着时间的推移，貌似热度已渐减。作为一个不算资深的程序猿，当别人为了冲关成功而欣喜，为了失败而失落时，我觉得程序猿们应该有透过现象看本质的想法与能力，正如，不以物喜，不以己悲。

        废话不多少，好文刚出锅，大家趁热食用。

    

 

01

 

        本次我分享的是小程序版好友对战答题的实现思路与具体方法，由于篇幅问题，我将分成多个小段进行分享。首先我们先来分析下需求流程。

    

        首先，用户进入小程序。有两个选择，一，发起挑战；二.围观对战，选择围观对战则随机进入一个正在对战的房间，成为围观观众。选择发起挑战，则服务端生成一个房间号，然后触发分享操作，携带生成的房间号，由用户选择分享给好友或者微信群。

        微信用户通过分享的卡片进入小程序后，可选择参战或者围观，如果已经选择参战了，则其他用户自动成为围观用户。此时，发起方的页面状态由等待好友响应变为等待开始。在发起方单击开始之前，参战的用户可选择退出参战，此时，任意一个围观用户则可以选择参战。

        答题正式开始时，每道题有10s的时间回答。答错，或者超时，均认为答题错误，则不加分。答对，则根据答题用时，(11-所用秒数)*10的公式进行加分，每题满分100（留了1s时间，用户客户端和服务端之间的通讯耗时，以及客户端渲染题目所需要的时间），最后一题双倍分数。

    

 

02

 

        下面说下程序的实现逻辑：

    

        程序分为两部分，小程序端和服务端。为了满足答题的及时性以及用户体验，小程序与服务端间的通讯使用WebSocket。小程序端负责用户交互，展示返回的数据。

        服务端负责处理用户创建房间、进入房间、围观、发弹幕的操作。

服务端的逻辑功能包括：处理围观用户的请求，围观用户的请求分为两种，随机围观和指定房间号围观，服务端根据用户请求数据中是否包含房间号进行判断，如果不含，则随机进入正在进行中的对战房间进行围观。

        处理围观用户发弹幕请求。用户在答题过程中，围观用户可进行交流评论，然后以弹幕的形式实时显示在界面中。

处理用户发起挑战的请求。用户发起挑战，则生成一个房间号，存储在数据库，并返回给请求用户。

        处理应战用户请求。用户点击应战按钮后，设置当前房间状态为配对成功，其他用户则不能再发起此房间的挑战。

        处理放弃挑战请求。与应战操作逻辑相反。

        处理房主点击开始请求。房主点击开始后，服务端随机从数据库中抽取有效的题目。并每隔11s（考虑到客户端与服务端之间的通讯耗时和客户端页面渲染耗时），推送新的题目，直到答题完毕。

        处理用户提交答案请求。用户提交答案时，从数据库（或缓存）中匹配答案，正确时，则根据耗时，计算本轮分数，另外，需要将答题结果推送给围观用户。错误时，则将正确答案推送给答题者。

处理用户超时未答。当服务端在11秒内未收到提交的答题请求，则自动判断答题超时，将正确答案推送给超时用户。

 

03

 

 

数据库中，跟题目相关的表有两个，一个是题库表，一个是每个对战房间的题目表。表结构如下：

题库表：

列名	类型	说明
Id	int	主键，唯一标识
CreateTime	DateTime	题目的创建时间
Title	Nvarchar	标题
Options	Nvarchar	答案选项
Status	int	是否可用，默认1，可用。0为不可用