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

[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
最近也在做埋点相关的事情，其实这里面最难而且还没解决的问题就是元素的定位。。。

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

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

根据业务需求，上面几个指标，我们可以选择性能去满足一些，而不是全部，因为上面的指标有时会互相抵消。
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，博主可以参考一下

[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]

 好文章