iOS Peacock广告、统计系统简介及重构
简介
名称来历
Peacock最早为中华万年历提供广告开屏使用,联想到孔雀开屏,所以命名Peacock。后来随着业务逻辑的扩展,加入了其他广告、统计、追踪等逻辑。
支撑APP
Peacock目前支撑的APP包括中华万年历、快马小报、万年历、哔哔的对话、微鲤头条等APP。
项目目录
项目目录.png新版运行时间
iOS端从17.3月重构到如今已经安全无事故运行了一年的时间。
重构前后对比
老版本的Peacock由于存在偶现的广告存取问题、自定义网络库bug、集成成本高等问题,17年3月进行了代码重构。
重构后优化了如下:
- 集成方式由静态库修改为Pod引入
- 网络库有前一版本的自定义改为因为依赖AFNetworking
- 添加了trace追踪系统
- 修改掉之前广告数据库存储bug、网络库偶现闪退bug的问题
- 接入成本降低
- 组件体积大幅度减少
- 支撑多个APP
接入方式
Podfile.png 设置key值.png接入方式采用Pod引入库,通过plist文件设置相关APP参数值。
广告系统
ETPeacockDownloader主要负责广告系统缓存、读取、更新、开屏广告的预下载以及一些广告小红点的逻辑等。
对外暴露的方法提供所有广告位的请求、单一广告位的请求,设计基于是否基于网络、对应广告两个维度。
/**
上传一条UGC统计
@param adId 事件id
@param targetType 事件target类型
@param ugcType UGC类型
@param contentMode contentMode
@param position 位置
@param args args参数
@param isAnchor 是否是锚点 判断是否需要立即上传
*/
- (void)uploadUgcStatisticsWithAdId:(long long)adId
targetType:(NSInteger)targetType
ugcType:(NSString *)ugcType
contentMode:(NSString *)contentMode
position:(NSString *)position
args:(NSString *)args
isAnchor:(NSInteger)isAnchor;
/**
上传APP启动事件
@param startType 事件string
*/
- (void)uploadAppStartEventStatisticsWithType:(NSString *)startType;
/**
上传一条自定义事件统计
@param event 事件
@param params 其他参数
*/
- (void)uploadCustomEventStatisticsWithEvent:(NSString *)event
params:(NSDictionary *)params;
广告存取数据库成功之后会通知外部APP刷新对应展示的广告位。
统计系统
ETPeacockUploader主要负责用户UGC统计、自定义事件统计等统计事件,是整个APP统计的根本。
/**
上传一条UGC统计
@param adId 事件id
@param targetType 事件target类型
@param ugcType UGC类型
@param contentMode contentMode
@param position 位置
@param args args参数
@param isAnchor 是否是锚点 判断是否需要立即上传
*/
- (void)uploadUgcStatisticsWithAdId:(long long)adId
targetType:(NSInteger)targetType
ugcType:(NSString *)ugcType
contentMode:(NSString *)contentMode
position:(NSString *)position
args:(NSString *)args
isAnchor:(NSInteger)isAnchor;
/**
上传APP启动事件
@param startType 事件string
*/
- (void)uploadAppStartEventStatisticsWithType:(NSString *)startType;
/**
上传一条自定义事件统计
@param event 事件
@param params 其他参数
*/
- (void)uploadCustomEventStatisticsWithEvent:(NSString *)event
params:(NSDictionary *)params;
难点
因为UGC事件包括view、click、page_view、exit等多种统计事件,所以需要设计实时统计和非实时统计的决定条件,避免服务器负载过高。
而客户端需要考虑用户进入后台或者统计失败的处理方式来避免统计数据的遗漏等。
目前系统以统计的锚点、统计条数是否满足某个阈值以及定时自动上传来决定是否上传,客户端UGC统计由于升级则沿用了最初两个数据库表(临时表、内存表)+ 内存的形式来避免统计数据的遗漏问题,自定义事件统计由于为重构新加入了是否为即时上传的逻辑,使用了单表 + 内存的形式解决上述问题。
UGC上传流程
- 客户端调用孔雀系统UGC上传方法
- 根据参数(uuid, ugcType, time, md ...)组装bean
- 加载bean到内存数组中
- 是否满足触发上传请求
- 满足请求同步内存数据至发送表(同时转移收集表数据至发送表, 转移成功清空收集表)
- 上传成功清空发送表
自定义事件上传流程
- 客户端调用孔雀系统自定义事件上传方法
- 根据参数(event, params)组装bean
- 根据是否为定时上传/非定时上传 强制事件/非强制事件 处理
- 上传事件
- 上传成功/失败处理本地数据
Trace追踪系统
Trace追踪系统主要是用来追踪某些指定url的成功、失败率,方便服务器对接口的维护。
总结
通过重构Peacock并不断的修补,对于重构也有了一定的理解。
- 重构一定要基于对原项目的深入理解,对于任何一个不懂的字段、变量、变量类型都要追溯到原作者,确保万无一失再进行修改。
- 对于一些小的方法,尽量去进行整合封装,保证代码的可读性和稳定性。
- 将相关的方法尽量进行移动到同一类中去,取到其合适的位置。
- 优化、重命名变量,将名称修改得更具描述性、更容易传达其含义。
- 分解方法,对于功能过于集中的方法,进行提取
- 提取子类,例如数据库的分类
- 提取工厂类,ETPeacockAnalysisTool即用于组装参数的工厂类
重构还有很多需要注意的地方,需要对原代码有较深入的理解,并且在重构完成之后需要进行大量的测试。