揭开JS无埋点技术的神秘面纱 | UncleChen的博客

[unclechen]

http://unclechen.github.io/2018/06/24/%E6%8F%AD%E5%BC%80JS%E6%97%A0%E5%9F%8B%E7%82%B9%E6%8A%80%E6%9C%AF%E7%9A%84%E7%A5%9E%E7%A7%98%E9%9D%A2%E7%BA%B1/#more

一、背景相信很多人都接触过“埋点”这个概念，无论是前端还是后端开发，我们都可以使用这门技术来生产出一些运营性质的原始数据（接口耗时、程序安装/启动、用户交互行为等等），然后分析它们得到一些抽象指标（例如留存率、转化率），进而决定产品运营或者代码优化的方向。现在业界有许多比较知名数据平台，比如Google Analytics、Facebook Pixel、Mixpanel、GrowingIO、诸葛I

[rick-yo]

最近也在做埋点相关的事情，其实这里面最难而且还没解决的问题就是元素的定位。。。

[unclechen]

@richardyou 最近也在做埋点相关的事情，其实这里面最难而且还没解决的问题就是元素的定位。。。

是的，这件事情最难最关键的就是“元素定位”，实现元素定位时，需要考虑的指标主要有下面几个：

• 可用性：每一个元素，都可以生成唯一的选择器
• 唯一性：生成出来的选择器，可以唯一定位这个元素
• 长度：生成的选择器的长度（单纯从技术角度说，肯定是越短越好）
• 查找速度：根据选择器查找元素的速度
• 代码量：实现这个功能的代码量多少

根据业务需求，上面几个指标，我们可以选择性能去满足一些，而不是全部，因为上面的指标有时会互相抵消。 https://github.com/fczbkk/css-selector-generator-benchmark里面是一份对多个css-selector-generator库的性能分析报告，其实目前基本上能考虑到的实现方式，都在里面有了。

[rick-yo]

@unclechen

@richardyou 最近也在做埋点相关的事情，其实这里面最难而且还没解决的问题就是元素的定位。。。

是的，这件事情最难最关键的就是“元素定位”，实现元素定位时，需要考虑的指标主要有下面几个：

• 可用性：每一个元素，都可以生成唯一的选择器
• 唯一性：生成出来的选择器，可以唯一定位这个元素
• 长度：生成的选择器的长度（单纯从技术角度说，肯定是越短越好）
• 查找速度：根据选择器查找元素的速度
• 代码量：实现这个功能的代码量多少

根据业务需求，上面几个指标，我们可以选择性能去满足一些，而不是全部，因为上面的指标有时会互相抵消。 https://github.com/fczbkk/css-selector-generator-benchmark里面是一份对多个css-selector-generator库的性能分析报告，其实目前基本上能考虑到的实现方式，都在里面有了。

目前我们公司的埋点都是基于xpath实现的，css-selector之类的方案我也看过，也是基于元素层级和属性定位的。实际上还是没有解决 dom结构频繁变动下和复杂业务场景下的定位问题。 比如：多个操作按钮根据权限展示的都不一样，这种交互复杂的场景下埋点就很容易失效。 尤其是web页面会频繁更新改版。基于层级的方案不怎么靠谱。 不过最近在做的尝试是：解析源码ast，给jsx和vue的template中的element加id。直接修改源文件。目前已经做出来demo，博主可以参考一下

[unclechen]

@richardyou

@unclechen

@richardyou 最近也在做埋点相关的事情，其实这里面最难而且还没解决的问题就是元素的定位。。。

是的，这件事情最难最关键的就是“元素定位”，实现元素定位时，需要考虑的指标主要有下面几个：

• 可用性：每一个元素，都可以生成唯一的选择器
• 唯一性：生成出来的选择器，可以唯一定位这个元素
• 长度：生成的选择器的长度（单纯从技术角度说，肯定是越短越好）
• 查找速度：根据选择器查找元素的速度
• 代码量：实现这个功能的代码量多少

根据业务需求，上面几个指标，我们可以选择性能去满足一些，而不是全部，因为上面的指标有时会互相抵消。 https://github.com/fczbkk/css-selector-generator-benchmark里面是一份对多个css-selector-generator库的性能分析报告，其实目前基本上能考虑到的实现方式，都在里面有了。

目前我们公司的埋点都是基于xpath实现的，css-selector之类的方案我也看过，也是基于元素层级和属性定位的。实际上还是没有解决 dom结构频繁变动下和复杂业务场景下的定位问题。 比如：多个操作按钮根据权限展示的都不一样，这种交互复杂的场景下埋点就很容易失效。 尤其是web页面会频繁更新改版。基于层级的方案不怎么靠谱。 不过最近在做的尝试是：解析源码ast，给jsx和vue的template中的element加id。直接修改源文件。目前已经做出来demo，博主可以参考一下

完全赞同你的观点，根据xpath、css选择器，本质上无法解决页面dom变化导致定位失效的问题。而且这种埋点方案无法理解上下文，比较适合作为简单页面（比如建站工具生成的网页，且不会频繁变化的情况下）的辅助。像你说的那种根据源码，添加id的方式是非常好的思路，如果页面是自己可控的话，用你的这种方案肯定是优秀很多的。还有一些情况，比如做sdk的，可能无法侵入别人的代码，我觉得只能尽最大努力提高元素定位的准确率和稳定性，并且在失效的情况下能够告警，其他的思路目前还没有想到。。

[rick-yo]

@unclechen

@richardyou

@unclechen

@richardyou 最近也在做埋点相关的事情，其实这里面最难而且还没解决的问题就是元素的定位。。。

是的，这件事情最难最关键的就是“元素定位”，实现元素定位时，需要考虑的指标主要有下面几个：

• 可用性：每一个元素，都可以生成唯一的选择器
• 唯一性：生成出来的选择器，可以唯一定位这个元素
• 长度：生成的选择器的长度（单纯从技术角度说，肯定是越短越好）
• 查找速度：根据选择器查找元素的速度
• 代码量：实现这个功能的代码量多少

根据业务需求，上面几个指标，我们可以选择性能去满足一些，而不是全部，因为上面的指标有时会互相抵消。 https://github.com/fczbkk/css-selector-generator-benchmark里面是一份对多个css-selector-generator库的性能分析报告，其实目前基本上能考虑到的实现方式，都在里面有了。

目前我们公司的埋点都是基于xpath实现的，css-selector之类的方案我也看过，也是基于元素层级和属性定位的。实际上还是没有解决 dom结构频繁变动下和复杂业务场景下的定位问题。 比如：多个操作按钮根据权限展示的都不一样，这种交互复杂的场景下埋点就很容易失效。 尤其是web页面会频繁更新改版。基于层级的方案不怎么靠谱。 不过最近在做的尝试是：解析源码ast，给jsx和vue的template中的element加id。直接修改源文件。目前已经做出来demo，博主可以参考一下

完全赞同你的观点，根据xpath、css选择器，本质上无法解决页面dom变化导致定位失效的问题。而且这种埋点方案无法理解上下文，比较适合作为简单页面（比如建站工具生成的网页，且不会频繁变化的情况下）的辅助。像你说的那种根据源码，添加id的方式是非常好的思路，如果页面是自己可控的话，用你的这种方案肯定是优秀很多的。还有一些情况，比如做sdk的，可能无法侵入别人的代码，我觉得只能尽最大努力提高元素定位的准确率和稳定性，并且在失效的情况下能够告警，其他的思路目前还没有想到。。

嗯，这种方案的确有局限性，只能公司内部用用。不仅是定位，检查工具，圈点工具也要跟上。

[SoftwareEngineerPalace]

 好文章