CN109660570A

CN109660570A - 低流量高实时性道具发放方法、存储介质、设备及系统

Info

Publication number: CN109660570A
Application number: CN201710932655.6A
Authority: CN
Inventors: 汪刚; 张文明; 陈少杰
Original assignee: Wuhan Douyu Network Technology Co Ltd
Current assignee: Wuhan Douyu Network Technology Co Ltd
Priority date: 2017-10-10
Filing date: 2017-10-10
Publication date: 2019-04-19
Anticipated expiration: 2037-10-10
Also published as: CN109660570B

Abstract

本发明公开了一种低流量高实时性道具发放方法、存储介质、设备及系统，涉及直播应用开发技术领域。该方法包括：服务器使用Socket向获得道具的用户端推送新道具发放消息；用户端使用Socket监听消息并调用消息接收函数来接收新道具发放消息；当用户端收到新道具发放消息后，对该消息进行解析并抛送至直播间页面；直播间页面收到解析后的消息后，使用消息弹框告知当前用户获得由某用户发放的道具，并在当前页面给出道具查看入口；当用户点击页面的道具查看入口时，用户端通过调用HTTP请求的方式，根据新道具发放消息查看相应的新道具。本发明不但能通过有针对性的消息推送，降低请求次数，减少流量消耗，而且实时性更高，用户体验佳。

Description

低流量高实时性道具发放方法、存储介质、设备及系统

技术领域

本发明涉及直播应用开发技术领域，具体来讲是一种低流量高实时性道具发放方法、存储介质、设备及系统。

背景技术

随着移动终端的快速发展，特别是手机移动终端的快速发展，直播行业越来越受欢迎，很多用户喜欢通过移动终端设备来观看直播。而随着直播热度的不断上升，直播中需要提供越来越丰富的互动内容，例如会举行很多活动，而每种活动中都会有一些用户赠送道具，特别是赠送火箭或者超级火箭。而赠送道具可以提升人气和增加互动性，因此，在直播间内某些用户为其他用户发放(赠送)道具是一个比较常见的操作。

目前，常规的道具发放(赠送)的实现方式是：用户进入直播间后通过HTTP(Hypertext Transfer Protocol，超文本传输协议)请求的方式调用接口来获知是否有道具发放(赠送)；若获知有用户发放(赠送)道具，则进行相应道具的获取。但是实际应用中，常规的实现方式存在以下缺陷：

(1)在常规的实现方式中，每个用户每次进入直播间都会通过HTTP请求调用接口来查询是否有道具发放的消息，这种无区别的通用查询方式使得接口请求的次数巨大(没有获得赠送的用户也会进行请求)，而巨大的请求次数就意味着流量消耗的巨大，因此，常规方式存在请求过多、流量消耗大的问题。

(2)常规的控制方式中，用户如果没有退出直播间或者不主动触发就无法查询到是否已获得到发放的道具，实时性不高，用户体验较差。

发明内容

本发明的目的是为了克服上述背景技术的不足，提供一种低流量高实时性道具发放方法、存储介质、设备及系统，不但能通过有针对性的消息推送，降低请求次数，减少流量消耗，而且实时性更高，用户体验佳。

为达到以上目的，本发明采取的技术方案是：提供一种低流量高实时性道具发放方法，该方法包括以下步骤：

S1、当用户启动直播间页面时，服务器使用Socket向获得道具的用户所在用户端推送新道具发放消息，所述新道具发放消息包括：发放道具的用户的用户信息、新道具的信息；

S2、用户端使用Socket监听服务器消息并调用预设的消息接收函数来接收新道具发放消息；

S3、用户端收到新道具发放消息后，对该消息进行解析；并将解析后的新道具发放消息抛送至直播间页面；

S4、直播间页面收到解析后的新道具发放消息后，根据解析后的新道具发放消息，使用消息弹框告知当前用户获得由某用户发放的道具，并在当前页面给出道具查看入口，引导用户去指定的位置进行道具查看；

S5、当用户点击页面的道具查看入口时，用户端通过调用HTTP请求的方式，根据新道具发放消息中的新道具的信息来查看相应的新道具。

在上述技术方案的基础上，步骤S3中，用户端对消息进行解析之前，将进行消息类型校验操作：使用用于字符串比较的函数判断当前的消息类型是否为指定类型，若不是，说明类型不正确，则终止操作；若是，说明类型正确，则对该消息进行解析。

在上述技术方案的基础上，步骤S4具体包括以下流程：S401、直播间页面收到解析后的新道具发放消息后，查看当前直播间页面的消息弹框的显示次数是否小于预设的次数，且道具查看入口是否打开；若显示次数小于预设的次数且道具查看入口已打开，转入步骤S402；S402、根据解析后的新道具发放消息中的发放道具的用户的用户信息，得知是由哪个用户发放的道具后，使用消息弹框告知当前用户获得由某用户发放的道具，转入步骤S403；S403、根据解析后的新道具发放消息中的新道具的信息，在当前页面给出相应的道具查看入口，引导用户去指定的位置进行道具查看。

在上述技术方案的基础上，步骤S5具体包括以下流程：S501、当用户点击页面的道具查看入口时，用户端使用网络工具类调用一个用于获取道具列表的函数，获取到道具列表；S502、根据新道具发放消息中的新道具的信息从获取的道具列表中查询到相应的新道具；S503、通过调用一个用于展示道具的函数，将查询到的新道具在当前页面展示。

本发明还提供一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述低流量高实时性道具发放方法的步骤。

本发明还提供一种低流量高实时性道具发放设备，包括存储器、处理器及存储在存储器上并在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述低流量高实时性道具发放方法的步骤。

本发明还提供一种低流量高实时性道具发放系统，该系统包括服务器和用户端，所述服务器设置有消息推送模块；所述用户端设置有消息监听接收模块、消息解析模块、消息通知模块、道具查看模块；

所述消息推送模块用于：当用户启动直播间页面时，服务器使用Socket向获得道具的用户所在用户端推送新道具发放消息，所述新道具发放消息包括：发放道具的用户的用户信息、新道具的信息；

所述消息监听接收模块用于：使用Socket监听服务器消息并调用预设的消息接收函数来接收新道具发放消息；

所述消息解析模块用于：收到新道具发放消息后，对该消息进行解析；并将解析后的新道具发放消息抛送至直播间页面；

所述消息通知模块用于：当直播间页面收到解析后的新道具发放消息后，根据解析后的新道具发放消息，使用消息弹框告知当前用户获得由某用户发放的道具，并在当前页面给出道具查看入口，引导用户去指定的位置进行道具查看；

所述道具查看模块用于：当用户点击页面的道具查看入口时，通过调用HTTP请求的方式，根据新道具发放消息中的新道具的信息来查看相应的新道具。

在上述技术方案的基础上，所述消息解析模块对消息进行解析之前，还将进行消息类型校验操作：使用用于字符串比较的函数判断当前的消息类型是否为指定类型，若不是，说明类型不正确，则终止操作；若是，说明类型正确，则对该消息进行解析。

在上述技术方案的基础上，所述消息通知模块进行消息通知的具体流程为：

当直播间页面收到解析后的新道具发放消息后，查看当前直播间页面的消息弹框的显示次数是否小于预设的次数，且道具查看入口是否打开；

若显示次数小于预设的次数且道具查看入口已打开，则根据解析后的新道具发放消息中的发放道具的用户的用户信息，得知是由哪个用户发放的道具后，使用消息弹框告知当前用户获得由某用户发放的道具；再根据解析后的新道具发放消息中的新道具的信息，在当前页面给出相应的道具查看入口，引导用户去指定的位置进行道具查看。

在上述技术方案的基础上，所述道具查看模块进行道具查看的具体流程为：当用户点击页面的道具查看入口时，使用网络工具类调用一个用于获取道具列表的函数，获取到道具列表；根据新道具发放消息中的新道具的信息从获取的道具列表中查询到相应的新道具；通过调用一个用于展示道具的函数，将查询到的新道具在当前页面展示。

本发明的有益效果在于：

(1)本发明中，采用有针对性的消息推送，只向获得了道具的用户推送新道具发放消息，避免了传统方式的无区别的“无脑式”查询方式，能有效减少请求次数、降低流量的消耗。并且，使用Socket(套接字)进行实时的消息推送，而放弃传统的http请求方式，能够保证获知有道具发放的消息的实时性，且Socket相较HTTP请求，本身流量消耗就小，因此，也能进一步降低流量的消耗。更重要的是，只有当用户对发放的道具感兴趣时才需要去查看道具，如果用户对道具不感兴趣就不需要查看道具，这也能从一定程度上减少请求次数，降低流量，并且避免了道具的强制查询，用户体验更好。

(2)本发明中，用户端对新道具发放消息进行解析前，将进行消息类型校验操作，能有效确保收到的新道具发放消息的准确性，避免对错误消息进行解析，浪费资源。

附图说明

图1为本发明实施例中低流量高实时性道具发放方法的流程图；

图2为本发明实施例中低流量高实时性道具发放设备的结构示意图；

图3为本发明实施例中低流量高实时性道具发放系统的结构框图。

具体实施方式

下面结合附图及具体实施例对本发明作进一步的详细描述。

参见图1所示，本发明实施例提供一种低流量高实时性道具发放方法，该方法包括以下步骤：

步骤S1、当用户启动直播间页面时(即用户进入直播间时)，服务器使用Socket(套接字)向获得道具的用户所在用户端推送新道具发放消息，该新道具发放消息包括：发放道具的用户的用户信息、新道具的信息。

可以理解的是，步骤S1中，采用的是服务器推送的方式，且该推送目标是有针对性的向获得道具的用户进行推送。相较于传统的无区别的“无脑式”通用查询方式，本发明实施例能有效降低请求次数。并且，使用Socket(套接字)进行消息的推送，Socket(套接字)相较HTTP请求，本身流量消耗就小，因此，也能有效降低流量的消耗。实际操作时，用户每次进入直播间都会连接服务器，登录服务器之后，服务端就可以使用Socket推送消息到获得道具的用户所在用户端。使用Socket技术而放弃传统的HTTP请求方式是能够保证获知有道具发放的消息实时性的关键，且Socket相较HTTP的最大的好处是节省流量。

步骤S2、用户端使用Socket(套接字)监听服务器消息并调用已有的(即预设好的)消息接收函数来接收新道具发放消息。

可以理解的是，实际操作时，用户端调用的消息接收函数具有一个字符串类型的参数msg，该参数msg的内容为新道具发放消息，且该参数msg是尽可能精简的字符，为了达到节约流量的目的。具体应用时，以IOS系统为例，消息接收函数可使用IOS系统下预设好的用来接收消息的receiveMessageWithType函数来实现。

步骤S3、用户端收到新道具发放消息后，对该消息进行解析，得到发放道具的用户的用户信息；并将解析后的新道具发放消息抛送至直播间页面。

具体来说，发放道具的用户的用户信息可包括但不限于：用户昵称nn、用户的唯一标识uid和用户名id。具体来说，以IOS系统为例，对新道具发放消息进行解析时，可使用IOS系统下封装的条目解析函数getItem来解析出发放道具的用户的用户信息。另外，将解析后的新道具发放消息抛送至直播间页面时，可使用代理设计模式将消息抛送到直播间。具体来说，还是以IOS系统为例，可使用代理是否遵从的判断函数respondsToSelector判断是否有控制器(直播间页面实质是一个控制器)遵守接收道具的消息函数socketReceiveDamageProp；如果有控制器遵守接收道具的消息函数socketReceiveDamageProp，就将上述解析后的新道具发放消息使用代理设计模式将消息抛送到直播间页面。

进一步地，为了有效确保收到的新道具发放消息的准确性，本实施例的步骤S3中，用户端对该消息进行解析前将进行消息类型校验操作：收到新道具发放消息后(如收到参数msg后)，使用字符串比较函数isEqualToString判断当前的消息类型是否为指定类型(该指定类型事前已与服务器约定好)，若不是，说明类型不正确，则终止操作；若是，说明类型正确，则对该消息进行解析。

步骤S4、直播间页面收到解析后的新道具发放消息后，根据解析后的新道具发放消息，使用消息弹框告知当前用户获得由某用户发放的道具，并在当前页面给出道具查看入口，可引导用户去指定的位置进行道具查看。可以理解的，由于步骤S3中解析得到了发放道具的用户的用户信息，因此，可根据该用户信息知道是由哪个用户发放的道具，从而可以告知当前接收道具的用户。

在一种实施方式中，步骤S4具体包括以下流程：

步骤S401、直播间页面收到解析后的新道具发放消息后，查看当前直播间页面的消息弹框的显示次数是否小于预设的次数，且道具查看入口是否打开；若显示次数小于预设的次数且道具查看入口已打开，转入步骤S402。可以理解的是，此处增加道具查看入口是否打开的判断是因为有些道具只在一定的活动期间发放,增加一个容错判断，对显示有道具发放的提示多一个判断，提高准确性。

步骤S402、根据解析后的新道具发放消息中的发放道具的用户的用户信息，得知是由哪个用户发放的道具后，使用消息弹框告知当前用户获得由某用户发放的道具，转入步骤S403。

步骤S403、根据解析后的新道具发放消息中的新道具的信息，在当前页面给出相应的道具查看入口，引导用户去指定的位置进行道具查看。

步骤S5、当用户点击页面的道具查看入口时(表示用户对道具感兴趣)，用户端通过调用HTTP请求的方式，根据新道具发放消息中的新道具的信息来查看相应的新道具。可以理解的是，当用户对道具感兴趣的时候才需要去查看道具,如果用户对道具不感兴趣就不需要查看道具,这么设计的好处是：一方面提高了用户体验，避免道具的强制查询；另一方面可减少接口的请求次数,当用户对道具不关心的时候，无需查看道具就无需通过HTTP请求调用接口来查询道具，从而减少流量消耗。

在一种实施方式中，步骤S5具体包括以下流程：

步骤S501、当用户点击页面的道具查看入口时，用户端使用网络工具类调用一个用于获取道具列表的函数(该函数可为事先预设好的函数)，从而获取到道具列表。实际操作时，以IOS系统为例，使用的网络工具类可为InterfaceManager；用于获取道具列表的函数可为预设的getPropsList函数。

步骤S502、根据新道具发放消息中的新道具的信息从获取的道具列表中查询到相应的新道具；

步骤S503、通过调用一个用于展示道具的函数(该函数可为事先预设好的函数)，将查询到的新道具在当前页面展示。实际操作时，以IOS系统为例，用于展示道具的函数可为预设的configPropInfo函数。

进一步的，为了避免因重复请求道具，而导致重复拉取数据，造成数据冗余，操作重复。本实施例中，若用户端已发起过HTTP请求，而想要再次发起HTTP请求(可能由于请求尚未响应，即还未成功获取到道具列表；也可能是其他原因想要再次发起HTTP请求)，则会调用一个用于取消网络请求的函数将之前正在发起的网络请求取消，即中断当前网络请求；然后再发起一个新的HTTP请求(即，使用网络工具类调用一个用于获取道具列表的函数)。

还是以IOS系统为例，上述操作具体实现时，可先定义一个网络请求任务类NSURLSessionTask的对象sessionTaskPropList；然后利用这个网络请求任务类的用于取消网络请求的函数cancel，来取消当前网络请求；再使用网络工具类InterfaceManager调用用于获取道具列表的函数getPropsList，来获取道具列表。

可以理解的是，本发明实施例中，采用有针对性的消息推送，只向获得了道具的用户推送新道具发放消息，避免了传统方式的无区别的“无脑式”查询方式，能有效减少请求次数、降低流量的消耗。并且，使用Socket(套接字)进行实时的消息推送，而放弃传统的http请求方式，能够保证获知有道具发放的消息的实时性，且Socket相较HTTP请求，本身流量消耗就小，因此，也能进一步降低流量的消耗。更重要的是，只有当用户对发放的道具感兴趣时才需要去查看道具，如果用户对道具不感兴趣就不需要查看道具，这也能从一定程度上减少请求次数，降低流量，并且避免了道具的强制查询，用户体验更好。

举例来说，假设有1000万用户，每个用户进入10次直播间。若采用常规的方案，则需要通过HTTP请求查询道具接口的次数是1000万*10次＝10000万次。而采用本方案：socket消息只给获得了道具的用户进行推送，获得了道具的用户一般只占总用户的很小比例A(例如10％)，这A比例的用户中，一般又只会有比例B(如50％)的概率去查看道具，那么道具接口请求的次数是1000万*A(此处为10％)*B(预估为50％)＝50万次，这样就将HTTP请求从10000万次降低到50万次，HTTP请求的次数大大降低,流量消耗大幅降低。而剩下的就是100万次(1000万*A)的socket流量(即向获得了道具的用户进行推送时所用的流量)，而每次socket的流量本身就小于每次HTTP请求的流量消耗，因此，整体的流量消耗将比HTTP请求减少很多。

对应上述的低流量高实时性道具发放方法，本发明实施例还提供一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时可实现上述各实施例中的低流量高实时性道具发放方法的步骤。需要说明的是，所述存储介质包括U盘、移动硬盘、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、磁碟或者光盘等各种可以存储程序代码的介质。

另外，参见图2所示，对应上述的低流量高实时性道具发放方法，本发明实施例还提供一种低流量高实时性道具发放设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，该处理器执行计算机程序时可实现上述各实施例中的低流量高实时性道具发放方法的步骤。

参见图3所示，本发明实施例还提供一种低流量高实时性道具发放系统，该系统包括服务器和用户端。所述服务器设置有消息推送模块；所述用户端设置有消息监听接收模块、消息解析模块、消息通知模块、道具查看模块。

其中，消息推送模块用于：当用户启动直播间页面时，服务器使用Socket向获得道具的用户所在用户端推送新道具发放消息，所述新道具发放消息包括：发放道具的用户的用户信息、新道具的信息；

消息监听接收模块用于：使用Socket监听服务器消息并调用预设的消息接收函数来接收新道具发放消息；

消息解析模块用于：收到新道具发放消息后，对该消息进行解析；并将解析后的新道具发放消息抛送至直播间页面；

消息通知模块用于：当直播间页面收到解析后的新道具发放消息后，根据解析后的新道具发放消息，使用消息弹框告知当前用户获得由某用户发放的道具，并在当前页面给出道具查看入口，引导用户去指定的位置进行道具查看；

道具查看模块用于：当用户点击页面的道具查看入口时，通过调用HTTP请求的方式，根据新道具发放消息中的新道具的信息来查看相应的新道具。

需要说明的是：上述实施例提供的系统在实现低流量高实时性道具发放的操作时，仅以上述各功能模块的划分进行举例说明，实际应用中，可根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或部分功能。

本发明不局限于上述实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围之内。

本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。

Claims

1.一种低流量高实时性道具发放方法，其特征在于，该方法包括以下步骤：

2.如权利要求1所述的低流量高实时性道具发放方法，其特征在于：步骤S3中，用户端对消息进行解析之前，将进行消息类型校验操作：使用用于字符串比较的函数判断当前的消息类型是否为指定类型，若不是，说明类型不正确，则终止操作；若是，说明类型正确，则对该消息进行解析。

3.如权利要求1所述的低流量高实时性道具发放方法，其特征在于，步骤S4具体包括以下流程：

S401、直播间页面收到解析后的新道具发放消息后，查看当前直播间页面的消息弹框的显示次数是否小于预设的次数，且道具查看入口是否打开；若显示次数小于预设的次数且道具查看入口已打开，转入步骤S402；

S402、根据解析后的新道具发放消息中的发放道具的用户的用户信息，得知是由哪个用户发放的道具后，使用消息弹框告知当前用户获得由某用户发放的道具，转入步骤S403；

S403、根据解析后的新道具发放消息中的新道具的信息，在当前页面给出相应的道具查看入口，引导用户去指定的位置进行道具查看。

4.如权利要求1所述的低流量高实时性道具发放方法，其特征在于，步骤S5具体包括以下流程：

S501、当用户点击页面的道具查看入口时，用户端使用网络工具类调用一个用于获取道具列表的函数，获取到道具列表；

S502、根据新道具发放消息中的新道具的信息从获取的道具列表中查询到相应的新道具；

S503、通过调用一个用于展示道具的函数，将查询到的新道具在当前页面展示。

5.一种存储介质，其上存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现上述权利要求1至4中任一项所述方法的步骤。

6.一种低流量高实时性道具发放设备，包括存储器、处理器及存储在所述存储器上并在所述处理器上运行的计算机程序，其特征在于：所述处理器执行所述计算机程序时实现上述权利要求1至4中任一项所述方法的步骤。

7.一种低流量高实时性道具发放系统，该系统包括服务器和用户端，其特征在于：所述服务器设置有消息推送模块；所述用户端设置有消息监听接收模块、消息解析模块、消息通知模块、道具查看模块；

8.如权利要求7所述的低流量高实时性道具发放系统，其特征在于，所述消息解析模块对消息进行解析之前，还将进行消息类型校验操作：使用用于字符串比较的函数判断当前的消息类型是否为指定类型，若不是，说明类型不正确，则终止操作；若是，说明类型正确，则对该消息进行解析。

9.如权利要求7所述的低流量高实时性道具发放系统，其特征在于，所述消息通知模块进行消息通知的具体流程为：

10.如权利要求7所述的低流量高实时性道具发放系统，其特征在于，所述道具查看模块进行道具查看的具体流程为：

当用户点击页面的道具查看入口时，使用网络工具类调用一个用于获取道具列表的函数，获取到道具列表；根据新道具发放消息中的新道具的信息从获取的道具列表中查询到相应的新道具；通过调用一个用于展示道具的函数，将查询到的新道具在当前页面展示。