【翻译】BroadcastReceiver

转载请注明出处：http://blog.csdn.net/kester_/article/details/52506715

参考地址：https://developer.android.com/reference/android/content/BroadcastReceiver.html

BroadcastReceiver

Base class for code that will receive intents sent by sendBroadcast().
基类代码会接收到发送自sendBroadcast()的intent。

If you don’t need to send broadcasts across applications, consider using this class with LocalBroadcastManager instead of the more general facilities described below. This will give you a much more efficient implementation (no cross-process communication needed) and allow you to avoid thinking about any security issues related to other applications being able to receive or send your broadcasts.
如果你不需要通过应用发送广播，可以考虑使用LocalBroadcastManager而不是下面描述的更多普通的功能。这会让你拥有更高效的实现（不需要跨进程通信）和让你能不用考虑和其他应用进行发送和接收广播涉及到的安全问题。

You can either dynamically register an instance of this class with Context.registerReceiver() or statically publish an implementation through the tag in your AndroidManifest.xml.
你可以使用Context.registerReceiver()动态注册实例或者通过在AndroidManifest.xml里标签静态生成。

Note: If registering a receiver in your Activity.onResume() implementation, you should unregister it in Activity.onPause(). (You won’t receive intents when paused, and this will cut down on unnecessary system overhead). Do not unregister in Activity.onSaveInstanceState(), because this won’t be called if the user moves back in the history stack.
注意：如果在Activity.onResume()的实现里注册接收者的话，你应该在Activity.onPause()里反注册它。（在paused状态时你不能接收到intent，而且这个会降低系统不必要的消耗）。不要在Activity.onSaveInstanceState()里反注册，因为当用户在历史栈里回退的时候不会调用这个方法。

There are two major classes of broadcasts that can be received:
主要有两种广播可以被接收：

Normal broadcasts (sent with Context.sendBroadcast) are completely asynchronous. All receivers of the broadcast are run in an undefined order, often at the same time. This is more efficient, but means that receivers cannot use the result or abort APIs included here.
无序广播（使用Context.sendBroadcast发送）是完全异步的。所有的广播接收者运行是并发的。这种方式更加高效，但是意味着接收者不能使用结果或者中断API。

Ordered broadcasts (sent with Context.sendOrderedBroadcast) are delivered to one receiver at a time. As each receiver executes in turn, it can propagate a result to the next receiver, or it can completely abort the broadcast so that it won’t be passed to other receivers. The order receivers run in can be controlled with the android:priority attribute of the matching intent-filter; receivers with the same priority will be run in an arbitrary order.
有序广播（使用Context.sendOrderBroadcast发送）同一时间只能传递给一个接收者。由于每个接收者是轮流执行的，它可以传递一个结果给下一个接收者，或者它能完全中断广播而不往下传递。有序接收者可以通过intent-filter的android:priority属性匹配；拥有同一优先级的接收者会以随机顺序执行。

Even in the case of normal broadcasts, the system may in some situations revert to delivering the broadcast one receiver at a time. In particular, for receivers that may require the creation of a process, only one will be run at a time to avoid overloading the system with new processes. In this situation, however, the non-ordered semantics hold: these receivers still cannot return results or abort their broadcast.
系统在一些特定时候可能会恢复到一次传递一个广播给一个接收者甚至是无序广播也会。特别地，接收者可能会要求创建一个进程，为了避免系统负荷过重，这时只有一个接收者会运行。在这个场景下，无序接收者依然不能获得返回结果也不能中断。

Note that, although the Intent class is used for sending and receiving these broadcasts, the Intent broadcast mechanism here is completely separate from Intents that are used to start Activities with Context.startActivity(). There is no way for a BroadcastReceiver to see or capture Intents used with startActivity(); likewise, when you broadcast an Intent, you will never find or start an Activity. These two operations are semantically very different: starting an Activity with an Intent is a foreground operation that modifies what the user is currently interacting with; broadcasting an Intent is a background operation that the user is not normally aware of.
需要注意的是，尽管Intent类是用来发送和接收这些广播的，广播机制里的Intent和Activity的Context.startActivity()里的Intent是完全不同的。用来startActivity()的Intent，BroadcastReceiver是无法看见或者获取的；同样地，当你广播一个Intent时，你永远无法找到或打开Activity。这两个操作在语法上是完全不同的：使用Intent打开一个Activity是一个和用户交互的前台操作；使用Intent广播是一个用户关注不到的后台操作。

The BroadcastReceiver class (when launched as a component through a manifest’s tag) is an important part of an application’s overall lifecycle.
BroadcastReceiver类（当使用manifest的标签启动一个组件时）是应用整个生命周期中很重要的一部分。

Topics covered here:
有下面几个主题：

Security
Receiver Lifecycle
Process Lifecycle

---

Developer Guides

For information about how to use this class to receive and resolve intents, read the Intents and Intent Filters developer guide.
可以查看Intent和Intent Filters开发者指引来获取更多关于如何使用这个类来接收和处理intent。

---

Security

Receivers used with the Context APIs are by their nature a cross-application facility, so you must consider how other applications may be able to abuse your use of them. Some things to consider are:
使用Context的API的广播接收者是跨应用的，所以你必须考虑不被其他应用滥用。下面有一些需要考虑的：

The Intent namespace is global. Make sure that Intent action names and other strings are written in a namespace you own, or else you may inadvertently conflict with other applications.
Intent的命名空间是全局的。一定要保证Intent的action名和其他字符串是写在你自己的命名空间里，要不然你可能会和其他应用产生冲突。

When you use registerReceiver(BroadcastReceiver, IntentFilter), any application may send broadcasts to that registered receiver. You can control who can send broadcasts to it through permissions described below.
当你使用registerReceiver(BroadcastReceiver,IntentFilter)时，任何应用都可能发送广播给这个注册了的广播接收者。你可以通过下面描述的权限控制谁可以发送广播给它。

When you publish a receiver in your application’s manifest and specify intent-filters for it, any other application can send broadcasts to it regardless of the filters you specify. To prevent others from sending to it, make it unavailable to them with android:exported=”false”.
当你在manifest创建一个接收者并指定intent-filters时，任何其他的应用都可以不顾你指定的过滤器发送广播给它。为了防止其他应用发送广播给它，可以设置android:exported=”false”。

When you use sendBroadcast(Intent) or related methods, normally any other application can receive these broadcasts. You can control who can receive such broadcasts through permissions described below. Alternatively, starting with ICE_CREAM_SANDWICH, you can also safely restrict the broadcast to a single application with Intent.setPackage。
当你使用sendBroadcast(Intent)或者相关的方法时，一般来说任何其他的应用也可以接收到这些广播。你可以通过以下描述的权限控制谁可以接收到这些广播。从Android 4.0.4开始，你可以使用Intent.setPackage安全地限制广播到单一的应用。

None of these issues exist when using LocalBroadcastManager, since intents broadcast it never go outside of the current process.
当使用LocalBroadcastManager的时候，这些问题都不存在，因为这个广播使用不会超出当前进程。

Access permissions can be enforced by either the sender or receiver of a broadcast.
访问权限要么被广播的发送者，要么被广播的接收者执行。

To enforce a permission when sending, you supply a non-null permission argument to sendBroadcast(Intent, String) or sendOrderedBroadcast(Intent, String, BroadcastReceiver, android.os.Handler, int, String, Bundle). Only receivers who have been granted this permission (by requesting it with the tag in their AndroidManifest.xml) will be able to receive the broadcast.
为了在发送广播的时候执行权限，你要提供一个非NULL的权限变量给sendBroadcast(Intent，String)或者sendOrderedBroadcast(Intent，String，BroadcastReceiver，android.os.Handler，int，String，Bundle)。只有获得权限允许的接收者（通过在AndroidManifest.xml的标签请求）可以接收到广播。

To enforce a permission when receiving, you supply a non-null permission when registering your receiver – either when calling registerReceiver(BroadcastReceiver, IntentFilter, String, android.os.Handler) or in the static tag in your AndroidManifest.xml. Only broadcasters who have been granted this permission (by requesting it with the tag in their AndroidManifest.xml) will be able to send an Intent to the receiver.
为了在接收的时候执行权限，你需要在你注册接收者的时候提供一个非NULL的权限 – 或者在调用registerReceiver（BroadcastReceiver，IntentFilter，String，android.os.Handler）时或者在AndroidManifest.xml静态标签。只有获得权限允许的广播（通过在标签请求）可以发送Intent给接收者。

See the Security and Permissions document for more information on permissions and security in general.
可以在Security和Permission文档查看更多关于权限和安全的信息。

---

Receiver Lifecycle

A BroadcastReceiver object is only valid for the duration of the call to onReceive(Context, Intent). Once your code returns from this function, the system considers the object to be finished and no longer active.
一个广播接收者只有在onReceive(Context，Intent)方法调用时是有效的。一旦你的代码从这个函数中返回时，系统就认为这个对象结束了并且不再有效。

This has important repercussions to what you can do in an onReceive(Context, Intent) implementation: anything that requires asynchronous operation is not available, because you will need to return from the function to handle the asynchronous operation, but at that point the BroadcastReceiver is no longer active and thus the system is free to kill its process before the asynchronous operation completes.
这个对于你实现onReceive(Context，Intent)是有重要影响的：任何要求异步操作都是不可能的，因为你要从方法中返回来处理异步操作，但是这时候BroadcastReceiver不再活跃，因此系统在异步操作完成之前是可以干掉它的。

In particular, you may not show a dialog or bind to a service from within a BroadcastReceiver. For the former, you should instead use the NotificationManager API. For the latter, you can use Context.startService() to send a command to the service.
特别地，你不能从BroadcastReceiver里展示一个对话框或者绑定Service。对于前者，你应该使用NotificationManager API来代替。对于后者，你可以使用Context.startService()来发送一个命令给Service。

---

Process Lifecycle

A process that is currently executing a BroadcastReceiver (that is, currently running the code in its onReceive(Context, Intent) method) is considered to be a foreground process and will be kept running by the system except under cases of extreme memory pressure.
一个正在执行BroadcastReceiver的进程（指的是在onReceive(Context,Intent)方法执行代码）被认为是前台进程而且在系统极度稀缺内存前不会被干掉。

Once you return from onReceive(), the BroadcastReceiver is no longer active, and its hosting process is only as important as any other application components that are running in it. This is especially important because if that process was only hosting the BroadcastReceiver (a common case for applications that the user has never or not recently interacted with), then upon returning from onReceive() the system will consider its process to be empty and aggressively kill it so that resources are available for other more important processes.
一旦你从onReceive()放回，BroadcastReceiver不再活跃，持有它的进程和其他应用组件保持一样的重要性。这是格外重要的，因为如果进程只持有BroadcastReceiver（通常是用户不再或最近不和它产生交互），当从onReceive()返回时系统会认为这个进程是空的而且当有其他更重要的进程需要资源时会把它杀掉。

This means that for longer-running operations you will often use a Service in conjunction with a BroadcastReceiver to keep the containing process active for the entire time of your operation.
这意味着对于长时间运行的操作，你经常需要使用Service结合BroadcastReceiver来保持进程活跃，从而保证你的操作的完整。