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


// 通过rename方法保存文件,保证并发操作的安全temp.renameTo(file))⑥ 文件添加完成之后通过发送广播通知,广播分为实时广播和延迟广播,延迟广播用来通知优先级较低的文件 。
//低优先级的可以发送延时广播mHandler.maybeDeferBroadcast(tag, time);//高优先级的发送实时广播mHandler.sendBroadcast(tag, time);2.4.4 获取文件
DBMS获取文件的逻辑比较简单,根据方法名getNextEntry(String tag, long millis,...)我们可以见名知意,主要根据使用者传入的时间戳,找出这个时间戳往后的第一个文件 。
for (EntryFile entry : list.contents.tailSet(new EntryFile(millis + 1))) {return new DropBoxManager.Entry(entry.tag, entry.timestampMillis, file, entry.flags);}2.5 源码阅读总结2.5.1 回答我们阅读前提出的问题
① 存取日志的策略

  • 会在低存储,添加获取文件等时机将文件列表初始化到内存中 。
② 设计哪些防呆策略
  • 提供了文件大小,存储占比等限制 。
  • 会在低存储,配置更改的时候清除文件 。
  • 配置保存在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.2 其它点
  1. 文件存储不光限制大小,也会限制文件类型
  2. 文件不是全部压缩的,超过一定大小的文件会进行压缩
  3. 文件命名有讲究,包含了应用类型,崩溃信息,发生时间等相关信息
  4. 文件获取是根据时间戳先后来获取的,对于时间戳异常的文件会进行时间上的调整
2.5.3 作为使用者的看法
当然,我在使用源码的过程中,也发现我个人觉得可以优化的点 。
  1. 在使用中,部分文件命名应该加上包名,类似应用产生的崩溃文件,可以按包名区分文件,对使用更友好,当然这个设计的初衷是给系统统一使用,可能不对外开放 。
  2. 权限管控过于单一,对于业务本身的一些异常日志,应当支持自由查看 。
  3. 这些文件的信息应该用数据库维护起来更好,方便使用者用,当然可能设计可能会变得更复杂,不够简约 。
三、源码阅读应用–日志文件管理&上报设计3.1 概述背景:
部分应用希望上报应用运行时的一些日志,包括运行时log,崩溃log,Hprof内存快照,捕获异常等等
需求:
需要设计一套客户端的日志文件收集、管理及上报一个功能
参考:
  1. 日志保存管理方案可以参考DBMS中的一些策略
  2. 日志上传方案参考业内已有的一些优秀模型
3.2 方案整体方案方案采用生产者-消费者模型,其中几个关键节点
  1. 生产者:应用的多个进程,他们可能会生成不同类型的日志,并写入到指定的文件目录


    推荐阅读