后台进程注册的ContentObserver接收到的回调晚10秒钟

后台进程中的ContentObserver延迟回调晚10秒钟

在Android系统中，后台进程注册的ContentObserver会有一个延迟回调机制，通常延迟10秒左右。这种机制的设计是为了优化系统资源，减少后台进程频繁监听数据变化带来的资源消耗。

在这里插入图片描述

背景

当应用处于后台时，系统会对其资源进行限制，以优化电池续航和系统性能。特别是对非前台的进程，系统会对ContentObserver的回调进行延迟处理。这种延迟机制主要体现在ContentObserver回调的onChange()方法中，影响注册在后台的ContentObserver收到的回调通知。

实现原因与机制

在Android的ActivityManagerService源码中，系统将前台和后台进程分别管理。对于后台进程，系统会降低其优先级，限制频繁的资源访问，尤其是数据变化监听。Android系统会检查当前进程的状态（前台或后台），对后台进程设置延迟调用，机制如下：

系统判定进程状态：当应用注册ContentObserver时，系统会根据该应用的进程状态决定回调的处理方式。如果是后台进程，系统会标记延迟回调。
延迟策略：对于后台进程，ContentObserver的回调会被延迟10秒左右。延迟时长并不是固定的10秒，而是根据系统负载动态调整。延迟时间的存在让后台进程无法频繁获取数据变化，节省系统资源。
触发机制：系统会在每隔一段时间后检查ContentObserver的注册状态，如果观察的URI在10秒内没有发生进一步的变化，则触发延迟回调。

相关源码分析

ContentObserver的延迟机制在ContentService源码中有所体现。以下是相关的源码片段示例：

// frameworks/base/core/java/android/content/ContentService.java/*** Delay to apply to content change notifications dispatched to apps running* in the background. This is used to help prevent stampeding when the user* is performing CPU/RAM intensive foreground tasks, such as when capturing* burst photos.*/private static final long BACKGROUND_OBSERVER_DELAY = 10 * DateUtils.SECOND_IN_MILLIS;public void dispatch() {for (int i = 0; i < collected.size(); i++) {final Key key = collected.keyAt(i);final List<Uri> value = collected.valueAt(i);final Runnable task = () -> {try {key.observer.onChangeEtc(key.selfChange,value.toArray(new Uri[value.size()]), key.flags, key.userId);} catch (RemoteException ignored) {}};// Immediately dispatch notifications to foreground apps that// are important to the user; all other background observers are// delayed to avoid stampedingfinal boolean noDelay = (key.flags & ContentResolver.NOTIFY_NO_DELAY) != 0;final int procState = LocalServices.getService(ActivityManagerInternal.class).getUidProcessState(key.uid);if (procState <= ActivityManager.PROCESS_STATE_IMPORTANT_FOREGROUND || noDelay) {task.run();} else {BackgroundThread.getHandler().postDelayed(task, BACKGROUND_OBSERVER_DELAY);}}}
}

可以看出，有两个或条件会导致通知回调延迟10秒钟：

后台进程：procState > ActivityManager.PROCESS_STATE_IMPORTANT_FOREGROUND, 也就是监听的进程为后台进程；
key.flags不为noDelay：发起通知的时候，会传进来一个int flags参数，如果该参数 (key.flags & ContentResolver.NOTIFY_NO_DELAY) != 0，则不会延迟调用。

实际开发过程中遇到的相关问题

在应用实际运行中，这一延迟会导致后台应用对数据变化的反应较慢。这种机制在以下场景中较为显著，比如后台进程监控的实时数据更新只能每隔10秒左右收到一次回调。典型的例子，就是添加到桌面的小部件相关的AppWidgetProvider，一般都运行在跟后台进程中，但是小部件基本都显示在桌面上。其监听的数据变化晚10秒的话，会导致用户感知到的数据刷新晚10秒。这样很大程度上被认为属于软件故障。

应对方案

为了降低这种延迟带来的影响，可以尝试以下策略：

前台服务：通过启动前台服务（Foreground Service），使应用在后台时也保持前台进程的优先级，从而即时接收数据变化的回调。但是随着Android系统版本的眼睛，后台进程通过启动前台服务使其变为前台进程的方法受到系统越来越多的限制甚至会引发报错。
JobScheduler和WorkManager：在后台场景下，采用JobScheduler或WorkManager来实现数据变化的处理，而非实时监听。
BroadcastReceiver：结合系统广播监听数据变化，适用于一些系统设置变化的场景。
修改ROM代码：对于可以修改ROM代码的开发人员，也可以在通知变化的地方修改flags为NO_DELAY或者在以上源码中增加白名单，使得特定包名的应用看了一绕过系统原生的延迟机制。