分類(lèi)： Android 2011-08-25 14:16 97人閱讀 收藏 舉報 目錄
1. Abstract
2. Introduction
3. Intent的架構
4. Intent的發(fā)送過(guò)程
4.1 Intent消息在發(fā)送進(jìn)程的邏輯
4.2 Intent發(fā)送在服務(wù)器端的執行
4.2.1 進(jìn)入消息隊列之前
4.2.2 進(jìn)入消息隊列后的處理
4.2.3 消息的分發(fā)過(guò)程
4.2.4 deliverToRegisteredReceiver的邏輯
4.2.5 processCurBroadcastLocked的邏輯
4.2.6 startProcessLocked的邏輯
5. Intent的接收過(guò)程
5.1 Receiver的注冊
5.2 scheduleReceiver
5.3 scheduleRegisteredReceiver的邏輯
6. 總結
7. 未分析
1. Abstract
主要是分析一下android的IPC通訊之Intent；
2. Introduction
Intent的通訊機制是基于Binder的，而B(niǎo)inder的機制本質(zhì)上是共享內存；
這里涉及兩方面的內容：
A） 消息的發(fā)送；
B） 消息的接收；
討論之前先看一個(gè)簡(jiǎn)單的例子：
Intent intent = new Intent(AudioManager.ACTION_AUDIO_BECOMING_NOISY);
mContext.sendBroadcast(intent);
這是摘自HeadsetObserver.java的代碼；
后面將會(huì )以此為例，分析發(fā)送和接收的過(guò)程；
3. Intent的架構
Intent的架構包括三方面：
Client，也就是發(fā)送這個(gè)Intent的activity；
Server，也就是activityManagerService.java,它主要是負責分發(fā)這些Intent給適當的對象；
Target，也就是那些需要處理這個(gè)Intent的activity，我們稱(chēng)為Receiver；
需要大致的了解一下，Intent通常有哪些部分？我們常用的包括三方面：
A）action，就是這個(gè)intent是想達到什么目的，比如是想打電話(huà)，還是想告訴我們電池電量低？
B）數據， 也就是這個(gè)intent要處理的是這些數據，如果你是receiver的話(huà)，你需要考慮，你是否需要處理這個(gè)intent，這里包括數據的URI，以及數據的類(lèi)型；
C）Category，這個(gè)就是需要處理這個(gè)Intent的activity的種類(lèi)，這個(gè)種類(lèi)是比較難以理解的，我想Google的本意是想區分一下不同的 Activity的種類(lèi)，比如對于CATEGORY_LAUNCHER，這個(gè)就表示它是一個(gè)啟動(dòng)器，有些消息只需要由特定類(lèi)型的activity來(lái)處理；
當然還有其它的一些屬性，但是我們經(jīng)常遇到的就是這三個(gè)，而這三個(gè)里面最常用的是Action；
這些項的作用，主要是被activityManagerService用來(lái)挑選適當的Activity來(lái)處理這個(gè)Intent；
4. Intent的發(fā)送過(guò)程
4.1 Intent消息在發(fā)送進(jìn)程的邏輯
回到我們先前的那個(gè)例子：
Intent intent = new Intent(AudioManager.ACTION_AUDIO_BECOMING_NOISY);
mContext.sendBroadcast(intent);
第一句話(huà)是構造一個(gè)Intent，注意只傳入了一個(gè)參數，這個(gè)參數就是一個(gè)Action，沒(méi)有指定data以及Category；也就是說(shuō)如果某個(gè)Receiver寫(xiě)成這樣（在A(yíng)ndroidManifext.xml里面）：
<receiver android:name="MediaButtonIntentReceiver">
<intent-filter>
<action android:name="android.media.AUDIO_BECOMING_NOISY" />
</intent-filter>
</receiver>
這個(gè)receiver的onReceive函數將會(huì )被調用，其中receiver表示處理這個(gè)Intent消息的類(lèi)，而intent-filter表示這個(gè)receiver關(guān)心哪些Intent，這里寫(xiě)明了，我只關(guān)心，action == android.media.AUDIO_BECOMING_NOISY的Intent，如果是其它的Intent請別來(lái)煩我；
第二句話(huà)的目的就是把這個(gè)消息廣播出去，誰(shuí)關(guān)心誰(shuí)處理去，從此和我沒(méi)關(guān)系了；
我可以很負責任的說(shuō)，這個(gè)mContext的類(lèi)型為ApplicationContext，在A(yíng)ndroid的代碼里，這樣命名的變量多半是這個(gè)類(lèi)型，所以后面的邏輯就簡(jiǎn)單描述為：
Android的代碼很多都這樣，一層層的調用，很多時(shí)候都是二傳手，這是模塊化設計需要付出的代價(jià)，不過(guò)，值得；
對于分析來(lái)說(shuō)，需要理清楚這個(gè)調用到底去了什么地方？
代碼在A(yíng)ctivityManagerNative.java里面：
這是一個(gè)典型的Binder調用，從此以后代碼的執行進(jìn)入了另外一個(gè)進(jìn)程；
4.2 Intent發(fā)送在服務(wù)器端的執行
4.2.1 進(jìn)入消息隊列之前
調用的這個(gè)函數broadcastIntentLocked，基本上主要的工作都是由它來(lái)完成的；
這個(gè)函數非常重要，需要詳細分析：
1，首先是進(jìn)行一些權限檢查，保證非串行的Intent其resultTo receiver必須是null;
2，如果這個(gè)Intent是說(shuō)某個(gè)包被刪除了或者改變了，那么當前的歷史棧里面的屬于這個(gè)包的activity就必須被關(guān)掉；
3，如果是時(shí)區改變的消息，那么將會(huì )先被放進(jìn)隊列里面通知當前正在運行的進(jìn)程；
4，權限檢查，判斷是否有權限發(fā)送受保護的Intent，對于SYSTEM_UID，PHONE_UID，SHELL_UID，或者callingUid == 0的情況不做檢查，也就是說(shuō)默認這些調用者有這個(gè)發(fā)送的權限；
5，對于sticky類(lèi)型的Intent做一些特殊處理（關(guān)于sticky類(lèi)型等概念后面會(huì )講），簡(jiǎn)單就是把這個(gè)Intent加入到mStickyBroadcasts鏈表中去；
6，判斷這個(gè)Intent是有一個(gè)明確的對象，如果是那么直接把它的對象加入到receivers列表中去，如果不是，那么會(huì )繼續判斷是不是這個(gè)Intent 在發(fā)送的時(shí)候設置了FLAG_RECEIVER_REGISTERED_ONLY標志，如果是，那么這個(gè)Intent將只發(fā)送給已經(jīng)注冊的 Receiver，不會(huì )發(fā)送給Broadcast receiver,否則就發(fā)送給所有的那些滿(mǎn)足條件的receivers；這里就涉及Intent的匹配原則，主要是通過(guò)函數 queryIntent(Intent intent, String resolvedType, boolean defaultOnly)來(lái)匹配的，原則就是我前面說(shuō)的，根據Action，data type，category等來(lái)匹配，記住，每條規則之間的關(guān)系是或的關(guān)系，比如：
<receiver android:name="MediaButtonIntentReceiver">
<intent-filter>
<action android:name="android.intent.action.MEDIA_BUTTON" />
<action android:name="android.media.AUDIO_BECOMING_NOISY" />
</intent-filter>
</receiver>
就表示只要匹配到其中一條就算成功；另外，對于沒(méi)有寫(xiě)明的匹配規則默認就算成功，比如對于此規則，沒(méi)有寫(xiě)明數據類(lèi)型，種類(lèi)等，那么默認所有的數據類(lèi)型都可以匹配上；
7，如果是registeredReceivers不為空并且這個(gè)Intent不是串行的，也就是上一步已經(jīng)取出了對應的接收者，那么就需要把這個(gè)Intent封裝成一個(gè)BroadcastRecord，然后加入到mParallelBroadcasts，這個(gè)稱(chēng)為并行廣播，也就是說(shuō)可以同時(shí)發(fā)送給多個(gè)接收者，再通過(guò)scheduleBroadcastsLocked觸發(fā)真正的發(fā)送；
8，過(guò)濾一種特殊情況，也就是對于A(yíng)CTION_PACKAGE_ADDED消息，這個(gè)被安裝的包本身不能作為這個(gè)消息的接收者；
9，然后對registeredReceivers和receivers做一個(gè)合并，如果這兩個(gè)都不為空的話(huà)，記住，合并前這個(gè)receivers標識了“具有固定對象的接收者或者是當前已經(jīng)注冊的接收者不包括廣播接收者”，而registeredReceivers表示broadcast Filter，另外這步能合并的前提是這個(gè)Intent是串行的Intent，否則是不會(huì )合并的；
10， 合并以后receivers表示所有的串行receivers通過(guò)mOrderedBroadcasts.add(r)加入到列表中去，再通過(guò)scheduleBroadcastsLocked觸發(fā)真正的發(fā)送；
OK，這個(gè)函數基本上就結束了，這里有三個(gè)概念需要解釋?zhuān)?并行，sticky的BroadCast；
串行：就表示這個(gè)Intent必須一個(gè)一個(gè)的發(fā)送給接收者；
并行：表示這個(gè)Intent可以同時(shí)發(fā)送給多個(gè)接收者，通常廣播的消息都是并行的；
Sticky：這個(gè)類(lèi)型的BroadCast比較難以理解，問(wèn)了google也沒(méi)有答案，我個(gè)人的理解是這樣的，某些Intent需要被保留，當新的應用起來(lái)后，需要關(guān)注這個(gè)消息，但是呢，又不需要啟動(dòng)這個(gè)應用來(lái)接收此消息，比如耳機插入等消息，這里說(shuō)實(shí)話(huà)，真的很巧妙，我們以前在maemo上碰到過(guò)這個(gè)問(wèn)題，當時(shí)我們的策略是應用起來(lái)的時(shí)候自己查詢(xún)耳機的狀態(tài)，這里的處理明顯就高明許多；
總結一下這個(gè)函數：它的主要作用是根據這個(gè)Intent的特點(diǎn)，構造BroadCastRecord加入到不同的列表，等待被處理；
OK，控制到了scheduleBroadcastsLocked這里，它的邏輯很簡(jiǎn)單：
private final void scheduleBroadcastsLocked() {
if (mBroadcastsScheduled) {
return;
}
mHandler.sendEmptyMessage(BROADCAST_INTENT_MSG);
mBroadcastsScheduled = true;
}
先判斷mBroadcastsScheduled是否為真，如果為真就直接返回,這個(gè)變量主要是實(shí)現scheduleBroadcastsLocked和 processNextBroadcast之間的順序執行，后面會(huì )看到在processNextBroadcast函數里面會(huì )把它設置為false；
下面就是通過(guò)BROADCAST_INTENT_MSG消息放入到消息隊列里面，從這個(gè)角度來(lái)說(shuō)Intent最后也是通過(guò)線(xiàn)程本身的消息隊列來(lái)實(shí)現Intent的分發(fā)的；
4.2.2 進(jìn)入消息隊列后的處理
上面有提到會(huì )通過(guò)mHandler.sendEmptyMessage(BROADCAST_INTENT_MSG)，把這個(gè)消息傳遞給mHandler，下面看看這個(gè)邏輯是如何實(shí)現的；
到這里消息就是按照時(shí)間順序進(jìn)入了mQueue了；
我們再看看一個(gè)activity的thread是如何進(jìn)入主循環(huán)的：
首先是通過(guò)prepareMainLooper建立基本的數據結構，包括mQueue以及mThread,mMainLooper;并把當前的這個(gè)Looper放入到線(xiàn)程獨有的變量中；其次是通過(guò)Looper.loop進(jìn)入到主循環(huán)，邏輯如下：
首先是取出當前進(jìn)入主循環(huán)的Looper，然后取出這個(gè)looper所擁有的mQueue，接下來(lái)就開(kāi)始處理這個(gè)隊列里面的消息了；
根據處理方式分兩種消息，
一種是消息的處理由一個(gè)線(xiàn)程來(lái)完成;
一種是消息的處理時(shí)由一個(gè)函數來(lái)完成;
后者的話(huà)也分兩種，
一種是handler創(chuàng )建的時(shí)候提供了callback，這種情況非常少見(jiàn)；
一種是通過(guò)handleMessage的方式來(lái)處理，通常我們在創(chuàng )建handler的時(shí)候都會(huì )提供這樣一個(gè)函數，于是消息就可以被處理了；
注意，最左邊的分支我們還沒(méi)有討論，后面會(huì )遇到；我們先看看這個(gè)handleMessage對于BROADCAST_INTENT_MSG的處理：
這是最重要的函數，如果說(shuō)broadcastIntentLocked是負責把Intent轉化為BroadCast的話(huà)放入不同的隊列，那么這個(gè)函數主要就是負責分發(fā)了，當然也涉及一點(diǎn)接收的流程；
4.2.3 消息的分發(fā)過(guò)程
下面分析函數private final void processNextBroadcast(boolean fromMsg)；
1，先判斷fromMsg,如果是通過(guò)消息發(fā)送過(guò)來(lái)的就為真，否則為假; 如果為真mBroadcastsScheduled = false，這樣的話(huà)在函數scheduleBroadcastsLocked里面就可以再次發(fā)送BROADCAST_INTENT_MSG的消息從而觸發(fā)processNextBroadcast函數被再次調用；
2，先判斷mParallelBroadcasts是否為空，不為空就開(kāi)始調用這個(gè)列表里面的receivers來(lái)接收消息，這個(gè)過(guò)程后面在串行intent的時(shí)候也會(huì )碰到，我們留到后面討論，這里只需要知道它通過(guò)一個(gè)while循環(huán)把Intent發(fā)送給關(guān)注這個(gè)Intent的所有的receivers；
3，再判斷 mPendingBroadcast是否為空，如果不為空，就表示先前發(fā)送的串行的Intent還沒(méi)有處理完畢，一般出現這種可能是因為我們要發(fā)送到的 receiver還沒(méi)有啟動(dòng)，所以需要先啟動(dòng)這個(gè)activity，然后等待起來(lái)的這個(gè)activity處理，這時(shí)候，這個(gè) mPendingBroadcast就為true；如果發(fā)送這種情況需要判斷這個(gè)Activity是否死了，如果死了，那么就把 mPendingBroadcast設為false，否則就直接返回，繼續等待；
4，接下來(lái)就順序的從 mOrderedBroadcasts里面取出BroadCastRecord消息，然后對這個(gè)消息的receiver一個(gè)一個(gè)的調用其接收流程，注意這里要把這個(gè)BroadCast的所有的receivers串行發(fā)送，都發(fā)送完了，才會(huì )進(jìn)入到下一個(gè)BroadCastRecord消息；對于這個(gè)消息的處理，先判斷其接收者是不是BroadFilter，如果是，就調用deliverToRegisteredReceiver來(lái)接收，它的處理流程和前面的處理并行BroadCast一樣，所以留到后面講；
5，如果不是BroadCast Filter，就需要找出這個(gè)reiver所在的進(jìn)程，這時(shí)候通常就是一個(gè)IntentFilter所在的進(jìn)程，如果這個(gè)進(jìn)程活著(zhù)，那么就調用processCurBroadcastLocked(r, app)來(lái)處理，否則
6，需要先啟動(dòng)這個(gè)進(jìn)程，這就是startProcessLocked做的事情，然后設置mPendingBroadcast = r，這樣等應用起來(lái)它會(huì )處理這個(gè)消息，后面會(huì )有進(jìn)一步的說(shuō)明；
到這里這個(gè)函數就結束了，比較復雜，里面還有一些安全的檢查等等，上面遺留了三個(gè)問(wèn)題：
A）deliverToRegisteredReceiver的處理流程；
B）processCurBroadcastLocked的處理流程；
C）startProcessLocked以后的進(jìn)程如何處理這個(gè)喚醒它的Intent；
4.2.4 deliverToRegisteredReceiver的邏輯
這里也分為這個(gè)receiver是否啟動(dòng)，如果已經(jīng)啟動(dòng)就通過(guò)binder調用到了接收 activity的進(jìn)程里面了，右邊的分支performReceive也會(huì )調用到activityThread這邊，留到接收過(guò)程再看；
4.2.5 processCurBroadcastLocked的邏輯
可以看到它和deliverToRegisteredReceive的最終差別，只在于一個(gè)調用的是ScheduleRegisterdReceiver,一個(gè)是scheduleReceiver，這兩個(gè)函數最后都會(huì )進(jìn)入到目標activity的線(xiàn)程；
4.2.6 startProcessLocked的邏輯
從這里可以看出最后通過(guò)Process.start啟動(dòng)了ActivityThread.java的進(jìn)程，我們看看這個(gè)線(xiàn)程啟動(dòng)后的執行邏輯：
首先是在進(jìn)入主循環(huán)之前調用attachApplication通過(guò)binder調用進(jìn)入到activityManagerService.java的進(jìn)程；
這個(gè)服務(wù)器進(jìn)程在把我們先前設置的mPendingBroadcast設置為null，表示這個(gè)pending的broadcat已經(jīng)得到處理了，然后調用 processCurBroadcastLocked來(lái)處理這個(gè)broadcast消息，最后通過(guò) app.thread.scheduleReceiver進(jìn)入到目標線(xiàn)程的接收流程；
OK,到這里的話(huà)所有的發(fā)送分發(fā)流程已經(jīng)結束了，剩下的就是兩個(gè)接收函數還沒(méi)有討論一個(gè)就是ScheduleRegisterdReceiver,一個(gè)是scheduleReceiver；
5. Intent的接收過(guò)程
5.1 Receiver的注冊
Receiver的注冊一般分為動(dòng)態(tài)注冊和靜態(tài)注冊，動(dòng)態(tài)注冊就是通過(guò)API registerReceiver來(lái)注冊，靜態(tài)的一般就是寫(xiě)在A(yíng)ndroidManifest.xml,比如我們在前面已經(jīng)看到的：
<receiver android:name="MediaButtonIntentReceiver">
<intent-filter>
<action android:name="android.intent.action.MEDIA_BUTTON" />
<action android:name="android.media.AUDIO_BECOMING_NOISY" />
</intent-filter>
</receiver>
至于它的原理以后在分析packageManger的時(shí)候再分析；
下面重點(diǎn)來(lái)看看這個(gè)動(dòng)態(tài)注冊的邏輯：
這兩條路徑都可能被走到，如果不在A(yíng)pplicationContent環(huán)境里面就需要通過(guò)context.registerReceiver來(lái)注冊了，經(jīng)過(guò)幾層傳遞會(huì )通過(guò)registerReceiverInternal進(jìn)入主題；
構造receiver放入到列表中去，只是中間又經(jīng)歷了Binder，這些receiver也就是我們先前在發(fā)送的過(guò)程中看到的那些receiver，當然它們能進(jìn)入到broadcast的列表還要看發(fā)送的intent是否滿(mǎn)足它們給自的filter；
好，現在可以看看我們在發(fā)送階段遺留的兩個(gè)函數：
scheduleReceiver
scheduleRegisteredReceiver；
5.2 scheduleReceiver
它的入口通常是Binder的分發(fā)函數，如下：
右下方的這個(gè)函數scheduleReceiver才會(huì )真正調用到ActivityThread.java，這個(gè)就是目標activity的母體；
前面兩個(gè)就是封裝參數，最后放入到消息隊列中，等待主循環(huán)的處理，這段邏輯我們前面已經(jīng)看到了，就不再細說(shuō)，總之會(huì )調用到handlemessage函數；
在收到這個(gè)消息的時(shí)候通過(guò)handleReceiver來(lái)處理；
這又是一個(gè)非常重要的函數，需要詳細分析：
1，取得這個(gè)Intent指向的component，包括包名，類(lèi)名；
2，取得包信息，這個(gè)結構提供了getClassLoader接口；
3，通過(guò)java.lang.ClassLoader cl = packageInfo.getClassLoader取得classLoader；
4，動(dòng)態(tài)創(chuàng )建一個(gè)receiver，receiver = (BroadcastReceiver)cl.loadClass(component).newInstance()；
5，調用receiver.onReceive(context.getReceiverRestrictedContext(), data.intent)，進(jìn)入到真正的處理流程中去了；
6，調用finishReceiver來(lái)觸發(fā)ActivityManagerService這個(gè)消息到其它receivers的發(fā)送或者下一個(gè)broadcast的發(fā)送；
這其中最重要的就是這個(gè)onReceive函數，我們通常都會(huì )實(shí)現這么一個(gè)函數，然后在里面處理我們收到的消息；
5.3 scheduleRegisteredReceiver的邏輯
入口還是Binder得分發(fā)函數，如下：
這種處理在A(yíng)ndroid的代碼里面隨處可見(jiàn)，都是在native文件里面通過(guò)onTransact分發(fā)調用service文件里面的同名函數來(lái)完成真正的功能；
邏輯如下：
也就是說(shuō)，這里把參數打包放入到args里面去，然后通過(guò)post放入到消息隊列里面等待處理，后面的邏輯和一個(gè)消息的發(fā)送很相似，如下：
這里需要關(guān)注兩個(gè)點(diǎn)，
一個(gè)就是m.callback=r,這個(gè)賦值會(huì )導致后面在分發(fā)消息的時(shí)候走不同的路徑；
Msg.target=this,表示將來(lái)分發(fā)的時(shí)候誰(shuí)來(lái)處理這個(gè)消息，如果設置為null將會(huì )導致主循環(huán)退出；
分發(fā)的邏輯前面我們有介紹就是dispatchMessage的時(shí)候，我們再看看這段代碼：
public void dispatchMessage(Message msg)
{
if (msg.callback != null)
{
handleCallback(msg);
}
else
{
if (mCallback != null)
{
if (mCallback.handleMessage(msg))
{
return;
}
}
handleMessage(msg);
}
}
這里就是需要先判斷msg.callback是否為null，前面我們已經(jīng)看到賦值了，所以這里不為null；
于是調用handleCallback,如下：
private final void handleCallback(Message message)
{
message.callback.run();
}
這個(gè)callback我們也看到了其實(shí)就是我們封裝的Args的args，原型為：
class Args implements Runnable，
也就是說(shuō)它是一個(gè)類(lèi)似線(xiàn)程的對象，它的run函數代碼有點(diǎn)多;
基本上這個(gè)邏輯就和我們之前看到的邏輯一致了，會(huì )調用receiver提供的onReceive函數來(lái)處理，這個(gè)onReceive函數是需要我們自己提供的，里面一般的邏輯都是根據不同的消息做不同的處理；
最后就是通過(guò)finishReceiver來(lái)觸發(fā)ActivityManagerService對Intent的其它receivers的發(fā)送；
6. 總結
需要總結一下，
Intent從使用的角度來(lái)說(shuō)，就是構造Intent，提供適當的參數，比如Action，比如數據類(lèi)型，數據的uri等，然后發(fā)送出去；接收方需要注冊一個(gè) receiver，然后提供onReceive函數就可以了；這個(gè)注冊可以簡(jiǎn)單的寫(xiě)在A(yíng)ndroidManifest.xml里面也可以通過(guò) registerReceiver來(lái)完成；
發(fā)送的時(shí)候有三個(gè)API可以用：
sendBroadcast
sendStickyBroadcast
sendOrderedBroadcast
第一個(gè)用于發(fā)送并行廣播；
第二個(gè)用于發(fā)送粘性廣播；
第三個(gè)用于發(fā)送串行廣播；
從原理的角度來(lái)說(shuō)，本質(zhì)上都是通過(guò)共享內存把信息傳遞給ActivityManagerService，它查詢(xún)已經(jīng)注冊的那些receiver的過(guò)濾器，看是否和這個(gè)Intent匹配，如果匹配成功就加入到這個(gè)Intent的receiver列表中去，當然要根據這個(gè)Intent的參數決定加入到并行，串行，還是sticky的列表中，再通過(guò)Message傳遞，到主循環(huán)的下一輪來(lái)分發(fā)；這時(shí)候控制已經(jīng)到了另外一個(gè)進(jìn)程，然后分發(fā)好以后再調用目標線(xiàn)程的處理函數，所以基本上就是涉及三個(gè)進(jìn)程，源——>server——>receiver；當然，源和目的可以是同一個(gè)進(jìn)程；
另外這里需要處理一種情況，就是這個(gè)消息發(fā)送的時(shí)候，目標線(xiàn)程還沒(méi)有創(chuàng )建，比如我們系統里面的校準程序，需要在第一次開(kāi)機的時(shí)候執行，那么就需要捕捉一個(gè)廣播消息，比如：
<receiver android:name="StartupIntentReceiver" >
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
<category android:name="android.intent.category.HOME" />
</intent-filter>
</receiver>
這個(gè)消息的意思就是說(shuō)啟動(dòng)已經(jīng)完畢了；
處理這個(gè)消息的類(lèi)是StartupIntentReceiver,首先包含這個(gè)receiver的主activity將會(huì )被執行，然后再執行這個(gè)接收類(lèi)的onReceive來(lái)接收消息并處理，所謂主activity是這樣的
摘自：http://blog.chinaunix.net/u2/67984/showart_2387391.html
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
就是activity filter里面包含ACTION android.intent.action.MAIN,種類(lèi)包含android.intent.category.LAUNCHER的activity；
這個(gè)啟動(dòng)過(guò)程是由ActivityManagerService.java來(lái)完成的，我們不必關(guān)心；
OK，基本上就這些了，關(guān)于A(yíng)ctivity本身的原理，需要專(zhuān)門(mén)的文檔來(lái)描述；
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
