第一次聽到埋點這名詞的時候，是在三年前，剛進某會時。

隨后一直接觸相關埋點需求的開發，然而，卻一直沒有好好的研究過。

最近，新公司需要埋點的實現方案。也就有了研究的機緣。

回想了前公司大神的實現方案，由于業務復雜，相關角色也錯綜復雜。起初美好的愿景變得慘不忍睹。該死的業務！

整理了下，我想，起初的愿景應該是醬紫的。

以下純粹為了記錄，水平不高，各路大神路過輕噴。

有以下三個角色：

Sender，專職發送埋點的。

Recorder，專職記錄埋點的。

Reader，專職讀取埋點的。

而這些角色之間的協作方案，就是埋點的實現方案。

主要采用了 Service + HandlerThread 的實現方式。（參考了前公司大神的實現方案）

由于 HandlerThread 持有 Loop 對象，并開啟了消息循環。所以用其作為埋點事件（記錄/發送）的隊列管理。

再通過HandlerThread 創建 Handler 對象，用于向 HandlerThread 發送消息。

如下圖，埋點記錄的時序圖：（Recorder 持有 RecorderHandlerThread 的 Handler 對象

當調用方Cp 埋點類 post 一個埋點信息（logData）時，Recorder 會調用 record() 方法，將 操作數據庫保存埋點信息的動作 包裝成線程，并通過Hander 向RecorderHandlerThread 發送該消息。

RecorderHandlerThread 收到消息后，執行保存埋點信息的動作。

再如下圖，埋點發送的時序圖：（Sender 持有 SenderHandlerThread 的 Handler 對象）

ReaderThread 循環向 Db 獲取埋點信息（logData），當不為空時，Sender 會調用 send() 方法，將 埋點信息發送的動作 包裝成線程，并向SenderHandlerThread 發送該消息。

SenderHandlerThread 收到消息后，便執行發送埋點信息的動作。

具體的類圖如下：結合上面的時序圖，可以清楚的看出各類之間的關系。

LogServiceV2：

繼承Service，各線程寄托于Service 里，提高優先級，延長其生命周期，避免內存不足時誤殺。

當LogServiceV2 啟動后，RecorderHandlerThread，SenderHandlerThread 便開始等待消息并執行。ReaderThread 便循環的讀取數據存儲的最新埋點信息。

Recorder :

埋點記錄者，持有RecorderHandlerThread 的 Handler 對象，通過handler對象，可向 RecorderHandlerThread 發送消息。

Sender ：

埋點發送者，持有SenderHandlerThread 的 Handler 對象，通過handler對象，可向SenderHandlerThread 發送消息。

ReaderThread：

埋點讀取者，循環向 數據存儲 讀取最新的埋點。

好久沒寫技術文檔。回看一遍，還是太粗糙了。感覺還是貼代碼會更加清晰點。囧。

下一篇貼下部分源代碼繼續介紹。