今天小编给大家分享一下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 端，一方面是将 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可视化埋点元素圈选器如何实现”这篇文章的所有内容，感谢各位的阅读！相信大家阅读完这篇文章都有很大的收获，小编每天都会为大家更新不同的知识，如果还想学习更多的知识，请关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
