android 埋点实现方案

第一次听到埋点这名词的时候，是在三年前，刚进某会时。

随后一直接触相关埋点需求的开发，然而，却一直没有好好的研究过。

最近，新公司需要埋点的实现方案。也就有了研究的机缘。

回想了前公司大神的实现方案，由于业务复杂，相关角色也错综复杂。起初美好的愿景变得惨不忍睹。该死的业务！

整理了下，我想，起初的愿景应该是酱紫的。

以下纯粹为了记录，水平不高，各路大神路过轻喷。

有以下三个角色：

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：

埋点读取者，循环向 数据存储 读取最新的埋点。

好久没写技术文档。回看一遍，还是太粗糙了。感觉还是贴代码会更加清晰点。囧。

下一篇贴下部分源代码继续介绍。