ContentObserver onChange检测App1修改延迟10秒的原因及优化方案

我开发了两个简单应用：

• 应用1：提供并修改Content Provider，通过URI共享一个布尔标记。
• 应用2：使用ContentObserver监听应用1提供的该标记，同时也可修改内容。

现象：当应用2修改内容时，ContentObserver的onChange方法会立即执行；但当应用1修改内容时，onChange方法总是需要整整10秒才能识别到变化并执行。

请问出现这种固定10秒延迟的原因是什么？如何降低该延迟？

应用1代码 #

MyProvider.kt

class MyProvider : ContentProvider() {
    companion object {
        const val AUTHORITY = "pizza.xyz.cp1.provider"

        private const val CODE_DIR = 1
        private val MATCHER = UriMatcher(UriMatcher.NO_MATCH)

        init {
            MATCHER.addURI(
                AUTHORITY,
                "flag",
                CODE_DIR
            )
        }

    }
    val appDatabase: AppDatabase? by lazy {
        context?.let {
            Room.databaseBuilder(
                it,
                AppDatabase::class.java,
                "MyDataBase"
            ).fallbackToDestructiveMigration().build()
        }
    }

    override fun onCreate(): Boolean {
        return true
    }

    override fun insert(
        uri: Uri,
        values: ContentValues?
    ): Uri {
        return when (MATCHER.match(uri)) {
            CODE_DIR -> {
                println("Writing flag in cp1: ${values?.getAsBoolean("flag")} ")
                appDatabase?.flagDao()?.updateFlag(values?.getAsBoolean("flag") ?: false)
                context?.contentResolver?.notifyChange(uri, null)
                uri
            }
            else -> throw java.lang.IllegalArgumentException("Unknown URI: $uri")
        }
    }

    @Nullable
    override fun query(
        uri: Uri,
        @Nullable projection: Array<String>?,
        @Nullable selection: String?,
        @Nullable selectionArgs: Array<String>?,
        @Nullable sortOrder: String?
    ): Cursor? {
        return when (MATCHER.match(uri)) {
            CODE_DIR -> {
                val context = context ?: return null
                val cursor: Cursor? = appDatabase?.flagDao()?.fetchFlag()
                cursor?.setNotificationUri(context.contentResolver, uri)
                cursor
            }
            else -> throw IllegalArgumentException("Unknown URI: $uri")
        }
    }
}

AndroidManifest

<provider
    android:authorities="pizza.xyz.cp1.provider"
    android:name=".MyProvider"
    android:exported="true"
    android:enabled="true"
    android:multiprocess="true"
    android:readPermission="pizza.xyz.PERMISSION"
    android:writePermission="pizza.xyz.PERMISSION"/>

应用2代码 #

ContentObserverFlow.kt

class ContentObserverFlow(private val contentResolver: ContentResolver, private val uri: Uri) : ContentObserver(
    Handler(Looper.getMainLooper())
) {
    private val _flow = MutableSharedFlow<Unit>(extraBufferCapacity = 1)
    val flow: Flow<Unit> get() = _flow

    init {
        contentResolver.registerContentObserver(uri, true, this)
    }

    override fun onChange(selfChange: Boolean) {
        println("change detected cp2")
        _flow.tryEmit(Unit)
    }

    fun unregister() {
        contentResolver.unregisterContentObserver(this)
    }
}

AndroidManifest

<uses-permission android:name="pizza.xyz.PERMISSION"/>

<queries>
    <package android:name="pizza.xyz.cp1.provider"/>
</queries>

原因分析 #

这个固定10秒延迟的核心原因是应用1的ContentProvider设置了android:multiprocess="true"属性：

当开启多进程模式后，每个访问该Provider的应用进程都会创建一个独立的Provider实例。应用1自身修改数据后调用notifyChange时，这个通知只会发送给当前进程内的观察者，而应用2的观察者属于另一个进程，无法直接接收该通知。

Android系统为了弥补这种跨进程通知的缺失，会默认每隔10秒自动检查ContentProvider的数据变化，这就是你看到固定延迟的来源。

而应用2修改数据时，是通过自身进程内的Provider实例调用notifyChange，通知会直接发送给同一进程内的观察者，因此没有延迟。

解决方案 #

方案1：移除多进程属性（优先推荐）

删除应用1Manifest中Provider声明的android:multiprocess="true"，这样系统内只会存在一个Provider实例。当应用1调用notifyChange时，系统会正确将通知广播到所有注册了该URI的跨进程观察者，实现实时通知。

修改后的应用1Manifest：

<provider
    android:authorities="pizza.xyz.cp1.provider"
    android:name=".MyProvider"
    android:exported="true"
    android:enabled="true"
    android:readPermission="pizza.xyz.PERMISSION"
    android:writePermission="pizza.xyz.PERMISSION"/>

方案2：手动实现跨进程通知（仅当必须保留多进程时）

如果业务需求必须保留多进程模式，可以通过以下方式实现实时通知：

1. 在应用1调用notifyChange时，传入syncToNetwork = true参数（注：该参数主要针对同步适配器，可靠性有限）；
2. 使用其他跨进程通信方式（如BroadcastReceiver、AIDL），在应用1修改数据后主动向应用2发送通知，应用2收到后自行触发回调或数据检查。

这种方式会增加代码复杂度，非必要不推荐使用。

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