移动端曝光统计方案设计

背景

从16年年初开始接触数据统计相关开发，断断续续经历了 2 年多时间，到目前为止，仍然在负责团队内部数据统计相关工作，也负责对其他同学做统计技术的指导。之前曾经经历过自研统计方案，与公司其他部门内部共建统计技术方案，后来搞过无痕埋点的探索。期间经历了很多问题，走了不少弯路，经过一年多的迭代，这部分内容基本上趋于稳定状态。最近接手另外一部分数据相关工作，发现历史遗留问题较多，就推动了数据曝光标准的统一，也是最重要的一个步骤，反复开了好几次会，终于大致敲定了整个数据曝光标准。

在与 PM 确定曝光标准之后，上周终于有了较多时间，于是开始重新思考整个曝光方案的设计。在数据统计方案中，前端埋点中相对较为复杂的是曝光埋点。click 事件的场景和代码逻辑都比较固定，往往在点击事件触发时插入相应的统计代码即可，比较恶心的地方是会与业务代码耦合，不过团队内部开发业务的同学反馈，如果 mock 和校验工具都比较完善的情况下，这部分工作量相对比较轻松，并不会占据太多开发时间，主要是工具的支撑。而曝光存在几方面问题：

定义复杂，比如用户看到才算曝光，曝光之后不能重复曝光。这些定义都会导致较多的逻辑代码，你需要管理曝光缓存，需要确认如何才算“看到”

不易测试，相对于 click 事件有明确的用户行为，曝光的用户行为可能没那么明确，比如用户滚动列表或者数据刷新，都会导致曝光逻辑变化

自定义组件，例如针对 banner，什么时候算用户看到？自动滚动算不算曝光？这些逻辑又跟通用的曝光逻辑有所区分

问题与方案设计

反应到代码实现层面，这些问题会导致实现上的问题：

触发上报事件的多样性和不确定性。例如PV变动会导致再次曝光再次上报，例如滚动事件会导致上报触发。但往往考虑到代码的易维护性，业务开发时，我们都会将页面拆分更为细颗粒度的模块维护，无论是 Android 的 还是 iOS 的 都是如此。当我们把业务拆分为更细颗粒度的业务模块时，都希望这些模块的公共接口清晰，不与其他模块耦合，方便后续的复用与维护。而曝光事件这个需求里会破坏这种封装，例如 会处理滚动事件，而 需要依赖这个滚动事件，这里就会有事件的传递和分发的问题。而在客户端现有的技术方案中，比较缺乏前端框架中跨 module 或跨页面的通信机制(类似Redux或vuex)，所以往往解决方式是暴露 interface 或闭包，这种方案会带来不必要的耦合，尤其是深层次传递事件时。

曝光逻辑一部分是统一的，例如缓存和事件处理。另一部分则是有差异的，比如具体统计上报的字段。这就需要我们抽象统一的逻辑，同时保留扩展差异化的能力。

自定义组件问题，之前设计的曝光方案仅仅支持列表曝光，但现状是首页顶部流量区域也是重中之重，对这部分也要着重支持

与 click 事件相同的问题，业务逻辑与曝光逻辑的耦合，甚至处理不当，耦合程度远超 click 事件。试想一下，我们改动统计逻辑会导致业务出现问题，这个无疑是不恰当的。

页面级框架的支持，随着移动端的流行，类似 以及 这种页面级框架会越来越流行，对类似方案的兼容和支持也是必须考虑的地方

在思考这几个问题的时候，我比较其实比较困惑，因为之前搞无痕埋点带来的失败教训，我对于比较 hack 或比较重的方案都不是特别有兴趣，一方面后期推广问题，一方面是后续维护问题。我比较倾向于在设计层面解决这个问题，虽然看起来不够酷或者超前，但是能够切实解决实际问题。思考了一天，有了一个大致的雏形，又花了一天时间书写详细方案、处理细节、接口设计，终于搞定了下面这个方案。核心思想有下面2个：

业务事件驱动：包括PV变动，列表滚动，数据刷新都统一定义为业务事件

Logic Controller 抽象树：用于事件分发和缓存逻辑的处理，每个 module 都会绑定一个 logic controller。其中最顶层页面的 logic controller 称之为 page logic controller。

复用问题

在设计完总体方案和确定核心思想之后，我开始进行接口设计，在设计的时候，我思考了一下曝光上报的逻辑：

发现只有蓝色部分的逻辑是与业务耦合的，无法提取复用，需要设计相应的接口，让业务层负责实现，其他部分逻辑都可以最大程度上进行复用。

总结

iOS 整个方案我花了一天多进行开发，比较核心的代码大概有 400+ 行代码，整个方案实际上比较简单。接下来会抽时间实现具体的业务逻辑实现，实践之后会对方案进行整体纠正和实现。Android 方案大概类似，我并不负责开发，但是整体思想上进行了同步一致，还未具体 challenge 问题。