埋点治理:如何把App埋点做到极致?
导语
本文基于实际场景业务需求,通过切面化、平台化、动态化探讨埋点治理方案,把App埋点做到极致,具有一定的实践意义,希望对大家有所帮助和启发。
背景
需求问题,解决方案,埋点系统
现有埋点方案比较
1. 传统代码埋点
实现方案:Coding阶段手动埋点。
代表解决方案:友盟、百度统计。
优点:灵活、准确,可以定制化。
缺点:业务埋点量非常大,开发成本高,不易维护,如果要修改、新增埋点,需要重新发版。
2. 动态埋点
实现方案:利用AccessibilityDelegate对每个view实例设置代理,监听控件点击事件。
代表方案:Github上开源的Mixpanel
优点:无需手动埋点,通过可视化圈选,动态下发配置监听指定控件。
缺点:不支持数据可回溯,采集不到Fragment页面数据,只支持API 14及以上,同时该监听方式对app性能影响严重,每个控件都需要动态绑定,在界面变更时,需要重新刷新ViewTree,效率低下。
3. 全埋点方案
实现方案:利用Gradle插件,在编译阶段在代码中插入埋点代码,进行数据采集。
代表方案:GrowingIO、美团的替换UI控件方案,WMDA
优点:开发效率高,无需手动埋点,编译时插入代码,性能高,支持数据可回溯。
缺点:埋点灵活性低。
现有的埋点方案各有利弊,没有一种方案可以完美的解决所有埋点问题,本方案中采用了手动埋点,WMDA全埋点方案,切面化动态埋点相结合的埋点方案,针对不同场景和埋点需求使用不同的埋点策略,尽可能的把埋点问题做到极致。
系统建立
1. 整体架构
埋点系统整体架构图
埋点系统主要做了三个事情
接下来将会详细说明。
2. 切面化 降低耦合 提高效率
切面化部分
主要指App内部的针对埋点Aop和拦截器方案:
拦截器,Aop
3、动态化 避免发版
具体内容:
LogParam,PassValue
b)WMDA
动态埋点框架
整体说整套动态埋点方案是基于切面插桩和反射机制的。以Android为例,
开发时在对应需要埋点或可能需要统计的地方添加注解,编译期通AspectJ插入埋点代码,并通过上传插件上传可埋点方法文件,何Mapping文件,可埋点方法文件如下图所示是由一个个Apath组成。
Apath
每个Apath由注释,类名,方法名,参数名组成,被上传到服务端,在通过配置需要的埋点以及参数,已如图所示的协议在下发到客户端map存储。Key就是方法名,值就是整个协议体。
配置上传下发示意图
运行时,当方法被调用时,检测内存中Key有没有该方法如果有则通过反射获取对应参数合并服务端参数生成日志上传。
运行时逻辑
动态埋点sdk 接入和使用都已经同步git 可以方便接入和使用。
4. 平台化
平台化部分
主要内容:
效果图如下:
埋点管理模块
埋点验证模块
总结
1. 切面化
通过拦截器,Aop等设计思想使手动埋点代码简单,兼容 ,埋点业务解耦
2. 动态化
通过LogParams,WMDA,动态埋点尽可能的使埋点动态化,避免发版,减少错误修复时间。
3. 平台化
通过埋点平台使数据,测试同学方便的管理,验证埋点,确保准确性。
展望与规划
1. 动态埋点覆盖性问题
因为是基于反射,只能保证调用方法的入参以及调用类的属性参数被获取,会存在一些参数没办法后获取到的问题,但是大部分情况没有问题
2. 动态埋点android混淆方案
Mapping文件的维护,版本控制等等体系还不健全,需要进一步完善和优化。
3. 验证的自动化部分
验证需要优化,自动化判空,自动化正则判断进一步提效
现阶段埋点占比:手动埋点60%,WMDA20%,动态埋点20%
优化期望:手动埋点20%,WMDA40%,动态埋点40%
参考文献
END
阅读推荐