不知不觉从事广告SDK工作也有快4年了，对相关业务已经比较熟悉，趁现在有时间，总结一下业务、SDK等相关的东西，分成业务和技术两块
广告业务
个人感受
- 必不可少。当一个公司产品发展成熟之后或者用户量达到一定级别，比如百万级以上，就开始考虑商业化或者叫流量变现，随之广告业务就要开展了，据统计互联网行业中一半以上的收入来自于广告，想想也确实如此，像BAT都有自己的广告平台，百度凤巢、腾讯广点通等等，其中百度广告业务占总收入的90%以上(2015年)，可见一斑。
- 价值巨大。最开始是误打误撞进入广告行业，第一家公司主要是学习技术、积累经验，后来看到广告对于公司的巨大价值，才想继续在这个业务深耕，希望在这个方向有深远的发展，同时路也能越走越宽。
- 大平台更挣钱，小公司基本就是在夹缝中生存，但如果傍上大公司的大腿，也可以活得很滋润，目前服务过三家公司，都有移动广告平台业务，各自的侧重点不同
| 公司 | 业务 | 描述 |
|---|---|---|
| 第一家 | 主要做积分墙、开屏、插屏、banner、视频等 | 非原生广告，相对小众，但是当时应该很挣钱，在13/14年有大批的创业公司做这类，据说单国内当时有上百家广告平台 |
| 第二家 | 原生、场景广告 | 服务一些知名媒体 |
| 第三家 | 以原生、开屏为主，针对内部特有的App，研发新的广告形式，视频贴片、直播贴片等 | 主要对内，由于是自家App，流量相对较大，利润应该可观 |
- SDK工程师应该是技术和售后的混合体，既能写得好代码，又能跟开发者、运营妹子、市场大哥等第三方群体良好的沟通，有时候这比写好代码更重要
- 需要有快速学习的能力，能够对产品的需求快速验证，这点儿也很有必要
广告类型
目前大致做过十来种广告形式，可分为数据类和UI展示类
| 类型 | 广告 | 描述 |
|---|---|---|
| 数据类 | 原生广告 | 主要提供数据，并支持上报 |
| UI展示类 | 开屏/插屏、banner、视频贴片、直播贴片、角标广告、场景广告等 | 提供UI展示图给媒体，或者由媒体提供渲染父视图，SDK端添加，有UI有交互 |
广告SDK业务
- 对于移动端或者整个大前端来说，广告业务主要展现形式就是SDK。
- SDK主要是做数据处理，包括但不限于数据请求、数据处理(格式化检验、异常处理）、数据上报等
- 具体广告形式逻辑介绍：
| 广告 | 描述 | 广告逻辑 |
|---|---|---|
| 原生广告 | 最常见的广告形式，主要提供广告素材给媒体端，素材包括：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涉及技术并不复杂，从之前的经验来看，更应该关注设计，应该说设计是第一位的。
大的原则
- 稳定性第一
- 不能崩溃。由于SDK需要寄生在宿主App中才能运行，SDK若崩溃，会导致App不能运行，所以最重要的一点是不能崩溃，应该采取各种办法防止崩溃；经历过线上大面积崩溃的血的教训，这一点儿印象深刻。
- 应对各种奇葩调用。由于开发者无暇看文档，并且认为SDK是完美无暇的，所以可能会出现各种奇葩的调用，比如参数类型错误，在新开的子线程调用等问题，若考虑不周，遇到问题会很棘手
- 应对各种系统、各种手机。手机种类越来越多，iOS系统版本越来越新，特别是做UI渲染时要考虑好版本、机型适配
- 接口稳定。稳定回调、数据格式不发生变化等
- 内部应对服务器端各种变化。由于要从服务器端获取数据以及上报等，比如会出现服务器端数据类型变化，为null等情况，SDK要能稳定应对
- 可扩展性
- 考虑变化。由于SDK更新迭代较慢，所以稳定版本要能良好运行，充分考虑到接口可能发生的变化，内部功能的变化等，做到改动小、效果好；比如原生广告配置参数可能会增加、素材数据也可能会增加等问题
- 无侵入
- 不能影响宿主App功能。SDK对于宿主App的依赖应该足够小，如不能跟宿主App起相同的类名、使用相同的扩展、依赖相同的第三方库等
- 不会导致宿主App卡顿。内部所有操作应该尽可能放在自定义子线程中
- 不能使用第三方库。尽可能情况下一个第三方库也不能使用，若使用（如Webp.framework、微信分享）由开发者添加
核心问题
- 如何防崩溃？
- 严格做好传递参数校验，若校验失败，则直接回调error；包括请求参数、服务端响应参数等
- 内部用好try{}catch{}
- 注册unCaughtExceptionHandler()，发现崩溃及时上报
- 及时上报异常、error等信息，尽早发现问题
- 不使用高版本API
- 避免在子线程处理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来说，重点关注几项
- 设备标识符变化：iOS 6之前使用UDID - > iOS6 时IDFA发布，依然可以使用UDID -> 后来在iOS 7发布之前禁止UDID，可以使用 和Mac -> iOS 7禁止 OpenUDID和Mac，只能使用IDFA -> iOS 10+ IDFA可以手动禁止获取 (此时一般返回默认0000，也可以使用IDFA模拟值)
- iOS 7+ 使用NSUrlSession网络库，及后台下载功能
- iOS 8+ 使用WKWebView
- IOS 9+ HTTP处理，支持BitCode
- iOS 10 openUrl方法
- 稳定回调？
- 所有的回调都在主线程
- 设置好超时周期，在请求超时或者API指定的时间内超时，都及时回调
广告SDK代码设计
目标是接口规范、注释清楚、使用简单无异议。大致可分为接口设计和架构设计两块儿：
- 接口主要包含API及注释、文档、demo
- 架构包含设备信息、网络、缓存、线程通信等核心模块。
见下篇，iOS 广告SDK总结（二）
