1.3 進(jìn)程和線(xiàn)程

當(dāng)應(yīng)用程序的第一個(gè)組件需要運(yùn)行時(shí)，Android會(huì)為它啟動(dòng)一個(gè)Linux進(jìn)程，及單一的執(zhí)行線(xiàn)程。默認(rèn)情況下，應(yīng)用程序所有的組件均在這個(gè)進(jìn)程、線(xiàn)程中運(yùn)行。

然而，你也可以安排組件在其他進(jìn)程中運(yùn)行，而且可以為任意進(jìn)程衍生出其它線(xiàn)程。

1.3.1 進(jìn)程

組件運(yùn)行的進(jìn)程由manifest文件控制。組件元素—— <activity>，<service>，<receiver>和<provider>每個(gè)都有一個(gè) process屬性來(lái)指定組件希望運(yùn)行的進(jìn)程。可以設(shè)置這些屬性讓每個(gè)組件運(yùn)行于自己的進(jìn)程之內(nèi)，或一些組件共享一個(gè)進(jìn)程而其余的組件擁有獨(dú)立的進(jìn)程。我 們也可以設(shè)置讓不同應(yīng)用程序的組件在同一個(gè)進(jìn)程運(yùn)行——使應(yīng)用程序的組成部分共享同一個(gè)Linux用戶(hù)ID并賦以同樣的權(quán) 限。<application>元素也有一個(gè)process屬性，以設(shè)定所有組件的默認(rèn)屬性值。

所有的組件實(shí)例都位于指定進(jìn)程的主線(xiàn)程內(nèi)， 而對(duì)這些組件的系統(tǒng)調(diào)用也將由那個(gè)線(xiàn)程進(jìn)行分發(fā)。一般不會(huì)為每個(gè)實(shí)例創(chuàng)建線(xiàn)程。因此，某些方法總是運(yùn)行在進(jìn)程的主線(xiàn)程內(nèi)，這些方法包括諸如View.onKeyDown()這 樣響應(yīng)用戶(hù)動(dòng)作以及后面組件生命周期一節(jié)所要討論的生命周期通知。這意味著 組件在被系統(tǒng)調(diào)用的時(shí)候，不應(yīng)該執(zhí)行長(zhǎng)時(shí)間的、或者阻塞的操作 （例如網(wǎng)絡(luò)相關(guān)操 作或是循環(huán)計(jì)算），因?yàn)檫@將阻塞同樣位于這個(gè)進(jìn)程中的其它組件的運(yùn)行。而應(yīng)該如同下面線(xiàn)程一節(jié)所敘述的那樣，為這些長(zhǎng)時(shí)間操作衍生出一個(gè)單獨(dú)的線(xiàn)程進(jìn)行處 理。

在可用內(nèi)存不足而又有一個(gè)正在為用戶(hù)進(jìn)行服務(wù)的進(jìn)程需要更多內(nèi)存的時(shí)候，Android有時(shí)候可能會(huì)關(guān)閉一個(gè)進(jìn)程。此時(shí)這個(gè)進(jìn)程中運(yùn)行著的應(yīng)用程序也因此被銷(xiāo)毀。當(dāng)再次需要這種組件進(jìn)行處理工作時(shí)，會(huì)為他們重新創(chuàng)建進(jìn)程。

在決定結(jié)束哪個(gè)進(jìn)程的時(shí)候，Android會(huì)衡量它們對(duì)于用戶(hù)的相對(duì)重要性。比如說(shuō)，相對(duì)于一個(gè)仍對(duì)用戶(hù)可見(jiàn)的Activity的進(jìn)程，它更有可能 去關(guān)閉一個(gè)其Activity已經(jīng)不為用戶(hù)所見(jiàn)的進(jìn)程。因此，決定是否關(guān)閉一個(gè)進(jìn)程主要依據(jù)運(yùn)行在那個(gè)進(jìn)程中的組件狀態(tài)。這些狀態(tài)將在后續(xù)的組件生命周期 一節(jié)中予以說(shuō)明。

1.3.2 線(xiàn)程

盡管可以把應(yīng)用程序限制于一個(gè)單獨(dú)的進(jìn)程中，有時(shí)，我們?nèi)匀恍枰苌鲆粋€(gè)線(xiàn)程以處理后臺(tái)任務(wù)。因?yàn)橛脩?hù)界面必須非常及時(shí)的對(duì)用戶(hù)操作做出響應(yīng)，所以，控制 Activity的線(xiàn)程不應(yīng)處理 一些諸如網(wǎng)絡(luò)下載之類(lèi)的 耗時(shí)操作 。 所有不能在瞬間完成的任務(wù)都應(yīng)安排到不同的線(xiàn)程中去 。

線(xiàn)程是由標(biāo)準(zhǔn)Java Thread對(duì)象在代碼中創(chuàng)建的。Android提供了很多用于管理線(xiàn)程的類(lèi)：Looper用于在一個(gè)線(xiàn)程中運(yùn)行一個(gè)消息循環(huán)，Handler用于消息處理，HandlerThread用于建立一個(gè)帶消息循環(huán)的線(xiàn)程。

1.3.3 遠(yuǎn)程過(guò)程調(diào)用

Android有一個(gè)輕量級(jí)的遠(yuǎn)程過(guò)程調(diào)用（RPC） 機(jī)制：即在本地調(diào)用一個(gè)方法，但在遠(yuǎn)程（其它的進(jìn)程中）進(jìn)程執(zhí)行，然后將結(jié)果返回調(diào)用者。這就需要將方法調(diào)用及其附屬的數(shù)據(jù)按操作系統(tǒng)可以理解的方式進(jìn)行 分解，并將其從本地進(jìn)程和地址空間傳送至遠(yuǎn)程進(jìn)程和地址空間，并在那里重新裝配、調(diào)用。返回值必須以相反的方向進(jìn)行傳遞。Android提供了完成這些工 作所需的所有代碼，使我們可以集中精力來(lái)定義和實(shí)現(xiàn)RPC接口本身。

RPC接口可以只包括方法。即使沒(méi)有返回值，所有方法都以同步的方式執(zhí)行（本地方法阻塞直至遠(yuǎn)程方法結(jié)束）。

簡(jiǎn)單的說(shuō)，這套機(jī)制這樣工作：首先我們用簡(jiǎn)單的IDL（接口定義語(yǔ)言）來(lái)聲明想要實(shí)現(xiàn)的RPC接口。然后用 aidl 工具為聲明生成一個(gè)Java接口定義，這個(gè)定義必須對(duì)本地和遠(yuǎn)程進(jìn)程都可見(jiàn)。它包含兩個(gè)內(nèi)部類(lèi)，如下圖所示：

對(duì)于我們用IDL聲明的接口遠(yuǎn)程過(guò)程調(diào)用接口，Inner類(lèi)中包含有管理它所需要的所有代碼。兩個(gè)內(nèi)部類(lèi)均實(shí)現(xiàn)了 IBinder接口。一個(gè)由系統(tǒng)在本地內(nèi)部使用，我們寫(xiě)的代碼可以忽略它；另外一個(gè)，我們稱(chēng)為Stub，擴(kuò)展了Binder類(lèi)。除了實(shí)現(xiàn)了IPC調(diào)用的內(nèi) 部代碼之外，它還包括了我們?cè)赗PC接口中聲明的方法的聲明。我們應(yīng)該如上圖所示的那樣寫(xiě)一個(gè)Stub的子類(lèi)來(lái)實(shí)現(xiàn)這些方法。

通常，遠(yuǎn)程進(jìn)程由一個(gè)服務(wù)所管理的（因?yàn)榉?wù)可以將進(jìn)程以及它到其他進(jìn)程的連接信息通知系統(tǒng)）。它包含 aidl工具生成的接口文件和實(shí)現(xiàn)了RPC方法的Stub子類(lèi)。而客戶(hù)端只需要包括aidl工具生成的接口文件。

下面說(shuō)明如何建立服務(wù)與其客戶(hù)端之間的連接：

v 服務(wù)的客戶(hù)端（位于本地）應(yīng)該實(shí)現(xiàn)onServiceConnected()和onServiceDisconnected()方法。這樣，當(dāng)至遠(yuǎn)程服務(wù)的連接成功建立或者斷開(kāi)時(shí)，都會(huì)收到通知。它們應(yīng)該調(diào)用bindService()來(lái)建立連接。

v 而服務(wù)則應(yīng)該實(shí)現(xiàn)onBind()方法以接受或拒絕連接。這取決于它收到的Intent（傳遞給bindService()的Intent）。如果接受連接，則返回一個(gè)Stub子類(lèi)的實(shí)例。

v 如果服務(wù)接受了連接，Android將會(huì)調(diào)用客戶(hù)端的onServiceConnected()方法，并傳遞給它一個(gè)IBinder對(duì)象，它是由服務(wù)所管理的Stub的子類(lèi)的代理。通過(guò)這個(gè)代理，客戶(hù)端可以對(duì)遠(yuǎn)程服務(wù)進(jìn)行調(diào)用。

這里的描述了忽略了RPC機(jī)制的某些細(xì)節(jié)。更多信息請(qǐng)參考Designing a Remote Interface Using AIDL和IBinder類(lèi)描述。

1.3.4 線(xiàn)程安全方法

在某些情況下，我們所實(shí)現(xiàn)的方法有可能會(huì)被多個(gè)線(xiàn)程調(diào)用，所以它們必須是線(xiàn)程安全的。

對(duì)于我們上一節(jié)所討論的RPC機(jī)制中的可以被遠(yuǎn)程調(diào)用的方法來(lái)說(shuō)，這是必須首先考慮的。如果針對(duì)一個(gè)IBinder對(duì)象中實(shí)現(xiàn)的方法的調(diào)用源自這個(gè) Ibinder對(duì)象所在的進(jìn)程時(shí)，這個(gè)方法將會(huì)在調(diào)用者的線(xiàn)程中執(zhí)行。然而，如果這個(gè)調(diào)用源自其它的進(jìn)程，則這個(gè)方法將會(huì)在一個(gè)線(xiàn)程池中選出的線(xiàn)程中運(yùn) 行，這個(gè)線(xiàn)程池由Android進(jìn)行管理，并與Ibinder存在于同一進(jìn)程內(nèi)；這個(gè)方法不會(huì)在進(jìn)程的主線(xiàn)程內(nèi)執(zhí)行。反過(guò)來(lái)說(shuō)，服務(wù)的onBind()方 法應(yīng)為服務(wù)進(jìn)程的主線(xiàn)程所調(diào)用，而實(shí)現(xiàn)了由onBind()返回的對(duì)象（比如一個(gè)實(shí)現(xiàn)了RPC方法的Stub子類(lèi)）的方法將為池中的線(xiàn)程所調(diào)用。因?yàn)榉?wù) 可以有多個(gè)客戶(hù)端，而同一時(shí)間，也會(huì)有多個(gè)池中的線(xiàn)程調(diào)用同一個(gè)Ibinder方法。因此Ibinder方法必須實(shí)現(xiàn)為線(xiàn)程安全的。

類(lèi)似的，內(nèi)容提供者也可能接受源自其它進(jìn)程的數(shù)據(jù)請(qǐng)求。盡管ContentResolver和ContentProvider類(lèi)隱藏了交互溝通過(guò)程 的管理細(xì)節(jié)，ContentProvider方法query()，insert()，delete()，update()和getType()會(huì)響應(yīng)這些 請(qǐng)求，而這些方法是從內(nèi)容提供者的進(jìn)程所包涵的線(xiàn)程池調(diào)用的，而不是進(jìn)程的主線(xiàn)程。所以這些方法可能在同一時(shí)間被多個(gè)線(xiàn)程調(diào)用，他們也必須實(shí)現(xiàn)為線(xiàn)程安全 的。

Android SDK 1.5中文版 (Application基礎(chǔ)—4)