在Android系統(tǒng)中，廣播（Broadcast）是在組件之間傳播數(shù)據(jù)（Intent）的一種機(jī)制；這些組件甚至是可以位于不同的進(jìn)程中，這樣它就像Binder機(jī)制一樣，起到進(jìn)程間通信的作用。

在Android系統(tǒng)中，為什么需要廣播機(jī)制呢？如果是兩個(gè)組件位于不同的進(jìn)程當(dāng)中，那么可以用Binder機(jī)制來(lái)實(shí)現(xiàn)，如果兩個(gè)組件是在同一個(gè)進(jìn)程中，那么它們之間可以用來(lái)通信的方式就更多了，這樣看來(lái)，廣播機(jī)制似乎是多余的。

然而，廣播機(jī)制卻是不可替代的，它和Binder機(jī)制不一樣的地方在于，廣播的發(fā)送者和接收者事先是不需要知道對(duì)方的存在的，這樣帶來(lái)的好處便是，系統(tǒng)的各個(gè)組件可以松耦合地組織在一起，這樣系統(tǒng)就具有高度的可擴(kuò)展性，容易與其它系統(tǒng)進(jìn)行集成。

(相關(guān)資料圖)

使用廣播的兩個(gè)步驟： 1、廣播的接收者需要通過(guò)調(diào)用registerReceiver函數(shù)告訴系統(tǒng)，它對(duì)什么樣的廣播有興趣，即指定IntentFilter，并且向系統(tǒng)注冊(cè)廣播接收器，即指定BroadcastReceiver：

IntentFilter counterActionFilter = new IntentFilter(CounterService.BROADCAST_COUNTER_ACTION);  registerReceiver(counterActionReceiver, counterActionFilter);  

這里，指定感興趣的廣播就是CounterService.BROADCAST_COUNTER_ACTION了，而指定的廣播接收器就是counterActonReceiver，它是一個(gè)BroadcastReceiver類型的實(shí)例。

2、廣播的發(fā)送者通過(guò)調(diào)用sendBroadcast函數(shù)來(lái)發(fā)送一個(gè)指定的廣播，并且可以指定廣播的相關(guān)參數(shù)：

Intent intent = new Intent(BROADCAST_COUNTER_ACTION);  intent.putExtra(COUNTER_VALUE, counter);  sendBroadcast(intent)  

這里，指定的廣播為CounterService.BROADCAST_COUNTER_ACTION，并且附帶的帶參數(shù)當(dāng)前的計(jì)數(shù)器值counter。調(diào)用了sendBroadcast函數(shù)之后，所有注冊(cè)了CounterService.BROADCAST_COUNTER_ACTION廣播的接收者便可以收到這個(gè)廣播了。

在第1步中，廣播的接收者把廣播接收器注冊(cè)到ActivityManagerService中；在第2步中，廣播的發(fā)送者同樣是把廣播發(fā)送到ActivityManagerService中，由ActivityManagerService去查找注冊(cè)了這個(gè)廣播的接收者，然后把廣播分發(fā)給它們。

在第2步的分發(fā)的過(guò)程，其實(shí)就是把這個(gè)廣播轉(zhuǎn)換成一個(gè)消息，然后放入到接收器所在的線程消息隊(duì)列中去，最后就可以在消息循環(huán)中調(diào)用接收器的onReceive函數(shù)了。這里有一個(gè)要非常注意的地方是，由于ActivityManagerService把這個(gè)廣播放進(jìn)接收器所在的線程消息隊(duì)列后，就返回了，它不關(guān)心這個(gè)消息什么時(shí)候會(huì)被處理，因此，對(duì)廣播的處理是異步的，即調(diào)用sendBroadcast時(shí)，這個(gè)函數(shù)不會(huì)等待這個(gè)廣播被處理完后才返回。

虛線上面Step 1到Step 4步是注冊(cè)廣播接收器的過(guò)程，其中Step 2通過(guò)LoadedApk.getReceiverDispatcher在LoadedApk內(nèi)部創(chuàng)建了一個(gè)IIntentReceiver接口，并且傳遞給ActivityManagerService；

虛線下面的Step 5到Step 11是發(fā)送廣播的過(guò)程，在Step 8中，ActivityManagerService利用上面得到的IIntentReceiver遠(yuǎn)程接口，調(diào)用LoadedApk.performReceiver接口，LoadedApk.performReceiver接口通過(guò)ActivityThread.H接口的post函數(shù)將這個(gè)廣播消息放入到ActivityThread的消息隊(duì)列中去，最后這個(gè)消息在LoadedApk的Args.run函數(shù)中處理，LoadedApk.Args.run函數(shù)接著調(diào)用MainActivity.BroadcastReceiver的onReceive函數(shù)來(lái)最終處理這個(gè)廣播。

注冊(cè)廣播接收器（registerReceiver）

在Android的廣播機(jī)制中，ActivityManagerService扮演著廣播中心的角色，負(fù)責(zé)系統(tǒng)中所有廣播的注冊(cè)和發(fā)布操作，因此，Android應(yīng)用程序注冊(cè)廣播接收器的過(guò)程就把是廣播接收器注冊(cè)到ActivityManagerService的過(guò)程。Android應(yīng)用程序是通過(guò)調(diào)用ContextWrapper類的registerReceiver函數(shù)來(lái)把廣播接收器BroadcastReceiver注冊(cè)到ActivityManagerService中去的，而ContextWrapper類本身又借助ContextImpl類來(lái)注冊(cè)廣播接收器。

在Android應(yīng)用程序框架中，Activity和Service類都繼承了ContextWrapper類，因此，我們可以在Activity或者Service的子類中調(diào)用registerReceiver函數(shù)來(lái)注冊(cè)廣播接收器。

我們先來(lái)看一下MainActivity是如何調(diào)用registerReceiver函數(shù)來(lái)注冊(cè)廣播接收器的：

public class MainActivity extends Activity implements OnClickListener {......        @Override         public void onResume() {super.onResume();              IntentFilter counterActionFilter = new IntentFilter(CounterService.BROADCAST_COUNTER_ACTION);            registerReceiver(counterActionReceiver, counterActionFilter);        }         ......    }

Step 1. ContextWrapper.registerReceiver

public class ContextWrapper extends Context {Context mBase;      ......        @Override      public Intent registerReceiver(          BroadcastReceiver receiver, IntentFilter filter) {return mBase.registerReceiver(receiver, filter);      }        ......    }  

這里的成員變量mBase是一個(gè)ContextImpl實(shí)例。

Step 2. ContextImpl.registerReceiver

class ContextImpl extends Context {......        @Override      public Intent registerReceiver(BroadcastReceiver receiver, IntentFilter filter) {return registerReceiver(receiver, filter, null, null);      }        @Override      public Intent registerReceiver(BroadcastReceiver receiver, IntentFilter filter,              String broadcastPermission, Handler scheduler) {return registerReceiverInternal(receiver, filter, broadcastPermission,              scheduler, getOuterContext());      }        private Intent registerReceiverInternal(BroadcastReceiver receiver,              IntentFilter filter, String broadcastPermission,              Handler scheduler, Context context) {IIntentReceiver rd = null;          if (receiver != null) {if (mPackageInfo != null && context != null) {if (scheduler == null) {scheduler = mMainThread.getHandler();                  }                  rd = mPackageInfo.getReceiverDispatcher(                      receiver, context, scheduler,                      mMainThread.getInstrumentation(), true);              } else {......              }          }          try {return ActivityManagerNative.getDefault().registerReceiver(                      mMainThread.getApplicationThread(),                      rd, filter, broadcastPermission);          } catch (RemoteException e) {return null;          }      }        ......    }  

通過(guò)兩個(gè)函數(shù)的中轉(zhuǎn)，最終就進(jìn)入到ContextImpl.registerReceiverInternal這個(gè)函數(shù)來(lái)了。這里的成員變量mPackageInfo是一個(gè)LoadedApk實(shí)例，它是用來(lái)負(fù)責(zé)處理廣播的接收的。

參數(shù)broadcastPermission和scheduler都為null，而參數(shù)context是上面的函數(shù)通過(guò)調(diào)用函數(shù)getOuterContext得到的，這里它就是指向MainActivity了，因?yàn)镸ainActivity是繼承于Context類的，因此，這里用Context類型來(lái)引用。

由于條件mPackageInfo != null和context != null都成立，而且條件scheduler == null也成立，于是就調(diào)用mMainThread.getHandler來(lái)獲得一個(gè)Handler了，這個(gè)Hanlder是后面用來(lái)分發(fā)ActivityManagerService發(fā)送過(guò)的廣播用的。這里的成員變量mMainThread是一個(gè)ActivityThread實(shí)例。

Step 3. ActivityThread.getHandler

public final class ActivityThread {......        final H mH = new H();        private final class H extends Handler {......            public void handleMessage(Message msg) {......                switch (msg.what) {......              }                ......          }            ......        }        ......        final Handler getHandler() {return mH;      }        ......    }  

有了這個(gè)Handler之后，就可以分發(fā)消息給應(yīng)用程序處理了。

再回到上一步的ContextImpl.registerReceiverInternal函數(shù)中，它通過(guò)mPackageInfo.getReceiverDispatcher函數(shù)獲得一個(gè)IIntentReceiver接口對(duì)象rd，這是一個(gè)Binder對(duì)象，接下來(lái)會(huì)把它傳給ActivityManagerService，ActivityManagerService在收到相應(yīng)的廣播時(shí)，就是通過(guò)這個(gè)Binder對(duì)象來(lái)通知MainActivity來(lái)接收的。

Step 4. LoadedApk.getReceiverDispatcher

final class LoadedApk {......        public IIntentReceiver getReceiverDispatcher(BroadcastReceiver r,              Context context, Handler handler,              Instrumentation instrumentation, boolean registered) {synchronized (mReceivers) {LoadedApk.ReceiverDispatcher rd = null;              HashMap map = null;              if (registered) {map = mReceivers.get(context);                  if (map != null) {rd = map.get(r);                  }              }              if (rd == null) {rd = new ReceiverDispatcher(r, context, handler,                      instrumentation, registered);                  if (registered) {if (map == null) {map = new HashMap();                          mReceivers.put(context, map);                      }                      map.put(r, rd);                  }              } else {rd.validate(context, handler);              }              return rd.getIIntentReceiver();          }      }        ......        static final class ReceiverDispatcher {final static class InnerReceiver extends IIntentReceiver.Stub {final WeakReference mDispatcher;              ......                InnerReceiver(LoadedApk.ReceiverDispatcher rd, boolean strong) {mDispatcher = new WeakReference(rd);                  ......              }                ......          }            ......            final IIntentReceiver.Stub mIIntentReceiver;          final Handler mActivityThread;            ......            ReceiverDispatcher(BroadcastReceiver receiver, Context context,                  Handler activityThread, Instrumentation instrumentation,                  boolean registered) {......                mIIntentReceiver = new InnerReceiver(this, !registered);              mActivityThread = activityThread;                            ......          }            ......            IIntentReceiver getIIntentReceiver() {return mIIntentReceiver;          }        }        ......    }  

在LoadedApk.getReceiverDispatcher函數(shù)中，首先看一下參數(shù)r是不是已經(jīng)有相應(yīng)的ReceiverDispatcher存在了，如果有，就直接返回了，否則就新建一個(gè)ReceiverDispatcher，并且以r為Key值保在一個(gè)HashMap中，而這個(gè)HashMap以Context，這里即為MainActivity為Key值保存在LoadedApk的成員變量mReceivers中，這樣，只要給定一個(gè)Activity和BroadcastReceiver，就可以查看LoadedApk里面是否已經(jīng)存在相應(yīng)的廣播接收發(fā)布器ReceiverDispatcher了。

在新建廣播接收發(fā)布器ReceiverDispatcher時(shí)，會(huì)在構(gòu)造函數(shù)里面創(chuàng)建一個(gè)InnerReceiver實(shí)例，這是一個(gè)Binder對(duì)象，實(shí)現(xiàn)了IIntentReceiver接口，可以通過(guò)ReceiverDispatcher.getIIntentReceiver函數(shù)來(lái)獲得，獲得后就會(huì)把它傳給ActivityManagerService，以便接收廣播。

在ReceiverDispatcher類的構(gòu)造函數(shù)中，還會(huì)把傳進(jìn)來(lái)的Handle類型的參數(shù)activityThread保存下來(lái)，以便后面在分發(fā)廣播的時(shí)候使用。

現(xiàn)在，再回到ContextImpl.registerReceiverInternal函數(shù)，在獲得了IIntentReceiver類型的Binder對(duì)象后，就開始要把它注冊(cè)到ActivityManagerService中去了。

Step 5. ActivityManagerProxy.registerReceiver

class ActivityManagerProxy implements IActivityManager  {......        public Intent registerReceiver(IApplicationThread caller,              IIntentReceiver receiver,              IntentFilter filter, String perm) throws RemoteException      {Parcel data = Parcel.obtain();          Parcel reply = Parcel.obtain();          data.writeInterfaceToken(IActivityManager.descriptor);          data.writeStrongBinder(caller != null ? caller.asBinder() : null);          data.writeStrongBinder(receiver != null ? receiver.asBinder() : null);          filter.writeToParcel(data, 0);          data.writeString(perm);          mRemote.transact(REGISTER_RECEIVER_TRANSACTION, data, reply, 0);          reply.readException();          Intent intent = null;          int haveIntent = reply.readInt();          if (haveIntent != 0) {intent = Intent.CREATOR.createFromParcel(reply);          }          reply.recycle();          data.recycle();          return intent;      }        ......    }  

這個(gè)函數(shù)通過(guò)Binder驅(qū)動(dòng)程序就進(jìn)入到ActivityManagerService中的registerReceiver函數(shù)中去了。

Step 6. ActivityManagerService.registerReceiver

public final class ActivityManagerService extends ActivityManagerNative          implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {......        public Intent registerReceiver(IApplicationThread caller,              IIntentReceiver receiver, IntentFilter filter, String permission) {synchronized(this) {ProcessRecord callerApp = null;              if (caller != null) {callerApp = getRecordForAppLocked(caller);                  if (callerApp == null) {......                  }              }                List allSticky = null;                // Look for any matching sticky broadcasts...              Iterator actions = filter.actionsIterator();              if (actions != null) {while (actions.hasNext()) {String action = (String)actions.next();                      allSticky = getStickiesLocked(action, filter, allSticky);                  }              } else {......              }                // The first sticky in the list is returned directly back to              // the client.              Intent sticky = allSticky != null ? (Intent)allSticky.get(0) : null;                ......                if (receiver == null) {return sticky;              }                ReceiverList rl                  = (ReceiverList)mRegisteredReceivers.get(receiver.asBinder());              if (rl == null) {rl = new ReceiverList(this, callerApp,                      Binder.getCallingPid(),                      Binder.getCallingUid(), receiver);                    if (rl.app != null) {rl.app.receivers.add(rl);                  } else {......                  }                  mRegisteredReceivers.put(receiver.asBinder(), rl);              }                BroadcastFilter bf = new BroadcastFilter(filter, rl, permission);              rl.add(bf);              ......              mReceiverResolver.addFilter(bf);                // Enqueue broadcasts for all existing stickies that match              // this filter.              if (allSticky != null) {......              }                return sticky;          }      }        ......    }  

函數(shù)首先是獲得調(diào)用registerReceiver函數(shù)的應(yīng)用程序進(jìn)程記錄塊：

ProcessRecord callerApp = null;     if (caller != null) {callerApp = getRecordForAppLocked(caller);  if (callerApp == null) {......         }     }  

這里得到的便是應(yīng)用程序Broadcast的進(jìn)程記錄塊了，MainActivity就是在里面啟動(dòng)起來(lái)的。

List allSticky = null;       // Look for any matching sticky broadcasts...     Iterator actions = filter.actionsIterator();     if (actions != null) {while (actions.hasNext()) {String action = (String)actions.next();      allSticky = getStickiesLocked(action, filter, allSticky);  }     } else {......     }       // The first sticky in the list is returned directly back to     // the client.     Intent sticky = allSticky != null ? (Intent)allSticky.get(0) : null; 

這里傳進(jìn)來(lái)的filter只有一個(gè)action，就是前面描述的CounterService.BROADCAST_COUNTER_ACTION了，這里先通過(guò)getStickiesLocked函數(shù)查找一下有沒(méi)有對(duì)應(yīng)的sticky intent列表存在。什么是Sticky Intent呢？我們?cè)谧詈笠淮握{(diào)用sendStickyBroadcast函數(shù)來(lái)發(fā)送某個(gè)Action類型的廣播時(shí)，系統(tǒng)會(huì)把代表這個(gè)廣播的Intent保存下來(lái)，這樣，后來(lái)調(diào)用registerReceiver來(lái)注冊(cè)相同Action類型的廣播接收器，就會(huì)得到這個(gè)最后發(fā)出的廣播。這就是為什么叫做Sticky Intent了，這個(gè)最后發(fā)出的廣播雖然被處理完了，但是仍然被粘住在ActivityManagerService中，以便下一個(gè)注冊(cè)相應(yīng)Action類型的廣播接收器還能繼承處理。

這里，假設(shè)我們不使用sendStickyBroadcast來(lái)發(fā)送CounterService.BROADCAST_COUNTER_ACTION類型的廣播，于是，這里得到的allSticky和sticky都為null了。

繼續(xù)往下看，這里傳進(jìn)來(lái)的receiver不為null，于是，繼續(xù)往下執(zhí)行：

ReceiverList rl  = (ReceiverList)mRegisteredReceivers.get(receiver.asBinder());     if (rl == null) {rl = new ReceiverList(this, callerApp,      Binder.getCallingPid(),      Binder.getCallingUid(), receiver);    if (rl.app != null) {rl.app.receivers.add(rl);  } else {......  }  mRegisteredReceivers.put(receiver.asBinder(), rl);     }  

這里其實(shí)就是把廣播接收器receiver保存一個(gè)ReceiverList列表中，這個(gè)列表的宿主進(jìn)程是rl.app，這里就是MainActivity所在的進(jìn)程了，在ActivityManagerService中，用一個(gè)進(jìn)程記錄塊來(lái)表示這個(gè)應(yīng)用程序進(jìn)程，它里面有一個(gè)列表receivers，專門用來(lái)保存這個(gè)進(jìn)程注冊(cè)的廣播接收器。接著，又把這個(gè)ReceiverList列表以receiver為Key值保存在ActivityManagerService的成員變量mRegisteredReceivers中，這些都是為了方便在收到廣播時(shí)，快速找到對(duì)應(yīng)的廣播接收器的。

再往下看：

BroadcastFilter bf = new BroadcastFilter(filter, rl, permission);  rl.add(bf);  ......  mReceiverResolver.addFilter(bf); 

上面只是把廣播接收器receiver保存起來(lái)了，但是還沒(méi)有把它和filter關(guān)聯(lián)起來(lái)，這里就創(chuàng)建一個(gè)BroadcastFilter來(lái)把廣播接收器列表rl和filter關(guān)聯(lián)起來(lái)，然后保存在ActivityManagerService中的成員變量mReceiverResolver中去。

發(fā)送廣播（sendBroadcast）的過(guò)程分析

前面我們分析了Android應(yīng)用程序注冊(cè)廣播接收器的過(guò)程，這個(gè)過(guò)程只完成了萬(wàn)里長(zhǎng)征的第一步，接下來(lái)它還要等待ActivityManagerService將廣播分發(fā)過(guò)來(lái)。

廣播的發(fā)送過(guò)程比廣播接收器的注冊(cè)過(guò)程要復(fù)雜得多了，不過(guò)這個(gè)過(guò)程仍然是以ActivityManagerService為中心。廣播的發(fā)送者將廣播發(fā)送到ActivityManagerService，ActivityManagerService接收到這個(gè)廣播以后，就會(huì)在自己的注冊(cè)中心查看有哪些廣播接收器訂閱了該廣播，然后把這個(gè)廣播逐一發(fā)送到這些廣播接收器中，但是ActivityManagerService并不等待廣播接收器處理這些廣播就返回了，因此，廣播的發(fā)送和處理是異步的。

在分析廣播的發(fā)送過(guò)程前，我們先來(lái)看一下廣播發(fā)送過(guò)程的序列圖，然后按照這個(gè)序圖中的步驟來(lái)一步一步分析整個(gè)過(guò)程。

Step 1. ContextWrapper.sendBroadcast

public class ContextWrapper extends Context {Context mBase;        ......        @Override      public void sendBroadcast(Intent intent) {mBase.sendBroadcast(intent);      }        ......    }  

Step 2. ContextImpl.sendBroadcast

class ContextImpl extends Context {......        @Override      public void sendBroadcast(Intent intent) {String resolvedType = intent.resolveTypeIfNeeded(getContentResolver());          try {ActivityManagerNative.getDefault().broadcastIntent(                  mMainThread.getApplicationThread(), intent, resolvedType, null,                  Activity.RESULT_OK, null, null, null, false, false);          } catch (RemoteException e) {}      }        ......    }  

這里的resolvedType表示這個(gè)Intent的MIME類型，我們沒(méi)有設(shè)置這個(gè)Intent的MIME類型，因此，這里的resolvedType為null。接下來(lái)就調(diào)用ActivityManagerService的遠(yuǎn)程接口ActivityManagerProxy把這個(gè)廣播發(fā)送給ActivityManagerService了。

Step 3. ActivityManagerProxy.broadcastIntent

class ActivityManagerProxy implements IActivityManager  {......        public int broadcastIntent(IApplicationThread caller,          Intent intent, String resolvedType,  IIntentReceiver resultTo,          int resultCode, String resultData, Bundle map,          String requiredPermission, boolean serialized,          boolean sticky) throws RemoteException      {Parcel data = Parcel.obtain();          Parcel reply = Parcel.obtain();          data.writeInterfaceToken(IActivityManager.descriptor);          data.writeStrongBinder(caller != null ? caller.asBinder() : null);          intent.writeToParcel(data, 0);          data.writeString(resolvedType);          data.writeStrongBinder(resultTo != null ? resultTo.asBinder() : null);          data.writeInt(resultCode);          data.writeString(resultData);          data.writeBundle(map);          data.writeString(requiredPermission);          data.writeInt(serialized ? 1 : 0);          data.writeInt(sticky ? 1 : 0);          mRemote.transact(BROADCAST_INTENT_TRANSACTION, data, reply, 0);          reply.readException();          int res = reply.readInt();          reply.recycle();          data.recycle();          return res;      }        ......    }  

Step 4. ActivityManagerService.broadcastIntent

public final class ActivityManagerService extends ActivityManagerNative          implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {......        public final int broadcastIntent(IApplicationThread caller,              Intent intent, String resolvedType, IIntentReceiver resultTo,              int resultCode, String resultData, Bundle map,              String requiredPermission, boolean serialized, boolean sticky) {synchronized(this) {intent = verifyBroadcastLocked(intent);                final ProcessRecord callerApp = getRecordForAppLocked(caller);              final int callingPid = Binder.getCallingPid();              final int callingUid = Binder.getCallingUid();              final long origId = Binder.clearCallingIdentity();              int res = broadcastIntentLocked(callerApp,                  callerApp != null ? callerApp.info.packageName : null,                  intent, resolvedType, resultTo,                  resultCode, resultData, map, requiredPermission, serialized,                  sticky, callingPid, callingUid);              Binder.restoreCallingIdentity(origId);              return res;          }      }        ......  }  

這里調(diào)用broadcastIntentLocked函數(shù)來(lái)進(jìn)一步處理。

Step 5. ActivityManagerService.broadcastIntentLocked

public final class ActivityManagerService extends ActivityManagerNative          implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {......        private final int broadcastIntentLocked(ProcessRecord callerApp,              String callerPackage, Intent intent, String resolvedType,              IIntentReceiver resultTo, int resultCode, String resultData,              Bundle map, String requiredPermission,              boolean ordered, boolean sticky, int callingPid, int callingUid) {intent = new Intent(intent);            ......            // Figure out who all will receive this broadcast.          List receivers = null;          List registeredReceivers = null;          try {if (intent.getComponent() != null) {......              } else {......                  registeredReceivers = mReceiverResolver.queryIntent(intent, resolvedType, false);              }          } catch (RemoteException ex) {......          }            final boolean replacePending =              (intent.getFlags()&Intent.FLAG_RECEIVER_REPLACE_PENDING) != 0;            int NR = registeredReceivers != null ? registeredReceivers.size() : 0;          if (!ordered && NR > 0) {// If we are not serializing this broadcast, then send the              // registered receivers separately so they don"t wait for the              // components to be launched.              BroadcastRecord r = new BroadcastRecord(intent, callerApp,                  callerPackage, callingPid, callingUid, requiredPermission,                  registeredReceivers, resultTo, resultCode, resultData, map,                  ordered, sticky, false);              ......              boolean replaced = false;              if (replacePending) {for (int i=mParallelBroadcasts.size()-1; i>=0; i--) {if (intent.filterEquals(mParallelBroadcasts.get(i).intent)) {......                          mParallelBroadcasts.set(i, r);                          replaced = true;                          break;                      }                  }              }                if (!replaced) {mParallelBroadcasts.add(r);                    scheduleBroadcastsLocked();              }                registeredReceivers = null;              NR = 0;          }            ......        }        ......  }  

這個(gè)函數(shù)首先是根據(jù)intent找出相應(yīng)的廣播接收器：

// Figure out who all will receive this broadcast.     List receivers = null;     List registeredReceivers = null;     try {if (intent.getComponent() != null) {......  } else {......      registeredReceivers = mReceiverResolver.queryIntent(intent, resolvedType, false);  }     } catch (RemoteException ex) {......     }  

回憶一下前面過(guò)程分析中的Step 6（ActivityManagerService.registerReceiver）中，我們將一個(gè)filter類型為BROADCAST_COUNTER_ACTION類型的BroadcastFilter實(shí)例保存在了ActivityManagerService的成員變量mReceiverResolver中，這個(gè)BroadcastFilter實(shí)例包含了我們所注冊(cè)的廣播接收器，這里就通過(guò)mReceiverResolver.queryIntent函數(shù)將這個(gè)BroadcastFilter實(shí)例取回來(lái)。由于注冊(cè)一個(gè)廣播類型的接收器可能有多個(gè)，所以這里把所有符合條件的的BroadcastFilter實(shí)例放在一個(gè)List中，然后返回來(lái)。在我們這個(gè)場(chǎng)景中，這個(gè)List就只有一個(gè)BroadcastFilter實(shí)例了，就是MainActivity注冊(cè)的那個(gè)廣播接收器。

繼續(xù)往下看：

final boolean replacePending =  (intent.getFlags()&Intent.FLAG_RECEIVER_REPLACE_PENDING) != 0;  

這里是查看一下這個(gè)intent的Intent.FLAG_RECEIVER_REPLACE_PENDING位有沒(méi)有設(shè)置，如果設(shè)置了的話，ActivityManagerService就會(huì)在當(dāng)前的系統(tǒng)中查看有沒(méi)有相同的intent還未被處理，如果有的話，就有當(dāng)前這個(gè)新的intent來(lái)替換舊的intent。這里，我們沒(méi)有設(shè)置intent的Intent.FLAG_RECEIVER_REPLACE_PENDING位，因此，這里的replacePending變量為false。

再接著往下看：

int NR = registeredReceivers != null ? registeredReceivers.size() : 0;    if (!ordered && NR > 0) {// If we are not serializing this broadcast, then send the  // registered receivers separately so they don"t wait for the  // components to be launched.  BroadcastRecord r = new BroadcastRecord(intent, callerApp,      callerPackage, callingPid, callingUid, requiredPermission,      registeredReceivers, resultTo, resultCode, resultData, map,      ordered, sticky, false);  ......  boolean replaced = false;  if (replacePending) {for (int i=mParallelBroadcasts.size()-1; i>=0; i--) {if (intent.filterEquals(mParallelBroadcasts.get(i).intent)) {......              mParallelBroadcasts.set(i, r);              replaced = true;              break;          }      }  }    if (!replaced) {mParallelBroadcasts.add(r);        scheduleBroadcastsLocked();  }    registeredReceivers = null;  NR = 0;     }  

前面我們說(shuō)到，這里得到的列表registeredReceivers的大小為1，且傳進(jìn)來(lái)的參數(shù)ordered為false，表示要將這個(gè)廣播發(fā)送給所有注冊(cè)了BROADCAST_COUNTER_ACTION類型廣播的接收器，因此，會(huì)執(zhí)行下面的if語(yǔ)句。這個(gè)if語(yǔ)句首先創(chuàng)建一個(gè)廣播記錄塊BroadcastRecord，里面記錄了這個(gè)廣播是由誰(shuí)發(fā)出的以及要發(fā)給誰(shuí)等相關(guān)信息。由于前面得到的replacePending變量為false，因此，不會(huì)執(zhí)行接下來(lái)的if語(yǔ)句，即不會(huì)檢查系統(tǒng)中是否有相同類型的未處理的廣播。

這樣，這里得到的replaced變量的值也為false，于是，就會(huì)把這個(gè)廣播記錄塊r放在ActivityManagerService的成員變量mParcelBroadcasts中，等待進(jìn)一步處理；進(jìn)一步處理的操作由函數(shù)scheduleBroadcastsLocked進(jìn)行。

Step 6. ActivityManagerService.scheduleBroadcastsLocked

public final class ActivityManagerService extends ActivityManagerNative          implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {......        private final void scheduleBroadcastsLocked() {......            if (mBroadcastsScheduled) {return;          }            mHandler.sendEmptyMessage(BROADCAST_INTENT_MSG);          mBroadcastsScheduled = true;      }        ......  }  

這里的mBroadcastsScheduled表示ActivityManagerService當(dāng)前是不是正在處理其它廣播，如果是的話，這里就先不處理直接返回了，保證所有廣播串行處理。

注意這里處理廣播的方式，它是通過(guò)消息循環(huán)來(lái)處理，每當(dāng)ActivityManagerService接收到一個(gè)廣播時(shí)，它就把這個(gè)廣播放進(jìn)自己的消息隊(duì)列去就完事了，根本不管這個(gè)廣播后續(xù)是處理的，因此，這里我們可以看出廣播的發(fā)送和處理是異步的。

這里的成員變量mHandler是一個(gè)在ActivityManagerService內(nèi)部定義的Handler類變量，通過(guò)它的sendEmptyMessage函數(shù)把一個(gè)類型為BROADCAST_INTENT_MSG的空消息放進(jìn)ActivityManagerService的消息隊(duì)列中去。這里的空消息是指這個(gè)消息除了有類型信息之外，沒(méi)有任何其它額外的信息，因?yàn)榍懊嬉呀?jīng)把要處理的廣播信息都保存在mParcelBroadcasts中了，等處理這個(gè)消息時(shí)，從mParcelBroadcasts就可以讀回相關(guān)的廣播信息了，因此，這里不需要把廣播信息再放在消息內(nèi)容中。

Step 7. Handler.sendEmptyMessage

這個(gè)自定義的Handler類實(shí)現(xiàn)在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中，它是ActivityManagerService的內(nèi)部類，調(diào)用了它的sendEmptyMessage函數(shù)來(lái)把一個(gè)消息放到消息隊(duì)列后，一會(huì)就會(huì)調(diào)用它的handleMessage函數(shù)來(lái)真正處理這個(gè)消息：

public final class ActivityManagerService extends ActivityManagerNative          implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {......        final Handler mHandler = new Handler() {public void handleMessage(Message msg) {switch (msg.what) {......              case BROADCAST_INTENT_MSG: {......                  processNextBroadcast(true);              } break;              ......              }          }      }        ......  }   

這里又調(diào)用了ActivityManagerService的processNextBroadcast函數(shù)來(lái)處理下一個(gè)未處理的廣播。

Step 8. ActivityManagerService.processNextBroadcast

public final class ActivityManagerService extends ActivityManagerNative          implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {......        private final void processNextBroadcast(boolean fromMsg) {synchronized(this) {BroadcastRecord r;                ......                if (fromMsg) {mBroadcastsScheduled = false;              }                // First, deliver any non-serialized broadcasts right away.              while (mParallelBroadcasts.size() > 0) {r = mParallelBroadcasts.remove(0);                  ......                  final int N = r.receivers.size();                  ......                  for (int i=0; iObject target = r.receivers.get(i);                      ......                        deliverToRegisteredReceiverLocked(r, (BroadcastFilter)target, false);                  }                  addBroadcastToHistoryLocked(r);                  ......              }                ......            }      }        ......  }  

這里傳進(jìn)來(lái)的參數(shù)fromMsg為true，于是把mBroadcastScheduled重新設(shè)為false，這樣，下一個(gè)廣播就能進(jìn)入到消息隊(duì)列中進(jìn)行處理了。前面我們?cè)赟tep 5中，把一個(gè)廣播記錄塊BroadcastRecord放在了mParallelBroadcasts中，因此，這里就把它取出來(lái)進(jìn)行處理了。廣播記錄塊BroadcastRecord的receivers列表中包含了要接收這個(gè)廣播的目標(biāo)列表，即前面我們注冊(cè)的廣播接收器，用BroadcastFilter來(lái)表示，這里while循環(huán)中的for循環(huán)就是把這個(gè)廣播發(fā)送給每一個(gè)訂閱了該廣播的接收器了，通過(guò)deliverToRegisteredReceiverLocked函數(shù)執(zhí)行。

Step 9. ActivityManagerService.deliverToRegisteredReceiverLocked

public final class ActivityManagerService extends ActivityManagerNative          implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {......        private final void deliverToRegisteredReceiverLocked(BroadcastRecord r,              BroadcastFilter filter, boolean ordered) {boolean skip = false;          if (filter.requiredPermission != null) {......          }          if (r.requiredPermission != null) {......          }            if (!skip) {// If this is not being sent as an ordered broadcast, then we              // don"t want to touch the fields that keep track of the current              // state of ordered broadcasts.              if (ordered) {......              }                try {......                  performReceiveLocked(filter.receiverList.app, filter.receiverList.receiver,                      new Intent(r.intent), r.resultCode,                      r.resultData, r.resultExtras, r.ordered, r.initialSticky);                  ......              } catch (RemoteException e) {......              }          }        }        ......  }  

函數(shù)首先是檢查一下廣播發(fā)送和接收的權(quán)限，在我們分析的這個(gè)場(chǎng)景中，沒(méi)有設(shè)置權(quán)限，因此，這個(gè)權(quán)限檢查就跳過(guò)了，這里得到的skip為false，于是進(jìn)入下面的if語(yǔ)句中。由于上面?zhèn)鲿r(shí)來(lái)的ordered參數(shù)為false，因此，直接就調(diào)用performReceiveLocked函數(shù)來(lái)進(jìn)一步執(zhí)行廣播發(fā)送的操作了。

Step 10. ActivityManagerService.performReceiveLocked

public final class ActivityManagerService extends ActivityManagerNative          implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {......        static void performReceiveLocked(ProcessRecord app, IIntentReceiver receiver,              Intent intent, int resultCode, String data, Bundle extras,              boolean ordered, boolean sticky) throws RemoteException {// Send the intent to the receiver asynchronously using one-way binder calls.          if (app != null && app.thread != null) {// If we have an app thread, do the call through that so it is              // correctly ordered with other one-way calls.              app.thread.scheduleRegisteredReceiver(receiver, intent, resultCode,                      data, extras, ordered, sticky);          } else {......          }      }        ......  }  

注意，這里傳進(jìn)來(lái)的參數(shù)app是注冊(cè)廣播接收器的Activity所在的進(jìn)程記錄塊，在我們分析的這個(gè)場(chǎng)景中，由于是MainActivity調(diào)用registerReceiver函數(shù)來(lái)注冊(cè)這個(gè)廣播接收器的，因此，參數(shù)app所代表的ProcessRecord就是MainActivity所在的進(jìn)程記錄塊了；

而參數(shù)receiver也是注冊(cè)廣播接收器時(shí)傳給ActivityManagerService的一個(gè)Binder對(duì)象，它的類型是IIntentReceiver。

MainActivity在注冊(cè)廣播接收器時(shí)，已經(jīng)把自己的ProcessRecord記錄下來(lái)了，所以這里的參數(shù)app和app.thread均不為null，于是，ActivityManagerService就調(diào)用app.thread.scheduleRegisteredReceiver函數(shù)來(lái)把這個(gè)廣播分發(fā)給MainActivity了。這里的app.thread是一個(gè)Binder遠(yuǎn)程對(duì)象，它的類型是ApplicationThreadProxy。

Step 11. ApplicationThreadProxy.scheduleRegisteredReceiver

class ApplicationThreadProxy implements IApplicationThread {......        public void scheduleRegisteredReceiver(IIntentReceiver receiver, Intent intent,              int resultCode, String dataStr, Bundle extras, boolean ordered, boolean sticky)              throws RemoteException {Parcel data = Parcel.obtain();          data.writeInterfaceToken(IApplicationThread.descriptor);          data.writeStrongBinder(receiver.asBinder());          intent.writeToParcel(data, 0);          data.writeInt(resultCode);          data.writeString(dataStr);          data.writeBundle(extras);          data.writeInt(ordered ? 1 : 0);          data.writeInt(sticky ? 1 : 0);          mRemote.transact(SCHEDULE_REGISTERED_RECEIVER_TRANSACTION, data, null,              IBinder.FLAG_ONEWAY);          data.recycle();      }        ......  }  

這里通過(guò)Binder驅(qū)動(dòng)程序就進(jìn)入到ApplicationThread.scheduleRegisteredReceiver函數(shù)去了。

Step 12. ApplicaitonThread.scheduleRegisteredReceiver

public final class ActivityThread {......        private final class ApplicationThread extends ApplicationThreadNative {......            // This function exists to make sure all receiver dispatching is          // correctly ordered, since these are one-way calls and the binder driver          // applies transaction ordering per object for such calls.          public void scheduleRegisteredReceiver(IIntentReceiver receiver, Intent intent,                  int resultCode, String dataStr, Bundle extras, boolean ordered,                  boolean sticky) throws RemoteException {receiver.performReceive(intent, resultCode, dataStr, extras, ordered, sticky);          }            ......      }        ......    }  

這里的receiver是在前面過(guò)程分析中的Step 4中創(chuàng)建的，它的具體類型是LoadedApk.ReceiverDispatcher.InnerReceiver，即定義在LoadedApk類的內(nèi)部類ReceiverDispatcher里面的一個(gè)內(nèi)部類InnerReceiver，這里調(diào)用它的performReceive函數(shù)。

Step 13. InnerReceiver.performReceive

final class LoadedApk {......         static final class ReceiverDispatcher {final static class InnerReceiver extends IIntentReceiver.Stub {......                public void performReceive(Intent intent, int resultCode,                      String data, Bundle extras, boolean ordered, boolean sticky) {LoadedApk.ReceiverDispatcher rd = mDispatcher.get();                  ......                  if (rd != null) {rd.performReceive(intent, resultCode, data, extras,                              ordered, sticky);                  } else {......                  }              }          }            ......      }        ......  }  

這里，它只是簡(jiǎn)單地調(diào)用ReceiverDispatcher的performReceive函數(shù)來(lái)進(jìn)一步處理，這里的ReceiverDispatcher類是LoadedApk類里面的一個(gè)內(nèi)部類。

Step 14. ReceiverDispatcher.performReceive

final class LoadedApk {......         static final class ReceiverDispatcher {......            public void performReceive(Intent intent, int resultCode,                  String data, Bundle extras, boolean ordered, boolean sticky) {......                Args args = new Args();              args.mCurIntent = intent;              args.mCurCode = resultCode;              args.mCurData = data;              args.mCurMap = extras;              args.mCurOrdered = ordered;              args.mCurSticky = sticky;              if (!mActivityThread.post(args)) {......              }           }            ......      }        ......  }  

這里mActivityThread成員變量的類型為Handler，它是前面MainActivity注冊(cè)廣播接收器時(shí)，從ActivityThread取得的。

這里ReceiverDispatcher借助這個(gè)Handler，把這個(gè)廣播以消息的形式放到MainActivity所在的這個(gè)ActivityThread的消息隊(duì)列中去，因此，ReceiverDispatcher不等這個(gè)廣播被MainActivity處理就返回了，這里也體現(xiàn)了廣播的發(fā)送和處理是異步進(jìn)行的。

注意這里處理消息的方式是通過(guò)Handler.post函數(shù)進(jìn)行的，post函數(shù)的參數(shù)是Runnable類型的，這個(gè)消息最終會(huì)調(diào)用這個(gè)這個(gè)參數(shù)的run成員函數(shù)來(lái)處理。這里的Args類是LoadedApk類的內(nèi)部類ReceiverDispatcher的一個(gè)內(nèi)部類，它繼承于Runnable類，因此，可以作為mActivityThread.post的參數(shù)傳進(jìn)去，代表這個(gè)廣播的intent也保存在這個(gè)Args實(shí)例中。

Step 15. Hanlder.post

這個(gè)函數(shù)定義在frameworks/base/core/java/android/os/Handler.java文件中，它的作用就是把消息放在消息隊(duì)列中，然后就返回了，這個(gè)消息最終會(huì)在傳進(jìn)來(lái)的Runnable類型的參數(shù)的run成員函數(shù)中進(jìn)行處理。

Step 16. Args.run

final class LoadedApk {......         static final class ReceiverDispatcher {......            final class Args implements Runnable {......                public void run() {BroadcastReceiver receiver = mReceiver;                    ......                    Intent intent = mCurIntent;                                    ......                    try {ClassLoader cl =  mReceiver.getClass().getClassLoader();                      intent.setExtrasClassLoader(cl);                      if (mCurMap != null) {mCurMap.setClassLoader(cl);                      }                      receiver.setOrderedHint(true);                      receiver.setResult(mCurCode, mCurData, mCurMap);                      receiver.clearAbortBroadcast();                      receiver.setOrderedHint(mCurOrdered);                      receiver.setInitialStickyHint(mCurSticky);                      receiver.onReceive(mContext, intent);                  } catch (Exception e) {......                  }                    ......              }                ......          }            ......      }        ......  }  

這里的mReceiver是ReceiverDispatcher類的成員變量，它的類型是BroadcastReceiver，這里它就是MainActivity注冊(cè)廣播接收器時(shí)創(chuàng)建的BroadcastReceiver實(shí)例了。

有了這個(gè)ReceiverDispatcher實(shí)例之后，就可以調(diào)用它的onReceive函數(shù)把這個(gè)廣播分發(fā)給它處理了。

Step 17. BroadcastReceiver.onReceive

public class MainActivity extends Activity implements OnClickListener {......          private BroadcastReceiver counterActionReceiver = new BroadcastReceiver(){public void onReceive(Context context, Intent intent) {int counter = intent.getIntExtra(CounterService.COUNTER_VALUE, 0);                String text = String.valueOf(counter);                counterText.setText(text);                  Log.i(LOG_TAG, "Receive counter event");            }          }        ......      }  

這樣，MainActivity里面的定義的BroadcastReceiver實(shí)例counterActionReceiver就收到這個(gè)廣播并進(jìn)行處理了。

至此，Android應(yīng)用程序發(fā)送廣播的過(guò)程就分析完成了。

最后，我們總結(jié)一下這個(gè)Android應(yīng)用程序發(fā)送廣播的過(guò)程：