Loaders 与 BroadcastReceivers 的优先级在主线程上启动答案

【问题标题】：Precedence of Loaders vs BroadcastReceivers started on the main threadLoaders 与 BroadcastReceivers 的优先级在主线程上启动
【发布时间】：2018-08-23 17:11:27
【问题描述】：

考虑以下事件序列：

BroadcastReceiver 在Activity 的onResume 方法中注册（没有处理程序）。
通过调用restartLoader 方法作为onResume 中的下一个立即语句来启动CursorLoader（restartLoader 在 main 线程本身上调用）

我的观察是onLoadFinished 方法总是在第一次调用onReceive 之前被调用。也就是说，CursorLoader 优先于BroadcastReciever。此外，BroadcastReceiver 的 onReceive 方法在 onLoadFinished 方法完成之前不会被调用。

假设：

有一个前台服务已经在后台运行，它正在为我的BroadcastReciever 发布消息，甚至在应用程序首次启动之前AND
考虑到BroadcastReciever 是在CursorLoader 启动之前注册的，考虑到BroadcastReceiver 已经有消息可用，不应该立即触发onReceive 方法。

由于不是这种情况，我相信CursorLoader 在活动的主线程上启动时优先于BroadcastReceiver。但是，我似乎找不到任何文档。

如何确保我的BroadcastReceiver 优先于CursorLoader？这种行为很重要，因为我希望我的Activity 使用前台服务正在广播的一些信息进行初始化，即使应用程序正在新启动（即在ACtivity 上调用onCreate）。 CursorLoader 需要此信息来创建 Uri 以用于获取相关数据并将其显示在 UI 上。由于CursorLoader 在BroadcastReciever 之前运行，它会在没有此信息的情况下构造Uri，然后从数据库中获取陈旧的数据。

【问题讨论】：

标签： java android android-broadcastreceiver android-loadermanager android-loader

【解决方案1】：

加载器已被弃用，强烈建议重构以使用 ViewModel。您还可以结合使用实时数据。

链接到 ViewModel ViewModel Overview 链接到实时数据LiveData Overview

【讨论】：

感谢您的提醒。据我了解，从 API 级别 28 起，加载程序已被弃用。我相信为一小部分支持 API 级别 28 的设备重构整个应用程序可以推迟几年。也就是说，将 ViewModel 组件与 LiveData 一起使用可以解决我在问题中描述的问题吗？
堆栈上的这篇文章可能会有所帮助：Dataflow between Android BroadcastReceiver, ContentProvider, and Activity?
再次感谢您的帮助；但是，我不想从BroadcastReciever 开始我的Activity。我的活动是注册BroadcastReciever 的活动，我的要求是此BroadcastReciever 的onReceive 方法在CursorLoader 之前运行。这有意义吗？