今天小编给大家分享一下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进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。