前言
数据现在已经成为每个公司，每个产品的核心资产。前几天看一篇文章，说阿里巴巴现在可以认为是一家数据公司，为什么很多商家愿意在淘宝平台做生意，因为有各种用户数据。为了拥有用户数据，所以几乎每个APP都会有用户行为埋点，有些用第三方埋点SDK，如TalkingData,友盟，神策等。其实对于小公司用第三方应该就够了，真的不建议开发埋点分析系统，不过对于大型项目而言，会希望更精细化的数据分析，可能第三方数据采集公司就不一定满足需求，因此自研用户行为埋点分析系统就很必要了。我面试过一些APP开发，不少单位都自研了数据分析埋点系统，但是沟通下来，却发现这些所谓的埋点系统还不如完全用第三方，连基本的数据完整行都没法保障。本文就抛砖引玉，介绍一个精简版的用户行为埋点SDK的技术方案，以供后来者参考。
一、埋点上报的流程
直奔主题，不拖泥带水，先关注埋点的数据采集流程，然后再抽丝剥茧，大方向不会出错。
- 获取配置文件
- 埋入行为数据
- 缓存行为数据
- 上报行为数据
- 其他细节处理
二、技术应用
- 支持多线程并发处理打点全过程，避免占用主线程时间，同时确保线程安全
- 支持内存和数据库二级缓存数据，上报更快更精确性能更好
- 支持网络请求上报的压缩和验签机制、（后端可以考虑下防重放）
- 支持数据库版本更新迁移（这个版本或者后期做？，稳定后一般数据结构改动可能性小，早期反而可能改）
- 支持接口请求的版本控制，如根据SDK版本控制不同版本的配置获取。
三、难点
- 数据的准确性要求。获取的公共数据准确不出错。
- 数据的时效性要求和APP性能要求的技术运用。
四、机制策略
1.上报机制
- 没有网络时不上报
- 没有数据时不上报
- 定时上报（可以再调研下根据系统做网络判断时的被动上报方案），服务器下发配置默认60秒
- （根据网络状态，根据不同APP的特性，支持配置灵活调整）
- 退到后台时上报，安卓无法监听退出后台，可以在启动时做一次。
- 先取内存再取数据库最新数据，限制每次上报数量，配置默认20条（根据定时间隔调整）。
- 数据库积压数量超过一定条数如5000条，需要加大单次上传数据的个数。此时采用默认单次最大上报1000条（？）。
- 上报成功后清理成功数据
- 上报失败，继续缓存，下次发
注释：（其实更好的的上报方式，可以考虑不使用定时机制，采取诸如根据系统监听网络状态或runloop等方式，被动上报的机制，这样对APP耗电量的损耗更小，甚至多种方式结合，根据不同的数据时效性要求）
2.缓存机制
- 埋点传入时先内存缓存
- 内存满足一定数量后存储到数据库。配置默认30条（？）
- 数据库升级迁移，数据完整要求。少量数据丢失允许的话，可以根据SDK版本删除旧的数据库，创建新的数据库。
3.获取配置机制
1.APP启动时获取。
2.根据SDK版本配置有更新则更新，没有则不返回。
3.缓存配置
4.更新缓存配置。根据不同需求，有些埋点系统更新配置会比较频繁，可以做到双向通信事实更新。多数埋点系统配置修改较少，只要在APP启动或者退出做一次更新即可。
五、配置文件获取接口的一般定义
一、请求参数：
APPID、SDK版本、系统、sign
二、返回字段：
- 控制内存数据个数mem_count(30)
- 控制定时上报间隔时间interval(60秒)
- 控制正常情况下单次最大上报个数upload_count(20)
- 控制数据库最大缓存数量max_mem_count(5000)
- 控制在数据库满max_mem_count后单次最大上报个数max_upload_count(1000)
- SDK开关 sdkSwitch（目前先做在SDK里，后期可以搞个配置接口单独在外面做）
六、上报数据接口的一般定义。
一、请求参数：
数据结构根据目前后端定义为一个json对象，对象包含公共参数以及埋入数据array。
二、返回数据：
1.成功，删除成功的数据
2.失败，保留失败的数据
三、其他技术
1.为防止串改和撞击，可以对数据验签
2.请求数据支持gzip压缩
七、常规事件SDK收集
1.冷热启动
2.热退出（安卓可能无法监听，iOS可以）
3.冷退出（iOS部分情况可以监听到，安卓好像无法监听，需要白辰确认下）。
注释：这些是否放在SDK收集可以看情况，有可能某天会在这些事件里增加一些特定APP的数据进去，SDK就不通用了~~
八、Debug模式支持
1.debug模式支持打印日志
2.debug模式支持数据校验
3.debug模式支持debug模式下的弹窗
总结：
埋点系统其实核心的东西就这么多，但是也是最基本的要求。然后可以在细节处理上更好，就可以成立类似友盟、TalkingData、神策这样优秀的数据埋点采集分析公司了。有兴趣的深入的可以在github找找神策的开源的埋点SDK。
