移動採集技術的演變

本文由 【友盟+】 技術專家馬巍源、張永峰共同撰稿

隨著移動互聯網和大數據技術的發展，智能手機的普及，幾乎所有工作、學習、生活中的所有場景都離不開手機，手機APP已經取代了傳統的生活方式，讓人們可以體驗便捷高效的服務，當然它也承載著大量豐富的信息，收集這些APP的數據，集中對數據進行清洗和分析，就能將這些海量數據變為有價值的數據能源。數據採集是開發數據能源的第一步，如何採集數據，什麼樣的技術架構能夠支持海量數據的採集、甄別和傳輸，這是本文需要討論的問題。

移動數據採集特點

與PC端不同，對於手機、iPad、智能手錶、電視盒子等移動設備，我們觸達它們的載體就是APP。原生SDK在多語言上支持上需要投入很多的開發資源，跨平台應用開發漸成趨勢，但JS SDK在各框架上的實現也各有差異，因此，目前移動採集SDK在對多平台、多語言的支持上難度較大。

難度更大的是對Android設備的機型適配問題。由於Android系統的開源特性，各廠商為了在各家機型上有更好的用戶體驗，都有針對性的做了ROM改良，尤其近些年Android在虛擬機、編譯器上的改動較大，這就給機型適配帶來更大的難度。為了不給App帶來卡頓、閃退、黑屏、崩潰、載入速度慢等差的體驗，還需要支持開發者各種異常方式的介面調用，需要有極強的容錯性。

移動端的流量在持續的增長，【友盟+】在移動端覆蓋的APP超過135萬款，覆蓋全球移動設備日活躍數超過14億個，每天處理的數據量達280億，龐大的數據每天都在考驗著我們的採集SDK和服務端的承載能力，【友盟+】在移動端採集技術上不斷更新迭代，持續多年保持市場覆蓋領先的地位。

SDK與伺服器通信協議的演進

我們最初SDK的設計思想是簡單高效，因此在SDK端沒有任何對數據預處理的邏輯，甚至緩存策略也非常簡單，所有實時產生的數據都會實時上報伺服器。但隨著移動端流量的暴漲，這種高並發的請求對伺服器帶來很大的壓力。下圖是1.0版本的通信協議。

於是考慮通過控制發送頻率來減小並發，開發者可以根據業務需要採用不同的發送策略：啟動、間隔、退出發送，並且在【友盟+】平台可隨時變更。雖然有效減小了服務端的壓力，但又帶來了另一個問題，單條數據的包體大小有可能超過request-body的上限，導致請求超時。並且流量壓力同樣是需要亟待解決的問題，於是，在2.0版本上我們對數據進行了壓縮，並增加了安全機制。 服務端增加了數據預處理的邏輯，完善了對數據的校驗。

只能單向通信的協議是不靈活的，有很多時候我們需要SDK的行為進行一些控制，比如發送策略的修改、屏蔽錯誤埋點數據，或者發現數據被污染決定拋棄，這些操作伺服器需要通知到SDK，並且在沒有長連接的情況下該怎麼做。在3.0版本上我們把http請求的response的信息包體設計控制語義，SDK除了從response獲得伺服器的接收狀態，同時可以獲得伺服器的控制指令，從而實現伺服器想要得到的效果。

如果每一條Log都必須等待並解析伺服器返回的控制信息，顯然伺服器對數據處理的時效性和並發處理能力會大大折損，並且有些業務數據其實無需解析並執行這些控制信息。因此，我們對業務數據進行了精細的分解，一些業務數據使用雙向通信協議，能夠解析並執行控制指令，其餘的業務數據屬於狀態無關數據，仍然使用單向通信協議。

那麼未來其實還可以將控制協議與業務傳輸協議分離，各自使用不同的發送頻率，但又能保證所有業務數據是受伺服器指令控制的。

SDK技術架構解析

移動數據採集SDK架構主要由三部分組成：用戶介面、業務模塊和控制模塊。

我們可以從幾個場景的時序圖來解析這幾個模塊的工作原理。

APP啟動

用戶啟動App的時候，其實是觸發了開發者調用的初始化介面，Service Moudle和Control Moudle會非同步的進行一些初始化的操作：創建Session、載入設備信息等。

APP在前台運行中

當用戶在APP中有點擊、滑動屏幕的行為，會觸發開發者在APP中預設置埋點事件。

Servie Moudle會生成相應的事件數據，調用Control Moudle的介面檢查發送策略和安全策略，之後Servie Moudle會將事件數據放到緩存隊里中待發送。

APP退出

無論用戶退出APP後，SDK還會在短暫的瞬間完成很多操作：結束Session、持久化保存數據，在iOS中還會直接完成數據封裝、打包、上報的工作。

SDK組件化架構

我們提供的產品功能越來越多，業務場景越來越複雜，為了滿足各種各樣的解決方案的需求，SDK需要為各個業務場景維護多個分支、多個版本，開發資源浪費、版本迭代周期拉長，為了解決這個問題，我們必須要設計一個靈活的架構，使每個產品功能變成可自由組合、拆卸的組件。

組件化將統一約定package和public API的文件規範。針對當前【友盟+】業務的需求，建立標準的SDK產品公共庫（如：network，serialize，configure，cache等），組件化結構分為兩部分，Common將作為一個獨立的library package，而Component中每個產品作為獨立library。 其結構如下：

業務組合靈活，適用更多場景

組件的劃分的顆粒度，可以根據業務需求，我們的設計是根據產品，或者業務來劃分組件。一個產品可能包含很多功能，比如統計產品包含事件數據採集、錯誤數據採集、A/B Test等功能，Push產品包含消息推送和應用內消息，在某些場景下，可能有些開發者會只使用部分功能，比如，只用錯誤分析功能和Push的消息推送，那麼組件顆粒細化到功能層，就會更加靈活，可滿足更多場景的需求，並且體積的減小是對開發者來說是非常有吸引力的。

業務邏輯解耦，代碼更加健壯

組件化的架構改變了以前業務邏輯與基礎功能深度耦合的狀況，業務開發人員可以專註於業務邏輯的實現，而不需要考慮如網路通信、消息隊列管理、設備信息採集等基礎功能的實現。業務邏輯代碼的任何改動，不會影響基礎功能邏輯，加強了代碼的健壯性，同時在回歸測試周期上也大大縮短。

【友盟+】數據採集技術將持續的適應業務場景的變化，未來我們的目標是讓我們的SDK更加智能，更加安全，讓企業及開發者集成更加簡單、數據更加精準。