可视化埋点平台元素曝光采集intersectionObserver思路实践
作者:芋仔
正文
最近一直在开发可视化埋点系统,其中元素的曝光埋点,就是借助了 intersectionObserver 这个原生 api。也是网上推荐度比较高的方案,同时 2022 年,该 api 兼容性也已经很高,同时也有 polyfill,基本上使用无虞。
intersectionObserver 本身 api 非常简单,但是在实际使用的过程中,由于可视化埋点的一些特殊性以及对埋点准确性的要求,还是遇到了一些 dom 变更后的边缘场景,本文便是对这些边缘场景的一个记录及实现背后的一些考虑。
通常来讲,元素的埋点是开发者主动在元素中直接埋点,而笔者正在开发的可视化埋点,在数据收集侧的工作,是异步从后台获取用户需要的元素 xpath,然后再通过 xpath 寻找到元素,调用 intersectionObserver 的 observe 方法进行监听元素的曝光。所以在进行监听的时机上,都是在元素挂载到 dom 后进行元素的监听,那么初次监听,是否会触发其回调,便关系到曝光埋点的准确性。
同时,可视化埋点也监听页面 dom 的变更,当变更后,需要解除旧元素的监听,同时增加对新元素的监听。那么如果多次监听同一元素,是否会多次触发回调,也影响到曝光的准确性。
设计方案
为了快速上线第一版,笔者最初的设计方案为:
- 根据服务端返回的 xpath,寻找到对应的 dom 元素,对元素进行 observe
- 监听 dom 变更事件,当 dom 发生改变后,重新根据 xpath 寻找 dom 元素,对元素进行再次 observe
在该方案中,存在几个触发时机可能导致的问题:
- 当监听发生在元素渲染到页面后,首次监听的同时,是否会触发回调(影响到初次曝光的准确性)
- 多次监听同一 dom 元素,是否会多次触发回调(影响到 dom 变更,多次监听同一元素后,曝光的准确性)
测验结论
- 当初次监听元素时,会立即触发一次回调
- 多次监听同一元素,并不会多次触发回调
在上述逻辑成立的情况下,笔者最初的方案其实是可以正常工作,对于初次曝光,虽然发生在元素渲染到 dom 之后,但是由于会立即触发一次,故初次曝光能够正常上报。而当 dom 发生变更后,消失的元素,虽然没有调用 unobserve,但是由于该元素消失了,并不会影响后续曝光埋点的上报,所以并没有带来大的问题,而 dom 变更后,元素如果依然存在,虽然再次进行了监听,但是多次监听并不影响同一元素,所以其实也没有问题。
对于第一版,上线后也确实能够正常工作,但是对于没有 unobserve 这一点,由于 js 的垃圾回收机制,必须是没有引用后才会销毁,而没有 unobserve,那么内部必然会维护一份监听的元素的列表,保留了已经从 dom 中移除的元素的引用,从而造成内存泄漏。
故需要做一些策略来避免该问题(不然代码也会被吐槽),思路如下:
维护一份 xpath -> 元素的映射,当 dom 发生变更时,遍历所有 xpath 寻找对应的元素,
如果元素同映射中一致,那么表示该元素没有发生变更,此时可以直接忽略,什么都不做。
而如果元素发生变化,那么调用 unobserve 取消旧元素的监听,同时对新元素进行监听即可。
完整的伪代码
// 工具函数命名很清晰,含义不赘述 import { getEleByXpath, getXpathByEle, debounce } from 'utils'; class track { constructor() { /* { xpath: '', id: ''id } */ this.config = {} // 存储远程服务端返回的埋点 xpath 信息 /* [xpath]: el, */ this.map = {} // 维护的 xpath -> el 映射 this.observer = null; // intersectionObserver 实例 } // 远端获取需要曝光点的元素 getConfig() { return fetch('xxx').then(res => { this.config = res; this.config.forEach(item => { // 初始化 xpath -> el 映射 this.map[item.xpath] = null; }) }); } // 监听 dom 变更 addDomtreeMutatorObserver() { // 不关心属性变化 const config = { attributes: false, childList: true, subtree: true }; // 监听dom变更,消个抖 const observer = new MutationObserver(debounce(this.observe.bind(this), 200)); observer.observe(document.body, config); } // 监听元素曝光 observe() { // 此处可以加个 requestIdleCallback 来增强性能 this.config.forEach((item) => { const targetEl = getEleByXpath(item.xpath); // 新旧元素不一致才需要取消旧元素监听,增加新元素监听 if (targetEl !== this.map[item.xpath]) { // 元素存在,就监听 if (targetEl) { this.observer.observe(targetEl); } // 取消旧元素的监听 if (this.map[shadow.xpath]) { this.observer.unobserve(this.map[shadow.xpath]); } // 更新map中的el this.map[shadow.xpath] = targetEl; } // 一致,则什么都不做 }); } // 创建 intersectionObserver initObserver() { const callback = (entries) => { entries.forEach((entry) => { if (entry.intersectionRatio > 0.2) { const targetXpath = getXpath(entry.target); for (let i = 0; i < this.config.length; i++) { if (this.config[i].xpath === targetXpath) { // xpath一致 // 发送曝光埋点 } } } }); }; const observer = new IntersectionObserver(callback, { threshold: 0.2, }); this.observer = observer; } init() { this.getConfig().then(() => { // 初始化 intersectionObserver this.initObserver(); // 监听元素 this.observe(); // 监听 dom 元素变更 this.addDomtreeMutatorObserver(); }); } }
以上便是精简后的伪代码,其核心的优化点便是维护 xpath -> el 的 map(说实话,一开始笔者其实就想到了 map,但是当时想的是拿 dom 引用作为 key,拿对象做 key 显然是行不通的,就短暂放弃,先上线再说。后来想到用 xpath 做key,才有了这篇文章)。
其实本文的初衷是记录一下 intersectionObserver 的一些边缘情况及结论(其实还对 intersectionObserver 做了其他一些比较傻的测试),但是在文章编写的过程中发现干巴巴的分析,显得实在是无趣,故夹杂了实际的可视化埋点曝光采集的业务场景,希望没有写的很乱。
同时,当笔者彻底理清思路后,发现这优化其实不值一提,只是笔者最初在设计可视化埋点方案时,由于对这些 api 的不熟悉,导致的一些迷迷糊糊的摸爬滚打经验,还望懂的同学别笑。
以上就是可视化埋点平台元素曝光采集intersectionObserver思路实践的详细内容,更多关于intersectionObserver元素曝光采集的资料请关注脚本之家其它相关文章!