IPC方式（ContentProvider、Socket、Binder連接池）--《Android開發藝術探索》閱讀筆記——第二章part4

版權聲明：本文爲博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/hfy8971613/article/details/80383564

一、ContentProvider

書中省略很多，建議閱讀此係列文章：https://blog.csdn.net/harvic880925/article/details/44521461

二、Socket

建議閱讀Socket詳解：https://blog.csdn.net/carson_ho/article/details/53366856

三、Binder連接池

在本節中要再次介紹一下AIdL，原因是AIDL是一種最常用的進程間通信方式，是日常開發中涉及進程間通信時的首選，所以我們需要額外強調一下.

如何使用AIDL在上面的一節中已經進行了介紹，這裏在回顧一下大致流程：首先創建一個Service和一個AIDL接口，接着創建一個類繼承自AIDL接口中的Stub類並實現Stub中的抽象方法，在Service的onBind方法中返回這個類的對象，然後客戶端就可以綁

定服務端Service，建立連接後就可以訪問遠程服務端的方法了。上述過程就是典型的AIDL的使用流程。

這本來也沒什麼問題，但是現在考慮一種情況；公司的項目越來越龐大了，現在有10個不同的業務模塊都需要使用AIDL來進行進程間通信，那我們該怎麼處理呢？也許你說：“就按照AIDL的實現方式一個個來吧”，這是可以的，如果用這種方法，首先我們需要創建10個Service，這好像有點多啊！如果有100個地方需要用到AIDL呢，先創建100個Servlce?到這裏，讀者應該明白問題所在了，隨着AIDL數量的增加，我們不能無限制地增Service,Service是四大組件之一，本生是一種系統資源。而且太多的Serice會使得我們的應用看起來很重量級，因爲正在運行的Service可以在應用詳情頁看到，當我們的應用詳情顯示有10個個服務正在運行時，這看起來並不是什麼好事。針對上述問題，我們需要減少Service的數量，將所有的AIDL放在同個Service中去管理。

在這種模式下，整個工作機制是這樣的；每個業務模塊創建自己的AIDL接口並實現此接口，這個時候不同業務模塊之間是不能有耦合的，所有實現細節我們要單獨開來，然後向服務端提供自己的唯一標識和其對應的Binder對象；對於服務端來說，只需要一個Service就可以了，服務端提供一個queryBinder接口，這個接口能夠根據業務模塊的特徵來返回相應的Binder對象給它們，不同的業務模塊拿到所需的Binder對象後就可以進行遠程方法調用了。由此可見，Binder連接池的主要作用就是將每個業務模塊的Binder請求統一轉發到遠程Service中去執行，從而避免了重複創建Service的過程，它的工作原理如圖所示。

通過上面的理論介紹，也許還有點不好理解，下面對Binder連接池的代碼實現做一說明。首先，爲了說明問題，我們提供了兩個AIDL接口（ISecurityCenter和ICompute）來模擬上面提到的多個業務模塊都要使用AIDL的情況，其中ISecurityCenter接口提供解密功能，聲明如下：

interface ISecurityCenter {
    String encrypt(String content);
    String decrypt(String password);
}

而ICompute提供了計算加法的功能：

interface ICompute {
    int add(int a,int b);
}

接下來我們來看一下兩個AIDL的實現：

public class SecurityCenterImpl extends ISecurityCenter.Stub{

    private static  final  char SECRET_CODE = '^';

    @Override
    public String encrypt(String content) throws RemoteException {
        char [] chars = content.toCharArray();
        for (int i = 0; i < chars.length; i++) {
            chars[i] ^= SECRET_CODE;
        }
        return new String(chars);
    }

    @Override
    public String decrypt(String password) throws RemoteException {
        return encrypt(password);
    }
}

public class ComputeImpl extends ICompute.Stub {

    @Override
    public int add(int a, int b) throws RemoteException {
        return a + b;
    }
}

現在的業務模塊的AIDL接口定義和實現都已經完成了，注意的是這裏並沒有爲每個模塊的AIDL創建單獨的Service,接下來就是服務端和Binder連接池的工作了

interface IBinderPool {

    IBinder queryBinder(int binderCode);
}

接着，爲Binder連接池創建遠程Service並實現IBnderPool,下面是queryBinder的具體實現，可以看到請求轉達的實現方法，當Binder連接池連接上遠程服務時，會根據不同的模塊的標識binderCode返回不同的Binder對象，通過這個對象就可以操作全部發生在遠程服務端上：

public static class BinderPoolImpl extends IBinderPool.Stub{

        public BinderPoolImpl(){
            super();
        }

        @Override
        public IBinder queryBinder(int binderCode) throws RemoteException {
            IBinder binder = null;
            switch (binderCode){
                case BINDER_SECURUITY_CENTER:
                    binder = new SecurityCenterImpl();
                    break;
                case BINDER_COMPUTE:
                    binder = new ComputeImpl();
                    break;
            }
            return binder;
        }
    }

遠程service的實現比較簡單，如下：

public class BinderPoolService extends Service{

    private  static final String  TAG = "BinderPoolService";

    private Binder mBinderPool = new BinderPool.BinderPoolImpl();

    @Override
    public void onCreate() {
        super.onCreate();
    }

    @Override
    public IBinder onBind(Intent intent) {
        return mBinderPool;
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
    }
}

下面還剩下Binder連接池的具體實現了，在他的內部首先他要去綁定遠程服務，綁定成功後，客戶端就課堂通過他的queryBinder方法來獲取對應的Binder，拿到所需的Binder之後，不同業務模塊就可以各自操作了。（其實這裏可以不用封裝BinderPool，就正常在客戶端BindService即可，然後調用服務，即通過code獲取對用Binder。只不過這裏封裝BinderPool後，客戶端使用會很簡潔。）

public class BinderPool {

    private static final String TAG = "BinderPool";
    public static final int BINDER_NONE = -1;
    public static final int BINDER_COMPUTE = 0;
    public static final int BINDER_SECURUITY_CENTER = 1;

    private Context mContext;
    private IBinderPool mIBinderPool;
    private static volatile BinderPool sInstance;
    private CountDownLatch mConnectBinderPoolCopuntDownLacth;

    private BinderPool(Context context) {
        mContext = context.getApplicationContext();
        connectBinderPoolService();
    }

    public static BinderPool getInstance(Context context) {
        if (sInstance == null) {
            synchronized (BinderPool.class) {
                if (sInstance == null) {
                    sInstance = new BinderPool(context);
                }
            }
        }
        return sInstance;
    }

    private synchronized void connectBinderPoolService() {
        mConnectBinderPoolCopuntDownLacth = new CountDownLatch(1);
        Intent service = new Intent(mContext, BinderPoolService.class);
        mContext.bindService(service, mBinderPoolConnection, Context.BIND_AUTO_CREATE);
        try {
            mConnectBinderPoolCopuntDownLacth.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public IBinder queryBinder(int binderCode) {
        IBinder binder = null;
        try {
            if (mIBinderPool != null) {
                binder = mIBinderPool.queryBinder(binderCode);
            }
        } catch (RemoteException e) {
            e.printStackTrace();
        }
        return binder;
    }

    private ServiceConnection mBinderPoolConnection  = new ServiceConnection() {

        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            mIBinderPool = IBinderPool.Stub.asInterface(service);
            try {
                mIBinderPool.asBinder().linkToDeath(mBinderPoolDeathRecipient,0);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
            mConnectBinderPoolCopuntDownLacth.countDown();
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {

        }
    };

   private IBinder.DeathRecipient mBinderPoolDeathRecipient  = new IBinder.DeathRecipient() {
       @Override
       public void binderDied() {
           mIBinderPool.asBinder().unlinkToDeath(mBinderPoolDeathRecipient,0);
           mIBinderPool = null;
           connectBinderPoolService();
       }
   };

    public static class BinderPoolImpl extends IBinderPool.Stub{

        public BinderPoolImpl(){
            super();
        }

        @Override
        public IBinder queryBinder(int binderCode) throws RemoteException {
            IBinder binder = null;
            switch (binderCode){
                case BINDER_SECURUITY_CENTER:
                    binder = new SecurityCenterImpl();
                    break;
                case BINDER_COMPUTE:
                    binder = new ComputeImpl();
                    break;
            }
            return binder;
        }
    }
}

Binder連接池就具體的分析完了，他的好處顯而易見，針對上面的例子，我們只需要創建一個Service就可以完成多個AIDL的工作，我們現在可以來驗證一下他的功能，新創建一個Activity，在線程中執行如下的操作：

public class BinderActivity extends AppCompatActivity{

    private ISecurityCenter mSecurityCenter;
    private ICompute mCompute;

    @Override
    protected void onCreate( Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_binder);

        new Thread(new Runnable() {
            @Override
            public void run() {
                dowork();
            }
        }).start();
    }

    private void dowork() {
        BinderPool binderPool = BinderPool.getInstance(BinderActivity.this);
        IBinder securityBinder = binderPool.queryBinder(BinderPool.BINDER_SECURUITY_CENTER);
        mSecurityCenter = SecurityCenterImpl.asInterface(securityBinder);
        String msg = "Android";
        try {
            String password = mSecurityCenter.encrypt(msg);
            System.out.print(mSecurityCenter.decrypt(password));
        } catch (RemoteException e) {
            e.printStackTrace();
        }

        IBinder computeBinder =  binderPool.queryBinder(BinderPool.BINDER_COMPUTE);
        mCompute = ComputeImpl.asInterface(computeBinder);
        try {
            System.out.print(mCompute.add(3,5));
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }
}

這裏需要額外說明一下，爲什麼要在線程中去執行呢？這是因爲在Binder連接池的實現中，我們通過CountDownLatch將bindService這一異步操作轉換成了同步操作，這就意味着他有可能是耗時的，然後就是Binder方法的調用過程也可能是耗時的，因此不建議放在主線程中執行。注意到BindePool是一個單例實現，因此在同一個進程中只會初始化一次，所以如果我們提前初始化BinderPool，那麼可以優化程序的體驗，比如我們可以放在Application中提前對BinderPool進行初始化，雖然這不能保證當我們調用BinderPool時它一定是初始化，好的，但是在大多數情況下，這種初始化工作（綁定遠程服務）的時間開銷（如果Binderpool沒有提前初始化完成的話)是可以接受的。另外，BinderPool中有斷線重連的機制，當遠程服務意外終止時，BinderPool會重新建立連接，這個時候如果業務模塊中的Binder調用出了異常，也需要手動去重新獲取最新的Binder對象，這個是需要注意的。

有了BinderPool可以大大方便日常的開發工作，比如如果有一個新的業務模塊需要添加新的AIDL，那麼在他實現自己的AIDL接口後，只需要修改BinderPoolImpl中的queryBinder方法，給自己添加新的binderCode並返回對應的Binder對象就可以，不需要做其他的修改，野不需要創建新的Service，由此可見，BinderPool能夠極大的提高對AIDL的開發效率，並且可以避免大量的Service創建，因此比較建議使用

注：以上是書中對Binder連接池的詳解。在認識Binder連接池之前，我所在的項目，也是有AIDL接口，剛好我就做了其中兩個，當時就直接寫兩個對應的Service，結果後來被Reviewer建議用一個Service就可以，具體做法是：在Service的onBinder()返回Binder時，根據intent（bindService傳遞過來的）中攜帶的action區分是想要得到哪一個AIDL的Binder，並維護一個map，key就是action，value是Binder。這個很簡單，也可以考慮使用。

四、選擇合適的IPC方式

另外，