想必各位APP开发者们对SDK都有一定了解，并且抱有爱恨交杂的情绪。

SDK，确实该爱。

SDK可以提升开发和集成效率，降低开发成本，市面上现有的SDK覆盖支付、客服、后台、广告、测试分析报告、推送、追踪、云存储等多个领域，APP对SDK有较强的依赖性。根据观研天下发布的《2019年中国移动APP行业分析报告》，截至2018年12月，全球APP平均安装SDK数量达到18.2个，拥有100-500万下载量的APP的SDK平均安装数量最多，达27.7个。

▲图片来自观研天下

SDK，真的该恨？

对于APP开发者来说，嵌入第三方SDK可能会引发安全问题，需要承担连带风险，比如SDK开发者的安全能力水平参差不齐，可能会导致SDK的安全漏洞；还有SDK开发者会在代码中故意预留“后门”，以便收集用户信息或执行越权操作。这些安全问题轻则让APP正常使用受到影响（卡顿），重则被应用商店下架，甚至需要承担法律责任。

▲某个SDK相关的问题在知乎上浏览量超8k

广告SDK是SDK中的“重灾区”，相关的安全事件频发，也让很多APP开发者在选择上更为慎重，并且进行严格的审查。

本文AdBright将简要介绍广告SDK的类型和原理，并且提供相应的审查指引。

广告SDK的分类

广义上，广告SDK代指为开发者提供广告相关功能（接入广告、广告监测等）的软件开发工具包。狭义上，广告SDK仅指帮助APP开发者接入广告，实现广告变现的软件开发工具包。广告SDK的类型较多，可以按下面的方式分类：

根据变现需求方的类型可以分为H5 SDK和APP SDK，按编程语言分又可以分为Java SDK、Objective-C SDK等。h5 SDK主要满足网页（包括各平台小程序）的变现需求，APP SDK则主要满足APP开发者的变现需求，其中Java SDK适用于Android应用，Objective-C SDK适用于iOS应用。

根据SDK开发者专注的垂直广告领域，可以分为激励广告SDK、互动广告SDK等。广告特性不同，适用的变现需求方也不同，激励广告SDK满足以休闲类游戏为主的游戏媒体的变现需求，互动广告SDK则适用类型更广，以工具类媒体为主。

根据SDK开发者的性质及商业目的，可以分为单一（single）广告SDK和聚合（mediation）广告SDK；SDK的开发者一般为广告联盟和广告技术公司。广告联盟开发自有的广告SDK，接入多个变现需求方，打造SSP平台，利用集群效应售卖流量并从中抽成；广告技术公司则开发聚合了多个广告联盟的SDK，帮助变现需求方一次接入多个广告联盟，收取服务费。

广告SDK如何在APP广告变现中发挥作用？

1.广告交易生态中的广告SDK

▲广告交易生态中的广告SDK

广告供给方：一般可称为媒体，分为网页和APP，从已嵌入的广告SDK中获取广告内容并展示。

广告SDK：广告供给方通过广告SDK的接口发起广告请求，请求内容包括广告位、广告素材尺寸、用户设备码等信息，并依靠流量分配控制器向广告交易平台分发广告请求。

广告交易平台：为ADX/SSP，接收广告请求和竞价信息，处理广告交易。

广告需求方：为DSP，在广告交易平台参与竞价，并向广告SDK回传广告内容。

*目前SSP与ADX功能模块趋同，故统称为广告交易平台

在广告交易生态中，广告SDK可以视为广告供给方参与广告交易的“门票”，串联起广告请求发起——广告创意展示——广告数据上报这一完整的广告交易链路，执行包括数据采集、数据检索、数据储存、数据上报、广告请求、广告下载、广告渲染、广告监测等在内的工作。

2.广告SDK的接入

在广告SDK真正发挥作用前，需要先完成接入。SDK开发者会为APP开发者分别提供iOS/Android SDK 接入文档，目前流程已经标准化，一般可以分为以下五步：

第一步：加入文件

把广告SDK文件嵌入指定的项目目录中。

第二步：构建关联

向广告SDK添加引用，建立关系，包括添加配置、权限等。

第三步：编写代码

应用初始化及广告位开发，调用广告SDK提供的广告位模板。

第四步：联调测试

即测试广告交易流程，测试点包括流程是否顺畅（请求正常触发等），广告展示是否正常（无变形加载等适配问题）、广告数据是否正常（无数据错漏等情况）等。

第五步：软件发布

将嵌入广告SDK的应用上架&更新，完成后即可开始发起广告请求，开始广告变现。

对于APP开发者来说，只接入单一广告SDK意义并不大，一方面高度依赖某个联盟，导致风险过于集中，另一方面如果联盟无广告返回会造成流量浪费，收益减少。

虽然SDK的接入流程已经标准化，但如果同时接入多个联盟的广告SDK，APP开发者仍需要付出大量的学习和开发成本，管理上也更为复杂，因此接入聚合广告SDK成为更高效的选择。

3.广告SDK的请求机制

APP开发者接入聚合广告SDK后能有了更多调整和选择，一次性对接多个广告联盟，可设置更灵活的请求机制和流量分配机制，目前市面上主流的聚合广告SDK的请求机制有下列三类：

▲聚合广告SDK请求机制

①WaterFall

即串行请求。聚合广告SDK按设定的顺序，依次向各个广告联盟发起广告请求，如果返回广告内容则进行展示广告。

优点：得到广告内容即可展示广告内容，能够提升广告展示率；

缺点：增加广告内容返回超时的几率，导致无法顺利进行广告展示，损失潜在的广告收益并且影响用户体验。

②Fan Out

即并行请求。聚合广告SDK一次请求所有的广告联盟，选择时间最短返回的广告内容并进行展示。

优点：几乎可以保证每次流量都被填充，顺利完成广告展示；

缺点：一次访问多个广告联盟的话，会造成部分广告联盟成功返回广告内容但总是无法曝光的情况，从而导致其降低引流权重，影响后续收益。

③Hybrid

即混合请求。聚合广告SDK一次请求所有的广告联盟，选择eCPM最高的广告联盟返回的广告内容（在广告联盟支持返回eCPM的前提下），并进行展示。

优点：几乎可以保证每次流量都被填充，并且每次填充的都是ecpm最高的广告；

缺点：除了Fan Out模式的缺点，此请求方式让聚合广告SDK需要进行较为复杂的逻辑判断，对其数据的处理速度和处理能力都要求较高，可能会导致广告展示率低。

三种方式各有利弊，在不考虑计算和数据处理能力的情况下，混合请求是最优请求方式。提升广告收益也是聚合广告SDK的价值所在，使用混合请求能够提升广告展示率、广告填充率、eCPM。

APP开发者如何审查广告SDK？

广告SDK的安全风险主要是SDK开发者瞒着APP设置“后门”获取用户信息，并且利用数据获利。

用户信息收集的风险也分等级，友盟+的高级产品研发专家马巍源曾整理风险级别，低风险为用户移动设备传感器的信息，包括光、声音、环境，极高风险则涉及用户已安装应用信息和账户信息这类最为私密的信息。

▲内容：马巍源 ，由AdBright整理制图

因此，审查是接入广告SDK的必要环节。对于APP开发者来说，既是对广告SDK的深入了解，能够提升后续的接入效率，也能理清风险点。审查方式可以分为三类，包括文档审查、工具审查和第三方审查：

1.文档审查

在SDK接入前进行审查，但SDK开发者一般不会直接在接入文档暴露“不当目的”。即APP开发者对SDK开发者提供的接入文档进行审查，查看是否有要求APP回传敏感信息，是否有涉及到双方未达成一致或有争议的内容。

2.工具审查

在联调测试环节使用抓包工具审查，常用的工具有Charles（青花瓷），能够支持Mac OS\Windows\Linux系统。即APP开发者使用抓包工具抓取接入SDK开发者的网络请求，并且分析是否有不在协议内的数据。

▲Charles官网

3.第三方审查

一般也是在联调测试环节进行审查，由第三方公司出面审查SDK，比如网易易盾、腾讯安全等。第三方公司有着更完整和全面的审查机制，能够出具权威客观的报告，但APP开发者需要付出更多成本。

技术不是原罪，使用技术的人才是。

广告SDK通过不断的技术创新，提升了广告交易的效率和效益，推进了广告市场的繁荣发展，让百万开发者受益，价值不容置疑。

广告SDK的潜在安全风险也不可小视，但令人欣喜的是，SDK相关的监管和法律法规在不断完善中。从2019年发布的《软件开发包（SDK）安全与合规白皮书》，再到近期国内首个SDK安全国家标准宣布正式立项。在可预见的将来，SDK行业的生态将会更为纯净、有序。

本文仅供参考，若您有疑问和其他见解，欢迎随时联系AdBright，共同探讨、合作共赢。

作者：AdBright

本文经授权发布，不代表APP干货铺子立场。如若转载请联系原作者。