iOS 广告SDK总结（一）

不知不觉从事广告SDK工作也有快4年了，对相关业务已经比较熟悉，趁现在有时间，总结一下业务、SDK等相关的东西，分成业务和技术两块

广告业务

个人感受

1. 必不可少。当一个公司产品发展成熟之后或者用户量达到一定级别，比如百万级以上，就开始考虑商业化或者叫流量变现，随之广告业务就要开展了，据统计互联网行业中一半以上的收入来自于广告，想想也确实如此，像BAT都有自己的广告平台，百度凤巢、腾讯广点通等等，其中百度广告业务占总收入的90%以上(2015年)，可见一斑。
2. 价值巨大。最开始是误打误撞进入广告行业，第一家公司主要是学习技术、积累经验，后来看到广告对于公司的巨大价值，才想继续在这个业务深耕，希望在这个方向有深远的发展，同时路也能越走越宽。
3. 大平台更挣钱，小公司基本就是在夹缝中生存，但如果傍上大公司的大腿，也可以活得很滋润，目前服务过三家公司，都有移动广告平台业务，各自的侧重点不同

公司	业务	描述
第一家	主要做积分墙、开屏、插屏、banner、视频等	非原生广告，相对小众，但是当时应该很挣钱，在13/14年有大批的创业公司做这类，据说单国内当时有上百家广告平台
第二家	原生、场景广告	服务一些知名媒体
第三家	以原生、开屏为主，针对内部特有的App，研发新的广告形式，视频贴片、直播贴片等	主要对内，由于是自家App，流量相对较大，利润应该可观

4. SDK工程师应该是技术和售后的混合体，既能写得好代码，又能跟开发者、运营妹子、市场大哥等第三方群体良好的沟通，有时候这比写好代码更重要
5. 需要有快速学习的能力，能够对产品的需求快速验证，这点儿也很有必要

广告类型

目前大致做过十来种广告形式，可分为数据类和UI展示类

类型	广告	描述
数据类	原生广告	主要提供数据，并支持上报
UI展示类	开屏/插屏、banner、视频贴片、直播贴片、角标广告、场景广告等	提供UI展示图给媒体，或者由媒体提供渲染父视图，SDK端添加，有UI有交互

广告SDK业务

1. 对于移动端或者整个大前端来说，广告业务主要展现形式就是SDK。
2. SDK主要是做数据处理，包括但不限于数据请求、数据处理(格式化检验、异常处理）、数据上报等
3. 具体广告形式逻辑介绍：

广告	描述	广告逻辑
原生广告	最常见的广告形式，主要提供广告素材给媒体端，素材包括：icon、title、imageUrl/videoUrl、targeUrl（跳转链接），一般用于展示信息流，以及曝光、点击上报方法	媒体端调用SDK指定接口，传入appid、placementid、count等参数，SDK根据指定参数请求服务端，服务端从广告池中拿到指定素材，返回给SDK，SDK通过delegate或者block等形式回调给媒体，媒体在拿到素材后，在信息流、banner等广告位展示，有曝光及点击时调用对应上报方法上报，完成闭环
开屏广告	UI展示类最常见的广告形式	请求过程与原生广告类似，不同的是请求完数据之后，需要先做好素材缓存，同时SDK负责渲染素材，并处理曝光和点击事件，点击跳转一般由媒体处理，如果有做得更好，还要做好超时处理，保证2s内回调
banner广告	一般用于App页面顶部推荐栏，宽度为屏幕宽度、宽高比375:150左右	请求过程类似，主要是视图展示的区别
视频贴片	有三种，前贴、中贴、后贴，分别在视频的开始、中间、播放结束状态，插入一段广告视频	请求逻辑类似，重点需要处理播放器逻辑(播放失败、前后台切换、播放结束、播放器页面(特别横竖屏适配)、播放器手动关闭)，上报处理也要增加关于视频播放逻辑的上报（如开始、播放时长、结束等）
直播贴片	与视频贴片类似	与视频贴片类似，UI展示更加复杂
角标广告	视频播放到指定位置时展示对应的广告，可点击广告查看详情	请求逻辑类似，后台会返回一组素材，分别对应视频播放的指定位置，重点要做好时效处理（当前广告前后1s之内都可展示、已经在展示后，滑动到指定时长，展示新广告）
场景广告	在页面指定位置展示播放动画（原生动画），可点击广告跳转到详情页	请求逻辑类似，SDK拿到指定的动画素材及对应模板，在视图的指定位置上播放动画

//TODO: 后续将各种广告效果，截图或者录屏上来

---

广告SDK设计

广告SDK设计原则

广告SDK涉及技术并不复杂，从之前的经验来看，更应该关注设计，应该说设计是第一位的。

大的原则

• 稳定性第一

1. 不能崩溃。由于SDK需要寄生在宿主App中才能运行，SDK若崩溃，会导致App不能运行，所以最重要的一点是不能崩溃，应该采取各种办法防止崩溃；经历过线上大面积崩溃的血的教训，这一点儿印象深刻。
2. 应对各种奇葩调用。由于开发者无暇看文档，并且认为SDK是完美无暇的，所以可能会出现各种奇葩的调用，比如参数类型错误，在新开的子线程调用等问题，若考虑不周，遇到问题会很棘手
3. 应对各种系统、各种手机。手机种类越来越多，iOS系统版本越来越新，特别是做UI渲染时要考虑好版本、机型适配
4. 接口稳定。稳定回调、数据格式不发生变化等
5. 内部应对服务器端各种变化。由于要从服务器端获取数据以及上报等，比如会出现服务器端数据类型变化，为null等情况，SDK要能稳定应对

• 可扩展性

1. 考虑变化。由于SDK更新迭代较慢，所以稳定版本要能良好运行，充分考虑到接口可能发生的变化，内部功能的变化等，做到改动小、效果好；比如原生广告配置参数可能会增加、素材数据也可能会增加等问题

• 无侵入

1. 不能影响宿主App功能。SDK对于宿主App的依赖应该足够小，如不能跟宿主App起相同的类名、使用相同的扩展、依赖相同的第三方库等
2. 不会导致宿主App卡顿。内部所有操作应该尽可能放在自定义子线程中
3. 不能使用第三方库。尽可能情况下一个第三方库也不能使用，若使用（如Webp.framework、微信分享）由开发者添加

核心问题

• 如何防崩溃？

1. 严格做好传递参数校验，若校验失败，则直接回调error；包括请求参数、服务端响应参数等
2. 内部用好try{}catch{}
3. 注册unCaughtExceptionHandler()，发现崩溃及时上报
4. 及时上报异常、error等信息，尽早发现问题
5. 不使用高版本API
6. 避免在子线程处理UI

• 版本适配？
  重点关注iOS8之后每个版本新框架以及API更新，就可以较好避免此问题
  (此处以后单开一篇文章总结)
  各版本新功能

版本	功能
iOS4	block、GCD、backgroundMode
iOS5	ARC、storyboard
iOS6	iDFV（应用标识符）、IDFA（广告标识符）
iOS7	NSUrlSession、UIKit Dynamics、扁平化设计
iOS8	WKWebView、sizeClass、UIAlertController
iOS9	App thining、UITest、TouchID、HTTPS(http默认禁止)、Bitcode
iOS10	UserNotification、openUrl方法、IDFA开关
iOS11	ARKit、CoreNFC

对SDK来说，重点关注几项

1. 设备标识符变化：iOS 6之前使用UDID - > iOS6 时IDFA发布，依然可以使用UDID -> 后来在iOS 7发布之前禁止UDID，可以使用 和Mac -> iOS 7禁止 OpenUDID和Mac，只能使用IDFA -> iOS 10+ IDFA可以手动禁止获取 (此时一般返回默认0000，也可以使用IDFA模拟值)
2. iOS 7+ 使用NSUrlSession网络库，及后台下载功能
3. iOS 8+ 使用WKWebView
4. IOS 9+ HTTP处理，支持BitCode
5. iOS 10 openUrl方法

• 稳定回调？

1. 所有的回调都在主线程
2. 设置好超时周期，在请求超时或者API指定的时间内超时，都及时回调

广告SDK代码设计

目标是接口规范、注释清楚、使用简单无异议。大致可分为接口设计和架构设计两块儿：

1. 接口主要包含API及注释、文档、demo
2. 架构包含设备信息、网络、缓存、线程通信等核心模块。
   见下篇，iOS 广告SDK总结（二）