这种隐式广播与通过显式广播进行相同操作的其他方式有什么区别?

What is the difference between this implicit broadcast and the other way of doing the same via explicit broadcast?

在 Android 中使用 implicitexplicit 两种广播类型 - 对于隐式,我们将在 AndroidManifest.xml 中声明广播,并且当某些应用程序发送使用该操作广播所有在其清单中使用该操作声明广播的应用程序将被调用并完成工作。

由于 O 的 Android 强加了 background execution limits,我不允许仅发送意图包含 action 的广播。我必须明确指定包名称和接收 class 名称。

现在通过这样做,我能够克服隐式广播限制

String action = "com.android.intent.CUSTOM";
Intent intent = new Intent();
intent.setAction(intent);

//Though this is a deprecated method
List<ResolveInfo> resolvedBroadcasts = List<ResolveInfo> queryBroadcastReceivers(intent, 0, current_user_id);

for (ResolveInfo info : resolvedBroadcasts) {
   ServiceInfo serviceInfo = info.serviceInfo;

   //Note: Now this is becoming explicit broadcast
   intent.setAction(serviceInfo.packageName, serviceInfo.name);
   context.sendBroadcast(intent);
}

我是不是漏掉了什么?在这一点上感到困惑,如果我能够这样做,那为什么 Android 给我施加这个后台执行限制?

Am I missing something here?

Google 工程师表示,如果太多的应用程序这样做,这种方法将被禁止,不知何故。

FWIW,我在博客中介绍了这种方法 two years ago

if I'm able to do this way then why Android imposed me this background execution limits?

Google 希望很少有开发人员会采用此解决方法,而是会使用其他一些 IPC 机制。

问题是进程流失。假设您的隐式广播匹配 25 个应用程序的清单。当您的代码执行时,Android 需要将您的 Intent 传递给 25 个接收者。但是,只有其中几个会在内存中——许多应用程序不会有 运行 个进程。所以,Android 现在需要分叉一大堆流程来交付你的 Intent。这反过来可能会迫使其他进程终止,以释放系统 RAM。最终结果是 low-end 设备上的性能不佳。

我认为,Android 不应禁止隐式广播,而应实施 store-and-forward 机制,以限制进程变动的速度缓慢传送广播。我的建议被拒绝了。