Android可視化埋點元素圈選器如何實現

今天小編給大家分享一下Android可視化埋點元素圈選器如何實現的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

整體流程

整體來講，圈選器的功能在于：

enable 前，用戶可自由交互，此時點擊、移動并不會被阻礙。

而 enable 后，當用戶移動鼠標/移動端移動手指，便會高亮當前選擇的元素的大小、padding 及 margin 等。

而當用戶鼠標點擊 / 移動端手指離開 后，將會觸發選中的回調，可視化埋點平臺在這一環節喚起 埋點錄入表單。

從整體的思路上來講，整個 元素圈選器 的核心功能在于：

• 計算元素的大小、位置，屬性，并增加蒙層

• 列表元素的判定、多選

• 兼容 pc/mobile

除此之外需要具備 開關能力，以免影響用戶正常交互。

元素位置、大小及屬性計算

首先是元素的位置計算，一個非常簡單的方法是借助現成的 api: Element.getBoundingClientRect 。

通過該方法拿到的 left, top，便是元素相對于視區左上角的位置，這樣在后續添加蒙層的時候，以此作為元素位置即可。

但是實際在添加蒙層時，左上角是包含了 margin 的位置，故此處通過 left - 'margin-left'， top - 'margin-top' 作為元素在左上角的位置。

而對于元素的大小，可以通過 element.offsetWidth 來獲取，這一值包含了元素的 border padding 及 content，故元素實際的寬高需要減去左右 border 和 左右 padding，才是元素的 實際寬高。

對于元素的屬性：margin, padding，border，可以通過 Window.getComputedStyle 獲取。

得到上述數據后，整個元素的位置、大小、margin/padding/border 值都得到了完整的值，此時便可以按照這一尺寸繪制元素的蒙層。

但是在實際的場景中，還存在元素通過 transform 后縮放的場景，此處對上述用到的 api 和 transform scale 的關系進行梳理。

• 獲取元素的位置，Element.getBoundingClientRect，獲取到的是縮放后的位置。

• 獲取元素的大小，offsetWidth，獲取到的是縮放前的寬高

• 獲取元素的屬性，padding/margin/border，Window.getComputedStyle,獲取到的是縮放前的值。

可以看出來，元素的位置是縮放后的，而大小、屬性是縮放前的，實際蒙層的位置和大小是無法對應的。

此時有兩種方案，一種是根據縮放比例，計算縮放后的大小、屬性，另一種方式是直接在父元素上追加同等的縮放比例，從而獲取到實際的蒙層大小。本文采用的是后一種方案。

通過 ele.offsetWidth / getComputedStyle().width 拿到元素本身的縮放比例，此時對蒙層父元素追加反向比例的縮放，即可正確添加縮放后的蒙層。此時，由于位置一直取的是左上角，故實際并不需要關心元素的 transform-origin，始終使用左上角即可保證蒙層的位置正確。

但是實際處理時，由于元素的位置是 left - 'margin-left' 獲得的，此時由于 left 是縮放后的，而 margin-left 是縮放前，所以此處還需要對 left 乘上比例后再相減，實際的 left 值計算出后，再除以縮放比例即可解決。

實際的場景中，還存在一種情況，就是對整個 html 文檔流的縮放，這一場景是在一些 h6 頁面，需要兼容 pc 12px 的字體時，以前一些舊的頁面會先對 整個頁面按照放大 3 倍的尺寸開發，然后在最外層再套一個 transform: scale(0.333) 來實現對 12px 字體的兼容。

要兼容該場景，首先需要全局插入一個輔助元素，用于檢測 html 上的縮放。

元素的大小、位置及屬性計算不進行修改，全部使用縮放前的值，但是蒙層父元素的縮放比例需要進行調整，從原本的 僅進行元素的縮放，改為進行元素的縮放并還原 html 的縮放。

這是因為由于蒙層本身被進行了縮放，而元素也被進行了自身和 html 的雙重縮放，所以蒙層父元素僅需要按照元素的實際縮放比例進行縮放，但是實際由于蒙層還被 html 的縮放了一層，故需要針對性的抵消縮放比例才可以正常展示蒙層的大小。

以上便是整個元素大小、位置及屬性獲取的方案，也解決了邊界的 transform 場景，實際中還會有一些額外的處理，比如 元素的 tips 由于存在文字，其展示就不進行元素大小的縮放，僅抵消掉 html 帶來的縮放比例即可。

列表元素的判定

在實際的頁面中，往往存在列表元素，這些元素結構類似但是每一行又有數據 or 樣式上的差別，對于這種元素，在可視化埋點中，往往需要智能檢測且需要批量選擇。

對于列表場景，每一行往往有跡可循，而判定列表元素，往往也是找到一行。當然，實際的判定還是需要按照一定的規則，在這里，我定的幾個判定規則有：

• 當前元素的子節點，最少具有 5個，且相同 tag 及相同 className 的數量要大于 70%。

• 當前元素的孫節點們的 tag 連接起的字符串，相同的數量要超過 70%。

• 如果不滿足，則從其父節點再開始查找，一直到 document.body 為止。

通過這樣的方式，實測能夠覆蓋業務中的大部分列表場景。

掛載位置

在實際可視化埋點過程中，圈選蒙層的掛載位置，一開始是放在 body 的最后一個元素，但是實際場景中，會存在動態 modal 這樣的場景，會動態的在 body 最后追加元素，此時該元素的 xpath 便會收到蒙層元素的影響，導致統計偏差，故在參考 vconsole 后，將元素轉移到了 html 下，從而減少對業務元素的影響。

pc/mobile 兼容

pc 端 與 mobile 端，一方面是將 mousemove 替換為 touchmove。

而另一方面，圈選結束的時機在 mobile 端丟失。原本 pc 端通過 body 上捕獲階段的點擊事件進行圈選結束的判定，而 mobile 端，由于 click 事件在 touchmove 后不會觸發，故需要在 touchend 中創建自定義事件，觸發 body 上的點擊。

除此之外，mobile 端還存在移動觸發頁面滾動的情況，此處本文采用了對所有元素增加 touch-action: none 的方法，避免了移動端手指滾動時對全局頁面的影響。

同時，移動端 touchmove 的 target 并不會指向當前 move 的元素，需要使用一些 api 進行當前元素的獲取，偽代碼如下：

if (e instanceof TouchEvent && e.touches) {
    const changedTouch = e.changedTouches[0];
    return document.elementFromPoint(changedTouch.clientX, changedTouch.clientY);
}

同時，由于該方案回獲取當前位置的元素，也就是說如果手指下方的元素是蒙層元素，那么也會被選中，所以需要對 蒙層等無關元素增加 touch-action: none 來避免被選中。

以上就是“Android可視化埋點元素圈選器如何實現”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。