Android開發中的進程與線程概念

當某個組件第一次運行的時候，Android啟動了一個進程。默認的，所有的組件和程序運行在這個進程和線程中。

  也可以安排組件在其他的進程或者線程中運行進程，組件運行的進程由manifest file控制。組件的節點—<activity>,<service>, <receiver>, 和<provider> —都包含一個process屬性。這個屬性可以設置組件運行的進程：可以配置組件在一個獨立進程運行，或者多個組件在同一個進程運行。甚至可以多個程序在一個進程中運行——如果這些程序共享一個UserID並給定同樣的權限。<application>節點也包含process屬性，用來設置程序中所有組件的默認進程。

  所有的組件在此進程的主線程中實例化，系統對這些組件的調用從主線程中分離。並非每個對象都會從主線程中分離。一般來說，響應例如View.onKeyDown()用戶操作的方法和通知的方法也在主線程中運行。這就表示，組件被系統調用的時候不應該長時間運行或者阻塞操作（如網絡操作或者計算大量數據），因為這樣會阻塞進程中的其他組件。可以把這類操作從主線程中分離。

  當更加常用的進程無法獲取足夠內存,Android可能會關閉不常用的進程。下次啟動程序的時候會重新啟動進程。

  當決定哪個進程需要被關閉的時候，Android會考慮哪個對用戶更加有用。如Android會傾向於關閉一個長期不顯示在界面的進程來支持一個經常顯示在界面的進程。是否關閉一個進程決定於組件在進程中的狀態，參見後面的章節Component Lifecycles.
線程

  即使為組件分配了不同的進程，有時候也需要再分配線程。比如用戶界面需要很快對用戶進行響應，因此某些費時的操作，如網絡連接、下載或者非常占用服務器時間的操作應該放到其他線程。

  線程通過java的標准對象Thread 創建. Android 提供了很多方便的管理線程的方法—Looper 在線程中運行一個消息循環； Handler傳遞一個消息； HandlerThread 創建一個帶有消息循環的線程。

  遠程調用Remote procedure calls Android有一個遠程調用(RPCs) 的輕量級機制— 通過這個機制，方法可以在本地調用，在遠程執行（在其他進程執行），還可以返回一個值。要實現這個需求，必須分解方法調用，並且所有要傳遞的數據必須是操作系統可以訪問的級別。從本地的進程和內存地址傳送到遠程的進程和內存地址並在遠程處理和返回。返回值必須向相反的方向傳遞。Android提供了做以上操作的代碼，所以開發者可以專注於實現RPC的接口。

  一個RPC接口只能包含方法。所有的方法都是同步執行的（直到遠程方法返回，本地方法才結束阻塞），沒有返回值的時候也是如此。

  簡單來說，這個機制是這樣的：使用IDL (interface definition language)定義你想要實現的接口， aidl 工具可以生成用於java的接口定義，本地和遠程都要使用這個定義。

inner類包含了所有的管理遠程程序（符合IDL描述的接口）所需要的代碼。所有的inner類實現了IBinder 接口.其中一個在本地使用，可以不管它的代碼；另外一個叫做Stub繼承了 Binder 類。為了實現遠程調用，這個類包含RPC接口。開發者可以繼承Stub類來實現需要的方法。

  一般來說，遠程進程會被一個service管理（因為service可以通知操作系統這個進程的信息並和其他進程通信），它也會包含aidl 工具產生的接口文件，Stub類實現了遠處那個方法。服務的客戶端只需要aidl 工具產生的接口文件。

  以下是如何連接服務和客戶端調用：
  服務的客戶端（本地）會實現onServiceConnected() 和onServiceDisconnected() 方法，這樣，當客戶端連接或者斷開連接的時候可以獲取到通知。通過 bindService() 獲取到服務的連接。
  服務的 onBind() 方法中可以接收或者拒絕連接，取決它收到的intent (intent通過 bindService()方法連接到服務). 如果服務接收了連接，會返回一個Stub類的實例.
  如果服務接受了連接，Android會調用客戶端的onServiceConnected() 方法，並傳遞一個Ibinder對象（系統管理的Stub類的代理），通過這個代理，客戶端可以連接遠程的服務。

  以上的描述省略很多RPC的機制。請參見Designing a Remote Interface Using AIDL 和 IBinder 類。

  線程安全的方法。在某些情況下，方法可能調用不止一個的線程，因此需要注意方法的線程安全。

  對於可以遠程調用的方法，也要注意這點。當一個調用在Ibinder對象中的方法的程序啟動了和Ibinder對象相同的進程，方法就在Ibinder的進程中執行。但是，如果調用者發起另外一個進程，方法在另外一個線程中運行，這個線程在和IBinder對象在一個線程池中；它不會在進程的主線程中運行。例如，一個service從主線程被調用onBind() 方法，onBind() 返回的對象（如實現了RPC的Stub子類）中的方法會被從線程池中調用。因為一個服務可能有多個客戶端請求，不止一個線程池會在同一時間調用IBinder的方法。因此IBinder必須線程安全。

  簡單來說，一個content provider可以接收其他進程的數據請求。即使ContentResolver和ContentProvider類沒有隱藏了管理交互的細節，ContentProvider中響應這些請求的方法（query(), insert(), delete(), update(), and getType() ）— 是在content provider的線程池中被調用的，而不是ContentProvider的本身進程。因為這些方法可能是同時從很多線程池運行的，所以這些方法必須要線程安全。