Android 為什麼動態廣播接收器比靜態廣播接收器要接受的早

如果，在短信攔截的軟件中，程序員們就發現了這個問題。 同一優先級的廣播接收器，動態的要比靜態注冊的早。

動態注冊：即由代碼注冊的廣播接收器

靜態注冊：即在 AndroidManifest.xml 中注冊的廣播接收器

優先級： 當廣播為有序發送的時候，要按這個排序並順序發送。

sendBroadcast 發送的是無序廣播。

sendOrderedBroadcast 發送的是有序廣播。

好了，現在尋找問題原因，在找原因前肯定有這樣的想法，一個有序隊列，既然允許有相同的優先級存在，那麼在同優先級內要不然有排序子因素，要不基就是按照某種操作可能影響順序。後者可能性很大。

打開源碼，順著 動態注冊廣播接受器 找，最後是 ActivityManagerService.java 這個文件找到了 registerReceiver 的實現。

同地也看到，存儲的廣播接收器列表是 HashMap mRegisteredReceivers 這個變理。

裡面有一段代碼為：

1. ReceiverList rl  
2.     = (ReceiverList)mRegisteredReceivers.get(receiver.asBinder());  
3. if (rl == null) {  
4.     rl = new ReceiverList(this, callerApp,  
5.             Binder.getCallingPid(),  
6.             Binder.getCallingUid(), receiver);  
7.     if (rl.app != null) {  
8.         rl.app.receivers.add(rl);  
9.     } else {  
10.         try {  
11.             receiver.asBinder().linkToDeath(rl, 0);  
12.         } catch (RemoteException e) {  
13.             return sticky;  
14.         }  
15.         rl.linkedToDeath = true;  
16.     }  
17.     mRegisteredReceivers.put(receiver.asBinder(), rl);  
18. }  

在裡面查找有沒有這個 Receiver ， 如果沒有 put 進去。 

看到這裡貌似沒有對廣播的順序做處理。是不是有別的地方做排序呢，找找成員變理，發現一個可疑的變量：

final ArrayList<BroadcastRecord> mOrderedBroadcasts

沒錯，感覺就應該是它了。 

找找對它的操作，只有一處 mOrderedBroadcasts.set ，把代碼摘錄一下： 

 BroadcastRecord r = new BroadcastRecord(intent, callerApp,
                    callerPackage, callingPid, callingUid, requiredPermission,
                    receivers, resultTo, resultCode, resultData, map, ordered,
                    sticky, false); 

mOrderedBroadcasts.set(i, r);

在這裡放入了一個 BroadcastRecord 對像，而這個對像中主要的東西其實是 receivers

向上跟蹤

1. int NT = receivers != null ? receivers.size() : 0;  
2. int it = 0;  
3. ResolveInfo curt = null;  
4. BroadcastFilter curr = null;  
5. while (it < NT && ir < NR) {  
6.     if (curt == null) {  
7.         curt = (ResolveInfo)receivers.get(it);  
8.     }  
9.     if (curr == null) {  
10.         curr = registeredReceivers.get(ir);  
11.     }  
12.     if (curr.getPriority() >= curt.priority) {  
13.         // Insert this broadcast record into the final list.   
14.         receivers.add(it, curr);  
15.         ir++;  
16.         curr = null;  
17.         it++;  
18.         NT++;  
19.     } else {  
20.         // Skip to the next ResolveInfo in the final list.   
21.         it++;  
22.         curt = null;  
23.     }  
24. }  

發現了一段 對 receivers 排序的代碼，並且判斷也是 priority 的值，用的是 >=  方式

感覺的找到了地方，但是對 Activity Manager Service 這個模塊卻更加的不懂了，以後有機會一定要分析一下這塊是怎樣設計的，才能確定本文的問題所在。