移动端埋点方式探讨 – iOS端

目标:灵活的埋点方式,移动端不需要大量修改代码,甚至不用重新发包即可按照PM要求发送需要的统计数据。

要求:高度解耦,复用性强,动态配置,易于维护。

知道了要努力的目标和要求,我们先来看一下现在老版教师端和重构版教师端的优缺点。

一.老版教师端采用的是一个工具类发送数据,需要的个性化数据由每个界面自行传值进入。

优点:

1.灵活性较高,能满足个性需求:按照现在的发送的数据映射表,个别界面需要发送一些特殊信息,此种实现方式可以较好的满足这种情况的出现。

举个栗子:播放教案时,需要发送教案本身的id以及教案所在讲次的id,这两个数据其余界面并不需要发送。

2.有一定的解耦:这里解耦的就是发送数据这块,做成了工具,每个界面调用工具的API然后传值进行发送,不需要每个界面都写一遍工具类中的实现代码。

缺点:

1.对界面侵入性强,后期维护困难:由于工具类只负责发送数据,每个界面都会写一遍调用API方法,这样就造成重复代码冗余,解决方案是所有的界面都继承一个公用基类,每个界面自己去实现基类的方法即可。

但是由于老版的界面没有一个基类来管理,所以导致现在如果添加基类需要修改大量代码,需要大量的测试工作以保证APP本身的质量和埋点的完善。

2.灵活性不强:这里所说的不灵活是指当统计需要的数据映射改变后,尤其是一些个性公用字段的修改(比如:界面id),就会导致APP涉及埋点界面全部修改一遍,非常不灵活。同时由于iOS本身的审核机制,导致了上架周期相对安卓变长,会造成数据的丢失和上架的不及时。

二.新版教师端的埋点,采用的是统一配置表,由基类抓取当前界面,然后根据配置表获取到界面,再根据界面来发送数据。

优点:

1.高度解耦:每个界面自身的id有一个配置表,通过运行时的一个抓取类来抓取当前界面,然后在配置表来获取界面id再发送数据。

2.侵入性低,维护简单:由于有基类的存在,每个界面都实现了基类的方法,就可以被钩子抓取到界面,统计的所有代码没有和业务代码在一起,后期维护时只需要修改配置表即可。

缺点:

1.灵活性不够,个性数据获取困难:钩子抓取到的界面,通过配置表获取需要数据发送,但是这些都是写死的,个别界面自身的特殊数据无法获取然后进行发送,可以看上面的例子,这种实现方式就无法获取,如果获取就需要侵入相应界面。

 

新老的埋点都是在原生写死的映射,无法实现灵活的修改更新。而且后期定下来的技术方案最好在新版本中进行实现,因为老版本的代码的问题可能不容易或无法满足一些条件。

 

下面是最近看的文章中关于统计方案的思路和实现方法。大部分的文章采用的都是和新版教师端一样的方法,利用OC的RunTime黑科技Method Swizzling来Hook界面注入代码实现。

先来这些文章的链接

http://blog.csdn.net/w10207010218/article/details/56274431

http://www.jianshu.com/p/0497afdad36d

http://blog.csdn.net/kaka_2928/article/details/61201320

http://www.cocoachina.com/ios/20170427/19108.html 主要查看了这篇文章,里面还有个链接可以查看基础篇

重点讲一下最后链接文章的内容,文章是网易乐得的技术人员写的,不过他们的SDK没有对外公开(好像安卓公开了),他们声称:SDK 已经具备不需要代码埋点就能 自动的、动态可配的、全面且正确 的收集用户在使用 App 时的所有事件数据。除此之外,还单独开发了与之配合的圈选SDK,能够在 App 端完成对界面元素的圈配以及 KVC 配置的上传。而界面元素圈配的工作完全可以交给用研与产品人员来做,减轻了开发人员的工作量。

完成了两大部分:基本事件数据的收集和业务层数据的收集

文章中的SDK的实现思路和大部分主流一样是利用了Runtime 特性的 Method Swizzling 黑魔法,但是SDK也可以实现对界面中的子控件的数据收集,通过viewPath 及 viewId ,内容很多建议通过链接查看

Snip20170602_5

要实现灵活的进行数据收集和发送,就需要使用KVC实现。

什么是KVC配置。其实 KVC配置 就是一些用来描述 App 应该在什么时机去收集什么数据的信息

  • 上传KVC配置
    • 利用 圈选SDK 上传 KVC配置 的操作对于用户是透明的,主要由开发人员进行上传与管理。此操作可以在任何时候进行,在想要收集某个或某些版本的 App 中的业务数据时,上传相应的KVC配置信息至后台即可,达到了根据需要动态可配的效果。
  • 请求KVC配置
    • SDK 在初始化时会触发 KVC配置 的请求操作,从后台拉取 App 当前版本对应的所有KVC配置,并将请求结果缓存起来,以提供给下一步使用。

上传的所有的 KVC配置 需要与 App 的版本相对应,因为 App 版本不同会直接导致keyPath可能不一样。所以与 KVC配置 相关的工作有如下2个:

  1. 针对当前 App 版本上传相应的 KVC配置,以获取想要的业务数据
  2. 当 App 新版本发布时,需要对之前版本上的 KVC配置 逐一验证,是否仍然适用于新版本。如果仍然适用,则直接在管理后台上把新的版本号添加到此 KVC配置;如果不再适用,则对新版本再上传一个新的KVC配置。

业务数据的收集与上报的流程

8db8721df6e82075t

重构版的埋点采用的是现在的主流方案,现在需要攻克的难点就是灵活性的问题,怎么样从服务器去获取配置表,然后本地映射获取需要的数据,然后发送给统计平台。

发表评论

电子邮件地址不会被公开。 必填项已用*标注