1. 前言

神策分析 Android 埋点 SDK，是一款轻量级用于 Android 端的数据采集埋点 SDK，包含代码埋点、全埋点、点击图和可视化全埋点功能。全埋点通过配合神策 Android 埋点插件来实现，神策分析 Android 埋点插件使用字节码插桩（ASM）的技术实现 Android 端的全埋点（无埋点 / 无码埋点 / 无痕埋点 / 自动埋点）。

2. SDK 目录分层

神策分析 Android 埋点 SDK 自开源以来，从最开始为了满足代码埋点的需求，到后来全埋点、可视化全埋点的支持，SDK 的目录结构不断发生调整以及相关代码的优化。目前开源代码中存在 demo、demoAndroidX、SensorsAnalyticsSDK 三个工程项目，其中：

• /sa-sdk-android/demo ：简单的测试工程
• /sa-sdk-android/demoAndroidX ：基于 AndroidX 库的测试工程
• /sa-sdk-android/SensorsAnalyticsSDK： 神策分析 SDK 工程项目

下面将以最新的 SDK 版本 v3.2.10 为基础介绍 SensorsAnalyticsSDK 的目录分层。

• /src/androidTest：单元测试代码
• /src/main/assets：用于运营商映射配置表
• /src/main/java：SDK 核心代码
• /src/main/res：SDK 用到的资源文件

3. 数据流程

一条数据从触发采集代码到最终删除的流程图如下所示：

SDK 采集一条数据首先会存入本地 SQLite 数据库，判断是否符合数据上报策略，如果符合则上报数据，若上报成功则删除已上报的数据，失败则不删除；如果不符合发送策略，则数据不上传、不删除。未上报的本地数据会在下一条数据采集时再次触发该流程上报数据或者 APP 进入后台时触发上报，以此循环。

4. 架构详解

4.1 简介

如上所述，神策分析 Android SDK 是一款轻量级用于 Android 端的数据采集埋点 SDK。而数据采集是构建数据平台的核心要素，数据采集是否完整，采集的数据是否准确，采集是否及时，采集的数据能否关联打通，都直接影响整个数据平台的应用效果。因此，神策分析 Android SDK 采用了良好的架构来保证数据的采集。

4.2 架构图

神策分析 Android SDK 总体架构图如下所示：

4.3 架构详解

4.3.1 配置模块

SDK 初始化配置模块中，不仅支持本地参数初始化配置，同时可支持后台远程配置初始化参数。下面将介绍 SDK 初始化配置及远程配置策略。

1.  SDK 初始化配置

在引入神策分析 Android SDK 之后，进行 SDK 的初始化时通过传入 SAConfigOptions 进行 SDK 的相关配置。SAConfigOptions 提供默认配置项，无特殊需求客户可以直接使用默认值进行初始化 SDK。涉及的文件：

• AbstractSAConfigOptions
• SAConfigOptions

示例：

2. SDK 远程配置

远程配置通过访问对应的数据接收地址下的 config 接口，得到 disableDebugMode、disableSDK 和 autoTrackMode 这三个配置项的值，来控制相应的功能。初始化 SDK 时可配置 SAConfigOptions 中的 mDisableRandomTimeRequestRemoteConfig 参数，该参数控制是否禁用随机时间请求远程配置，该配置目的是通过设置可分散降低 SDK 远程配置请求的频次。如果该值设置为 true，则每次 APP 启动后都会访问远程配置接口获取远程配置，如果开启随机时间请求远程配置后，可设置远程配置请求最小间隔时长 mMinRequestInterval (单位为小时，默认值 24)、远程配置请求最大间隔时长 mMaxRequestInterval（单位为小时，默认值48），SDK 根据设定的时间按照一定规则判断是否满足请求远程配置条件，如果满足条件则触发远程配置请求，若不满足则不请求。请求失败后，会自动最多重试3次。请求成功后更新配置，生效配置。具体时间约束规则，可参考 Android SDK 源码中 SensorsDataUtils 类中 isRequestValid 方法。远程配置请求流程如下图所示：

下面分别介绍下这三个配置项的取值含义：

1.disableDebugMode（目前已经废弃）

• true: 代表关闭 debugMode
• false: 代表不做处理
• 默认值为0，无法通过这种方式开启 debugMode。

2.disableSDK

• true：关闭 SDK
• false：开启 SDK
• 默认值为 false。

3.autoTrackMode

• -1: 代表不做任何处理
• 0：代表关闭全埋点的所有事件
• 默认值：-1

如果要开启全埋点中的部分事件，需要用下面的几个值进行组合：

• $AppStart：1
• $AppEnd：2
• $AppClick：4
• $AppViewScreen：8

比如，我想开启 $AppStart 和 $AppClick 事件，那 autoTrackMode 的值就是 5，即：1 + 4 = 5

4.3.2 数据采集模块

数据采集模块是核心模块，主要负责准确、完整地通过埋点来采集数据。数据采集模块主要提供了下面几个功能：

• 代码埋点：在 SDK 初始化之后，对需要采集的事件，调用 track 接口方法埋点采集事件。
• 全埋点：无需开发工程师写代码或者写少量的代码，即可预先自动收集用户的所有或者绝大部分的行为数据。
• 点击图：应用一种特殊高亮的颜色形式，显示页面或页面组区域中不同元素被点击的次数和占比。
• 可视化全埋点：通过可视化的方式，对界面上标识的可埋点元素创建新的埋点，标识显示名或事件名，对已埋点元素可修改显示名。
• 预制属性：埋点 SDK 自动采集的一些任何用户触发的任何事件都需要携带一些最基本的属性(信息)（比如操作系统类型、操作系统版本号、运营商信息、应用程序版本号、设备厂商等）

4.3.3 数据存储模块

为了最大限度的保证事件数据的准确性和及时性，会要求数据采集 SDK 尽快将事件数据同步到服务端。但在某些情况下，例如用户处于断网环境，或者根据实际需求（对用户体验要求比较高的情况）会要求只有在 Wi-Fi 环境中才会同步数据，可能会导致事件数据无法同步或者同步失败。因此，数据采集 SDK 一般采取的策略是：先把事件数据缓存在本地，待符合一定的策略之后，再去同步数据。

在 Android 应用程序中，使用 SQLite 数据库进行埋点事件的存储。

4.3.4 网络模块

在数据存储模块中，介绍了如何把事件数据存储到客户端本地。如果事件数据一直缓存在本地，是没有意义的，我们还需要把数据同步到服务端，然后再经过服务端的存储、抽取、分析和展现，才能充分发挥数据的价值。因此，网络模块主要负责如何把缓存在本地的事件数据同步给服务端。

在 Android 开发中，常见的网络请求框架有：OkHttp、Volley 等。但是对于 SDK 来说，一般的原则是不依赖第三方的库，所以这里我们通过简单封装 HttpURLConnection 类进行网络请求的发送。这里会涉及到数据的网络发送策略，网络策略一方面是为了降低用户使用数据采集 SDK 的难度和成本，另一方面更是为了确保数据的正确性、完整性和及时性。

在这里，我们以最常用的三种数据同步策略为例来介绍：

• 策略一：客户端本地存储的数据超过一定条数时同步数据（默认 100 条）
• 策略二：客户端与上次发送的时间间隔大于预设的发送时间间隔 flushInterval （默认 15 秒）时同步数据
• 策略三：客户端 APP 应用程序进入后台时为了最大限度的保证数据的完整性，尽可能同步本地缓存的所有数据

上述三种策略是自动同步数据策略，三种策略为“或”的关系，当满足其中一个策略 SDK 就会上报数据。如果需要手动触发数据同步，可以直接调用 flush() 方法同步数据。

4.3.5 辅助工具

神策分析 Android SDK 提供了许多埋点相关的工具类，这些辅助工具可以帮助埋点的实现。例如 AopUtil 提供了获取控件内容、获取页面标题内容，获取组件显示的文本内容、获取控件位置等等方法；SensorsDataUtils 工具类获取运营商信息、获取UA、合并 JSON 、检测 Android Permission 等等方法，关于这些辅助工具的功能和实现就不逐一赘述了，具体可以参考 SDK 的源码。

4.3.6 日志服务

扫码打开调试模式后，SDK 同时自动开启日志输出功能，也可在测试阶段通过 enableLog 接口打开 SDK 日志输出功能。
SDK 日志输出开启后，在 IDE Logcat 日志控制台中筛选 SA. 关键词进行日志筛选。

• 埋点事件触发成功时，SDK 会输出 【track event】 开头的事件数据；
• 事件数据上报成功时，SDK 会输出 【valid message】字段开头的事件数据；
• 事件数据上报失败时，SDK 会输出 【invalid message】 字段开头的事件数据并输出错误原因。

日志示例：

5. 总结

随着业务不断地发展以及 Android 技术的不断更新，技术架构是一个持续更新的过程，以适应业务的不断的发展。