出于商业化的目的，大型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这种第三方的库，来上报，复合行业标准。
广告控制时机讨论
如果封装成SDK，只要有请求，展示，上报。具体什么时机展示，多长时间展示，都是app 控制。具体来说就是把SDK公开的接口，放入对应app的代码位置。另外SDK可以接受一些如qq 微信或者手机号的openid ，便于标识用户。
通过上面的介绍，就可以实现一个完整的闪屏业务或SDK。