移动端闪屏广告业务设计模式

出于商业化的目的，大型APP都会接入广告闪屏的业务或SDK。下面介绍闪屏广告业务或SDK的设计思路。

背景知识：

移动闪屏广告出现的时机主要是冷启动和热启动。两次广告出现之间有一个间隔时长，一般冷启动情况会跳过这个时长限制，有广告会直接展示。移动闪屏展示模式主要有图片、视频和webview模式。

设计模式

请求模式主要分为实时请求和选单请求两种模式。

实时请求模式

在闪屏广告出现时机的时候，立刻发送请求，请求会返回一定时间内的广告列表，按照优先顺序排列。拿到列表后，首先看本地有没有缓存，如果有命中缓存就立刻展示；如果都没有命中，选择下载对应资源。下载成功立刻展示。不过广告展示尽量快的展示，所以整体从发出列表请求，到查询缓存、可能下载资源。这里有一个整体的超时时间Tmax。Tmax结束后还没有能立刻展示的广告资料，本次就结束。这个根据经验一般是0.5s。一般人眼能分辨的时间长度是0.4s，这个之外就能感觉到卡顿或者延时。一般正常网络两次请求也能够优化在0.5s之内，所以选择这个时间。总之，考虑一般请求时间和人眼感觉的卡顿时间。这个时间其实也可以通过后台下发。 流程如下图：

只要请求到了广告列表，就可以在子线程选择一个时机去默默的下载对应广告资源。关于存储位置，下面有对应讲解。

选单请求模式

每次是根据客户端缓存好的素材请求服务器，服务器决定显示哪一个，之后在请求广告列表，并根据广告列表下载资源。这个好处是广告展示时间缩短，只需要一个请求就能决定是否展示。模式如下图：

这两种模式每次都需要有一个请求，第二种更好一些，第一种实时性更好。如果开始不用选单，直接看缓存这样不更快吗?从性能时间考虑肯定会有这样的疑问，但是这样后台就很难控制广告的展示。一般售卖通过点击和展示时间，如果不通过请求，超过时间还展示，相当于浪费了广告的展示时机。

广告展示程序设计

根据广告的展示可以这样设计，广告展示通过一个单独的window，一个盖在最上面的window展示。主要的展示逻辑放在一个基础basecontroller，basecontroller的view加到上面的window上，这个和App本身类似。

• basecontroller，包括基本功能，展示，结束，跳过等等。 根据广告样式写出具体的imagecontroller ，videocontroller， webviewcontroller继承 basecontroller，根据不同广告展示对应controller。 每个controller管理具体的展示业务逻辑。

• 资源管理封装成一个类，管理资源的获取和清理。

• 网络请求封装成一个类，管理对应的请求。

• 整体对外的接口统一成一个manager，将请求、view展示和下载等封装在一起。对外暴露一些接口和协议。协议主要包括：广告即将展示、广告展示、没有广告展示、广告即将结束、广告结束、点击跳过广告、点击广告内容跳转等等。

• DEBUG 功能 debug 主要是给两类人，一类是开发人员，可以通过上报的日志进行分析。 另一类人是广告主，广告主通过一个url看对应广告样式。设计一个链接，跳到APP 中给SDK 解析，如果能解析，那么一段时间内下次app 就展示广告。这样方便广告主看广告。

• 日志功能类 主要是写入日志，用于错误情况上报。

• 其他 广告点击后进入页面，SDK 可以提供一个默认view，也可能回调给调用方自己处理。 广告都有倒计时功能，一般就是用timer 定时回调，但是在冷启动的时候，展示出闪屏后 app的主线程可能有繁重任务，会影响timer，这时用子线程更好一些。

存储位置与管理

广告资源一般存储在Library/cache 下，这样用户可以通过清理缓自动删除。 如果为了广告能够高的目中率，可以存到document下，虽然有可能被同步，占用用户资源。 此外每次请求到广告后，在子线程做一下广告缓存数据清理，把非次本次列表中的缓存资源全部删除。 这样就不会有过多的占用。

上报相关

广告在需要请求，发出请求，展示，结束等都需要有上报，主要统计广告展示的效率和真正次数。 另外一般都会接入MMA这种第三方的库，来上报，复合行业标准。