时间戳

首页 > 解决方案 > 这种隐式广播与通过显式广播进行相同操作的其他方式有什么区别？

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

问题描述

implicit使用 Android 中的广播和广播两种类型explicit- 对于隐式，我们将在其中声明广播，AndroidManifest.xml并且当某些应用程序发送带有操作的广播时，所有在其清单中使用该操作声明广播的应用程序将被调用并执行工作。

由于 Android 从 O 施加的后台执行限制，我不允许仅发送包含action. 我必须明确指定包名和接收类名。

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

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 会给我施加这个后台执行限制？

标签： androidandroid-8.0-oreoandroid-broadcast

解决方案

我在这里错过了什么吗？

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

FWIW，两年前我在博客上写过这种方法。

如果我能够做到这一点，那么为什么 Android 会给我施加这个后台执行限制？

谷歌希望很少有开发人员会采用这种解决方法，而是使用其他一些 IPC 机制。

问题是流程流失。假设您的隐式广播匹配 25 个应用程序的清单。当您的代码执行时，Android 需要将您传递Intent给 25 个接收器。但是，只有其中几个会在内存中——许多应用程序不会有正在运行的进程。因此，Android 现在需要派生一大堆进程来交付您的Intent. 这反过来可能会强制终止其他进程，以释放系统 RAM。最终结果是低端设备的性能不佳。

我认为，Android 不应该禁止隐式广播，而是应该实现存储转发机制，以限制进程流失的速度缓慢传递广播。我的建议被拒绝了。

推荐阅读