BroadcastReceiver处理耗时操作

Long-Running Receivers and Services 

So far, we have covered the happy path of broadcast receivers w here the execution of a 
broadcast receiver is unlikely to take more than ten seconds. As it turns out, the 
problem space becomes a bit complicated if we  want to perform tasks that take longer than ten seconds. 

To understand why, let’s quickly review a few facts about broadcast receivers:  
 A broadcast receiver, like other components of an An droid process, 
runs on the main thread.  
 Holding up the code in a broadcast receiver will hold up the main 
thread and will result in ANR.  
 The time limit on a broadcast receiver is ten seconds compared to five 
seconds for an activity. It is a touch of a reprieve, but the limit is still 
there. 
 The process hosting the broadcast receiver will start and terminate 
along with the broadcast receiver execution. Hence the process will 
not stick around after  the broadcast receiver’s onReceive()  method 
returns. Of course, this is assumi ng that the process contains only the 
broadcast receiver. If the process contains other components, such as 
activities or services, that are alr eady running, then the lifetime of the 
process takes these component life cycles into account as well. 
 Unlike a service process, a broadcast receiver process will not get restarted.  
 If a broadcast receiver were to start  a separate thread  and return to 
the main thread, Android will assume that the work is complete and 
will shut down the process even if there are threads running, bringing 
those threads to abrupt stop.  
 Android acquires a partial wake lock when invoking a broadcast 
service and releases it when it re turns from the service in the main 
thread. A wake lock is a mechanism  and an API class available in the 
SDK to keep the device from going to sleep or wake it up if it is already asleep. 

Given these predicates, how can we ex ecute longer-running code in response to a 

broadcast event?

Long-Running Broadcast Receiver Protocol 
The answer lies in resolving the following:  
We will clearly need a separate thread so that the main thread can get 
back and avoid ANR messages.  
To stop Android from killing the process and hence the worker thread, 
we need to tell Android that this process contains a component, such 
as a service, with a life cycle. So we need to create or start that 
service. The service itself cannot directly do the work for more than 
five seconds because that happens on the main thread, so the service 
needs to start a worker thread and let the main thread go.  
For the duration of the worker thread’s execution, we need to hold on 
to the partial wake lock so that the device won’t go to sleep. A partial 
wake lock will allow the device to run code without turning on the 
screen and so on, which allows for longer battery life. 
The partial wake lock must be obtained in the main line code of the 
receiver; otherwise, it will be too late. For example, you cannot do this 
in the service, because it may be too late between the  startService()
being issued by the broadcast receiver and the  onStartCommand() of a 
service that begins execution. 
Because we are creating a service, the service itself can be brought 
down and brought back up because of low-memory conditions. If this 
happens, we need to acquire the wake lock again. 
When the worker thread started by the onStartCommand() method of 
the service completes its work, it needs to tell the service to stop so 
that it can be put to bed and not brought back to life by Android.  
It is also possible that more than one broadcast event can occur. 
Given that, we need to be cautious about how many worker threads 
we need to spawn. 

Given these facts, the recommended protocol for extending the life of a broadcast 
receiver is as follows: 

1. Get a (static) partial wake lock in the onReceive()  method of the 
broadcast receiver. The partial wake lock needs to be static to allow 
communication between the broadcast receiver and the service. There 
is no other way of passing a reference of the wake lock to the service, 
as the service is invoked through a default constructor that takes no 
parameters. 
2. Start a local service so that the process won’t be killed.  
CHAPTER 19:  Broadcast Receivers and Long-Running Services  516 
3.   In the service, start a worker thread  to do the work. Do not do the work 
in the  onStart()  method of the service. If you do, you are basically 
holding up the main thread again. 
4.   When the worker thread is done, tell the service to stop itself either 
directly or through a handler.  
5.   Have the service turn off the static  wake lock. To repeat, a static wake 
lock is the only way to communicate  between a service and its invoker, 
in this case the broadcast service,  because there is no way to pass a 
wake lock reference to the service.

You can read the book for more info, the following is an example:

public abstract class ALongRunningNonStickyBroadcastService  extends IntentService  {      public static String tag = "ALongRunningBroadcastService";     protected abstract void       handleBroadcastIntent(Intent broadcastIntent);          public ALongRunningNonStickyBroadcastService(String name){           super(name);         }          /*      * This method can be invoked under two circumstances       * 1. When a broadcast receiver issues a "startService"       * 2. when android restarts it due to pending "startService" intents.       *        * In case 1, the broadcast receiver has already      * setup the "lightedgreenroom".      *        * In case 2, we need to do the same.       */      @Override      public void onCreate()       {          super.onCreate();                   //Set up the green room          //The setup is capable of getting called multiple times.         LightedGreenRoom.setup(this.getApplicationContext());           //It is possible that more than one service          //of this type is running.           //Knowing the number will allow us to clean up           //the locks in ondestroy.          LightedGreenRoom.s_registerClient();     }      @Override      public int onStartCommand(Intent intent, int flag, int startId)      {          //Call the IntentService "onstart"         super.onStart(intent, startId);                   //Tell the green room there is a visitor         LightedGreenRoom.s_enter();                   //mark this as non sticky          //Means: Don't restart the service if there are no         //pending intents.         return Service.START_NOT_STICKY;     }      /*      * Note that this method call runs      * in a secondary thread setup by the IntentService.      *        * Override this method from IntentService.       * Retrieve the original broadcast intent.      * Call the derived class to handle the broadcast intent.       * finally tell the lighted room that you are leaving.      * if this is the last visitor then the lock        * will be released.      */      @Override          final protected void onHandleIntent(Intent intent)       {                  try {              Intent broadcastIntent             = intent.getParcelableExtra("original_intent");              handleBroadcastIntent(broadcastIntent);          }                  finally {              LightedGreenRoom.s_leave();          }          }      /*      * If Android reclaims this process,      * this method will release the lock        * irrespective of how many visitors there are.       */      @Override      public void onDestroy() {          super.onDestroy();         LightedGreenRoom.s_unRegisterClient();     }  }