广告请求方法、装置及移动终端与流程

本发明涉及互联网技术领域，具体而言，本发明涉及一种广告请求方法、装置及移动终端。

背景技术：

目前，普遍存在应用端对服务器发起过多广告请求而出现的广告“浪费”的现象。同时目前的广告很多都是实时竞价的广告，如果因为广告请求过多而导致广告浪费的话，广告投放系统的投放策略和竞价会受到很大的影响。另一方面，广告请求过多的情况，还会对广告展示率造成很大影响：因为广告展示率＝showcount/requestcount，其中，showcount是广告展示个数，requestcount是广告请求个数。由于通常应用内设置的广告位数量都是固定的，所以影响广告展示率的因素就只剩下广告请求个数。根据上述广告展示率的公式可知，广告的请求量越大，广告的展示率就越低。由于广告展示率低直接会影响应用的评价评判指标，假如广告展示率一直低下，那么应用内的广告位就会得不到广告主的青睐。

因此，如何解决应用端由于请求广告过多而导致的浪费成为了亟需解决的问题。

技术实现要素：

本发明针对现有技术的缺点，提供了一种广告请求方法、装置及移动终端，能够合理地确定广告请求量，解决现有技术中应用客户端设置的广告请求数量不准确而增大广告服务器压力和浪费流量的问题。

本发明实施例提供了一种广告请求方法，应用于应用客户端中的嵌入式sdk，包括以下步骤:

步骤一：确定广告请求量，向广告服务器发送包括所述广告请求量的广告获取请求；

步骤二：接收所述广告服务器返回的广告数据信息，并确定广告返回量；

步骤三：判断是否满足停止请求条件；

若不满足，则重复执行步骤一至步骤三，直至判断满足停止请求条件。

进一步地，所述确定广告请求量，之前还包括：

接收来自应用客户端的广告请求通知，所述广告请求通知包括广告需求量。

进一步地，所述确定广告请求量的步骤，包括：

若第1次请求广告数据，则依据广告请求通知中包括的广告需求量来确定广告请求量；

若为第n次请求广告数据，则确定第n次的广告请求量为第n-1次广告请求量与第n-1次广告返回量之间的差值，其中n是大于1的整数。

进一步地，所述若第1次请求广告数据，则依据广告请求通知中包括的广告需求量来确定广告请求量，包括：

确定广告数据缓存区域中是否缓存有广告数据；

若有，则将广告请求通知中包括的广告需求量与缓存的广告缓存量的差值，确定为广告请求量；

若没有，则将广告请求通知中包括的广告需求量确定为广告请求量。

进一步地，确定广告数据缓存区域中是否缓存有广告数据，具体包括：

确定广告数据缓存区域中是否缓存有有效的广告数据；

其中，确定有效的广告数据包括：

确定广告数据缓存区域中缓存的全部广告数据；

依据各个广告数据的广告时限信息，确定广告数据缓存区域中缓存的有效广告数据。

进一步地，所述广告请求通知还包括广告位数量。

进一步地，还包括：

若判断满足停止请求条件，停止广告请求，并根据广告位数量处理返回的广告数据，并将处理后的广告数据保存至广告数据缓存区域。

进一步地，还包括：

接收来自应用客户端的广告展示通知，所述广告展示通知包括成功展示的广告的标识；

删除广告数据缓存区域中与所述成功展示的广告的标识对应的广告数据。

进一步地，所述停止请求条件，具体包括以下至少一项：

广告返回量等于预设数值；

广告返回量满足广告请求量；

重复执行步骤一至步骤三的次数等于预设次数。

本发明实施例还提供了一种应用客户端中的嵌入式sdk，包括以下模块:

重复请求第一模块，用于确定广告请求量，向广告服务器发送包括所述广告请求量的广告获取请求；

重复请求第二模块，用于接收所述广告服务器返回的广告数据信息，并确定广告返回量；

重复请求第三模块，用于判断是否满足停止请求条件；

若不满足，则重复依次执行重复请求第一模块至重复请求第三模块所执行的操作，直至满足重复请求第三模块的停止请求条件。

进一步地，还包括广告请求通知接收模块，用于接收来自应用客户端的广告请求通知，所述广告请求通知包括广告需求量。

进一步地，所述重复请求第一模块包括：

广告请求量确定第一子模块，用于在第1次请求广告数据时，依据广告请求通知中包括的广告需求量来确定广告请求量；

广告请求量确定第二子模块，用于在第n次请求广告数据，确定第n次的广告请求量为第n-1次广告请求量与第n-1次广告返回量之间的差值，其中n是大于1的整数。

进一步地，所述广告请求量确定第一子模块，包括：

广告缓存数据确定单元，用于确定广告数据缓存区域中是否缓存有广告数据；

若有，则广告请求量确定第一子模块将广告请求通知中包括的广告需求量与缓存的广告缓存量的差值，确定为广告请求量；

若没有，则广告请求量确定第一子模块将广告请求通知中包括的广告需求量确定为广告请求量。

进一步地，广告缓存数据确定单元，具体包括：

有效广告缓存数据确定子单元，用于确定广告数据缓存区域中是否缓存有有效的广告数据；

其中，确定有效的广告数据包括：

确定广告数据缓存区域中缓存的全部广告数据；

依据各个广告数据的广告时限信息，确定广告数据缓存区域中缓存的有效广告数据。

进一步地，所述广告请求通知接收模块所接收的广告请求通知还包括广告位数量。

进一步地，还包括：

广告数据处理子模块，用于当判断满足停止请求条件时，停止广告请求，并根据广告位数量处理返回的广告数据，并将处理后的广告数据保存至广告数据缓存区域。

进一步地，还包括：

广告展示通知接收模块，用于接收来自应用客户端的广告展示通知，所述广告展示通知包括成功展示的广告的标识；

广告数据删除模块，用于删除广告数据缓存区域中与所述成功展示的广告的标识对应的广告数据。

进一步地，所述重复请求第三模块中的停止请求条件，具体包括以下至少一项：

广告返回量等于预设数值；

广告返回量满足广告请求量；

重复依次执行重复请求第一模块至重复请求第三模块所执行的操作的次数等于预设次数。

本发明的实施例根据另一个方面，还提供了一种移动终端，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现上述广告请求方法。

本发明实施例在停止请求条件不满足时，应用客户端中的嵌入式sdk会重新确定广告请求量，之后向广告服务器发送广告请求，直至满足停止请求条件，通过合理地确定广告请求量，解决了现有技术中应用客户端设置广告请求数量不准确而增大广告服务器压力和浪费流量的问题，同时在停止请求条件不满足时重复向广告服务器请求广告，更加充分地满足了应用客户端对广告数量的需求。

进一步地，广告数据缓存区域能够保存未被成功展示的广告数据，当应用客户端再次有广告需求时，sdk为其提供仍有效的广告数据，从而避免广告资源的浪费；多个停止请求条件能够合理控制应用客户端等待sdk返回广告数据的时间，进而保障应用客户端的广告数据加载速度。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为应用更新方法的流程图；

图2为应用更新装置的结构示意图；

图3为应用更新装置的详细结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的“终端”、“终端设备”既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，进行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；pcs(personalcommunicationsservice，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；pda(personaldigitalassistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或gps(globalpositioningsystem，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的“终端”、“终端设备”可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。这里所使用的“终端”、“终端设备”还可以是通信终端、上网终端、音乐/视频播放终端，例如可以是pda、mid(mobileinternetdevice，移动互联网设备)和/或具有音乐/视频播放功能的移动电话，也可以是智能电视、机顶盒等设备。

本发明实施例提供了一种广告请求方法，所述广告请求方法是通过应用客户端中的嵌入式sdk来实现的。

sdk(softwaredevelopmentkit，软件开发工具包)是指辅助开发某一特定的应用软件时提供的相关文档、范例和开发工具的集合，包括用于调试和其他用途的实用工具。它可以简单的为某个程序设计语言提供应用程序接口api的一些文件，也可能包括能与某种嵌入式系统通讯的复杂的硬件，还可能包括示例代码、支持性的技术注解或者其他的为基本参考资料澄清疑点的支持文档。

该广告请求方法的流程图如图1所示，具体包括以下步骤：

步骤s100：sdk确定广告请求量，向广告服务器发送包括所述广告请求量的广告获取请求；

步骤s200：sdk接收所述广告服务器返回的广告数据信息，并确定广告返回量；

步骤s300：sdk判断是否满足停止请求条件；若不满足，则重复执行步骤一至步骤三，直至判断满足停止请求条件。

应用本发明实施例提供的广告请求方法所获得的有益效果包括：

本发明实施例在停止请求条件不满足时，应用客户端中的嵌入式sdk会重新确定广告请求量，之后向广告服务器发送广告请求，直至满足停止请求条件，通过合理地确定广告请求量，解决了现有技术中应用客户端设置广告请求数量不准确而增大广告服务器压力和浪费流量的问题，同时在停止请求条件不满足时重复向广告服务器请求广告，更加充分地满足了应用客户端对广告数量的需求，从而有效提高广告展示率，使广告主和应用开发者的利益最大化，促进一个良性循环。

以下以sdk为执行主体，针对以上各个步骤的具体实现做进一步的说明。

步骤s100：sdk确定广告请求量，向广告服务器发送包括所述广告请求量的广告获取请求。

步骤s100之前，还包括步骤s000：sdk接收来自应用客户端的广告请求通知，所述广告请求通知包括广告需求量，广告位数量。

sdk确定广告请求量有两种情况。

情况一：若第1次请求广告数据，则依据广告请求通知中包括的广告需求量来确定广告请求量。

具体地，sdk确定广告数据缓存区域中是否缓存有广告数据；若有，则将广告请求通知中包括的广告需求量与缓存的广告缓存量的差值，确定为广告请求量；若没有，则将广告请求通知中包括的广告需求量确定为广告请求量。

所述广告数据缓存区域位于与应用客户端的对应的一段内存区域内，用于存储广告服务器返回的广告数据。广告数据缓存区域能够保存未被成功展示的广告数据，当应用客户端再次有广告需求时为其提供仍有效的广告数据，从而避免广告资源的浪费。

在一种优选实施方式中，所述sdk除了确定广告数据缓存区域中是否缓存有广告数据，还需要确认缓存的广告数据是否有效。因为某些广告具有时效性，广告主会要求广告投放在某具体时段，而只有当广告投放在广告主要求的时段内才会被视为有效。比如，广告主要求广告在2017年12月5日9点到22点时段内投放，那么广告投放的时间为2017年12月5日9点之前或22点之后，都视为无效。因此，所述sdk确定广告数据缓存区域中是否缓存有广告数据，具体包括：确定广告数据缓存区域中是否缓存有有效的广告数据；其中，确定有效的广告数据包括：确定广告数据缓存区域中缓存的全部广告数据；依据各个广告数据的广告时限信息，确定广告数据缓存区域中缓存的有效广告数据。所述广告时限信息是包含在广告服务器返回的广告数据中。

具体地，sdk接收到来自应用客户端的广告需求通知后，先确定出广告数据缓存区域中缓存的全部广告数据，并提取出各个广告数据对应的广告时限信息，sdk会判断当前时刻是否在广告时限信息中的广告投放时段中，如果是包含在广告投放时段中，则确定广告数据为有效广告数据，反之，则无效。例如sdk确定了广告数据缓存区域中有a广告数据，还需要确定a广告数据是否为有效广告数据，当前时刻为2017年12月5日10点整，从a提出的广告时限信息中的广告投放时段为2017年12月5日9点到22点时段，通过将当前时刻与广告投放时段对比可知，当前时刻处于a广告数据的广告投放时段内，因此sdk就可以确定a广告数据为有效广告数据。

情况二：若为第n次请求广告数据，则确定第n次的广告请求量为第n-1次广告请求量与第n-1次广告返回量之间的差值，其中n是大于1的整数。

步骤s200：sdk接收所述广告服务器返回的广告数据信息，并确定广告返回量。

具体地，sdk确定广告请求量之后，会向广告服务器发送包括所述广告请求量的广告获取请求。广告服务器接收到来自sdk的广告获取请求后，会尽力满足sdk的广告获取请求，但有可能广告服务器接收所述广告获取请求时，拥有的广告数量较少，并不满足sdk所请求的广告请求量。由于目前的广告很多都是实时竞价的广告，所以广告服务器下一时刻所拥有的广告数量是不确定的。通常会出现广告服务器接收到来自sdk的广告获取请求时，当前时刻并没有满足sdk请求的广告数量，但是在下一时刻广告服务器就有能够满足sdk请求的广告量。为了尽可能满足应用客户端的广告需求，sdk会重新确定广告请求量，并向广告服务器发送包括重新确定的广告请求量的广告获取请求。第二次或以上向广告服务器请求广告数据时，确定对应的广告请求量具体包括：确定第n次的广告请求量为第n-1次广告请求量与第n-1次广告返回量之间的差值，其中n是大于1的整数。比如sdk第三次请求广告数据，则确定第三次的广告请求量为第2次广告请求量与第2次广告返回量之间的差值。

步骤s300：sdk判断是否满足停止请求条件；若不满足，则重复执行步骤一至步骤三，直至判断满足停止请求条件。

步骤s300还包括：步骤s310；步骤s310：若判断满足停止请求条件，停止广告请求，并根据广告位数量处理返回的广告数据，并将处理后的广告数据保存至广告数据缓存区域。

具体地，当应用客户端拥有的每个广告位对应放置一个广告，则sdk接收到广告服务器返回的广告数据后，按照应用客户端的广告位数量对所述广告数据进行拆分。比如a、b、c三个广告位，当sdk向广告服务器请求到3个广告数据，如字符序列时，将字符序列根据广告位数量拆分成3个广告地址信息，对应于3个广告位。

优选地，若应用客户端有多个广告位，并且每个广告位需要广告数量不相同。比如a广告位需要3个广告，b广告位需要4个广告，c广告位需要5个广告。当sdk向广告服务器请求到12个广告数据时，将广告数据根据广告位数量，以及各个广告位所需要的广告数量进行拆分。

如果广告服务器返回的广告返回量不满足sdk请求的广告请求量，则sdk根据应用客户端中广告位的优先级对接收到的广告数据进行分配，所述广告位的优先级规则由sdk预先配置，或由应用开发者预先配置。

其中，所述停止请求条件，具体包括以下至少一项：

广告返回量满足广告请求量；

广告返回量等于预设数值；

重复执行步骤一至步骤三的次数等于预设次数。

通过设置多个停止请求条件能够更加充分地满足了应用客户端对广告数量的需求；同时能够合理控制应用客户端等待sdk返回广告数据的时间，从而保障应用客户端的广告数据加载速度。

具体地，一种情况下，由于广告返回量不满足广告请求量，sdk会重复地向广告服务器发送广告获取请求，最终保证广告服务器返回的广告数量满足应用客户端的广告需求量。

在另一种情况下，sdk向广告服务器发送广告获取请求，但广告服务器没有回应或是返回的广告数量不合常理等，这很有可能是广告服务器出现问题了，这时候通过设置停止请求条件为广告返回量等于预设数值，来避免广告服务器出现问题而sdk仍继续向广告服务器发送广告获取请求，浪费发送请求的资源以及等待反馈的时间。比如sdk跟广告服务器交互后反馈的广告返回量为0，那么之后很大概率广告返回量均为0。在广告服务器返回的广告返回量为0时，广告服务器在很大概率上是实时竞价系统出现异常问题，而很有可能在接下来一段时间内广告服务器都没有广告返回，因此设置预设数值为0，如果某个时刻广告服务器返回的广告返回量为0，则不再继续尝试发送广告获取请求。

在又一种情况下，设置停止请求条件为重复执行步骤一至步骤三的次数等于预设次数。sdk向广告服务器发起广告获取请求次数越多，会使得sdk与广告服务器之间的交互时长变得越长，相对的，应用客户端等待sdk的时间会就越长，这样很有可能导致广告没有展示的机会，或错失展示的机会。因为实际情况中，用户在应用客户端中停留时间不长，很有可能用户进入应用客户端后，广告还没有展示出来，用户就退出应用客户端；也有可能用户进入应用客户端后，广告迟迟没有加载完毕，那用户会认为广告的加速速度太慢，并且在广告内容全部加载出来之前就退出应用或关闭广告，因此需要限制请求广告的时长。而另一方面，在预设次数内，比如3次，广告服务器返回的广告总量仍然达不到应用客户端的广告需求，有可能是广告主这段时间的广告投放量不高，再继续尝试请求所得到广告服务器返回的广告数量也很可能无法满足需求，此时可以停止广告请求，避免浪费资源。

另一实施方式中，可以对应用客户端向sdk所请求的广告需求量加以限制，比如最多请求10个。因为广告需求量越多，sdk要向广告服务器请求的广告数量就越多，那么应用客户端等待广告服务器返回足够广告数量的时间就会越长，这也会使广告的加载时间变慢。

优选地，该方法还包括步骤s400；步骤s400：sdk接收来自应用客户端的广告展示通知，所述广告展示通知包括成功展示的广告的标识。

具体地，当应用客户端接收到的sdk返回的广告数据后，应用客户端会展示接收到的广告数据，而广告展示成功后，会向sdk发送广告展示通知，所述广告展示通知包括成功展示的广告的标识。

更优选地，该方法还包括步骤s500；步骤s500：sdk删除广告数据缓存区域中与所述成功展示的广告的标识对应的广告数据。

具体地，sdk接收来自应用客户端的广告展示通知后，会根据所述成功展示的广告的标识在广告数据缓存区域中找到与所述成功展示的广告的标识对应的广告数据，并将所述广告数据删除。

为了以模块化的方式对本发明所述方法做进一步说明，本申请提供了一种应用更新装置，如图2所示，包括：重复请求第一模块100，重复请求第二模块200，重复请求第三模块300。

以下针对以上各个模块的具体实现做进一步的说明。

重复请求第一模块100：用于确定广告请求量，向广告服务器发送包括所述广告请求量的广告获取请求。

如图3所示，本实施例的应用更新装置还包括广告请求通知接收模块000：用于接收来自应用客户端的广告请求通知，所述广告请求通知包括广告需求量，广告位数量。

重复请求第一模块100包括广告请求量确定第一子模块和广告请求量确定第二子模块。

广告请求量确定第一子模块：用于在第1次请求广告数据时，依据广告请求通知中包括的广告需求量来确定广告请求量。

具体地，广告请求量确定第一子模块包括：

广告缓存数据确定单元，用于确定广告数据缓存区域中是否缓存有广告数据。

若有，则广告请求量确定第一子模块将广告请求通知中包括的广告需求量与缓存的广告缓存量的差值，确定为广告请求量；

若没有，则广告请求量确定第一子模块将广告请求通知中包括的广告需求量确定为广告请求量。

所述广告数据缓存区域位于应用客户端的内存内，用于存储广告服务器返回的广告数据。

在一种实施方式中，所述广告缓存数据确定单元，具体包括：

有效广告缓存数据确定子单元，用于确定广告数据缓存区域中是否缓存有有效的广告数据；

其中，确定有效的广告数据包括：

确定广告数据缓存区域中缓存的全部广告数据；

依据各个广告数据的广告时限信息，确定广告数据缓存区域中缓存的有效广告数据。

这是因为某些广告具有时效性，广告主会要求广告投放在某具体时段，而只有当广告投放在广告主要求的时段内才会被视为有效。比如，广告主要求广告在2017年12月5日9点到22点时段内投放，那么广告投放的时间为2017年12月5日9点之前或22点之后，都视为无效。因此，所述sdk确定广告数据缓存区域中是否缓存有广告数据，所述广告时限信息是包含在广告服务器返回的广告数据中。

具体地，广告请求通知接收模块000接收到来自应用客户端的广告请求通知后，有效广告缓存数据确定子单元先确定出广告数据缓存区域中缓存的全部广告数据，并提取出各个广告数据对应的广告时限信息，判断当前时刻是否在广告时限信息中的广告投放时段中，如果是包含在广告投放时段中，则确定广告数据为有效广告数据，反之，则无效。例如广告缓存数据确定单元确定了广告数据缓存区域中有a广告数据，还需要有效广告缓存数据确定子单元进一步确定a广告数据是否为有效广告数据，当前时刻为2017年12月5日10点整，从a提出的广告时限信息中的广告投放时段为2017年12月5日9点到22点时段，通过将当前时刻与广告投放时段对比可知，当前时刻处于a广告数据的广告投放时段内，因此有效广告缓存数据确定子单元就可以确定a广告数据为有效广告数据。

广告请求量确定第二子模块：用于在第n次请求广告数据，确定第n次的广告请求量为第n-1次广告请求量与第n-1次广告返回量之间的差值，其中n是大于1的整数。

重复请求第二模块200：用于接收所述广告服务器返回的广告数据信息，并确定广告返回量。

具体地，重复请求第一模块100确定广告请求量之后，会向广告服务器发送包括所述广告请求量的广告获取请求。广告服务器接收到来自重复请求第一模块100的广告获取请求后，会尽力满足重复请求第一模块100的广告获取请求，但有可能广告服务器接收所述广告获取请求时，拥有的广告数量较少，并不满足重复请求第一模块100所请求的广告请求量。由于目前的广告很多都是rtb(实时竞价)的广告，所以广告服务器下一时刻所拥有的广告数量是不确定的。通常会出现广告服务器接收到来自重复请求第一模块100的广告获取请求时，当前时刻并没有满足重复请求第一模块100请求的广告数量，但是在下一时刻广告服务器就有能够满足重复请求第一模块100请求的广告量。为了尽可能满足应用端的广告需求，重复请求第一模块100会重新确定广告请求量，并向广告服务器发送包括重新确定的广告请求量的广告获取请求。第二次或以上向广告服务器请求广告数据时，重复请求第一模块100确定对应的广告请求量具体步骤包括：确定第n次的广告请求量为第n-1次广告请求量与第n-1次广告返回量之间的差值，其中n是大于1的整数。比如重复请求第一模块100第三次请求广告数据，则确定第三次的广告请求量为第2次广告请求量与第2次广告返回量之间的差值。

重复请求第三模块300：用于判断是否满足停止请求条件；若不满足，则重复依次执行重复请求第一模块100至重复请求第三模块300所执行的操作，直至判断满足停止请求条件。

所述重复请求第三模块300包括广告数据处理子模块。

广告数据处理子模块：用于若判断满足停止请求条件，停止广告请求，并根据广告位数量处理返回的广告数据，并将处理后的广告数据保存至广告数据缓存区域。

具体地，当应用客户端拥有的每个广告位对应放置一个广告，则重复请求第二模块200接收到广告服务器返回的广告数据后，广告数据处理子模块按照应用客户端的广告位数量对所述广告数据进行拆分。比如a、b、c三个广告位，当重复请求第一模块100向广告服务器请求到3个广告数据，如字符序列时，广告数据处理子模块将字符序列根据广告位数量拆分成3个广告地址信息，对应于3个广告位。

优选地，若应用客户端有多个广告位，并且每个广告位需要广告数量不相同。比如a广告位需要3个广告，b广告位需要4个广告，c广告位需要5个广告。当重复请求第一模块100向广告服务器请求到12个广告数据，广告数据处理子模块将广告数据根据广告位数量，以及各个广告位所需要的广告数量进行拆分。

如果广告服务器返回的广告返回量不满足重复请求第一模块100请求的广告请求量，则广告数据处理子模块根据应用客户端中广告位的优先级对接收到的广告数据进行分配，所述广告位的优先级规则由广告数据处理子模块预先配置，或由应用开发者预先配置。

其中，所述停止请求条件，具体包括以下至少一项：

广告返回量满足广告请求量；

广告返回量等于预设数值；

重复依次执行重复请求第一模块100、重复请求第二模块200和重复请求第三模块300所执行的操作的次数等于预设次数。

通过设置多个停止请求条件能够更加充分地满足了应用客户端对广告数量的需求；同时能够合理控制应用客户端等待sdk返回广告数据的时间，从而保障应用客户端的广告数据加载速度。

具体地，一种情况下，由于广告返回量不满足广告请求量，sdk会重复地向广告服务器发送广告获取请求，最终保证广告服务器返回的广告数量满足应用客户端的广告需求量。

在另一种情况下，重复请求第一模块100向广告服务器发送广告获取请求，但广告服务器没有回应或是返回的广告数量不合常理等，这很有可能是广告服务器出现问题了，这时候通过设置停止请求条件为广告返回量等于预设数值，来避免广告服务器出现问题而重复请求第一模块100仍继续向广告服务器发送广告获取请求，浪费发送请求的资源以及浪费等待反馈的时间。比如重复请求第一模块100跟广告服务器交互后反馈广告返回量是0，那么之后很大概率广告返回量均为0。在广告服务器的广告返回量为0时，广告服务器在很大概率上是实时竞价系统出现异常问题，而很有可能在接下来一段时间内广告服务器都没有广告返回，因此设置预设数值为0，如果某个时刻广告服务器的广告返回量为0，则不再继续尝试发送广告获取请求。

在又一种情况下，设置停止请求条件为重复依次执行重复请求第一模块100、重复请求第二模块200和重复请求第三模块300所执行的操作的次数等于预设次数。重复请求第一模块100向广告服务器发起广告获取请求次数越多，会使得sdk与广告服务器之间的交互时长变得越长，相对的，应用客户端等待sdk的时间会就越长，这样很有可能导致广告没有展示的机会，或错失展示的机会。因为实际情况中，用户在应用客户端中停留时间不长，很有可能用户进入应用客户端后，广告还没有展示出来，用户就退出应用客户端；也有可能用户进入应用客户端后，广告迟迟没有加载完毕，那用户会认为广告的加速速度太慢，并且在广告内容全部加载出来之前就退出应用或关闭广告，因此需要限制请求广告的时长。而另一方面，在预设次数内，比如3次，广告服务器返回的广告总量仍然达不到应用客户端的广告需求，有可能是广告主这段时间的广告投放量不高，再继续尝试请求所得到广告服务器返回的广告数量也很可能无法满足需求，此时可以停止广告请求，避免浪费资源。

另一实施方式中，可以对应用客户端向sdk所请求的广告需求量加以限制，比如最多请求10个。因为广告需求量越多，sdk要向广告服务器请求的广告数量就越多，那么应用客户端等待广告服务器返回足够广告数量的时间就会越长，这也会使广告的加载时间变慢。

优选地，所述嵌入式sdk还包括广告展示通知接收模块400；广告展示通知接收模块400：用于接收来自应用客户端的广告展示通知，所述广告展示通知包括成功展示的广告的标识。

具体地，当应用客户端接收到的sdk返回的广告数据后，应用客户端会展示接收到的广告数据，而广告展示成功后，会向广告展示通知接收模块400发送广告展示通知，所述广告展示通知包括成功展示的广告的标识。

更优选地，所述嵌入式sdk还包括广告数据删除模块500；广告数据删除模块500：用于删除广告数据缓存区域中与所述成功展示的广告的标识对应的广告数据。

具体的，广告展示通知接收模块400接收来自应用客户端的广告展示通知后，广告数据删除模块500会根据所述成功展示的广告的标识在广告数据缓存区域中找到与所述成功展示的广告的标识对应的广告数据，并将所述广告数据删除。

本发明的实施例根据另一个方面，还提供了一种服务器，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现上述应用更新方法。

本技术领域技术人员可以理解，本发明包括涉及用于执行本申请中所述操作中的一项或多项的设备。这些设备可以为所需的目的而专门设计和制造，或者也可以包括通用计算机中的已知设备。这些设备具有存储在其内的计算机程序，这些计算机程序选择性地激活或重构。这样的计算机程序可以被存储在设备(例如，计算机)可读介质中或者存储在适于存储电子指令并分别耦联到总线的任何类型的介质中，所述计算机可读介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、cd-rom、和磁光盘)、rom(read-onlymemory，只读存储器)、ram(randomaccessmemory，随即存储器)、eprom(erasableprogrammableread-onlymemory，可擦写可编程只读存储器)、eeprom(electricallyerasableprogrammableread-onlymemory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。

本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本发明公开的结构图和/或框图和/或流图的框或多个框中指定的方案。

本技术领域技术人员可以理解，本发明中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本发明中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本发明中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。

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