小程序可视化实时自动埋点设计

|导语小程序上线新版本的时候需要经过微信审核，如果有紧急需求要添加埋点并即时生效，那就来不及了。

1、为什么要做？

先看下之前的埋点流程，如图所示。产品提出埋点需求，开发人员在mp平台配置埋点事件，然后进行代码埋点，再测试埋点，没问题之后再提审。

小程序从提审到审核通过大概需要半天到两天的时间。通过之后还需要半天的线网验证，线网有问题之后又得重新走一遍发版流程。整个埋点流程比较长。

有一次在比赛前一天晚上彩排的时候，产品临时需要加个埋点需求，因为当时已经晚上10点多了，小程序没人审核，所以只能等到第二天早上找领导走内部紧急审核通道，比较尴尬。

这个时候如果有一个实时的埋点系统就可以完美解决了。

细心的同学还会发现，整个埋点流程开发还是需要费神费力的，这种重复性的工作也是比较繁琐的，而且对于技术能力的提升也没有多少帮助。
所以埋点系统的另外一个要求就是不需要开发介入，产品或者运营人员就可以单独完成埋点。

2、怎么做

2.1、避免重复造轮子

在做之前，先了解下公司内外已有的埋点方案，避免重复造轮子。如图所示，目前公司外有growingio和神策两款产品，小程序官方也提供了埋点方案。

growingio是全埋点，数据全，但是由于是全埋点，后期还需要开发介入清理数据，不满足埋点系统的要求；
神策和MP需要代码埋点，不能实时生效。
因此，现有的埋点方案都不能够完全满足我们的要求，需要独立开发一个系统。

2.2、埋点方案设计

框架图如下，小程序的sdk分成两种模式，埋点模式和采集模式，

埋点模式是产品操作的，供产品新增埋点事件。
采集模式就是采集用户的点击操作，在小程序启动的时候，从后台拉取产品需要的埋点事件，用户点击动作命中埋点事件之后自动进行上报。

在web端，产品可以查看埋点数据

这一篇阐述的是小程序SDK的实现，下面做具体介绍

3、埋点系统具体实现

3.1 埋点整体流程

具体流程如图所示，通过配置确定是埋点模式还是采集模式，假如是采集模式，需要获取埋点事件，判断是否有要统计的埋点事件。
接下来就是重点，用户点击之后，首先需要确定响应者，然后是唯一标识这个点击动作，最后是拦截这个交互事件，上报统计事件。简单的说就是

寻找响应者
唯一标识
拦截交互事件
其中比较难的一个点是寻找响应者，因为小程序是双线程，视图层和逻辑层是分开的，跟H5不太一样，H5是可以获取完整的dom节点信息。但是在小程序中可以获取到的信息很少

下面重点介绍下这几个流程

3.2 寻找响应者

1）业界方案介绍 业界方案主要有两种，分别是工程化注入和冒泡采集。

工程化注入就是给所有标签注入点击事件，这种相当于全埋点，数据比较全。
但是缺点也很明显，给所有标签加上点击事件会让项目显得比较重，而且假如原来的标签有点击事件，就更不好处理了。
冒泡采集就是在wxml代码的最外层添加一个view，然后绑定catchtap事件。这种就比较轻量级，无需注入大量代码。但是依赖于冒泡事件，假如原来的业务代码阻止了冒泡，那就获取不了，可靠性比较差。

这两种方案都是从视图层出发，或多或少需要入侵业务代码，各有缺陷，不满足我们的需求。

2）思路转换 上面的方案是从视图层出发，因为小程序的双线程模型，这里我从另外一个角度出发，从逻辑层下手。

原理是这样的：在渲染层触发的点击事件都会传递到逻辑层，所以可以从逻辑层入手，对逻辑层的每个函数提供hook方法，在hook中捕获到用户的点击事件。

3）具体实现

目标分析：获取用户的点击行为，从wxml=>js，也就是从渲染层转向逻辑层。小程序的逻辑层涉及到两个系统对象
- 页面对象
- 自定义组件
  因此，只要重构这两个系统对象即可，具体做法如下：
在小程序启动的时候，重构Page()和Component()这两个系统对象，遍历对象里面的所有属性，如果属性类型是函数，则进一步判断是否在忽略名单，像监听页面滚动的函数这种是不需要添加hook的，最后才是给函数添加hook

不过在小程序启动的时候去给页面的函数添加hook还不完整，因为有些函数是在运行时添加的，像这种该怎么添加hook呢？

给运行时的func添加hook
这块我想到了几种方案
1. 给Page对象设置proxy，监控set方法
2. 在所有hook中监控Page属性的数量
3. Page添加生命周期函数，onLoad执行完之后给新生成的func添加hook

第一种和第二种都存在多次触发的情况，影响性能。只有第三种是一劳永逸的，只需要执行一次就可以了。

3.3 唯一标识

唯一标识就是确定用户点击动作的唯一性，传统的标识大部分是通过视图栈方案，也叫特征值标识。在小程序中，就是通过标签的id来标识，id就是标签的特征值。

1）视图栈方案

如图所示，当用户点击某个标签时，可以获取到两个id，一个是targetId，另一个是currentTargetId，其中

Target，触发事件的源组件，
currentTarget，事件绑定的当前组件。

这种方案，唯一标识就是通过这两个id进行组合得到

使用这种方案可靠性比较差，因为在写业务代码的时候，可能没有给标签添加id，这样取到的id就是空字符串，使得标识并不唯一

2）变量名+新特征值

前面说过，用户点击某一个标签，都会对应到逻辑层的某个函数，所以这里把函数名作为新的特征值。为了确保唯一性，再加上当前页面路径，防止其他页面有相同的函数名。
这种方案的优势很明显，就是不依赖于id，可靠性有保证。

不过细想一下，还是有一些情况需要考虑：

custom components如何获取pagePath 因为组件的层级比页面层级低，从组件对象是没法获取页面信息的。
但是由于是可视化埋点，所以组件所在的页面肯定在页面栈的最上面，因此，可以通过页面栈获取当前的页面对象，然后再获取页面路径
对于list点击事件，如何区分？

如图，每个tab的点击情况是需要区分统计的，而对于下面列表中的奖励领取，一般是不需要区分的。不需要区分的按照原方案即可。
对于需要区分统计的，因为tab不同时，所触发的函数参数肯定也不同，所以唯一标识需要带上函数的参数。

如何统计一个事件在所有页面的情况

对于全局范围的统计，因为要统计所有页面的情况，所以需要将页面路径和函数名称分开存放，其中函数名作为埋点事件的唯一标识，页面路径作为子标识。

3.4 拦截交互事件

1）事件模型分析

小程序的事件模型如下，用户点击某个view时，会从外到内进行捕获，事件冒泡的响应顺序相反，是从内到外进行冒泡。可以看到，用户点击一次可能会触发多个事件，所以重点是要防止多次上报统计事件。

为了防止多次上报，需要寻找当前点击事件的唯一性。
这是小程序的事件对象，可以看到，通过时间戳和标识符可以唯一确定当前的点击事件，
其中时间戳timeStamp是用户打开小程序到点击事件产生的时间戳，标识符identifier是触摸点的标志符。

2）埋点模式流程

埋点模式是供产品使用的，产品点击页面时，会触发逻辑层的某个函数，前面说到，每个函数都会添加hook.

Hook的执行流程如下，首先会根据事件对象的事件戳和标识符来判断这个事件是否已经上报处理过，如果是就直接结束。

否则就记录下这个事件已经处理过，防止后面重复处理。

然后再判断这个事件类型是否为点击事件，如果是就询问用户是否要执行埋点上报，最后确保埋点类型及名称。

3）采集模式流程

采集模式是根据埋点事件进行数据上报。可以跟埋点模式一样，

给所有func添加hook，在hook判断是否要上报。这种方案有个弊端，因为埋点事件的数量远比函数的数量要少，大多数函数是没必要进行hook的，给全部函数加上hook会影响页面的性能。
根据埋点事件找到需要上报的func，只给这些func添加hook。很明显，这种方案更佳，下面看看具体实现流程。

小程序启动的时候，同时进行两件事。

给页面添加一个生命周期函数initFuncHook
从后台拉取埋点事件
当页面打开的时候，去执行initFuncHook生命周期函数，initFuncHook的流程如下：
遍历页面的属性，判断属性是否为fun类型，并且是需要埋点的，如果需要则添加hook，如果不需要就重新遍历对象属性，直到所有属性都遍历为止。