可视化埋点平台元素曝光采集intersectionObserver的方法是什么(intersectionobserver,开发技术)

为了快速上线第一版，笔者最初的设计方案为：

根据服务端返回的 xpath，寻找到对应的 dom 元素，对元素进行 observe

监听 dom 变更事件，当 dom 发生改变后，重新根据 xpath 寻找 dom 元素，对元素进行再次 observe

在该方案中，存在几个触发时机可能导致的问题：

当监听发生在元素渲染到页面后，首次监听的同时，是否会触发回调（影响到初次曝光的准确性）

多次监听同一 dom 元素，是否会多次触发回调（影响到 dom 变更，多次监听同一元素后，曝光的准确性）

当初次监听元素时，会立即触发一次回调

多次监听同一元素，并不会多次触发回调

在上述逻辑成立的情况下，笔者最初的方案其实是可以正常工作，对于初次曝光，虽然发生在元素渲染到 dom 之后，但是由于会立即触发一次，故初次曝光能够正常上报。而当 dom 发生变更后，消失的元素，虽然没有调用 unobserve，但是由于该元素消失了，并不会影响后续曝光埋点的上报，所以并没有带来大的问题，而 dom 变更后，元素如果依然存在，虽然再次进行了监听，但是多次监听并不影响同一元素，所以其实也没有问题。

对于第一版，上线后也确实能够正常工作，但是对于没有 unobserve 这一点，由于 js 的垃圾回收机制，必须是没有引用后才会销毁，而没有 unobserve，那么内部必然会维护一份监听的元素的列表，保留了已经从 dom 中移除的元素的引用，从而造成内存泄漏。

故需要做一些策略来避免该问题（不然代码也会被吐槽），思路如下：

维护一份 xpath -> 元素的映射，当 dom 发生变更时，遍历所有 xpath 寻找对应的元素，

如果元素同映射中一致，那么表示该元素没有发生变更，此时可以直接忽略，什么都不做。

而如果元素发生变化，那么调用 unobserve 取消旧元素的监听，同时对新元素进行监听即可。