iOS 广告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更新,就可以较好避免此问题
    (此处以后单开一篇文章总结)
    各版本新功能
版本功能
iOS4block、GCD、backgroundMode
iOS5ARC、storyboard
iOS6iDFV(应用标识符)、IDFA(广告标识符)
iOS7NSUrlSession、UIKit Dynamics、扁平化设计
iOS8WKWebView、sizeClass、UIAlertController
iOS9App thining、UITest、TouchID、HTTPS(http默认禁止)、Bitcode
iOS10UserNotification、openUrl方法、IDFA开关
iOS11ARKit、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总结(二)


 

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值