数据上报那些事

1. 前言

神策分析是依托于数据进行的，数据是分析的根基。因此，数据上报的时效性是至关重要的。那么 iOS SDK（后面简称 SDK）是如何保证数据上报的时效性呢？

接下来，我们就围绕这个问题来看看 SDK 究竟做了什么。

2. 上报策略

直观来说，要解决数据上报的时效性问题似乎很简单：实时上报（当触发事件后立刻上报到服务端）不就可以保证时效性了吗？但是，事实并非如此简单。

不同于服务端，移动设备上的资源是非常有限的，采取实时上报的方式势必会造成 App 整体性能的下降，如何平衡性能与数据上报的时效性是 SDK 需要面临的一个挑战。

目前 SDK 中使用的数据上报策略是事件触发后不立即上报，而是先将事件缓存在本地，然后满足一定的条件再进行上报。

SDK 每次触发事件时会检查如下条件，用于判断是否向服务端上报数据：

1. 当前网络是否符合发送策略 flushNetworkPolicy（默认 3G、4G、5G、WiFi）；
2. 与上次发送的时间间隔是否大于指定的时间间隔 flushInterval（默认 15 秒）； 
3. 本地缓存的事件条数是否大于最大缓存事件数 flushBulkSize（默认 100 条）。 

只有 1、2 或者 1、3 满足时，SDK 才会发送数据。当然，为了满足不同的需求，可以通过修改 flushNetworkPolicy、flushInterval、flushBulkSize 的值来控制事件上报。

SDK 的数据上报流程如图 2-1 所示：

 

图 2-1 SDK 的数据上报流程图

3. 时效性优化

按照我们指定的上报策略进行数据上报，对于一般的自定义埋点事件及全埋点事件是可以满足时效性的要求。但是，这种上报策略存在一些弊端：

1. App 退到后台或终止后如果不再打开，最后未上报的数据不会及时地上报到神策分析平台；
2. 无法满足一些事件的实时上报需求。

为了解决这两个问题，SDK 进行了如下的优化。

3.1. App 进入后台时上报

3.1.1. iOS 后台机制

在了解 App 进入后台时如何上报之前，我们先来看下 iOS 的后台机制。iOS 系统中，App 在执行时可能会出现 Active、Inactive、Background、Not Running、Suspended 这几种状态[1]。当我们的 App 由前台进入到后台时，会有 5 秒的时间执行任务，在此后 App 将被系统置为挂起状态（Suspended）。此时 App 运行在后台，但无法执行代码。

对于大多数 App 来说，5 秒的时间足够执行一些进入后台的关键任务。考虑一些 App 需要更多后台时间来处理任务，iOS 提供了用于延长应用后台执行时间[2] 的接口，可以申请额外的后台运行时间以保证任务执行完成。经过测试，在 iOS 12 及以上的系统最多可以申请 30 秒的运行时间。

3.1.2. 后台数据上报

我们已经知道 App 在进入后台时会在很短的时间内被系统挂起，由于数据上报时网络环境的不确定性，很难保证 S