進(jìn)程和線程的基本概念
當(dāng)一個(gè)應(yīng)用程序開始運(yùn)行它的第一個(gè)組件時(shí)，Android會(huì)為它啟動(dòng)一個(gè)Linux進(jìn)程，并在其中執(zhí)行一個(gè)單一的線程。默認(rèn)情況下，應(yīng)用程序所有的組件均在這個(gè)進(jìn)程的這個(gè)線程中運(yùn)行。然而，你也可以安排組件在其他進(jìn)程中運(yùn)行，而且可以為任意進(jìn)程衍生出其它線程。
Android中的進(jìn)程
組件運(yùn)行所在的進(jìn)程由manifest文件所控制。組件元素——<activity>， <service>， <receiver>和<provider>——都有一個(gè) process 屬性來指定組件應(yīng)當(dāng)運(yùn)行于哪個(gè)進(jìn)程之內(nèi)。這些屬性可以設(shè)置為使每個(gè)組件運(yùn)行于它自己的進(jìn)程之內(nèi)，或一些組件共享一個(gè)進(jìn)程而其余的組件不這么做。它們也可以設(shè)置為令不同應(yīng)用程序的組件在一個(gè)進(jìn)程中運(yùn)行——使應(yīng)用程序的組成部分共享同一個(gè)Linux用戶ID并賦以同樣的權(quán)限。<application>元素也有一個(gè)process屬性，以設(shè)定所有組件的默認(rèn)值。
所有的組件實(shí)例都位于特定進(jìn)程的主線程內(nèi)，而對(duì)這些組件的系統(tǒng)調(diào)用也將由那個(gè)線程進(jìn)行分發(fā)。一般不會(huì)為每個(gè)實(shí)例創(chuàng)建線程。因此，某些方法總是運(yùn)行在進(jìn)程的主線程內(nèi)，這些方法包括諸如View.onKeyDown()這樣報(bào)告用戶動(dòng)作以及生命周期通告的。這意味著組件在被系統(tǒng)調(diào)用的時(shí)候，不應(yīng)該施行長(zhǎng)時(shí)間的抑或阻塞的操作（諸如網(wǎng)絡(luò)相關(guān)操作或是循環(huán)計(jì)算），因?yàn)檫@將阻塞同樣位于這個(gè)進(jìn)程的其它組件的運(yùn)行。你應(yīng)該如同下面線程部分所敘述的那樣，為這些長(zhǎng)時(shí)間操作衍生出一個(gè)單獨(dú)的線程進(jìn)行處理。
在可用內(nèi)存不足而又有一個(gè)正在為用戶進(jìn)行服務(wù)的進(jìn)程需要更多內(nèi)存的時(shí)候，Android有時(shí)候可能會(huì)關(guān)閉一個(gè)進(jìn)程。而在這個(gè)進(jìn)程中運(yùn)行著的應(yīng)用程序也因此被銷毀。當(dāng)再次出現(xiàn)需要它們進(jìn)行處理的工作的時(shí)候，會(huì)為這些組件重新創(chuàng)建進(jìn)程。
在決定結(jié)束哪個(gè)進(jìn)程的時(shí)候，Android會(huì)衡量它們對(duì)于用戶的相對(duì)重要性。比如說，相對(duì)于一個(gè)仍有用戶可見的activity的進(jìn)程，它更有可能去關(guān)閉一個(gè)其activity已經(jīng)不為用戶所見的進(jìn)程。也可以說，決定是否關(guān)閉一個(gè)進(jìn)程主要依據(jù)在那個(gè)進(jìn)程中運(yùn)行的組件的狀態(tài)。
Android中的線程
盡管你可以把你的應(yīng)用程序限制于一個(gè)單獨(dú)的進(jìn)程中，有時(shí)，你仍然需要衍生出一個(gè)線程以處理后臺(tái)任務(wù)。因?yàn)橛脩艚缑姹仨毞浅＜皶r(shí)的對(duì)用戶操作做出響應(yīng)，所以，控管activity的線程不應(yīng)用于處理一些諸如網(wǎng)絡(luò)下載之類的耗時(shí)操作。所有不能在瞬間完成的任務(wù)都應(yīng)安排到不同的線程中去。
線程在代碼中是以標(biāo)準(zhǔn)JavaThread對(duì)象創(chuàng)建的。Android提供了很多便于管理線程的類：Looper用于在一個(gè)線程中運(yùn)行一個(gè)消息循環(huán)，Handler用于處理消息，HandlerThread 用于使用一個(gè)消息循環(huán)啟用一個(gè)線程。
RPC：遠(yuǎn)程過程調(diào)用
Android有一個(gè)輕量級(jí)的遠(yuǎn)程過程調(diào)用（RPC）機(jī)制：即在本地調(diào)用一個(gè)方法，但在遠(yuǎn)程（其它的進(jìn)程中）進(jìn)行處理，然后將結(jié)果返回調(diào)用者。這將方法調(diào)用及其附屬的數(shù)據(jù)以系統(tǒng)可以理解的方式進(jìn)行分離，并將其從本地進(jìn)程和本地地址空間傳送至遠(yuǎn)程過程和遠(yuǎn)程地址空間，并在那里重新裝配并對(duì)調(diào)用做出反應(yīng)。返回的結(jié)果將以相反的方向進(jìn)行傳遞。Android提供了完成這些工作所需的所有的代碼，以使你可以集中精力來實(shí)現(xiàn)RPC接口本身。
RPC接口可以只包括方法。即便沒有返回值，所有方法仍以同步的方式執(zhí)行（本地方法阻塞直至遠(yuǎn)程方法結(jié)束）。
簡(jiǎn)單的說，這套機(jī)制是這樣工作的：一開始，你用簡(jiǎn)單的IDL（界面描繪語言）聲明一個(gè)你想要實(shí)現(xiàn)的RPC接口。然后用aidl 工具為這個(gè)聲明生成一個(gè)Java接口定義，這個(gè)定義必須對(duì)本地和遠(yuǎn)程進(jìn)程都可見。它包含兩個(gè)內(nèi)部類。內(nèi)部類中有管理實(shí)現(xiàn)了你用IDL聲明的接口的遠(yuǎn)程方法調(diào)用所需要的所有代碼。兩個(gè)內(nèi)部類均實(shí)現(xiàn)了IBinder接口。一個(gè)用于系統(tǒng)在本地內(nèi)部使用，你些的代碼可以忽略它；另外一個(gè)，我們稱為Stub，擴(kuò)展了Binder類。除了實(shí)現(xiàn)了IPC調(diào)用的內(nèi)部代碼之外，它還包括了你聲明的RPC接口中的方法的聲明。一般情況下，遠(yuǎn)程過程是被一個(gè)服務(wù)所管理的（因?yàn)榉?wù)可以通知系統(tǒng)關(guān)于進(jìn)程以及它連接到別的進(jìn)程的信息）。它包含著aidl工具產(chǎn)生的接口文件和實(shí)現(xiàn)了RPC方法的Stub的子類。而客戶端只需要包括aidl工具產(chǎn)生的接口文件。
下面將說明服務(wù)與其客戶端之間的連接是如何建立的，更為詳細(xì)的有關(guān)RPC機(jī)制的討論和知識(shí)，讀者可以參見坦尼保姆所著的《分布式系統(tǒng)》一書，里面有非常詳細(xì)和精彩的論述：
1) 服務(wù)的客戶端（位于本地）應(yīng)該實(shí)現(xiàn)onServiceConnected() 和onServiceDisconnected() 方法。這樣，當(dāng)至遠(yuǎn)程服務(wù)的連接成功建立或者斷開的時(shí)候，它們會(huì)收到通知。這樣它們就可以調(diào)用bindService() 來設(shè)置連接。
2) 而服務(wù)則應(yīng)該實(shí)現(xiàn)onBind() 方法以接受或拒絕連接。這取決于它收到的intent（intent將傳遞給bindService()）。如果接受了連接，它會(huì)返回一個(gè)Stub的子類的實(shí)例。
3) 如果服務(wù)接受了連接，Android將會(huì)調(diào)用客戶端的onServiceConnected()方法，并傳遞給它一個(gè)IBinder對(duì)象，它是由服務(wù)所管理的Stub的子類的代理。通過這個(gè)代理，客戶端可以對(duì)遠(yuǎn)程服務(wù)進(jìn)行調(diào)用。
掌握線程安全方法
在一些情況下，你所實(shí)現(xiàn)的方法有可能會(huì)被多于一個(gè)的線程所調(diào)用，所以它們必須被寫成線程安全的。
對(duì)于我們上面所討論的RPC機(jī)制中的可以被遠(yuǎn)程調(diào)用的方法來說，這是必須首先考慮的。如果針對(duì)一個(gè)IBinder對(duì)象中實(shí)現(xiàn)的方法的調(diào)用源自這個(gè)IBinder對(duì)象所在的進(jìn)程時(shí)，這個(gè)方法將會(huì)在調(diào)用者的線程中執(zhí)行。然而，如果這個(gè)調(diào)用源自其它的進(jìn)程，則這個(gè)方法將會(huì)在一個(gè)線程池中選出的線程中運(yùn)行，這個(gè)線程池由Android加以管理，并與IBinder存在于同一進(jìn)程內(nèi)；這個(gè)方法不會(huì)在進(jìn)程的主線程內(nèi)執(zhí)行。反過來說，一個(gè)服務(wù)的onBind() 方法應(yīng)為服務(wù)進(jìn)程的主線程所調(diào)用，而實(shí)現(xiàn)了由onBind() 返回的對(duì)象（比如說，一個(gè)實(shí)現(xiàn)了RPC方法的Stub的子類）的方法將為池中的線程所調(diào)用。因?yàn)榉?wù)可以擁有多于一個(gè)的客戶端，而同一時(shí)間，也會(huì)有多個(gè)池中的線程調(diào)用同一個(gè)IBinder方法。因此IBinder方法必須實(shí)現(xiàn)為線程安全的。
類似的，一個(gè)內(nèi)容提供者能接受源自其它進(jìn)程的請(qǐng)求數(shù)據(jù)。盡管ContentResolver和ContentProvider類隱藏了交互溝通過程的管理細(xì)節(jié)，ContentProvider會(huì)由query()，insert()，delete()，update()和getType()方法來相應(yīng)這些請(qǐng)求，而這些方法也都是由那個(gè)內(nèi)容提供者的進(jìn)程中所包涵的線程池提供的，而不是進(jìn)程的主線程本身。所以這些有可能在同一時(shí)間被很多線程調(diào)用的方法也必須被實(shí)現(xiàn)為線程安全的。
