目錄進程和線程的關系跨進程的種類Serializable，Parcelable接口Binder進程和線程的關系

按照操作系統中的描述，線程是CPU調度的最小單位，同時線程也是一種有限的系統資源。而進程一般是指一個執行單元，在pc端或者移動端上是指一個程序或者一個應用。一個進程中可以包含一個或者是多個線程。所以他們的關系應該是包含和被包含的關系。

跨進程的種類

在Android中跨進程通信的方式有很多種，Bundle,文件共享，AIDL,Messenger,ContentProvider,Socket,這些都能實現進程間之間的通信，當然，雖然都能夠實現進程間通信，但是他們之間的實現原理或者說是底層的實現方式都是不一樣的。下面，我們將會一一說明。

注：很多同學覺得創建進程就應該創建一個新的應用。其實不是的。只要我們在AndroidMenifest上加上這一句代碼就可以了android:process=“:remote”具體的，同學們可以自己的了解。

在說IPC之前，先說一下一些基礎概念，這樣對后面的內容能夠更好的理解。

Serializable，Parcelable接口

Serializable接口是java提供的一個序列化的接口，這是一個空的接口，為對象提供標準的序列化和反序列化操作。

Serializable序列化和反序列化，都是采ObjectOutputStream和ObjectInputStream就可以實現，當然這些系統基本已經為我們實現了。

Parcelable接口，是Android自帶的一種序列化方式。序列化和反序列化都是通過writeToParcel方法來完成的。

兩者的區別：Serializable是java的序列化接口使用簡單，但是由于序列化和反序列化的過程需要大量的I/o操作，所以性能較差。Parcelable接口使用較為麻煩，但是效率很高，但是存在一個很大的缺點，就是被Parcelable將對象序列化以后，要將對象保存到磁盤中的，將會很麻煩。所以建議是使用Serializable。

Binder

直觀來說，Binder是Android中的一個類，它實現了IBinder接口，從IPC的角度來說，Binder是Android中的一種跨進程通信的一種方式，同時還可以理解為是一種虛擬的物理設備，它的設備驅動是／dev/binder/。從Framework角度來說，Binder是ServiceManager的橋梁。從應用層來說，Binder是客戶端和服務端進行通信的媒介。

在Android開發中，Binder主要用在Service中，包括AIDL和Messenger，由于Messenger的底層其實就是Aidl，所以現在我們以AIDL來分析一下binder的工作機制。

上代碼：

/* * This file is auto-generated. DO NOT MODIFY. * Original file: /Users/huangjialin/MyApplication/service/src/main/aidl/aidl/MyAIDLService.aidl */package aidl;// Declare any non-default types here with import statementspublic interface MyAIDLService extends android.os.IInterface { /** * Local-side IPC implementation stub class. */ public static abstract class Stub extends android.os.Binder implements aidl.MyAIDLService {private static final java.lang.String DESCRIPTOR = 'aidl.MyAIDLService';/** * Construct the stub at attach it to the interface. */public Stub() { this.attachInterface(this, DESCRIPTOR);}/** * Cast an IBinder object into an aidl.MyAIDLService interface, * generating a proxy if needed. */public static aidl.MyAIDLService asInterface(android.os.IBinder obj) { if ((obj == null)) {return null; } android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR); if (((iin != null) && (iin instanceof aidl.MyAIDLService))) {return ((aidl.MyAIDLService) iin); } return new aidl.MyAIDLService.Stub.Proxy(obj);}@Overridepublic android.os.IBinder asBinder() { return this;}@Overridepublic boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException { switch (code) {case INTERFACE_TRANSACTION: { reply.writeString(DESCRIPTOR); return true;}case TRANSACTION_getString: { data.enforceInterface(DESCRIPTOR); java.lang.String _result = this.getString(); reply.writeNoException(); reply.writeString(_result); return true;} } return super.onTransact(code, data, reply, flags);}private static class Proxy implements aidl.MyAIDLService { private android.os.IBinder mRemote; Proxy(android.os.IBinder remote) {mRemote = remote; } @Override public android.os.IBinder asBinder() {return mRemote; } public java.lang.String getInterfaceDescriptor() {return DESCRIPTOR; } @Override public java.lang.String getString() throws android.os.RemoteException {android.os.Parcel _data = android.os.Parcel.obtain();android.os.Parcel _reply = android.os.Parcel.obtain();java.lang.String _result;try { _data.writeInterfaceToken(DESCRIPTOR); mRemote.transact(Stub.TRANSACTION_getString, _data, _reply, 0); _reply.readException(); _result = _reply.readString();} finally { _reply.recycle(); _data.recycle();}return _result; }}static final int TRANSACTION_getString = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0); } public java.lang.String getString() throws android.os.RemoteException;}

上面這段代碼是系統生成的，在gen目錄下可以看到根據MyAIDLService.aidl系統為我們生成了MyAIDLService.java這個類。我們先來了解一下這個類中每個方法的含義：

DESCRIPTOR：Binder的唯一標識，一般用于當前Binder的類名表示。

asInterface(android.os.IBinder obj)：用于將服務端的Binder對象轉換成客戶端所需的AIDL接口類型的對象，這種轉化過程是區分進程的，如果客戶端和服務端位于同一個進程，那么這個方法返回的是服務端的stub對象本身，否則返回的是系統封裝后的Stub.proxy對象。

asBinder()：用于返回當前Binder對象。

onTransact：該方法運行在服務端的Binder線程池中，當客戶端發起跨進程通信請求的時候，遠程請求通過系統底層封裝后交給該方法處理。注意這個方法public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags)，服務端通過code可以確定客戶端所請求的目標方法是什么，接著從data中取出目標方法所需的參數，然后執行目標方法。當目標方法執行完畢后，就像reply中寫入返回值。這個方法的執行過程就是這樣的。如果這個方法返回false，客戶端是會請求失敗的，所以我們可以在這個方法中做一些安全驗證。

public java.lang.String getString() throws android.os.RemoteException：

這個方法運行在客戶端中，當客戶端調用此方法的時候，它的內部實現是這樣的：首先創建該方法所需要的輸入類型Parcel對象_data，然后調用transact方法發起遠程調用請求，同時當前線程掛起，然后服務端的OnTransact方法會被調用，直到RPC過程返回后，當前線程繼續執行，并從_reply中讀取返回的數據。

如圖：Binder的工作機制

從上面分析，我們明白了Binder的工作機制但是要注意一些問題：

1.當客戶端發起請求時，由于當前線程會被掛起，直到服務端返回數據，如果這個遠程方法很耗時的話，那么是不能夠在UI線程，也就是主線程中發起這個遠程請求的。

2.由于Service的Binder方法運行在線程池中，所以Binder方法不管是耗時還是不耗時都應該采用同步的方式，因為它已經運行在一個線程中了。

以上就是淺談Android IPC機制之Binder的工作機制的詳細內容，更多關于Android IPC機制之Binder的工作機制的資料請關注好吧啦網其它相關文章！