Android应用关闭时RxJava的Timber日志缓冲区刷新及订阅处理问询

问题1：逐Activity在onDestroy()中手动触发刷盘的方案评估 #

首先明确结论：这种方案完全不合理，存在明显缺陷，不推荐使用，具体问题包括：

• 侵入性极强：需要修改每一个Activity的基类才能实现，遇到第三方SDK提供的Activity根本无法接入，很容易出现漏加导致刷盘逻辑覆盖不全的问题
• 触发时机不可靠：Android系统在内存紧张时会直接杀死进程，不会保证执行Activity的onDestroy()回调，靠这个时机刷盘本质上是靠不住的
• 严重违背缓冲设计的初衷：如果Activity因为屏幕旋转、配置变更频繁销毁重建，会导致日志频繁触发刷盘，之前为了减少IO做的缓冲优化效果会被完全抵消

更优的实现路径 #

• 基于全局进程生命周期触发刷盘：接入ProcessLifecycleOwner监听整个应用的前后台状态，当应用完全进入后台（所有Activity、前台Service均不可见）时，直接触发一次手动刷盘。这种方案不需要改动任何业务组件，能覆盖所有入口（Activity、后台服务、广播等）的场景，触发时机比单个Activity可靠得多
• 增加崩溃兜底刷盘逻辑：注册全局未捕获异常处理器，在进程因崩溃即将被系统杀死前，将缓冲区剩余的日志同步写入磁盘——这部分往往是定位问题最关键的日志，丢了损失最大
• 不要等待“应用主动退出”的时机：绝大多数场景下应用不会走主动退出逻辑，用户按Home键切后台后，系统可能随时回收进程，只要应用进入后台就触发一次刷盘，就能覆盖绝大多数丢日志的场景

问题2：长期运行的RxJava订阅是否需要主动dispose的判断 #

首先明确结论：你“Application被系统回收时订阅会自动清理，不需要主动dispose”的判断不严谨，存在实际的资源浪费风险，不能完全照搬，具体分析如下：

• 当应用进程被系统彻底回收时，所有内存、线程资源确实会被操作系统统一释放，不存在系统层面的永久泄漏，但在进程存活的全周期内，无意义的长期任务会持续消耗资源：比如代码里的Observable.interval(2, TimeUnit.MINUTES)会在computation线程池里创建一个永久运行的定时任务，哪怕应用切到后台、没有任何新日志写入，这个任务也会持续占用线程资源、周期性唤醒CPU做无用功。这类后台空跑的任务还会提高应用被系统判定为高耗电进程的概率，可能降低应用进程的保活优先级，反而更容易被系统提前回收
• 如果后续迭代中，订阅链不小心引入了Activity相关的强引用，哪怕你用的是单例的Application级订阅，也会造成难以排查的内存泄漏

这类场景的标准处理方式 #

• 因为你这套日志逻辑的生命周期确实和Application完全对齐，根本不需要在零散的业务组件里找dispose时机：直接在自定义的Application类里持有这个Disposable的全局引用即可，不需要在Activity、Service的销毁逻辑里硬加取消逻辑
• 正常运行场景下根本不需要主动dispose：只要进程存活，日志订阅就需要保持运行，不需要为了“满足RxJava的代码提示”强行在业务逻辑里加取消调用
• 仅在以下两个场景下需要主动dispose释放资源：
  • 需要更换日志文件路径、重新搭建日志订阅链时，先调用旧订阅的dispose()方法，避免新旧两个订阅同时向磁盘写日志的冲突
  • 检测到进程即将完全退出时（比如所有组件都销毁且长时间无新组件启动、即将触发系统回收），先把缓冲区剩余的日志全部刷盘，再调用dispose()方法停止后台定时任务，避免无意义的资源消耗
• 另外提一个现有代码的小隐患：当前代码里的processed计数器，在手动触发刷盘、定时刷盘完成后不会重置，会导致“累计满100条触发刷盘”的阈值统计不准——比如累计99条日志时手动触发一次刷盘，下一条日志进来时processed就会达到100、触发自动刷盘，出现连续两次刷盘的IO浪费，只要在每次刷盘完成时把processed计数重置为0，就能解决这个问题。

内容的提问来源于stack exchange，提问作者widavies