Android系统服务DropBoxManagerService详解与实践应用

随着公司应用的逐渐增多，需要集中收集公司部分应用线上运行的一些崩溃数据和日志来进行分析处理，在此实践过程中了解到系统data/system/dropbox目录会生成所有应用的相关日志文件。

这个目录是由Android系统服务之一DropBoxManagerService来管理，所以由此详细阅读了DropBoxManagerService相关的源码，以下简称DBMS。

DBMS可能是Android系统服务源码较少的一个，所以阅读起来相对比较简单，阅读之后发现，其实这就是一个简易的日志文件管理服务。

我们在对应用本地的部分日志文件进行记录和管理的时候，恰巧可以借鉴DBMS源码对于文件管理的设计方案。

假设不读源码，如果我们自己设计日志文件管理系统，应该需要考虑哪些？

除了最基础的获取各类日志文件的方案，我们针对文件管理可以提出几个需要考虑的点：

DropBoxManagerService是Android系统的服务之一，采用C/S结构：

• Client端：DropboxManager，用于对应用层提供接口。

• Server端：DropBoxManagerService，管理系统目录(data/system/dropbox)的系统服务。

• 系统Setting数据库：负责管理DBMS的一些配置信息。

整体架构关系如下图所示：

• tag：代表日志类型，常见的tag：data_app_anr，system_app_crash，data_app_nativecrash，其中data_app表示普通应用，system_app表示系统应用

• timeStampMillis：日志的时间戳，一般情况下等于崩溃的时间，有些情况下系统会做一些调整

• extentions：后缀名，常见的文件后缀名：.txt,.lost,.txt.gz,.tmp，一般的日志文件都是.txt或者.txt.gz，文件被删除后的记录会以.lost命名

这种文件命名方式优点是可以一眼看出这是什么类型的文件。

2.1.2 常见的文件

2.2.1 添加文件

addData/addFile/addEntry

2.2.2 获取文件

getNextEntry，根据tag和时间戳来获取想要的文件。

2.2.3 dump目录信息

获取DropBox目录的一些信息：文件个数，文件列表，文件详细信息等，可以通过命令行操作(dumpsys dropbox)。

$ dumpsys dropboxDrop box contents: 131 entriesMax entries: 1000// 以下省略......

2.2.4 其它CMD命令

提供其他一些CMD操作的命令，如set-rate-limit，add-low-priority等等。

2.3.1 默认基础配置及文件清除策略

这些配置存在系统的setting数据库里面，可以通过settings.global来访问配置。

文件存储的配置主要包括以下几个维度：

根据以上配置，我们可以知道该目录下的日志文件清除策略，触发配置上限后会及时的删除文件。

在以下三种情况会执行文件清除策略，防止DropBox占用太多的空间：

2.3.2 文件删除及标记处理策略

在上述策略不满足后，部分文件会被删除，删除后，会在DropBox添加一个.lost的空文件标记被删除的文件。

2.3.3 文件类型管控

DropBoxMangerService对于可存储的文件类型也有控制，主要是对于TAG的控制。

public boolean isTagEnabled(String tag) {}

2.3.4 权限管控

这块涉及到DBMS几个关键方法和属性，主要涉及到初始化(init)，添加文件(addEntry)，获取文件(getNextEntry)，文件类型(EntryFile)。

DBMS作为系统服务会由SystemServer启动，添加文件(addEntry)和获取文件(getNextEntry)在调用时会先进行初始化(init)。

其中每个文件都会转换成一个EntryFile类来管理，关系见下图：

2.4.1 初始化

初始化会将DropBox文件列表缓存到内存中。

/** If never run before, scans disk contents to build in-memory tracking data. */private synchronized void init() throws IOException {    // 省略代码......     File[] files = mDropBoxDir.listFiles(); // 列出所有文件     for (File file : files) {          EntryFile entry = new EntryFile(file, mBlockSize); // 一个日志文件对应一个EntryFile对象          enrollEntry(entry); // 加入到mAllFiles    }}

初始化的时机：

2.4.2 EntryFile文件属性

每个文件对应一个EntryFile，用block数来统计大小，DBMS涉及的读写都是根据磁盘的blockSize来进行，效率会更高。

static final class EntryFile implements Comparable<EntryFile> {        public final String tag; // 日志文件的tag，类型        public final long timestampMillis; // 日志文件的时间戳        public final int flags; // 日志文件的flag，标志TEXT，EMPTY，GZIPPED        public final int blocks; // 存放文件的块数}

2.4.3 添加文件

添加一个日志文件，常见的在Ams中的addErrorToDropBox方法调用。

添加文件管控策略

② 设计哪些防呆策略

• 提供了文件大小，存储占比等限制。
  

• 会在低存储，配置更改的时候清除文件。

• 配置保存在setting中，然后通过ContentObserver来监听配置变化。

③ 对外提供哪些接口

• 提供添加获取，以及cmd命令相关的接口，开发调试都能兼顾。

④ 如何保证性能

• 从源码的注解可以看出，目前每个Entry无论大小都对应一个文件效率是比较低，源码也列出了TODO，考虑用单文件队列来优化。

// TODO: This implementation currently uses one file per entry, which is// inefficient for smallish entries -- consider using a single queue file// per tag (or even globally) instead.

• 采用文件系统块大小来读写来提高效率。

⑤ 多进程的问题如何解决

• 文件操作都是先写temp，然后采用rename的方案来保证原子操作从而保证并发操作的安全。

• addEntry和getNextEntry都做了加锁处理。

⑥ 文件丢失该如何处理

• 文件被删除后，会用一个同名的空文件来替代，从而标记有文件被删除了。

⑦ 文件变化如何通知使用方

• 通过发广播的方式来通知外界，针对不同优先级的文件又设置实时和延时广播。

2.5.3 作为使用者的看法

参照DBMS添加文件的实时和延时通知方案，上报也分为实时上报和延时上报

• 实时上报：出现一份日志，就直接上报，针对重要性较高的日志

• 延时上报：达到一定数量，或者达到一定时间进行上报

我们经常强调源码阅读，源码究竟能给我们带来什么呢？我认为主要有以下几点：

• 编码技术的提升

• 分析问题的思路

• 解决方案的设计

• 设计模式的应用

参考：