聚合广告sdk的开发之路

        好久没写博客了，因为这段时间一直很忙。搬了新家，换了新的工作，开启人生的另一个阶段。从事过其他App的开发工作，发现还是比较喜欢广告这个行业，毕竟在这个行业也算是个老人了，应该有5个年头了吧，从普通的应用外广告，应用内广告，激励视频广告，再到现在海外聚合广告，一直在积累，一直在成长。

         中国的移动互联网兴起已经有几个年头了，大概是14年开始火起来的，到现在也有6个年头了，国内的互联网也从创业的蓝海变成红海，互联网的红利正在消失。 出海似乎成了一种趋势，毕竟很多东南亚国家的互联网才刚刚开始。估计又会有一批创业者，屌丝逆袭，迎娶白富美，当上CEO,走上人生的巅峰。好了，废话不多说，直接进入主题。

         刚入职的这家公司在海外拥有海量的流量，是一家手机厂商，比oppo,vivo,华为的出货量还高，有非洲之王的称号（有兴趣，自行百度），自家的手机都会内置很多App,而变现方式离不开广告，故而拥有一个帮助集团内部App变现的广告sdk就显得尤为重要。但是考虑到，各家海外广告sdk（admob,unity,facebook等）的填充率在有的国家的填充率实在不怎么样，所以为了提高整体的广告填充率，聚合多家广告sdk才是明智之举。废话不多说，先贴上聚合sdk的软件架构图

各个层级介绍如下：

第一层：sdk接口层，即暴露给开发者调用接口。因为该聚合sdk包含5种展示方式，分别是banner 横幅，interstitial 插屏，native原生，开屏，RewardViedeo激励视频,每一种展示方式对应封装成一个对象，该对象主要提供 加载广告loadAd(),展示广告show()等函数。

第二层：各个第三方平台sdk封装层。该聚合sdk主要集成了 admob,facebook,unity,和公司自家的sdk.每一家广告sdk所提供的接口和回调参数等都不一样，所以为了调用的方便，需要进一步对各个平台进行封装，对外暴露同样的接口以及回调。

第三层，也是整个聚合sdk最核心的层级，也就是流量分配层级。一个聚合广告sdk的核心所在。该层级就是如何将流量价值最大化，如何将最优的流量展示最优的广告，将Ecpm最大化以及广告的缓存策略，从而保证填充率。

第四层：数据监测层，也就是广告请求数，展示数，点击数，下载数，安装数等等数据统计已经各种事件埋点。该层级主要是帮助运营根据这些数据进行运营优化

第五层：基础服务层，就是一些基础服务，例如网络请求，比如拉取广告数据，数据库服务，就是数据持久化，图片缓存等服务。

整个项目的uml类图如下：

 

                      

                         

 

以上大概是整个聚合sdk的架构设计。该聚合sdk支持国内任何一家广告sdk,灵活配置。整体项目非常稳定，崩溃率控制在万分之二。

其实整个项目的核心应该就是广告缓存和流量分发策略，如何在保证填充率的同时又要尽可能的提高展示率，因为展示率太低，相对应的ecpm就会降低，收益也就跟着降低，如何将最优的广告提供给媒体等都是聚合广告sdk必须要面临的重要问题。

目前聚合广告sdk缓存广告的策略分为三种：WaterFall，Fan Out，Hybrid。

WaterFall就是首先去访问SDK1,如果SDK1返回了广告，就Serve给Publisher；如果SDK1没有广告返回，就访问SDK2. 依次访问，直到有广告Serve给Publisher就完毕。

Fan Out既是一次请求所有的SDK，谁家SDK最短时间返回广告就Serve这家的广告到Publisher。

Hybrid就是一种混合模式了，一次全部SDK请求，返回的各家SDK广告对比最好的eCPM, 谁家eCPM高就Serve谁家的广告。

目前我们的sdk支持两个模式，分别就是 Fan out和 Hybrid这两种，具体使用哪种，由后台配置决定

欢迎大家探讨学习