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的運行機制。

---

文章爲原創，轉載請註明出處。