Android 基于开源Countly的App统计平台开发 [1] 结构分析

当前提到APP统计，友盟无疑是做得最好的一家，同样类型的公司有talkingData，CNZZ（参考 app统计工具简单介绍），此外百度，AVOS等也提供了类似的服务，但是有的时候公司不愿意APP相关数据外漏，希望对于一些日志数据进行自行处理，就需要自己搭建统计平台。

Countly是国外比价有名的一款开源统计平台，Countly的历史和相关信息参考网页 Countly如是说，其包括一个node.js的server，以及Android，IOS，JS，WP和Unity的客户端SDK，并且是以实时的方式进行统计。

countly平台的简单使用可参考博客：http://blog.csdn.net/changemyself/article/details/12653151

由于我们要做的相对简单，不需要复杂的功能，因此我没有采用Countly自带的server，而是自己写了一个统计脚本（主要是没有设备去配置node.js和mongoDB,而且部分数据得和另外一个系统对接），对于数据进行入库和每日的统计。

---

基于Countly的统计平台结构

整体结构

 Countly Service Management（客户端）：
使框架拥有通用性，不同APP可以使用同一个SDK，Countly Service Management提供一个Android后台Service管理队列，给每个APP和其启动的Service通过Tag对应上，负责顺序唤醒当前APP对应的Service，并通过使用频率调整管理队列。
 Countly Framework（客户端）:
APP统计数据的处理核心，Countly提供一个全局实例和APP里的初始化方法，同时维护EventQueue和ConnectionQueue两个事件队列。其中EventQueue维护自定义（如激活，埋点，出错）事件的记录和发送，ConnectionQueue维护APP的打开，关闭，停留时间计算等常规数据记录。
Countly通过Timer将两个Queue中的数据定时发往Server。EventQueue和ConnectionQueue同时带有本地存储功能（无需SD卡），在网络发送成功时清除本地SharedPreference记录数据。
上传时使用Post方法，每次批量上传全部记录。如果上传不成功（网络异常），则本地缓存记录数据超过一定数量（100）后，会清除较早的一半数据。
 Countly Web Interface（Server端）:
测试阶段用Python搭建了简单服务器，处理Post请求。postHandler将请求数据传递给解析脚本，将数据转义、分割并解析成python dict，然后区分不同类型的数据，将数据插入轻云中的Mysql中。

客户端SDK结构

客户端数据记录类型

由客户端发往服务器的主要有4中记录类型，他们都是转码之后打包成json格式，混在一起发送到服务器的。

---

类型	说明	类型id
BeginSession	登入APP	100
UpdateSession	更新登入的时间	101
EndSession	登出APP	102
Events	自定义事件	103

其中，beginSession表示一个打开APP的动作，仅记录一个开始时间，之后每隔一个时间间隔（例如30秒），则会再生成一条updateSession，表示持续时间增加多少，这样可以较精确地实时指导用户在线情况和实际使用时间，当用户退出前会产生一个endSession，表示一个用户ID从BeginSession到UpdateSession，到EndSession生命周期结束了，服务器可以做这一个周期的统计工作了。
Event则是自己定义的，原则上打开APP，不如不出发代码总发送事件的部分，是只有前三种生命周期记录的。Event就是让你在代码中为你要统计的各种事件埋点的。

这些记录在Countly SDK中的格式如下，下篇文章会就源码实现来仔细记录。

---

BeginSession信息描述
Json样例：
{"_locale": "zh_CN", "_os": "Android", "timestamp": "1405421176", "app_key": "XIAOMAI_4S5R7C2D", "_os_version": "4.1.2", "metrics": "1", "sdk_version": "2.0", "_app_version": "1.2.1", "_resolution": "480x854", "_density": "HDPI", "begin_session": "1", "_channel": "1001", "_carrier": "China+Mobile", "_device": "MI+1S", "device_id": "2141724f81a367bc"}

名称	值样例	说明
timestamp	1405421227	事件时间戳
app_key	XIAOMAI_4S5R7C2D	在客户端和服务器约定的appkey
device_id	2141724f81a367bc	设备udid，可唯一识别设备
begin_session	1	表示该记录类型
metrics	1	表示该记录带metrics信息

---

Metrics信息
带有metrics的所有信息

字段名称	值样例	说明
_locale	zh_CN	区域信息
_os	Android	系统类型
_os_version	4.1.2	系统版本号
sdk_version	2.0	统计sdk版本号
_app_version	1.2.1	App版本号
_resolution	480x854	屏幕分辨率
_density	HDPI	屏幕分辨度
_channel	1001	App来源渠道码
_carrier	China+Mobile	运营商
_device	MI+1S	手机类型（品牌）

---

UpdateSession信息描述
Json样例：{"timestamp": "1405421327", "session_duration": "20", "app_key": "XIAOMAI_4S5R7C2D", "device_id": "2141724f81a367bc"}

名称	值样例	说明
timestamp	1405421227	事件时间戳
app_key	XIAOMAI_4S5R7C2D	在客户端和服务器约定的appkey
device_id	2141724f81a367bc	设备udid，可唯一识别设备
session_duration	13	停留时间增量（秒）

---

EndSession信息描述
Json样例：{"timestamp": "1405499182", "session_duration": "1", "end_session": "1", "app_key": "XIAOMAI_4S5R7C2D", "device_id": "2141724f81a367bc"}

名称	值样例	说明
timestamp	1405421227	事件时间戳
app_key	XIAOMAI_4S5R7C2D	在客户端和服务器约定的appkey
device_id	2141724f81a367bc	设备udid，可唯一识别设备
end_session	1	标识该记录为登出
session_duration	13	停留时间增量（秒）

---

Events信息描述
Json样例：{"timestamp": "1405421187", "events": [{"count": 1, "timestamp": 1405421176, "sum": 0, "key": "open_acivity"}], "app_key": "XIAOMAI_4S5R7C2D", "device_id": "2141724f81a367bc"}
发送来的一条记录中可能有多条event，需要进行分离

名称	值样例	说明
timestamp	1405421227	记录时间戳
app_key	XIAOMAI_4S5R7C2D	在客户端和服务器约定的appkey
device_id	2141724f81a367bc	设备udid，可唯一识别设备
Events	1	标识该记录为自定义事件
key	open_acivity	该事件的标识
count	1	事件出现次数
sum	10	一个累加值，可自行使用
timestamp	1405421176	事件发生的时间戳

好了，以上介绍了我开发的基于Countly的统计的主要架构和其记录的表示含义。下一篇将根据源码分析Countly Android SDK的运行机制。

---

文章为原创，转载请注明出处。