打点的痛点
打点是由用户操作，引起视图变化，在记录视图变化时的业务数据信息，以**品、运维分析。所以打点既包括视图逻辑，也包括业务逻辑，这是蛋疼的地方。我们在开发的时候，一直致力于业务逻辑和视图逻辑要分离，而打点非要将他们糅合在一起……
总结一下打点的几个痛点：
1、与业务代码耦合（回调打点）
2、与视图逻辑耦合（点击点必须写onclick）
3、曝光点逻辑多、复杂
4、没法在发版之后打点（产品开发时不关心打点，发版前突然关心！）
耦合问题
思路，选择与视图和逻辑一方耦合，采用声明式，这样会较少代码恶心程度，利于维护。
1、选择与业务逻辑耦合
视图逻辑用钩子，在业务逻辑代码声明打点。问题是如何描述视图，目前没有看到完美的方式， 讯享网
有两种方案：
a、View树路径定位+声明Tag名称方式
即使用ViewPath+TagName唯一确定一个View。
b、ViewID + TagName
总结：两者各有利弊，如果在业务逻辑声明View的Click点，最好用b方案；但如果后台生成打点，a方案更好。自己体会吧！
2、选择与视图耦合
3、钩子
说了半天，Click点的钩子怎么设置，什么是Click时候的钩子？就是用户在点击时，能够截获点击事件。这里总结了三种方式，可行性都很好，看你的选择了：
a、运行时方案：复写所有的原生View
例如:
View——》MoonView
LinearLayout——》MoonLinearLayout
………………
干什么呢？把它的PerformClick方法截获，插入你的打点逻辑。然后规范所有这个APP的开发者，使用的View必须是包装过的View！这种方案对于大型项目就不好了，除非在线上打包时加上静态检查，否则很难推广。
b、运行时方案：在你的Activity或者框架中给所有的View添加AccessibilityDelegate
这是google提供的无障碍使用接口，你不知道怎么用就去百度吧，在AccessibilityDelegate中可以截获Click事件，但是你的View不要把AccessibilityDelegate功能关闭。还有在设置AccessibilityDelegate时，最好先通过反射方式getAccessibilityDelegate()，如果有人已经设置了AccessibilityDelegate最好不要覆盖它，可以写个代理的AccessibilityDelegate然后再设置，这些坑不要说我没告诉你！
c、编译时方案：gradle脚本
写个gradle插件，在编译时找到所有的OnClicklistener，然后hook掉Onclick，把打点代码注入进去！很简单很暴力，并且毫不侵入。
本人建议使用c方案！
曝光打点
首先，我们要理清曝光打点有哪些逻辑，然后将曝光打点逻辑参数化，最后定义接口，适配不同容器（统一容器最优雅）
1、曝光打点逻辑
总结几个维度：延迟、移入、移除、间隔、是否完全。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/18837.html