CN111737628B - 一种弹窗弹出方法及装置 - Google Patents

Abstract

本申请提供了一种弹窗弹出方法及装置，该方法通过预先从服务端获取弹窗配置信息，并基于弹窗配置信息，更新客户端的待弹窗列表，实现将弹窗配置信息预先存储到客户端，在需要弹出弹窗时即在获取到弹窗触发信息时，由客户端在满足预先设定的弹窗条件时，基于客户端存储的待弹窗列表中的弹窗配置信息，弹出弹窗，减少客户端与服务端交互的次数，从而减少对网络资源和网络流量的消耗。并且，通过预先从服务端获取弹窗配置信息，并基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表，进行弹出弹窗的方式与服务端通过长连接推送的弹窗配置信息进行弹出弹窗的方式结合，能够提高弹窗的覆盖率，以此能够提高弹窗弹出的可靠性。

Description

一种弹窗弹出方法及装置

技术领域

本申请涉及App(Application，应用软件)技术领域，特别涉及一种弹窗弹出方法及装置。

背景技术

随着网络技术的发展，弹窗也成为一种非常重要的信息展示方式。

目前，常用的弹窗弹出方式有以下两种：(1)基于长连接的弹出方式：服务端定时给某一个场景中的客户端推送弹窗，客户端收到弹窗后，弹出弹窗。(2)基于http轮询的弹出方式：客户端定时请求服务端，由服务端判断是否应该弹出弹窗。

但是，方式(1)和(2)均会消耗较多的网络资源和网络流量。

发明内容

为解决上述技术问题，本申请实施例提供一种弹窗弹出方法及装置，以达到减少对网络资源和网络流量的消耗及提高弹窗弹出的可靠性的目的，技术方案如下：

一种弹窗弹出方法，应用于客户端，该方法包括：

预先从服务端获取弹窗配置信息，并基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表；

在获取到弹窗触发信息时，基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；

若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗。

所述方法还包括：

在接收到所述服务端通过长连接推送的弹窗配置信息时，基于所述服务端通过长连接推送的弹窗配置信息，更新所述待弹窗列表；

基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；

若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗。

所述预先从服务端获取弹窗配置信息，包括：

在所述客户端启动时，通过HTTP协议从服务端获取弹窗配置信息。

所述预先从服务端获取弹窗配置信息，包括：

预先与服务端建立长连接；

向所述服务端发送弹窗配置信息请求消息，并接收所述服务端响应所述弹窗配置信息请求消息，下发的弹窗配置信息。

所述弹窗触发信息，包括：

所述客户端中APP启动信息；

或，所述服务端通过长连接推送的触发信息；

或，页面切换信息；

或，从后台切换到前台的信息。

所述基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件，包括：

从所述弹窗配置信息中获取弹窗开始展示时间；

判断用户所在时间，是否位于所述弹窗开始展示时间；

若位于所述弹窗开始展示时间，则从所述弹窗配置信息中获取规定的弹窗场景信息；

判断用户当前所处的场景是否位于所述规定的弹窗场景信息中；

若位于所述规定的弹窗场景信息中，则判断待弹出弹窗是否达到预先设定的频率控制要求。

所述基于所述弹窗配置信息，更新所述客户端的待弹窗列表，包括：

判断是否基于所述弹窗配置信息，执行过弹窗弹出动作；

若是，则丢弃所述弹窗配置信息；

若否，则判断所述待弹窗列表中是否存在与所述弹窗配置信息匹配的信息；

若存在，则将所述待弹窗列表中与所述弹窗配置信息匹配的信息，替换为所述弹窗配置信息；

若不存在，则将所述弹窗配置信息存储到所述待弹窗列表中。

一种弹窗弹出装置，应用于客户端，该装置包括：

获取模块，用于预先从服务端获取弹窗配置信息；

第一更新模块，用于基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表；

第一判断模块，用于在获取到弹窗触发信息时，基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；

第一弹出模块，用于若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗。

所述装置还包括：

第二更新模块，用于在接收到所述服务端通过长连接推送的弹窗配置信息时，基于所述服务端通过长连接推送的弹窗配置信息，更新所述待弹窗列表；

第二判断模块，用于基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；

第二弹出模块，用于若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗。

所述获取模块，具体用于：

在所述客户端启动时，通过HTTP协议从服务端获取弹窗配置信息。

所述获取模块，具体用于：

预先与服务端建立长连接；

向所述服务端发送弹窗配置信息请求消息，并接收所述服务端响应所述弹窗配置信息请求消息，下发的弹窗配置信息。

所述弹窗触发信息，包括：

所述客户端中APP启动信息；

或，所述服务端通过长连接推送的触发信息；

或，页面切换信息；

或，从后台切换到前台的信息。

所述第一判断模块，具体用于：

从所述弹窗配置信息中获取弹窗开始展示时间；

判断用户所在时间，是否位于所述弹窗开始展示时间；

若位于所述弹窗开始展示时间，则从所述弹窗配置信息中获取规定的弹窗场景信息；

判断用户当前所处的场景是否位于所述规定的弹窗场景信息中；

若位于所述规定的弹窗场景信息中，则判断待弹出弹窗是否达到预先设定的频率控制要求。

所述第二判断模块，具体用于：

从所述弹窗配置信息中获取弹窗开始展示时间；

判断用户所在时间，是否位于所述弹窗开始展示时间；

若位于所述弹窗开始展示时间，则从所述弹窗配置信息中获取规定的弹窗场景信息；

判断用户当前所处的场景是否位于所述规定的弹窗场景信息中；

若位于所述规定的弹窗场景信息中，则判断待弹出弹窗是否达到预先设定的频率控制要求。

所述第一更新模块，具体用于：

判断是否基于所述弹窗配置信息，执行过弹窗弹出动作；

若是，则丢弃所述弹窗配置信息；

若否，则判断所述待弹窗列表中是否存在与所述弹窗配置信息匹配的信息；

若存在，则将所述待弹窗列表中与所述弹窗配置信息匹配的信息，替换为所述弹窗配置信息；

若不存在，则将所述弹窗配置信息存储到所述待弹窗列表中。

所述第二更新模块，具体用于：

判断是否基于所述弹窗配置信息，执行过弹窗弹出动作；

若是，则丢弃所述弹窗配置信息；

若否，则判断所述待弹窗列表中是否存在与所述弹窗配置信息匹配的信息；

若存在，则将所述待弹窗列表中与所述弹窗配置信息匹配的信息，替换为所述弹窗配置信息；

若不存在，则将所述弹窗配置信息存储到所述待弹窗列表中。

与现有技术相比，本申请的有益效果为：

在本申请中，通过预先从服务端获取弹窗配置信息，并基于所述弹窗配置信息，更新所述客户端的待弹窗列表，实现将弹窗配置信息预先存储到客户端，在需要弹出弹窗时即在获取到弹窗触发信息时，由客户端基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件，在满足预先设定的弹窗条件时，基于客户端存储的待弹窗列表中的弹窗配置信息，弹出弹窗，减少客户端与服务端交互的次数，从而减少对网络资源和网络流量的消耗。

并且，相比于在需要弹出弹窗是，再从服务端获取弹窗配置信息的方式，可以缩短弹窗配置信息的获取时间，提高弹出弹窗的效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例1提供的一种弹窗弹出方法的流程示意图；

图2是本申请实施例2提供的一种弹窗弹出方法的流程示意图；

图3是本申请提供的一种弹窗弹出装置的逻辑结构示意图；

图4是本申请提供的另一种弹窗弹出装置的逻辑结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

参照图1，为本申请实施例1提供的一种弹窗弹出方法的流程图，该方法应用于客户端，如图1所示，该方法可以包括但并不局限于以下步骤：

步骤S11、预先从服务端获取弹窗配置信息，并基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表。

弹窗配置信息，可以包括但不局限于：弹窗id，弹窗开始预埋时间、弹窗开始展示时间、弹窗结束展示时间、弹窗展示内容、弹窗展示样式和弹窗投放场景等配置信息。例如，服务端配置的弹窗配置信息的数据结构可以参见表1，如表1所示，弹窗配置信息包含：多个不同的字段，每个字段存储不同的信息。

表1

其中，弹窗开始预埋时间，可以理解为：客户端提前从服务端获取弹窗配置信息的时间。

本实施例中，预先从服务端获取弹窗配置信息，可以包括但不局限于：每次预先从服务端获取多个弹窗配置信息。每次预先从服务端获取多个弹窗配置信息，实现对弹窗配置信息的批量获取，提高获取效率。

预先从服务端获取弹窗配置信息，可以包括：

S111、在所述客户端启动时，通过HTTP协议从服务端获取弹窗配置信息。

当然，预先从服务端获取弹窗配置信息，也可以包括：

S112、预先与服务端建立长连接；

S113、向所述服务端发送弹窗配置信息请求消息，并接收所述服务端响应所述弹窗配置信息请求消息，下发的弹窗配置信息。

本实施例中，客户端可以为但不局限于：aphone、iPhone、web或PC客户端。

本实施例中，客户端还可以清理已弹窗列表和待弹窗列表中弹窗结束展示时间大于当前时间的所有过期的弹窗配置信息。具体地，客户端中弹窗服务器可以从所有配置好的弹窗中，筛选出所有当前时间位于pre_begin_time和end_time时间之间的所有弹窗返回给客户端。pre_begin_time可以理解为：将弹窗开始预埋配置到客户端的时间。end_time可以理解为：结束弹窗展示的时间。end_time＝客户端本地时间+end_time_dis。

需要注意的是，begin_time可以理解为弹窗的开始时间，其等于客户端本地时间+begin_time_dis。如果这个时间为负数则用当前时间减去这个秒数。客户端在收到弹窗后，需要计算成客户端本地时间，存储到变量begin_time中，比如“2020-01-01 12:00:30”这种格式。

begin_time等于客户端本地时间+begin_time_dis，以及end_time＝客户端本地时间+end_time_dis，保证客户端预埋后的弹窗能够在准确的时间点弹出。比如，现在北京时间是00：00，但是客户端本地时间由于配置错误或者其他原因，是01：00。这个时候预埋到客户端本地的弹窗，弹出时机就会出现误差。为了解决这个问题，服务端会把时间换算成相对时间，就是相对当前时间是多少秒。比如bein_time_dis为10，那么到客户端就应该是客户端本地的时间+10s。如果客户端本地时间为01：00那么换算过来begin_time就是01：10。如果begin_time_dis＝-10,客户端本地时间为01:00那么换算过来begin_time就是00:50。

基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表的过程，可以包括：

S114、判断是否基于所述弹窗配置信息，执行过弹窗弹出动作。

若是，则执行步骤S115；若否，则执行步骤S116。

S115、丢弃所述弹窗配置信息；

S116、判断所述待弹窗列表中是否存在与所述弹窗配置信息匹配的信息；

若存在，则执行步骤S117；若不存在，则执行步骤S118。

S117、将所述待弹窗列表中与所述弹窗配置信息匹配的信息，替换为所述弹窗配置信息；

S118、将所述弹窗配置信息存储到所述待弹窗列表中。

步骤S12、在获取到弹窗触发信息时，基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件。

若是，则执行步骤S13。

本实施例中，在获取弹窗触发信息时，说明需要弹窗，但是未立即进行弹窗，而是基于待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件，保证弹窗的可靠性。

弹窗触发信息，可以包括但不局限于：

所述客户端中APP启动信息；

或，所述服务端通过长连接推送的触发信息；

或，页面切换信息；

或，从后台切换到前台的信息。

所述基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件，可以包括：

S121、从所述弹窗配置信息中获取弹窗开始展示时间。

S122、判断用户所在时间，是否位于所述弹窗开始展示时间。

若位于所述弹窗开始展示时间，则执行步骤S123。

S123、从所述弹窗配置信息中获取规定的弹窗场景信息。

S124判断用户当前所处的场景是否位于所述规定的弹窗场景信息中。

若位于所述规定的弹窗场景信息中，则执行步骤S125。

S125、判断待弹出弹窗是否达到预先设定的频率控制要求。

步骤S13、基于所述待弹窗列表中的弹窗配置信息，弹出弹窗。

当然，本实施例中，客户端还可以存储已弹窗列表，已弹窗列表中存储有已经展示的弹窗的信息。客户端存储已弹窗列表，可以方便查询已经展示的弹窗的信息。

在本申请中，通过预先从服务端获取弹窗配置信息，并基于所述弹窗配置信息，更新所述客户端的待弹窗列表，实现将弹窗配置信息预先存储到客户端，在需要弹出弹窗时即在获取到弹窗触发信息时，由客户端基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件，在满足预先设定的弹窗条件时，基于客户端存储的待弹窗列表中的弹窗配置信息，弹出弹窗，减少客户端与服务端交互的次数，从而减少对网络资源和网络流量的消耗。

并且，相比于在需要弹出弹窗是，再从服务端获取弹窗配置信息的方式，可以缩短弹窗配置信息的获取时间，提高弹出弹窗的效率。

作为本申请另一可选实施例，参照图2，为本申请提供的一种弹窗弹出方法实施例2的流程图，本实施例主要是对上述实施例1描述的弹窗弹出方法的扩展方案，如图2所示，该方法可以包括但并不局限于以下步骤：

步骤S21、预先从服务端获取弹窗配置信息，并基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表。

步骤S22、在获取到弹窗触发信息时，基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件。

若是，则执行步骤S23。

步骤S23、基于所述待弹窗列表中的弹窗配置信息，弹出弹窗。

步骤S21-S23的详细过程可以参见实施例1中步骤S11-S13的相关介绍，在此不再赘述。

步骤S24、在接收到所述服务端通过长连接推送的弹窗配置信息时，基于所述服务端通过长连接推送的弹窗配置信息，更新所述待弹窗列表。

本实施例中，到弹窗的开始时间，服务端会通过长连接向客户端推送弹窗配置信息，相应地，客户端判断是否接收到所述服务端通过长连接推送的弹窗配置信息，若接收到，则执行步骤S25。

需要说明的是，服务端会通过长连接向所有在线客户端推送弹窗配置信息，而非只对弹窗中规定的场景中的用户进行推送，以此解决客户端在A场景，弹窗规定的场景在B场景，并且这个客户端未进行过重新登陆没有预埋这个弹窗。那么这个客户端在弹窗时间内从A场景切换到B场景的时候，将无法进行弹窗的问题。其中，由于客户端均做了场景约束的判断，因此也不会在弹窗约束的其他场景进行弹窗展示。

本实施例中，基于所述服务端通过长连接推送的弹窗配置信息，更新所述待弹窗列表的详细过程可以参见实施例1中步骤S114-S118的相关介绍，在此不再赘述。

步骤S25、基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件。

基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件的详细过程，可以参见实施例1中步骤S121-S125的相关介绍，在此不再赘述。

在步骤S24更新待弹窗列表之后，客户端基于待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件。

若是，则执行步骤S26。

步骤S26、基于所述待弹窗列表中的弹窗配置信息，弹出弹窗。

本实施例中，通过预先从服务端获取弹窗配置信息，并基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表，进行弹出弹窗的方式与服务端通过长连接推送的弹窗配置信息进行弹出弹窗的方式结合，能够提高弹窗的覆盖率，并且能够更好的实现在一个时间区间内进行弹窗，以此能够提高获取弹窗配置信息的可靠性，进而提高弹出弹窗的可靠性。例如，若将pre_begin_time配置为2019-12-31 12:00:00，也就是说在12:00:00后启动的客户端都能通过http协议请求弹窗服务将抽奖弹窗预埋到本地。begin_time配置为2019-12-31 19:00:00，end_time配置为2020-01-01 00:00:00。mqtt_pub_time_list(可以理解为：长连接将弹窗配置推送到客户端的时间列表。比如，配置的mqtt_pub_time_list为2019-12-31 19:00:00，2019-12-31 20:00:00。那么服务端将会在 2019-12-31 19:00:0，2019-12-31 20:00:00两个时间点，分别给客户端推送一次这个弹窗配置信息)配置为“2019-12-31 19:00:00，2019-12-31 20:00:00，2019-12-31 21:00:00，2019-12-31 22:00:00，2019-12-31 23:00:00”。那么在mqtt_pub_time_list这些时间点位于跨年直播间的客户端，将能够收到mqtt长连接的推送。那些2019-12-31 12：00：00在线并且位于跨年直播间的用户，收到mqtt长连接推送会马上进行弹窗。那些2019-12-31 19:00:00前已经在线，但是没有位于跨年直播间内的客户端，在2019-12-31 19:00:00后切换到跨年直播间将会启动客户端的弹窗判断最终能够弹窗。那些在2019-12-31 19:00:00这个时间点的移动客户端在位于后台的情况下。如果操作系统未将客户端的app杀掉，客户端将能在后台收到长连接推送消息并预埋到本地。如果位于后台时间过久操作系统已经将app杀掉，那么这部分客户端在回到前台时会执行步骤S21-S24的流程，同样能够弹窗。此种场景，启动客户端请求http协议拉取弹窗和mqtt长连接推送弹窗，会导致同一个弹窗被客户端多次收到。此种冗余的方案会使送达率更高。

接下来对本申请提供的弹窗弹出装置进行介绍，下文介绍的弹窗弹出装置与上文介绍的弹窗弹出方法可相互对应参照。

弹窗弹出装置应用于客户端，请参见图3，弹窗弹出装置包括：获取模块11、第一更新模块12、第一判断模块13和第一弹出模块14。

获取模块11，用于预先从服务端获取弹窗配置信息；

第一更新模块12，用于基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表；

第一判断模块13，用于在获取到弹窗触发信息时，基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；

第一弹出模块14，用于若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗。

本实施例中，如图4所示，弹窗弹出装置还可以包括：

第二更新模块15，用于在接收到所述服务端通过长连接推送的弹窗配置信息时，基于所述服务端通过长连接推送的弹窗配置信息，更新所述待弹窗列表；

第二判断模块16，用于基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；

第二弹出模块17，用于若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗。

本实施例中，获取模块11，具体可以用于：

在所述客户端启动时，通过HTTP协议从服务端获取弹窗配置信息。

本实施例中，获取模块11，具体可以用于：

预先与服务端建立长连接；

向所述服务端发送弹窗配置信息请求消息，并接收所述服务端响应所述弹窗配置信息请求消息，下发的弹窗配置信息。

本实施例中，弹窗触发信息，可以包括：

所述客户端中APP启动信息；

或，所述服务端通过长连接推送的触发信息；

或，页面切换信息；

或，从后台切换到前台的信息。

所述第一判断模块13，具体可以用于：

从所述弹窗配置信息中获取弹窗开始展示时间；

判断用户所在时间，是否位于所述弹窗开始展示时间；

若位于所述弹窗开始展示时间，则从所述弹窗配置信息中获取规定的弹窗场景信息；

判断用户当前所处的场景是否位于所述规定的弹窗场景信息中；

若位于所述规定的弹窗场景信息中，则判断待弹出弹窗是否达到预先设定的频率控制要求。

本实施例中，第二判断模块16，具体可以用于：

从所述弹窗配置信息中获取弹窗开始展示时间；

判断用户所在时间，是否位于所述弹窗开始展示时间；

若位于所述弹窗开始展示时间，则从所述弹窗配置信息中获取规定的弹窗场景信息；

判断用户当前所处的场景是否位于所述规定的弹窗场景信息中；

若位于所述规定的弹窗场景信息中，则判断待弹出弹窗是否达到预先设定的频率控制要求。

本实施例中，第一更新模块12，具体可以用于：

判断是否基于所述弹窗配置信息，执行过弹窗弹出动作；

若是，则丢弃所述弹窗配置信息；

若否，则判断所述待弹窗列表中是否存在与所述弹窗配置信息匹配的信息；

若存在，则将所述待弹窗列表中与所述弹窗配置信息匹配的信息，替换为所述弹窗配置信息；

若不存在，则将所述弹窗配置信息存储到所述待弹窗列表中。

第二更新模块16，具体可以用于：

判断是否基于所述弹窗配置信息，执行过弹窗弹出动作；

若是，则丢弃所述弹窗配置信息；

若否，则判断所述待弹窗列表中是否存在与所述弹窗配置信息匹配的信息；

若存在，则将所述待弹窗列表中与所述弹窗配置信息匹配的信息，替换为所述弹窗配置信息；

若不存在，则将所述弹窗配置信息存储到所述待弹窗列表中。

需要说明的是，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

以上对本申请所提供的一种弹窗弹出方法及装置进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (7)

1.一种弹窗弹出方法，其特征在于，应用于客户端，该方法包括：

预先从服务端获取弹窗配置信息，并基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表；其中，清理待弹窗列表中弹窗结束展示时间大于当前时间的所有过期的弹窗配置信息；

在获取到弹窗触发信息时，基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗；

其中，所述方法还包括：

在接收到所述服务端通过长连接推送的弹窗配置信息时，基于所述服务端通过长连接推送的弹窗配置信息，更新所述待弹窗列表；其中，所述服务端通过长连接向所有在线客户端推送弹窗配置信息，而非只对弹窗中规定的场景中的客户端进行推送；

基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；

若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗；

其中，所述基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件，包括：

从所述弹窗配置信息中获取弹窗开始展示时间；

判断用户所在时间，是否位于所述弹窗开始展示时间；

若位于所述弹窗开始展示时间，则从所述弹窗配置信息中获取规定的弹窗场景信息；

判断用户当前所处的场景是否位于所述规定的弹窗场景信息中；

若位于所述规定的弹窗场景信息中，则判断待弹出弹窗是否达到预先设定的频率控制要求。

2.根据权利要求1所述的方法，其特征在于，所述预先从服务端获取弹窗配置信息，包括：

在所述客户端启动时，通过HTTP协议从服务端获取弹窗配置信息。

3.根据权利要求1所述的方法，其特征在于，所述预先从服务端获取弹窗配置信息，包括：

预先与服务端建立长连接；

向所述服务端发送弹窗配置信息请求消息，并接收所述服务端响应所述弹窗配置信息请求消息，下发的弹窗配置信息。

4.根据权利要求1所述的方法，其特征在于，所述弹窗触发信息，包括：

所述客户端中APP启动信息；

或，所述服务端通过长连接推送的触发信息；

或，页面切换信息；

或，从后台切换到前台的信息。

5.根据权利要求1所述的方法，其特征在于，所述基于所述弹窗配置信息，更新所述客户端的待弹窗列表，包括：

判断是否基于所述弹窗配置信息，执行过弹窗弹出动作；

若是，则丢弃所述弹窗配置信息；

若否，则判断所述待弹窗列表中是否存在与所述弹窗配置信息匹配的信息；

若存在，则将所述待弹窗列表中与所述弹窗配置信息匹配的信息，替换为所述弹窗配置信息；

若不存在，则将所述弹窗配置信息存储到所述待弹窗列表中。

6.一种弹窗弹出装置，其特征在于，应用于客户端，该装置包括：

获取模块，用于预先从服务端获取弹窗配置信息；

第一更新模块，用于基于所述弹窗配置信息，更新所述客户端预先存储的待弹窗列表；其中，清理待弹窗列表中弹窗结束展示时间大于当前时间的所有过期的弹窗配置信息；

第一判断模块，用于在获取到弹窗触发信息时，基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；

第一弹出模块，用于若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗；

其中，所述装置还包括：

第二更新模块，用于在接收到所述服务端通过长连接推送的弹窗配置信息时，基于所述服务端通过长连接推送的弹窗配置信息，更新所述待弹窗列表；其中，所述服务端通过长连接向所有在线客户端推送弹窗配置信息，而非只对弹窗中规定的场景中的客户端进行推送；

第二判断模块，用于基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件；

第二弹出模块，用于若满足预先设定的弹窗条件，则基于所述待弹窗列表中的弹窗配置信息，弹出弹窗；

其中，所述基于所述待弹窗列表中的弹窗配置信息，判断是否满足预先设定的弹窗条件，包括：

从所述弹窗配置信息中获取弹窗开始展示时间；

判断用户所在时间，是否位于所述弹窗开始展示时间；

若位于所述弹窗开始展示时间，则从所述弹窗配置信息中获取规定的弹窗场景信息；

判断用户当前所处的场景是否位于所述规定的弹窗场景信息中；

若位于所述规定的弹窗场景信息中，则判断待弹出弹窗是否达到预先设定的频率控制要求。

7.根据权利要求6所述的装置，其特征在于，所述获取模块，具体用于：

在所述客户端启动时，通过HTTP协议从服务端获取弹窗配置信息。