掌握Android中的程式和執行緒

技術小甜發表於2017-11-09
Android執行緒
程式和執行緒是現代網路作業系統的核心概念。Android作為一種優秀的、承襲Linux的移動作業系統，其程式和執行緒的概念是開發者和安全工作人員需要深入瞭解的問題。本文將詳細介紹Android中的程式、執行緒以及相關的技術問題。
 


程式和執行緒的基本概念

當一個應用程式開始執行它的第一個元件時，Android會為它啟動一個Linux程式，並在其中執行一個單一的執行緒。預設情況下，應用程式所有的元件均在這個程式的這個執行緒中執行。然而，你也可以安排元件在其他程式中執行，而且可以為任意程式衍生出其它執行緒。

Android中的程式

元件執行所在的程式由manifest檔案所控制。元件元素——<activity>， <service>， <receiver>和<provider>——都有一個 process 屬性來指定元件應當執行於哪個程式之內。這些屬性可以設定為使每個元件執行於它自己的程式之內，或一些元件共享一個程式而其餘的元件不這麼做。它們也可以設定為令不同應用程式的元件在一個程式中執行——使應用程式的組成部分共享同一個Linux使用者ID並賦以同樣的許可權。<application>元素也有一個process屬性，以設定所有元件的預設值。
所有的元件例項都位於特定程式的主執行緒內，而對這些元件的系統呼叫也將由那個執行緒進行分發。一般不會為每個例項建立執行緒。因此，某些方法總是執行在程式的主執行緒內，這些方法包括諸如View.onKeyDown()這樣報告使用者動作以及生命週期通告的。這意味著元件在被系統呼叫的時候，不應該施行長時間的抑或阻塞的操作（諸如網路相關操作或是迴圈計算），因為這將阻塞同樣位於這個程式的其它元件的執行。你應該如同下面執行緒部分所敘述的那樣，為這些長時間操作衍生出一個單獨的執行緒進行處理。
在可用記憶體不足而又有一個正在為使用者進行服務的程式需要更多記憶體的時候，Android有時候可能會關閉一個程式。而在這個程式中執行著的應用程式也因此被銷燬。當再次出現需要它們進行處理的工作的時候，會為這些元件重新建立程式。
在決定結束哪個程式的時候，Android會衡量它們對於使用者的相對重要性。比如說，相對於一個仍有使用者可見的activity的程式，它更有可能去關閉一個其activity已經不為使用者所見的程式。也可以說，決定是否關閉一個程式主要依據在那個程式中執行的元件的狀態。
 
 

Android中的執行緒

儘管你可以把你的應用程式限制於一個單獨的程式中，有時，你仍然需要衍生出一個執行緒以處理後臺任務。因為使用者介面必須非常及時的對使用者操作做出響應，所以，控管activity的執行緒不應用於處理一些諸如網路下載之類的耗時操作。所有不能在瞬間完成的任務都應安排到不同的執行緒中去。
執行緒在程式碼中是以標準JavaThread物件建立的。Android提供了很多便於管理執行緒的類：Looper用於在一個執行緒中執行一個訊息迴圈，Handler用於處理訊息，HandlerThread 用於使用一個訊息迴圈啟用一個執行緒。
 
 

RPC：遠端過程呼叫

Android有一個輕量級的遠端過程呼叫（RPC）機制：即在本地呼叫一個方法，但在遠端（其它的程式中）進行處理，然後將結果返回撥用者。這將方法呼叫及其附屬的資料以系統可以理解的方式進行分離，並將其從本地程式和本地地址空間傳送至遠端過程和遠端地址空間，並在那裡重新裝配並對呼叫做出反應。返回的結果將以相反的方向進行傳遞。Android提供了完成這些工作所需的所有的程式碼，以使你可以集中精力來實現RPC介面本身。
RPC介面可以只包括方法。即便沒有返回值，所有方法仍以同步的方式執行（本地方法阻塞直至遠端方法結束）。
簡單的說，這套機制是這樣工作的：一開始，你用簡單的IDL（介面描繪語言）宣告一個你想要實現的RPC介面。然後用aidl 工具為這個宣告生成一個Java介面定義，這個定義必須對本地和遠端程式都可見。它包含兩個內部類。內部類中有管理實現了你用IDL宣告的介面的遠端方法呼叫所需要的所有程式碼。兩個內部類均實現了IBinder介面。一個用於系統在本地內部使用，你些的程式碼可以忽略它；另外一個，我們稱為Stub，擴充套件了Binder類。除了實現了IPC呼叫的內部程式碼之外，它還包括了你宣告的RPC介面中的方法的宣告。一般情況下，遠端過程是被一個服務所管理的（因為服務可以通知系統關於程式以及它連線到別的程式的資訊）。它包含著aidl工具產生的介面檔案和實現了RPC方法的Stub的子類。而客戶端只需要包括aidl工具產生的介面檔案。
下面將說明服務與其客戶端之間的連線是如何建立的，更為詳細的有關RPC機制的討論和知識，讀者可以參見坦尼保姆所著的《分散式系統》一書，裡面有非常詳細和精彩的論述：
1) 服務的客戶端（位於本地）應該實現onServiceConnected() 和onServiceDisconnected() 方法。這樣，當至遠端服務的連線成功建立或者斷開的時候，它們會收到通知。這樣它們就可以呼叫bindService() 來設定連線。
2) 而服務則應該實現onBind() 方法以接受或拒絕連線。這取決於它收到的intent（intent將傳遞給bindService()）。如果接受了連線，它會返回一個Stub的子類的例項。
3) 如果服務接受了連線，Android將會呼叫客戶端的onServiceConnected()方法，並傳遞給它一個IBinder物件，它是由服務所管理的Stub的子類的代理。通過這個代理，客戶端可以對遠端服務進行呼叫。
 
 

掌握執行緒安全方法

在一些情況下，你所實現的方法有可能會被多於一個的執行緒所呼叫，所以它們必須被寫成執行緒安全的。
對於我們上面所討論的RPC機制中的可以被遠端呼叫的方法來說，這是必須首先考慮的。如果針對一個IBinder物件中實現的方法的呼叫源自這個IBinder物件所在的程式時，這個方法將會在呼叫者的執行緒中執行。然而，如果這個呼叫源自其它的程式，則這個方法將會在一個執行緒池中選出的執行緒中執行，這個執行緒池由Android加以管理，並與IBinder存在於同一程式內；這個方法不會在程式的主執行緒內執行。反過來說，一個服務的onBind() 方法應為服務程式的主執行緒所呼叫，而實現了由onBind() 返回的物件（比如說，一個實現了RPC方法的Stub的子類）的方法將為池中的執行緒所呼叫。因為服務可以擁有多於一個的客戶端，而同一時間，也會有多個池中的執行緒呼叫同一個IBinder方法。因此IBinder方法必須實現為執行緒安全的。
類似的，一個內容提供者能接受源自其它程式的請求資料。儘管ContentResolver和ContentProvider類隱藏了互動溝通過程的管理細節，ContentProvider會由query()，insert()，delete()，update()和getType()方法來相應這些請求，而這些方法也都是由那個內容提供者的程式中所包涵的執行緒池提供的，而不是程式的主執行緒本身。

本文轉自samsunglinuxl51CTO部落格，原文連結： http://blog.51cto.com/patterson/932703，如需轉載請自行聯絡原作者


相關文章