智能采集组合文章( 友盟+：移动数据采集特点与PC端不同的演进)

　　智能采集组合文章(

友盟+：移动数据采集特点与PC端不同的演进)

　　本文由【友盟+】技术专家马巍源、张永峰共同撰稿

　　随着移动互联网和大数据技术的发展，以及智能手机的普及，几乎所有的工作、学习、生活场景都离不开手机。手机APP取代了传统的生活方式，让人们体验到便捷高效的服务，当然也承载着海量丰富的信息。从这些APP中采集

数据，集中清理和分析数据，可以将这些海量数据转化为宝贵的数据能量。数据采集​​是数据能源发展的第一步。如何采集数据，什么样的技术架构可以支持海量数据的采集、筛选和传输，是本文需要讨论的问题。

　　移动数据采集功能

　　与PC端不同，对于手机、iPad、智能手表、电视盒等移动设备，我们接触它们的载体是APP。Native SDK 需要大量的开发资源来支持多语言支持。跨平台应用开发正在逐渐成为一种趋势，但是各个框架中JS SDK的实现也不尽相同。因此，目前的移动采集SDK在支持多平台、多语言方面比较难支持。

　　更难的是安卓设备的机型适配。由于Android系统的开源特性，各家厂商为了在各机型上都有更好的用户体验，都进行了针对性的ROM改进。尤其是近几年，Android 在虚拟机和编译器上都做了很大的改变。这给模型适配带来了更大的困难。为了不给APP卡死、死机、黑屏、死机、加载速度慢等不良体验，还需要支持开发者的各种异常接口调用，并且需要有很强的容错能力。

　　移动流量持续增长。【友盟+】移动端应用超过135万款，覆盖全球超过14亿的日活跃移动设备，每天处理280亿条数据。测试我们采集SDK和服务器的承载能力，【友盟+】在移动采集技术上不断更新迭代，连续多年保持市场覆盖率领先。

　　SDK与服务端通信协议演进

　　我们最初的SDK设计思路简单高效，所以SDK端没有数据预处理的逻辑，甚至缓存策略也很简单。所有实时生成的数据都会实时上报给服务器。但是随着移动端流量的暴涨，这种高并发的请求给服务器带来了很大的压力。下图是版本0的通讯协议。

　　所以考虑通过控制发送频率来降低​​并发。开发者可以根据业务需求采用不同的发送策略：开始发送、间隔发送、退出发送，并且可以在【友盟+】平台上随时更改。虽然有效地减轻了服务器端的压力，但也带来了另一个问题。单条数据的大小可能会超过request-body的上限，导致请求超时。而流动压力也是一个急需解决的问题。因此，在2.0 版本中，我们压缩了数据并添加了安全机制。服务器增加了数据预处理的逻辑，完善了数据的校验。

　　只能在一个方向上通信的协议是不灵活的。很多时候我们需要控制SDK的行为，比如修改发送策略，屏蔽错误的数据，或者发现数据被污染而决定丢弃。需要通知这些运行中的服务器。SDK，以及没有长连接怎么办。在3.0版本中，我们设计了http请求响应的信息包体的控制语义。SDK除了从响应中获取服务器的接收状态外，还可以获取服务器的控制指令，以达到服务器的预期效果。

　　如果每个Log都必须等待解析服务器返回的控制信息，显然服务器对数据处理的及时性和并发处理能力会大打折扣，部分业务数据实际上并不需要解析和执行这些控制信息。因此，我们对业务数据进行了精细的分解。一些业务数据使用双向通信协议，可以解析和执行控制命令。其余的业务数据是与状态无关的数据，仍然使用单向通信协议。

　　那么在未来，控制协议和服务传输协议其实可以分开，各自使用不同的传输频率，但是可以保证所有的服务数据都由服务器的指令控制。

　　SDK技术架构分析

　　移动数据采集SDK架构主要由三部分组成：用户界面、业务模块、控制模块。

　　我们可以从几个场景的时序图分析这些模块的工作原理。

　　APP启动

　　当用户启动App时，实际上触发了开发者调用的初始化接口。Service Moudle 和 Control Moudle 会异步执行一些初始化操作：创建 Session、加载设备信息等。

　　APP在前台运行

　　当用户在APP中点击或滑动屏幕时，会触发开发者在APP中预设埋点事件。

　　Servie Moudle 会生成相应的事件数据，调用 Control Moudle 接口检查发送策略和安全策略，然后 Servie Moudle 将事件数据放入缓存队列中进行发送。

　　APP退出

　　无论用户退出APP后，SDK都会在短时间内完成多项操作：结束会话，持久保存数据，直接在iOS中完成数据打包、打包、上报等工作。

　　SDK组件化架构

　　我们提供越来越多的产品功能和越来越复杂的业务场景。为了满足各种解决方案的需求，SDK需要为每个业务场景维护多个分支、多个版本，浪费开发资源，并且版本迭代周期被拉长。为了解决这个问题，我们必须设计一个灵活的架构，让每个产品功能成为一个可以自由组合和拆卸的组件。

　　组件化将统一约定包和公共API的文件规范。针对当前【友盟+】业务需求，建立标准的SDK产品公共库（如：网络、序列化、配置、缓存等），组件结构分为两部分，Common将作为独立的library 包，和 Component 中的每个产品都作为一个独立的库。

　　其结构如下：

　　灵活的业务组合，适用更多场景

　　组件划分的粒度可以根据业务需要而定。我们的设计是根据产品或业务来划分组件。一个产品可能收录

许*敏*感*词*。例如，统计产品包括事件数据采集、错误数据采集、A/B Test等功能。推送产品包括消息推送和应用内消息。在某些场景下，一些开发人员可能只使用其中的一部分。以函数为例，只使用错误分析函数和Push消息推送，然后将组件粒度细化到功能层，会更加灵活，可以满足更多场景的需求，体积的减小对于开发人员有吸引力。

　　业务逻辑解耦，代码更健壮

　　组件化架构改变了以往业务逻辑与基础功能的深度耦合。业务开发者可以专注于业务逻辑的实现，而无需考虑网络通信、消息队列管理、设备信息采集等基本功能的实现。业务逻辑代码的任何改动都不会影响基本的功能逻辑，增强了代码的健壮性，大大缩短了回归测试周期。

　　【友盟+】数据采集技术将不断适应业务场景的变化。未来，我们的目标是让我们的SDK更智能、更安全，让企业和开发者的整合更简单、数据更准确。