一文帮你搞定 H5、小程序、Taro 长列表曝光埋点

目录

前言：

1. 监听列表内元素曝光的常见方法

1. 1 方式一：根据接口下发分页数据估算可见元素

1. 2 方式二：监听滚动事件，实时计算元素相对位置

1. 3 方式三：利用浏览器标准 API 监听元素可视区变化

2. 列表内元素曝光事件监听的具体实现

2. 1 Web（H5）端

2. 1. 1 具体使用方法：

第一步：创建一个观察者（IntersectionObserver）

第二步：对目标元素添加观察

第三步：处理观察结果

第四部：停止观察

2. 1. 2 Tips

2. 1. 3 Intersection Observer API 的浏览器支持情况

2. 2 小程序端（微信小程序）

第一步：创建一个观察者（IntersectionObserver）

第二步：指定参照节点（参照区域）

第三步：开启观察

第四步：处理回调

第五步：停止监听

Tips

2. 3 Taro 框架内（Taro3+React）

1. 监听不生效的问题

2. 创建 Observer 需传入原生组件实例

3. 回调方法内如何获取目标元素的其他信息？

方案一：taro-plugin-inject 方案

方案二：访问 Taro 虚拟 DOM

---

前言：

 H5、小程序和Taro是当前流行的前端开发框架，它们都支持在移动端构建应用程序。在这些应用程序中，长列表曝光埋点是一个常见的需求，用于统计用户在列表中浏览的数据。

1. 监听列表内元素曝光的常见方法

长列表（或滚动视图）中元素的曝光埋点，关键是如何监听子元素的 “曝光” 事件。“曝光” 即元素进入到了屏幕的可见区域，也就是能被用户看到了，这是人类的直观视觉感受，那么如何用代码的方式来判定呢？目前大概有这么三种方法：1.根据接口下发分页数据估算可见元素；2.监听滚动视图的滚动事件，实时计算元素相对位置；3. 利用浏览器（或其他平台如小程序、Taro）标准 API 监听元素与可见区域的相交变化。下面分别介绍一下这三种方法的具体原理、适用范围及优缺点。

1. 1 方式一：根据接口下发分页数据估算可见元素

实现思路：长列表的数据往往通过分页接口进行加载，可以利用这一特性，以单页数据返回的维度粗略估算元素的可见性，具体说就是以每一次的接口返回的数据当做当前可见的元素的列表；

优点：

• 这种方式的好处是简单：仅仅根据分页接口每次请求的数据进行元素曝光的判断，计算很简单；

缺点：

• 缺点就是误差太大：一方面分页接口单次请求的数据也往往会超出一屏，另一方面列表内元素的高度可能也是不同的、分页返回的数据条数也可能存在差异，这种方式来计算元素的曝光误差太大；

由于缺点很明显，误差太大，现在很少有人这么来实现曝光埋点，但是在很多精度要求不高的场景或者年代很久的代码中还能看到这种实现方式

1. 2 方式二：监听滚动事件，实时计算元素相对位置

实现思路：监听长列表（或滚动视图容器）的滚动事件，通过平台 UI 基础接口（如浏览器 DOM 接口 getBoundingClientRect）实时获取元素坐标（包括位置和大小信息等），并计算同可视区域的相对状态（是否有重叠）来判定元素是否 “可见”；

优点：

• 相比方式一，精度有了很大的改进，如果计算的方式正确，计算结果可以说是准确的；
• 另外由于使用的是平台内的通用基础能力接口，兼容性较好；

缺点：

• 计算量大，性能损耗严重：这种计算方式需要监听滚动视图的滚动事件，在滚动回调事件内实时进行列表内所有元素的位置坐标计算（获取所有元素的位置并同当前可见区域进行对比），这样带来的计算量是相当大的，往往会造成页面的性能问题（如滑动卡顿）；
• 代码分散、逻辑复杂：除了需要监听滚动视图的滚动事件，还要在首屏数据加载或者数据刷新时，额外进行一次计算，整体复杂度及对页面的性能影响都比较大；
• 其他问题：可能引发其他额外操作，如在 H5 中 getBoundingClientRect() 的频繁调用也可能引发浏览器的样式重计算和布局； iframe 里，无法直接访问内部元素等等；

这种方式虽然计算量大、逻辑复杂、性能较差（当然也可以进行一些性能上的优化，代价是代码复杂度变的更高，不利于后续更新维护），但是计算结果是准确的，在没有出现方法三中的 Web 端标准接口（2016）之前，在计算精度要求严格的场景下，这视乎是唯一的选择；

1. 3 方式三：利用浏览器标准 API 监听元素可视区变化

优点：

• 性能更高： 浏览器底层实现，并进行了相应优化，性能没有问题：监听不会在主线程进行（只要回调方法会在主线程触发）
• 计算量小：这里的计算量小是指的我们 web 开发者需要进行的计算操作，因为大部分的计算浏览器 API 内已经帮我们计算好了，我们只需要根据需求场景在此基础上进行简单的处理即可满足需求；
• 计算更结果准确：浏览器 API 实现的计算结果是比较准确的，这块毋庸置疑；
• 代码更优雅：大部分的监听、计算逻辑都在 API 内部实现了，开发者的代码量不会太多太复杂，代码更简洁从而更利用后续维护；

缺点：

• 需要新浏览器支持（根据文档描述的浏览器兼容情况其实已经满足绝大多数的使用场景），太低版本的浏览器不支持，如果需要兼容，也有办法，通过官方提供的 polyfill 可以解决（引入 polyfill，当然不可避免的带来代码体积的增量，项目中实测打包后 js 文件体积增大了 8kb，这算是唯一的缺点吧）；（w3c 官方提供了对应 polyfill）

基于以上，这种方式是目前最推荐的一种实现元素曝光监听的方式，具体怎么用呢，下面对 H5、小程序、Taro 的使用场景分别来介绍一下。

2. 列表内元素曝光事件监听的具体实现

2. 1 Web（H5）端

简单来说，利用 Intersection Observer API 来进行视图元素的可见性观察主要分成这么几个步骤：创建观察者、对目标元素添加观察、处理观察结果（回调）、停止观察；

2. 1. 1 具体使用方法：

第一步：创建一个观察者（IntersectionObserver）

首先我们需要创建一个观察者IntersectionObserver ，用于监听目标元素相对于根视图（可以是父视图或当前窗口）的相交状态变化情况（即元素的 “可见” 状态）。具体创建方式是利用 Web 标准 API：IntersectionObserver构造方法，具体代码如下：

let observer = new IntersectionObserver(callback, options);

• 其中callback 就是当监听到元素位置变化时触发的回调方法，具体定义及用法会在第三步处理观察结果中具体介绍；

• options是定制观察模式的参数，参数定义如下

  interface IntersectionObserverInit {
      root?: Element | Document | null;
      rootMargin?: string;
      threshold?: number | number[];
  }
  

  • root: 用于指定观察的参照区域，一般是目标元素的父视图容器或整个视图窗口（必须是目标元素的父级元素。如果未指定或者为 null，则默认为浏览器视窗）
  • rootMargin：参照区域（root）的外边距，类似于 CSS 中的 margin 属性，比如 "10px 20px 30px 40px" (top, right, bottom, left)，用于对参照物的区域范围进行调整（收缩或扩张）；
  • threshold：相交比例阈值，用于定制需要观察的相交比例的临界值；元素的交集（相交比例）发生变化时并不是每次变化都会执行回调方法，只有当相交比例达到设置的阈值时才会触发回调（callback）;可以是单一数值（number）也可以是一组数值；例如当设置为 0.25 时，只有当相交达到 0.25 时（增大到 0.25 或减小到 0.25 都会触发&#x