HttpURLConnection 的具体使用步骤如图 3-1 所示：
图 3-1 HttpURLConnection 使用流程
由于涉及到网络访问，需要在 Manifest 文件中添加网络访问权限：
以上是对 HttpURLConnection 的原理以及具体使用的介绍，下面对 SDK 中网络请求的具体实现进行介绍。
3.2 具体实现
3.2.1 网络相关配置
SDK 可以对数据上报进行一系列的配置，开发者可根据 App 的特点设置相应的配置，从而达到最高效的数据上报效果。SDK 的相关配置在初始化时完成，可以配置的参数如下：
mServerUrl：数据上报地址，采集的本地数据将上报到该地址； mFlushInterval：两次数据发送的最小时间间隔（单位毫秒），默认值为 15； mFlushBulkSize：本地缓存数据的最大条目数，当本地缓存条数达到 mFlushBulkSize 则会上报数据， 默认值为 100； mNetworkTypePolicy：网络上传策略，可配置为 3G、4G、5G、WIFI 等网络类型进行上报。
3.2.2 工作线程封装
SDK 数据上报是在子线程中完成的，当采集的数据满足上报策略时触发数据异步上报，上传任务的管理调度在 Worker 类中完成。在 Worker 初始化时，创建 HandlerThread 实例，HandlerThread 本质上是一个线程类，它继承自 Thread 类。HandlerThread 内有自己的 Looper 对象，可以进行 Looper 循环。通过获取 HandlerThread 中 Looper 对象传递给 Handler 对象，可以在 handleMessage 方法中执行异步任务。
AnalyticsMessageHandler 继承自 Handler，在 handleMessage 中接收 Worker 发送的消息并执行数据上报或删除。
在 HandlerThread 中的 Looper 对象，传递给 AnalyticsMessageHandler 对象，在 handleMessage 方法中实现异步网络任务。AnalyticsMessageHandler 代码实现如下：
private class AnalyticsMessageHandler extends Handler {
…
Worker() {
final HandlerThread thread =
new HandlerThread(“com.sensorsdata.analytics.android.sdk.AnalyticsMessages.Worker”,
Thread.MIN_PRIORITY);
thread.start();
mHandler = new AnalyticsMessageHandler(thread.getLooper());
}
@Override
public void handleMessage(Message msg) {
…
if (msg.what == FLUSH_QUEUE) {
sendData();
} else if (msg.what == DELETE_ALL) {
try {
mDbAdapter.deleteAllEvents();
} catch (Exception e) {
com.sensorsdata.analytics.android.sdk.SALog.printStackTrace(e);
}
} else {
SALog.i(TAG, "Unexpected message received by SensorsData worker: " + msg);
}
…
}
…
}
Worker 中封装了两个方法 runMessage 和 runMessageOnce ：
-
runMessage 方法用于执行数据实时上报；
-
runMessageOnce 方法用于延时执行上报任务。
Handler 中的 sendMessageDelayed() 方法可以实现数据的延时上报。
3.2.3 数据上报策略
在 SDK 数据存储解析中介绍了数据的采集与存储策略：采集的数据会先保存到本地，符合上报策略才会上报。
- 客户端本地存储的数据超过一定条数时（默认 100 条）会上报数据
在 SDK 初始化时，可配置 mFlushBulkSize 参数来控制条数限制。如果不进行设置，则默认为 100 条。如果用户设置的条数小于 50 条，则默认为 50 条。SDK 采集的数据较多，如果设置上报条数太小会导致频繁的网络请求（上报数据），从而影响性能。如果用户设置上报条数过多，会导致一次上传的数据过大，这样不仅会导致上传时间长还很可能会出现上传失败的情况。如果没有特殊要求，可直接使用默认值。
- 数据采集后间隔一定时间（默认 15 秒）会上报数据
在 SDK 初始化时，可配置 mFlushInterval 参数来控制时间间隔限制。如果不满足上报条数限制时，SDK 会执行一个延时任务，延时 mFlushInterval 设定的时间后执行。
除了上文中提到的策略外，还会在触发以下事件时，会以阻塞的形式将本地缓存的数据全部上报：
-
在采集 $AppEnd 事件时上报数据；
-
捕获 App 异常时上报数据；
-
在激活事件触发后上报数据。
3.2.4 数据安全
3.2.4.1 数据加密
SDK 上报的数据涉及到用户隐私，保护用户隐私是开发者应尽的责任和义务。SDK 提供数据加密策略对上报的数据进行加密，以防止用户信息在传输过程中发生泄漏。
SDK 的数据加密策略是将采集到的数据缓存到本地，然后采用 RSA + AES 加密算法进行加密，主要实现流程如下：
-
App 内置 RSA 公钥及密钥（假设为 A），或者从服务端获取（从服务端获取方便更换公钥，缺点是使用更多的传输带宽、增加初始化的成本；另外服务端同时使用多个密钥对，解密时需要选取对应私钥，若密钥过多可能会影响导入性能）；
-
随机生成长度为 128 位的对称加密 AES 对称秘钥（假设为 B），使用 RSA 公钥 A 对 AES 对称密钥 B 进行加密；
-
用户触发事件产生 JSON 数据，使用 AES 对称秘钥 B 对采集的事件（即整条 JSON 数据）进行加密产生密文数据；
-
按照与后台约定的格式拼装数据存储到本地。
拼装后的格式如下：
{
“pkv”: RSA 公钥对应的秘钥编号,
“ekey”: “使用 RSA 公钥 A 对 AES 对称密钥 B 加密产生的密文”,
“payload”: “使用 AES 对称秘钥 B 对采集的事件即整条 JSON 数据进行加密产生密文数据”
}
上报数据时，会从磁盘读取数据。根据加密方案，“ekey” 字段会很长（与 RSA 密钥长度有关），每条带一个“ekey” 冗余较多。因此，在上报之前会进行数据合并，对于 “ekey” 相同的数据，合并到一个数组中。合并后发送到服务端的数据格式如下：
[{
“pkv”: RSA 公钥对应的秘钥编号1,
“ekey”: “使用 RSA 公钥 A 对 AES 对称密钥 B 加密产生的密文”,
“payloads”: [“加密后的事件数据1”，“加密后的事件数据2”]
},{
“pkv”: RSA 公钥对应的秘钥编号2,
“ekey”: “使用 RSA 公钥 A 对 AES 对称密钥 B 加密产生的密文”,
“payloads”: [“加密后的事件数据3”，“加密后的事件数据4”]
}]
最后，服务端使用 “pkv” 对应的私钥解密 “ekey” 字段得到 AES 对称密钥的参数 key，解密 payloads 得到多条消息原文。
3.2.4.2 HTTPS 双向验证
HTTPS 是在 HTTP 上建立的 SSL 加密层，并对传输数据进行加密，是 HTTP 协议的安全版。
在 HTTP 协议中可能存在安全问题，主要包括以下几个方面：
-
传输的数据使用明文，可能被窃取；
-
无法校验数据是否完整；
-
无法确认通信双
方的身份。
使用 HTTPS 协议可以有效地防止这些问题：
-
内容经过加密并生成一个唯一的加密秘钥；
-
能够校验数据是否完整；
-
可以确认通信双方的身份。
SDK 支持 HTTPS 协议网络请求，通过 HTTPS 双向验证保证数据的安全性。
3.2.5 数据上报流程
数据采集时，会创建一个异步任务加入到任务队列中，通过 TrackTaskManagerThread 调度任务顺序执行。在子线程中执行一个任务时，首先采集预置属性信息，其次将预置信息和自定义属性信息封装成神策需要的 JSON 格式，存储到数据库中。
如果当前处于 Debug 模式或者数据库超过最大缓存限制时，会进行上报数据操作；不满足时会进行如下判断：如果触发的事件为 “$SignUp” 或者本地缓存的条数大于设置的 mFlushBulkSize 时会进行上报数据；否则会触发延时上报，在间隔设置的 mFlushInterval 时间上报数据。上报流程如图 3-2 所示：
图 3-2 数据上报流程图
发送数据时，以下情况不会发送数据：
-
用户设置 mEnableNetworkRequest 为 false 不会上报数据，用户可通过 enableNetworkRequest 方法设置是否上报数据；
-
serverURL 为空时不会上报数据；
-
不在主进程时不会上报数据；
-
无网络时不会上报数据；
-
不满足 SDK 设置的上报策略时不会上报数据。
满足上报条件时，SDK 会将本地的数据全部上报。如果一次传输的数据较大，会增加数据上传失败的可能性，同时对性能的影响也比较大。因此，SDK 一次最多读取 50 条数据，对读取的原始事件数据先采用 Gzip 压缩，然后对压缩的内容进行 Base64 编码，保证高效的传输。同时考虑到数据的完整性和安全性，会将原始数据的 hashCode 值传到服务端，用于对数据完整性校验。
数据上报后，根据网络请求状态码判断数据是否上报成功：网络请求状态码在 200 ~ 300 之间时，认为 SDK 上报数据是成功的，会删除本地上报成功的数据。网络请求失败时，本地数据不删除。每次发送都会循环读取本地缓存的数据，直到数据全部上传完成。
四、数据上报校验
==========================================================================
开发者在集成 SDK 开发过程中，需要校验 SDK 是否将数据正常、准确地上报到服务端。SDK 提供了通过查看 Logcat 控制台日志和 Debug 实时查询的方式来校验数据上报的准确性。
4.1Logcat 本地日志校验
通过日志查看数据是否上报成功，首先需要在初始化 SDK 后调用 enableLog(true) 打开 SDK 的日志输出功能。如果相应事件触发，SDK 会自动进行采集并定时发送到神策分析后台。可以通过 Logcat 查看日志进行数据校验， 在 Logcat 中筛选 “SA.” 可查看事件采集上报的相关日志，具体分为以下几种情况：
-
埋点事件触发成功时，输出 “track event” 开头的事件数据；
-
埋点事件触发失败时，输出相应的错误原因；
-
事件数据上报成功时，输出 “valid message” 字段开头的事件数据；
-
事件数据上报失败时，输出 “invalid message” 字段开头的事件数据并输出错误原因。
开发过程中通过日志即可判断数据是否正常上报。
4.2 Debug 实时数据查询
Logcat 中筛选 “SA.” 可查看事件采集上报的相关日志，具体分为以下几种情况：
-
埋点事件触发成功时，输出 “track event” 开头的事件数据；
-
埋点事件触发失败时，输出相应的错误原因；
-
事件数据上报成功时，输出 “valid message” 字段开头的事件数据；
-
事件数据上报失败时，输出 “invalid message” 字段开头的事件数据并输出错误原因。
开发过程中通过日志即可判断数据是否正常上报。
4.2 Debug 实时数据查询
