为什么有些广播接收机只能通过Code或AndroidManifest进行注册

有些广播接收机只有通过代码注册才能工作,而不是在AndroidManifest中定义。

例如:

SCREEN_ON, SCREEN_OFF 

这些操作只适用于在代码中注册的接收者。 如果它们在清单中注册,则不会发生错误,但是它们也不会被调用。

这种无证行为的原因是什么? 安全?

Solutions Collecting From Web of "为什么有些广播接收机只能通过Code或AndroidManifest进行注册"

我不认为这是一个安全问题。

清单定义的广播接收机已注册,即使应用程序不在内存中也可以接收意图。 相反不会发生。

这可能是一个性能问题,因为注册这种types的事件的接收器,可能会耗尽用户的电池。

BroadcastReceiver的清单和编程注册的主要区别

我认为这是一个devise决定。 我们可以静态或dynamic地注册我们的广播接收机。 Android系统对这两种接收器types的处理略有不同。

主要performance;

dynamic广播接收机与应用程 我们可以多次使用它。 最重要的是,它运行在UI线程上。

静态广播接收器与操作系统。 包pipe理器处理其生命周期。 静态注册的BroadcastReceiver的瞬态性意味着它的onReceive()方法不能使用任何asynchronous的function,例如绑定到服务。

有些播放像SCREEN_ON,SCREEN_OFF …可以连续调用。 如果我们可以注册这种广播。 很多数字应用程序想要使用它。 每当我们打开设备屏幕,所有这个应用程序将被操作系统触发。 这对于任何一种操作系统都不是一个好的行为。

另一方面,当我们使用代码时,有一些广播是没有意义的。 如“BOOT_COMPLETED”。 它应该在系统范围内注册,而不是在UI线程中。

我认为这种决定取决于安全性,性能和用例场景。

PS:很久以前,我曾经搜查过,但没有find任何有关它的确切原因的文件。

看来这个答案对我来说是好的,但是这还不能说明为什么有些只能在AndroidManifest中注册,有些只能通过代码

清单注册接收机的主要用途是在代码不在内存中的情况下进行广播(例如,BOOT_COMPLETED,通过AlarmManager的预定警报)。

这种行为与Diogo Bento提到的安全性没有任何关系。

如果在使用资源之前需要一个宝贵的资源,那么无论您在清单中声明您的广播接收器的天气还是在代码中注册,都必须要求这个权限。 没有所需的权限,两个都将失败。

我认为只有代码行为的原因是,Googe不希望让你的应用程序由该行动启动。 SCREEN_ON和SCREEN_OFF就是一个很好的例子。 做一个恼人的应用程序会很容易,会做屏幕打开的事情。 有了这个限制就更难了。 如果您确实需要在屏幕打开时启动应用程序,那么您必须做更多的工作才能达到相同的效果。 例如,您必须维护一个监听这些事件的服务。

另外,大多数应用程序只关心前台的屏幕事件,所以不需要唤醒每一个甚至没有运行的应用程序。 假设您有10个应用程序对SCREEN_ON操作感兴趣。 当你打开你的屏幕时,Android只需要启动10个进程就可以忽略这些事件,因为它们都没有运行。 而从OS的angular度来看,进程是最昂贵的资源之一。