第一次听到埋点这名词的时候，是在三年前，刚进某会时。
随后一直接触相关埋点需求的开发，然而，却一直没有好好的研究过。
最近，新公司需要埋点的实现方案。也就有了研究的机缘。
回想了前公司大神的实现方案，由于业务复杂，相关角色也错综复杂。起初美好的愿景变得惨不忍睹。该死的业务！
整理了下，我想，起初的愿景应该是酱紫的。
以下纯粹为了记录，水平不高，各路大神路过轻喷。
有以下三个角色：
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：
埋点读取者，循环向 数据存储 读取最新的埋点。
好久没写技术文档。回看一遍，还是太粗糙了。感觉还是贴代码会更加清晰点。囧。
下一篇贴下部分源代码继续介绍。
