得到团队无埋点方案

移动开发 简书

无埋点SDK开发的初衷是这样的,由于业务迭代速度很快,手动埋点方案虽然灵活多变,但是极大的增加了客户端开发人员的工作量。开发完成业务功能需要花费很大的精力处理埋点事宜,而且随着迭代版本,埋点的数量会越来越多,这些老旧埋点的维护工作也是不小的工作量。而且,手动埋点的正确性同样是个极度考验开发人员的耐心。综上,如果能够研发出一款不需要或者很少需要开发人员介入就能实现根据不同业务场景埋点的功能sdk那对于提高版本迭代速度和开发人员的幸福感绝对是一件非常有价值的事情。

纵观目前比较成熟的无埋点方案,存在着如下问题:

问题1:通过XPath定位控件,理论上可行,但实践表明这个方案的复杂度非常高,尤其对于处理像GridView,ListView,RecyclerView的控件更是捉襟见肘,极端不可理解。不仅如此,生成xpath的过程本身就是一个及其耗费性能的行为,它需要遍历view tree。

问题2:获取控件对应的数据同样是通过 path的方式解决,每次添加新埋点时,如果需要上报数据,那用研人员需要和开发人员逐一确认控件数据的path,这极大的限制了客户端开发的自由度,即使简单的重构也会使得之前配置的埋点信息失效。

针对如上问题,我们经过深挖内在本质及对比优劣,总结出了一套更灵活,更合理的无埋点方案,下面分三个部分逐一介绍实现考量及内部机制。

一、定位与用户产生交互行为的目标控件

关于定位交互控件,我们也考虑过xpath的方案,但是考虑到其实现的复杂度,不灵活和各种潜在的问题,我们抛弃了这种方案。通过反复的阅读View的touch事件处理相关的源码,我们终于发现了解决问题的本质。

ViewGroup中有一个TouchTarget 类型的变量 mFirstTouchTarget。顾名思义,表示用户触摸事件的目标消费者。当ViewGroup接收到MotionEvent 并派发事件时,他会首先判断变量mFirstTouchTarget是否为空,如果变量存在,会循环遍历TouchTarget链表,找到能处理该事件的View并将MotionEvent 派发给该控件。如果不存在TouchTarget,ViewGroup 会循环遍历所有child view,直到找到一个能处理该事件的View,并将该View作为first touch target 赋值给mFirstTouchTarget。

利用ViewGroup的这种处理机制,我们在Activity的dispatchTouchEvent中添加处理函数analyzeMotionEvent()。如果接收到up事件,执行处理逻辑,通过ViewGroup TouchTarget链表,找到本次交互行为的目标控件。拿到控件后,通过拼接控件所在Activity的名字,控件所在layout文件的名字,控件id对应的资源名,我们能够得到一个全局唯一id,作为目标控件的唯一标识。

二、获取与目标控件对应的业务数据

对于获取控件数据,为了最大化获取速度,我们在系统中配置了多个数据获取策略。如果目标控件是AbsListView或者RecyclerView 的child view及child view 的chid,那我们可以通过child view在adapter中的位置获取到我们想要的数据。这种方式能够处理大多数页面控件数据的获取问题。对于完全自定义布局绘制的页面,例如个人中心等页面,业务开发人员需要通过框架api建立一个控件树到数据的映射关系,这样框架在需要获取数据时,通过这个关系就可以非常容易的获取到想要的数据。

三、实现埋点的动态可配置

在测试环境下,用研人员会通过手动模拟点击的方式获取sdk上报的控件唯一id和数据信息,在确认id,和数据的正确性之后,需要手动配置id和埋点事件的对应关系,及上报的数据字段,并存储到配置仓库。在线上环境,当用户启动app会拉取配置信息并加载到内存。这样,当用户触发点击行为时,会根据第一步获取的id信息查询配置,如果在配置中查到对应的条目,会将对应的事件及数据上报到服务器。

至此,无埋点sdk的核心运作机制已经全部梳理清楚,如果想更深入的了解无埋点sdk具体实现细节,我的git地址:

https://github.com/jessie345/DDAutoPointer.git
,欢迎fork

简书稿源:简书 (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 移动开发 » 得到团队无埋点方案

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录