Android日志解决方案（理论篇）

Android客户端日志应该围绕用户层面、功能模块、报警等级、APP启动生命周期进行设计。

方案如下：

使用Sqlite数据库用于存储用户(或系统)触发的所有日志信息，单独数据库文件，数据库表分为两类：(用户日志)总表和(日志信息)子表

总表：表名与用户id挂钩，表内结构为子表表名。

子表：表名为app启动时创建表的时间戳，表内结构为日志触发时间戳、报警等级（vbiwe）、信息详情、功能模块title、写入时间戳（后面详述）。

工作原理：

在app启动时，(先检查是否有当前用户的总表，没有则创建)，使用当前时间戳创建一个子表，并将子表表名保存在当前用户对应的总表内，检查总表内信息条数，超过100则仅保留最近100条，同时删除久远的子表实体。

功能模块粗略可以分为系统（页面生命周期、用户交互等）、业务（用户数据、具体业务功能等），在需要的时机进行日志打印，所有打印的日志都暂存在内存内，用户可以自己配置flush时机，一旦flush则将内存内信息保存到数据库子表内，同时子表的"写入时间戳"使用flush时的系统时间戳。

可以进行的配置项：

1.是否触发系统原生打印，即Log.i()、Log.e()等，一般根据Build.DEBUG来判断，方便开发人员在AndroidStudio的logcat中观察分析

2.内存缓存池大小，单位(条)，也可以动态修改缓存池容积。比如进入日志高频触发区，则将缓存池容积扩大到100条，进入低频触发区就缩小到10条。容积缩小时，如果缓存池内条目数已经大于目标条数，自动触发flush。

3.flush时机，粗略分为四种情况：缓存池满、应用从前台进入后台、应用从后台恢复至前台、手动代码调用。 手动代码调用一般发生在进入超高频触发区之前，或者是跨功能模块时，以及用户交互需求日志上传时。

子表中的写入时间戳：（flush时间戳）

子表中的写入时间戳（flush时间戳），是用于数研分析，判断每次的flush时间间隔，从而更好地调整缓存池容积，以实现最佳的io操作，避免性能浪费和拥挤。

日志获取：

参考上图，因为我们需要的日志时间段可能横跨多次App生命周期，又因为一次进程生命周期对应一张子表，所以1.根据用户信息找到对应的总表，2.从总表中获取需求日志时间段内涉及的子表（因为子表表名就是进程启动的时间戳），3.再使用需求日志时间段的两个时间节点，去上述的子表中进行查询。

查询得到数据之后，(由于条目可能量级巨大，建议在数据库检索的同时进行文件读写)，将数据库信息写入本地文件，当写入完毕之后，对本地的文件加密，然后上传至对象存储服务器（比如OSS），然后就可以下载了。下载得到文件之后先进行解密，然后可以根据脚本转至成excel或者转储进数据库，以利于之后的数据分析。

总结：

以上就是全部的android日志解决方案了，解决方案足够轻量，用户只需要提供起止时间即可以准确地上传日志，使用总表+子表的方式减轻数据库查询负担，也避免携带需求时间段以外的冗余日志。由于缓存池和动态缓存容积调整策略的存在，对于android本地io消耗可控。