Android 全埋点解决方案 (1):全埋点概述 1

阅读数:14 2019 年 11 月 30 日 15:17

Android全埋点解决方案(1):全埋点概述 1

(全埋点概述)

内容简介
这是一本实战为导向的、翔实的 Android 全埋点技术与解决方案手册,是国内知名大数据公司神策数据在该领域多年实践经验的总结。由神策数据合肥研发中心负责人亲自执笔,他在 Android 领域有近 10 年研发经验,开发和维护着知名的商用开源 Android & iOS 数据埋点 SDK。
本书详细阐述了 Android 全埋点的 8 种解决方案,涵盖各种场景,从 0 到 1 详解技术原理和实现步骤,并且提供完整的源代码,各级研发工程师均可借此实现全埋点数据采集,为市场解开全埋点的神秘面纱。
8 种 Android 全埋点解决方案包括:
AppClick 全埋点方案 1:代理 View.OnClickListener、
AppClick 全埋点方案 2:代理 Window.Callback
AppClick 全埋点方案 3:代理 View.AccessibilityDelegate
AppClick 全埋点方案 4:透明层
AppClick 全埋点方案 5:AspectJ
AppClick 全埋点方案 6:ASM
AppClick 全埋点方案 7:Javassist
AppClick 全埋点方案 8:AST

全埋点,也叫无埋点、无码埋点、无痕埋点、自动埋点。全埋点是指无须 Android 应用程序开发工程师写代码或者只写少量的代码,就能预先自动收集用户的所有行为数据,然后就可以根据实际的业务分析需求从中筛选出所需行为数据并进行分析。

全埋点采集的事件目前主要包括以下四种(事件名称前面的 $ 符号,是指该事件是预置事件,与之对应的是自定义事件)。

  • $AppStart 事件

是指应用程序启动,同时包括冷启动和热启动场景。热启动也就是指应用程序从后台恢复的情况。

  • $AppEnd 事件

是指应用程序退出,包括应用程序的正常退出、按 Home 键进入后台、应用程序被强杀、应用程序崩溃等场景。

  • $AppViewScreen 事件

是指应用程序页面浏览,对于 Android 应用程序来说,就是指切换 Activity 或 Fragment。

  • $AppClick 事件

是指应用程序控件点击,也即 View 被点击,比如点击 Button、ListView 等。

在采集的这四种事件当中,最重要并且采集难度最大的是 AppClickAppClick 事件来进行的。

对于 $AppClick 事件的全埋点整体解决思路,归根结底,就是要自动找到那个被点击的控件处理逻辑(后文统称原处理逻辑),然后再利用一定的技术原理,对原处理逻辑进行“拦截”,或者在原处理逻辑的执行前面或执行者后面“插入”相应的埋点代码逻辑,从而达到自动埋点的效果。

至于如何做到自动“拦截”控件的原处理逻辑,一般都是参考 Android 系统的事件处理机制来进行的。关于 Android 系统的事件处理机制,本书由于篇幅有限,不再详述。

至于如何做到自动“插入”埋点代码逻辑,基本上都是参考编译器对 Java 代码的整体处理流程来进行的,即:

复制代码
JavaCode --> .java --> .class --> .dex

选择在不同的处理阶段“插入”埋点代码,所采用的技术或者原理也不尽相同,所以全埋点的解决方案也是多种多样的。

面对这么多的全埋点方案,我们究竟该如何做选择呢?

在选择全埋点的解决方案时,我们需要从效率、兼容性、扩展性等方面进行综合考虑。

  • 效率

全埋点的基本原理,如上所述,其实就是利用某些技术对某些方法(控件被点击时的处理逻辑)进行拦截(或者叫代理)或者“插入”相关埋点代码。比如按钮 Button,如果要给它设置点击处理逻辑,需要设置 android.view.View.OnClickListener,并重写它的 onClick(android.view.View) 方法。如果要实现 AppClickonClick(android.view.View)onClick(android.view.View)AppClick 事件的全埋点技术可以大致分为如下两种方式。

  • 静态代理

所谓静态代理,就是指通过 Gradle Plugin 在应用程序编译期间“插入”代码或者修改代码(.class 文件)。比如 AspectJ、ASM、Javassist、AST 等方案均属于这种方式。这几种方案,我们在后面会一一进行介绍。

这几种方式处理的时机可以参考图 1-1。

Android全埋点解决方案(1):全埋点概述 1

图 1-1 静态代理处理时机
  • 动态代理

所谓动态代理,就是指在代码运行的时候(Runtime)去进行代理。比如我们比较常见的代理 View.OnClickListener、Window.Callback、 View.AccessibilityDelegate 等方案均属于这种方式。这几种方案,我们也会在后面一一进行介绍。

不同的方案,其处理能力和运行效率各不相同,同时对应用程序的侵入程度以及对应用程序的整体性能的影响也各不相同。从总体上来说,静态代理明显优于动态代理,这是因为静态代理的“动作”是在应用程序的编译阶段处理的,不会对应用程序的整体性能有太大的影响,而动态代理的“动作”是在应用程序运行阶段发生的(也即 Runtime),所以会对应用程序的整体性能有一定的影响。

  • 兼容性

随着 Android 生态系统的快速发展,不管是 Android 系统本身,还是与 Android 应用程序开发相关的组件和技术,都在飞速发展和快速迭代,从而也给我们研发全埋点方案带来一定的难度。比如不同的 Android 应用程序可以有不同的开发语言(Java、Kotlin)、不同的 Java 版本(Java7、Java8)、不同的开发 IDE(eclipse、Android Studio),更有不同的开发方式(原生开发、H5、混合开发),使用不同的第三方开发框架(React Native、APICloud、Weex)、不同的 Gradle 版本,以及 Lambda、D8、Instant Run、DataBinding、Fragment 等新技术的出现,都会给全埋点带来很多兼容性方面的问题。

  • 扩展性

随着业务的快速发展和对数据分析需求的不断提高,对使用全埋点进行数据采集,也提出了更高的要求。一方面要求可以全部自动采集(采集的范围),同时又要求能有更精细化的采集控制粒度(采集可以自定义)。比如,如何给某个控件添加自定义属性?如果不想采集某个控件的点击事件应该如何控制?如果不想采集某种控件类型(ImageView)的点击事件又该如何处理?如果某个页面(Activity)上所有控件的点击事件都不想采集又该如何处理等。

任何一种全埋点的技术方案,都有优点和缺点,没有一种普适的完美解决方案。我们只需要针对不同的应用场景,选择最合适的数据采集方案即可。能满足实际数据采集需求的方案,才是最优的方案。

Android全埋点解决方案(1):全埋点概述 1

购书地址 https://item.jd.com/12574672.html?dist=jd

评论

发布