文章已发布微信公众号：知识点梳理：聊聊iOSSDK数据采集那点事儿
1. 背景
随着互联网的发展，我们无时无刻不在主动或被动接收着大量的信息，早晚上下班坐公交、挤地铁，行色匆匆、各行各业的精英分子都不忘打开手机浏览新闻动态，追看喜爱的电影、电视剧，网上购物，浏览各种订阅号，打打小游戏等等，当然还有些同学阅读纸质书籍或使用kindle阅读。
通过上面的观察可以发现，移动电子设备占用了我们大量的时间，不论购物、吃饭、出行、租赁等等，而移动设备主要通过App来操作，比如购物会使用淘宝、京东等，出行会使用滴滴、摩拜，美食会使用饿了么、美团等。
那么为了更好为自己的用户提供更优质、更加人性化的服务，企业或公司往往都会采集用户的一些信息，以便以后简化用户操作或方便营销等。比如记录登录用户经常购买某个品牌的化妆品，购买价格通常在300-500元区间，那么企业可能会将该品牌在这个区间的化妆品放到App最明显的位置；还比如公司做活动，但由于活动页面比较深，导致用户很难发现，因此触发次数特别少，没有起到营销效果，那么企业可能就会根据采集回的数据信息进行实时调整，将该模块放到明显位置、或减少操作路径等等。
SDK数据采集的作用就在于此，既能方便用户操作，又能起到帮助企业自我调整的作用。
2. SDK 具备的“素质”
上图为一款SDK本身及所采集数据需要具备的一些基本“素质”，下面将对每个模块逐一介绍。
2.1 SDK 本身具备的“素质”
2.1.1 稳定性
作为App重要的组成部分，稳定性是SDK的重中之重，因为一款SDK可能会被多个App使用，而每个App又有N个用户在使用，如果某行代码出现crash，后果将可想而知。
对于可能出现crash的代码适当添加try catch进行异常捕获，对于常用的NSMutableDictionary/NSMutableArray等控件在插入或访问时经常出现数组越界、nil数据插入等，可使用Category添加自定义安全方法，也可以在Category中使用方法交换，先调用自定义方法进行数据校验，校验无误再执行系统方法。
-
try catch异常捕获
image.png Category方法交换
2.1.2 安全性
安全性目前主要使用代码混淆方式，为防止他人通过class-dump(下载后将文件复制到/usr/local/bin目录下)反编译后，根据源代码中的方法名就可以推断出其功能。
- 特定标识方法混淆
对工程中所有方法使用特定标识开头，将所有带有标识的方法都使用随机生成字符串方式替换。具体使用方式可参考：HSKConfuse
运行程序后，找到工程 Products -> Show in Finder -->显示包内容 找到工程执行文件，使用以下命令反编译文件：
class-dump -H 执行文件路径 -o 导出的.h文件存放文件夹路径
可发现反编译后的.h文件的方法名称已被混淆。
2.1.3 易用性
易用性主要是指用户在使用时只需要部分代码即可完成相应功能。
易观SDK对外提供了页面自动跟踪功能、页面自定义采集、事件采集、通用属性配置、用户属性、消息推送跟踪及Hybrid混合页面等模块化的接口，用户可根据需要自行选择，并且接口均为类方法，可以简便的调用。同时还提供了React Native、Weex、PhoneGap三个跨平台移动应用开发框架的接口文件，开发者无需再次进行封装。
2.1.4 扩展性
对于程序来讲扩展性无疑非常重要，不能因某个小小需求的改变而导致代码重构，不仅浪费人力、物力，更重要的浪费了时间，而时间可能导致商机的流失。
在易观SDK初始化方法中使用了配置类，可以方便的扩展未知的配置信息：
为了方便用户对自定义信息的扩展，部分接口也预留了自定义信息，如购买商品时后期可能需要分析品牌、价格、购买时间段等，那么开发者可通过track:properties:方法将数据放到properties字典中。
2.2 数据应具备的“素质”
2.2.1 准确性
数据采集的准确性是为后续数据的处理提供基础保障。
其中可能需要用户参与，传入明确需要计算或统计的指标以对其进行精准分析；为保证数据及时上传到服务器，数据上传至少触发一次，若发生网络中断、服务器无响应等特殊情况，SDK需要建立起重试机制，保证数据准确送达；由于数据产生先后顺序会影响前端的展现和分析，因此在SDK中我们会使用数据处理串行队列及网络上传队列，确保数据先触发先到达。
2.2.2 安全性
数据安全性主要体现在存储和网络传输过程中。
SDK采集的数据将首先存储到本地数据库中，为了防止用户篡改数据，需要对数据进行保护；为了增加数据的安全性，在数据上传时需要对数据进行加密处理，常用的加密方式有：Base64加密、MD5加密、AES加密、RSA加密等。目前易观SDK使用前三种结合的方式对数据进行了加密，每次上传的数据都会根据一定的算法产生不同的加密key，以保证数据的安全性。
2.2.3 合法性
作为数据采集模块，每天都会有大量数据上传服务端，其中必然有部分数据是不合法的，比如某些页面无网络状态下无法获取商品信息，由于疏忽导致购买按钮可能触发，但数据信息无法获取，导致调用SDK的数据为无效数据，这些数据可以称为“垃圾数据”，不仅对后期分析无用，还会增加清洗数据的时间，浪费了磁盘空间。
因此SDK中单独抽出校验层，对数据进行合法性校验。如：SDK本身预定义一部分保留字段，$platform(iOS/Android/java等)、$lib_version(SDK版本号)、$debug(debug/release)等，为防止用户覆盖，也是为了后期数据分析时更明确、更具有针对性，对传入参数进行校验；常用的字符串长度校验，防止输入字符串过长；自定义属性多层嵌套校验，层次嵌套过多可能导致分析效率下降，增加复杂性；属性总个数校验等等。
2.2.4 可控性
作为SDK更新频率可能没有App那么高，所以对SDK需要一定的策略控制。我们在SDK中加入了策略控制模块，优先级从高到低依次为：服务器策略>用户设置策略>默认策略。
对正在使用的SDK主要采取服务器控制策略，比如：服务器端可以控制数据上传累积条数及数据上传间隔时间；延迟一段时间后SDK再进行数据上传；更改数据上传服务器地址；数据上传失败后的重试次数以及达到最大次数后下次数据上传的时间等等，都可进行灵活控制。
3. 总结
由于SDK模块很少涉及UI部分，所以基本结构如下如所示：