美团点评前端无痕埋点实践.docxVIP

美团点评前端无痕埋点实践 由于后面要引见的声明式埋点和无痕埋点方案仍旧依靠原有代码埋点的底层规律，这里有必要简约引见下代码埋点。在实现代码埋点时，我们次要关注的是数据结构的规范性、埋点接口的易用性、上报策略的牢靠性等问题。全体的模块划分如下图所示。 开发者需要手动在需要埋点的节点处（例如：点击大事的回调方法、列表元素的呈现回调方法、页面的生命周期函数等等）插入这些埋点代码。 可以看出，代码埋点是一种典型的命令式编程，因而埋点代码经常要侵入具体的业务规律，这使埋点代码变得很繁琐并且简约出错。因而，最直接的做法就是将埋点代码与业务规律解耦，也就是“声明式编程”，从而降低埋点的难度。 声明式埋点 声明式埋点的思路是将埋点代码和具体的交互和业务规律解耦，开发者只用关怀需要埋点的控件，并且为这些控件声明需要的埋点数据即可，从而降低埋点的成本。 Android 在Android中，我们自定义了常用的UI控件，例如TextView、LinearLayout、ListView、ViewPager等，重写了大事响应方法，在这些方法内部自动填写埋点代码。重写控件的好处在于可以拦截到更多的大事，执行效率高并且运转稳定。但其弊端也格外明显——移植成本很高！ 为了处理这个问题，我们自创了Android v7支持库的思路，即通过AppCompatDelegate代理自动替换UI控件。 这样，开发者只需要在本人的Activity基类中重写getDelegate方法，将方法的前往值替换为修改过的AppCompatDelegate，就可以实现自动替换UI控件了。 然而，新的问题又消灭了。 假如引用的第三方库中重写了UI控件，上述方法是不生效的，也就是说我们需要一种替换UI控件类的父类方法。可是在运转时，我们没有找到可行的替换UI控件类的父类方法。因而，我们尝试在编译时修改父类，并开发了一个Gradle插件。现实上，这样做并不存在运转时效率的问题，只是会牺牲一些编译速度。这样开发者只需要运转这个插件，就可以实现自动将UI控件的父类替换为我们重写的UI控件了。 接受了声明式埋点后，只需要在控件初始化时声明一下需要的埋点就可以了。我们不必再侵入程序的各种响应函数，降低了埋点的难度。 iOS 在iOS中，利用Objective-C关联属性和类别的语法特性，我们无需重写UI控件，就能实现声明式打点。对于UIControl，可以在声明埋点时添加新的action，并在大事发生时自动填写埋点代码。 对于UITableView，可以通过重写UITableViewDelegate，利用消息传递机制拦截大事，并在大事回调方法中自动填写埋点代码。 同样的，接受了声明式埋点后，埋点代码得到了简化。 声明式埋点能够替代全部的代码埋点，并且能处理晚期遇到的移植成本高等问题。但是其本质上还是一种代码埋点，只是埋点的代码削减了，并且不再侵入业务规律了。假如要满足动态部署与修复埋点的需求，就需要彻底毁灭写死在前端的埋点代码。 无痕埋点 我们留意到，之所以声明式埋点还需要写死代码，次要有两个缘由：第一是需要声明埋点控件的独一大事标识，即bid；其次是有的业务字段需要在前端埋点时携带，而这些字段是在运转时才可获知的值。 对于第一点，我们可以尝试在前后端使用全都的规章自动生成大事标识，这样后端就可以配置前端的埋点行为，从而做到自动化埋点。对于其次点，可以尝试通过某种方式将业务数据自动与埋点数据关联，这种关联可以发生在前端，也可以发生在后端。 大事标识 为了自动生成大事标识，我们需要猎取每个控件本身的ID、类名以及位于所属父组件的Index等特征信息，并逐级向上遍历找到根节点。根节点一般是手动标记的，假如没有标记则默认是视图层次树的顶层节点。最终，将遍历产生的路径上全部节点的特征信息组合在一起，就是这个大事的标识。考虑到在实际规划中有可能存在一些动态插入的控件，我们允许父组件的Index有肯定的误差。 配置后台需要维护自动生成的大事标识和bid的映射关系，并且可以下发给前端一个配置文件。当前端控件大事触发时，自动和配置文件婚配就可以拿到对应的bid了。需要留意的是，配置后台维护大事标识的工作可不是一件轻松的事情，次要的简单性在于不同版本之间规划变更导致的大事标识变更，这就是为什么还需要手动标记根节点的缘由。所以，一般我们会选取不易变更的视图节点。 数据关联 为了实现业务数据与埋点数据的自动关联，我们起初尝试了前后端日志关联的方式。即在前端恳求后端API的时机，由后端将业务数据写入日志，最终在数据清洗时将相对应的前后端日志合并。这种方式带来的问题是后端改形成本较高，并且数据清洗的开销较大，因而并不能广泛应用。但是在一些特殊场景下，例如某些业务数据只要后端可以获知，而前端不能获知时，这种关联是必要的。 更常