首頁 > 軟體

視覺化埋點平臺元素曝光采集intersectionObserver思路實踐

2023-01-06 14:00:07

正文

最近一直在開發視覺化埋點系統,其中元素的曝光埋點,就是藉助了 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元素曝光采集的資料請關注it145.com其它相關文章!


IT145.com E-mail:sddin#qq.com