iOS 广告SDK总结(一)

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

广告业务

个人感受
  1. 必不可少。当一个公司产品发展成熟之后或者用户量达到一定级别,比如百万级以上,就开始考虑商业化或者叫流量变现,随之广告业务就要开展了,据统计互联网行业中一半以上的收入来自于广告,想想也确实如此,像BAT都有自己的广告平台,百度凤巢、腾讯广点通等等,其中百度广告业务占总收入的90%以上(2015年),可见一斑。
  2. 价值巨大。最开始是误打误撞进入广告行业,第一家公司主要是学习技术、积累经验,后来看到广告对于公司的巨大价值,才想继续在这个业务深耕,希望在这个方向有深远的发展,同时路也能越走越宽。
  3. 大平台更挣钱,小公司基本就是在夹缝中生存,但如果傍上大公司的大腿,也可以活得很滋润,目前服务过三家公司,都有移动广告平台业务,各自的侧重点不同
公司 业务 描述
第一家 主要做积分墙、开屏、插屏、banner、视频等 非原生广告,相对小众,但是当时应该很挣钱,在13/14年有大批的创业公司做这类,据说单国内当时有上百家广告平台
第二家 原生、场景广告 服务一些知名媒体
第三家 以原生、开屏为主,针对内部特有的App,研发新的广告形式,视频贴片、直播贴片等 主要对内,由于是自家App,流量相对较大,利润应该可观
  1. SDK工程师应该是技术和售后的混合体,既能写得好代码,又能跟开发者、运营妹子、市场大哥等第三方群体良好的沟通,有时候这比写好代码更重要
  2. 需要有快速学习的能力,能够对产品的需求快速验证,这点儿也很有必要

广告类型

目前大致做过十来种广告形式,可分为数据类和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总结(二)

你可能感兴趣的:(iOS 广告SDK总结(一))