Posted by YSY on October 20, 2018


又因为onReceive中的代码在执行完后,BroadcastReceiver对象就无效了,生命周期结束。 所以我们不能直接在里面起子线程,若应用进程被回收掉,线程的任务就可能无法完成。徒增不可控因素。

解决: 普遍的处理方式是在onReceive中再起一个IntentService去执行异步操作。这样就有了Service组件的保障,进程不会被轻易杀掉,但同时这个操作也比较重,代码实现上还得再去写个处理特殊业务的IntentService。


在API 11以后,BroadcastReceiver新增了一个静态内部类PendingResult,我们可以通过调用goAsync()方法来获取这个PendingResult对象,然后就可以愉快地进行子线程操作了,最后通过调用它的finish方法来结束广播接收者的生命。一切就变得可控了(相当于强行给Receiver续命)。

    public void onReceive(final Context context, final Intent intent) {
        final PendingResult result = goAsync();
        AsyncHandler.post(new Runnable() {
            public void run() {
                // 在这里搞事情
                // 成功续命,可以手动结束了

要注意的是,尽管这里可以异步操作,但耗时超过10s依然会爆ANR。 其中AsyncHandler是一个简单封装的可复用的异步操作类(来自Android源码):

 * Helper class for managing the background thread used to perform io operations
 * and handle async broadcasts.
public final class AsyncHandler {
    private static final HandlerThread sHandlerThread = new HandlerThread("AsyncHandler");
    private static final Handler sHandler;
    static {
        sHandler = new Handler(sHandlerThread.getLooper());
    public static void post(Runnable r) {
    public static void postDelayed(Runnable r, long delayedMills) {
        sHandler.postDelayed(r, delayedMills);
    public static Message obtain(Runnable r) {
        return Message.obtain(sHandler, r);
    public static void sendMessageDelayed(Message message, long delayedMills) {
        sHandler.sendMessageDelayed(message, delayedMills);
    public static void removeCallbacks(int what) {
    private AsyncHandler() {}


     * State for a result that is pending for a broadcast receiver.  Returned
     * by {@link BroadcastReceiver#goAsync() goAsync()}
     * while in {@link BroadcastReceiver#onReceive BroadcastReceiver.onReceive()}.
     * This allows you to return from onReceive() without having the broadcast
     * terminate; you must call {@link #finish()} once you are done with the
     * broadcast.  This allows you to process the broadcast off of the main
     * thread of your app.
     * <p>Note on threading: the state inside of this class is not itself
     * thread-safe, however you can use it from any thread if you properly
     * sure that you do not have races.  Typically this means you will hand
     * the entire object to another thread, which will be solely responsible
     * for setting any results and finally calling {@link #finish()}.
    public static class PendingResult {
     * This can be called by an application in {@link #onReceive} to allow
     * it to keep the broadcast active after returning from that function.
     * This does <em>not</em> change the expectation of being relatively
     * responsive to the broadcast (finishing it within 10s), but does allow
     * the implementation to move work related to it over to another thread
     * to avoid glitching the main UI thread due to disk IO.
     * @return Returns a {@link PendingResult} representing the result of
     * the active broadcast.  The BroadcastRecord itself is no longer active;
     * all data and other interaction must go through {@link PendingResult}
     * APIs.  The {@link PendingResult#finish PendingResult.finish()} method
     * must be called once processing of the broadcast is done.
    public final PendingResult goAsync() {
        PendingResult res = mPendingResult;
        mPendingResult = null;
        return res;