出於商業化的目的，大型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。