9.Android中的IPC方式——Bundle、文件共享、Messenger、AIDL、Content-Provider

    Android中的IPC方式有很多，比如可以通过Intent中附加extras（Bundle类型）来传递信息，或者通过共享文件的方式来共享数据，还可以采用前面的文章说的Binder方式来跨进程通信，另外ContentProvider天生就支持跨进程访问的（ContentProvider底层使用的就是Binder机制），所以我们也可以使用ContengProvider来进行IPC。另外，我们也可以通过网络通信的方式来实现IPC，所以，我们也可以使用Socket来实现IPC。下面将介绍几种IPC的方式。

    

    9.1 使用Bundle

    Android中的四大Component都支持在Intent中传递Bunlde数据。其中我们要知道，只有可序列化的类才能在进程间传递，Bundle正是实现了Parcelable接口，我们常用的方式比如，打开一个Service、Activity，或者是发送一个广播，这时候我们都可以在intent中setExtras来放入Bundle数据，使得进程之间可以互相通信。（广播其实是非常常用的一种IPC方式，它本质也是使用Bundle来实现）

    

     9.2 使用文件共享

    两个进程通过读/写同一个文件来交接数据，比如A进程把数据写入文件,B进程通过读取这个文件来获取数据。Android是基于Linux的，所以并发读、写文件可以没有限制地进行，甚至多个线程对一个文件进行写操作都是允许的，所以这样也很容易造成脏数据等问题。所以说，文件共享的方式适合在数据同步要求不高的进程之间进行通信，并且要妥善处理并发读写的问题。我们知道Sharepreferences也是以文件形式的存储数据，所以，我们也可以用Sharepreferences  来实现进程通信。

    

     9.3 使用Messenger

    Messenger意思是信差。因此，它其实就是用来传递Message数据的。在Messager中加入我们需要传递的数据，就可以轻松地实现数据的进程间的通信了。（底层还是使用Binder实现的），在Message中放入我们需要传递的数据，就可以轻松地实现数据的进程间传递了。Messenger是一种轻量级的IPC方案，它的底层实现是AIDL。

     /**     * Create a Messenger from a raw IBinder, which had previously been     * retrieved with {@link #getBinder}.     *      * @param target The IBinder this Messenger should communicate with.     */    public Messenger(IBinder target) {        mTarget = IMessenger.Stub.asInterface(target);    }

    从这个函数中，就可以知道，Messenger其实就是AIDL。

    Messenger的使用是比较简单的，它对AIDL做了封装，所以我们可以更简便地进行进程间的通信。并且，Messenger一次只处理一个请求，因此在服务端我们不需要考虑线程同步的问题（已经为我们处理好了，那么普通的AIDL有这个问题吗？）。实现一个Messenger有如下几个步骤，可以分为服务端和客户端。

    

    1.服务端进程    

    下面看下服务端的代码实现：

package com.example.messengerserverapp;import android.app.Service;import android.content.Intent;import android.os.Bundle;import android.os.Handler;import android.os.IBinder;import android.os.Message;import android.os.Messenger;import android.os.RemoteException;import android.util.Log;public class MyMessengerService extends Service {    public static final String TAG  = "MyMessengerService";    public static final int MSG_FROM_CLIENT = 1;    public static final int MSG_FROM_SERVICE  = 2;    Handler handler = new Handler()    {        public void handleMessage(android.os.Message msg) {            switch (msg.what) {            case MSG_FROM_CLIENT:                Log.i( TAG,msg.getData().getString( "msg") );                Messenger messenger = msg.replyTo;                Message message = Message.obtain(null, MSG_FROM_SERVICE);                Bundle bundle = new Bundle();                bundle.putString( "reply", "服务端已经接受到了您的请求，已经处理完毕");                message.setData(bundle);                try {                    messenger.send(message);                } catch (RemoteException e) {                    // TODO: handle exception                }                break;            default:                break;            }        };    };    Messenger messenger = new Messenger(handler);    @Override    public IBinder onBind(Intent arg0) {         return messenger.getBinder();    }}

从上面的代码中可以看到，在服务端，我们可以给Messenger指定一个Handler来处理客户端发送的数据。服务端在onBind方法中返回这个Messenger的Binder对象，然后，客户端就可以获取到这个Binder的对象，在前面的文章：http://blog.csdn.net/savelove911/article/details/51288577中，我们学过了Binder了，这里就不再赘述了。接下来我们开始看客户端的代码。

2.客户端进程

    下面是客户端的代码实现：

package com.example.messengerclientapp;import android.content.ComponentName;import android.content.Context;import android.content.Intent;import android.content.ServiceConnection;import android.os.Bundle;import android.os.Handler;import android.os.IBinder;import android.os.Message;import android.os.Messenger;import android.os.RemoteException;import android.support.v4.app.Fragment;import android.support.v4.widget.SearchViewCompatIcs.MySearchView;import android.support.v7.app.ActionBarActivity;import android.util.Log;import android.view.LayoutInflater;import android.view.Menu;import android.view.MenuItem;import android.view.View;import android.view.ViewGroup;public class MainActivity extends Activity {    public static final String TAG = "MessengerActivity";    public static final int MSG_FROM_CLIENT = 1;    public static final int MSG_FROM_SERVICE = 2;    private Messenger mService;    private Messenger mGetReplyMessenger = new Messenger( new Handler() {        public void handleMessage(Message msg) {            switch (msg.what) {            case MSG_FROM_SERVICE:                Log.i( TAG,"receiver msg from services:" + msg.getData().getString( "reply"));                break;            default:                break;            }        };    });    private ServiceConnection mConnection = new ServiceConnection(){        @Override        public void onServiceConnected(ComponentName arg0, IBinder arg1) {            mService = new Messenger(arg1);            Message msg = Message.obtain( null , MSG_FROM_CLIENT );            Bundle data = new Bundle();            data.putString( "msg", "这个消息来自于客户端");            msg.setData(data);            msg.replyto = mGetReplyMessenger;            try {                mService.send(msg);            } catch (RemoteException e) {             }        }        @Override        public void onServiceDisconnected(ComponentName arg0) {        }    };    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        Intent startService = new Intent( );        startService.setAction( "com.zhenfei.messengertest");        bindService(startService, mConnection, Context.BIND_AUTO_CREATE);         }    @Override    protected void onDestroy() {         super.onDestroy();        unbindService(mConnection);    } }

接下来我们主要看下面这几行代码中：

  mService = new Messenger(arg1);

   在这行代码中，我们使用了服务端的Binder对象来创建Messenger对象，这个Messenger对象可以根据Binder对象发送Message给服务端。实现细节这边就不进行讨论了。然后，服务端就会接收到客户端的消息了，并且，在本例中，服务端可以在接收到消息以后返回数据给客户端，因为我们在客户端设置了replyTo，看到如下代码：

     msg.replyto = mGetReplyMessenger;

   在这边，我们把客户端的Messenger对象放在了Message当中传递给了服务端，所以服务端那边可以通过Message来获取客户端的Messenger，使得他们之间可以互相通信。

    

    本例只是Messenger的简单应用，在实际应用的时候，我们可以在Message中放入一些客户端进程的信息，然后，服务端那边可以用一个List或者是一个Map来维护客户端的发送过来的客户端信息和Message的replyTo属性,这样服务端就能和客户端进行通信了。

    那么，客户端不发送信息，服务端能主动给客户端发送信息吗？答案是，NO。不行.简单地理解，你不写信给别人，别人如何给你回信呢？所以，使用Messenger在连接服务端后，只能客户端先发送Message给服务端。

 9.4 使用AIDL进行进程通信。

   9.4.1 在AIDL中设置回调

    

在前面的文章中：http://blog.csdn.net/savelove911/article/details/51288577 我们已经简单地使用了AIDL，接下来，我们进一步丰富AIDL的使用。其中包括了服务端主动回调客户端的接口，实现客户端监听服务端，比如在前面的例子中，当服务端添加了一本书以后，回调给客户端，通知客户端。下面我们就开始继续完善上面的代码，代码从上一篇文章开始修改。

    首先，在这边先实现客户端添加书到服务端上，代码如下：

    

public void onClick( View view )    {        switch (view.getId()) {        case R.id.addNewBook:            if( iBookManager != null )            {                try {                    iBookManager.addBook( new Book( "客户端的第"+cilentCount+"本书" ));                } catch (RemoteException e) {                    // TODO Auto-generated catch block                    e.printStackTrace();                }            }            break;        default:            break;        }    }      

    其实就是调用IBookManager的addBook方法，接下来我们重点放在符合让服务端回调客户端。在AIDL中，我们是无法使用普通的接口的，只能使用AIDL接口（进程不同，所以无法互相访问对方的内存，所以找不到对方的接口对象，自然无法使用普通的接口）

    那我们这边先做一个aidl接口，如下：

 

   package com.zhenfei.aidl;    import com.zhenfei.aidl.Book;    interface AddNewBookListener{    void onAddNewBook( in Book book );    }

    在这边，我们继续来讨论这个方法的声明，在上一篇文章，我们说过这样的一段话：

    如果client不需要传输数据给server，client只需要处理经过server处理过后的数据，

    那么 client 和 server 都为 out 

    如果client只需要传输数据给server，而不需要处理返回的数据，

    那么client和server都为 in

    那么，为什么上面我们这个方法声明是in,这个方法应该是Service调用，然后客户端App接收才对吧？

    那这边应该是out才对吧？

    错，这边必须是in。那上面的内容错了吗？也不是，我们这边先要搞清楚，什么样才叫服务端，什么样又叫客户端。

    在AIDL中，服务端并非固定是Service，并没有这样定义过，对于AIDL来说，服务端是指：

    创建了Binder对象那一方

    客户端是指：

    从Binder驱动获取Binder对象的那一方。

    所以，因为这个AddNewBookListener的Binder对象是在“客户端”创建的，所以，调用回调方法的时候，客户端充当了服务端的角色，因此，在此处，我们需要使用in 作为参数的方向。

    接下来，我们需要继续完善IBookManager代码：

    

package com.zhenfei.aidl;import com.zhenfei.aidl.Book;import com.zhenfei.aidl.AddNewBookListener;interface IBookManager{    List<Book> getBookList();    void addBook( in Book book);    void registerListener( AddNewBookListener listener);    void unregisterListener( AddNewBookListener listener);}这边看到，我们在AddNewBookListener 上，并不需要使用方向，因为他们并不是数据类型，而是接口类型的参数。然后，我们先完善客户端的代码，也就是在客户端上，加上添加监听器和注销监听器的代码： 如下：private Stub stub = new Stub() {        @Override        public List<Book> getBookList() throws RemoteException {             return books;        }        @Override        public void addBook(Book book) throws RemoteException {            books.add(book);            for( AddNewBookListener addNewBookListener : list )            {                addNewBookListener.onAddNewBook(book);            }        }        @Override        public void registerListener(AddNewBookListener listener)                throws RemoteException {            Log.i(TAG, "添加监听器成功");            list.add(listener);        }        @Override        public boolean unregisterListener(AddNewBookListener listener)                throws RemoteException {             for( AddNewBookListener addNewBookListener : list )             {                 if( addNewBookListener == listener )                 {                      list.remove(listener);                      return true;                 }             }            Log.i(TAG, "移除监听器失败，没有找到对应的Listener对象");             return false;        }    };

然后是客户端的监听器的代码：

private class MyAddNewBookListener extends AddNewBookListener.Stub    {       int pos;        private  MyAddNewBookListener( int pos )        {            this.pos = pos;        }        @Override        public void onAddNewBook(Book book) throws RemoteException {            Log.i(TAG, "第"+pos+"个监听器接收到回调，添加了一本新书："+book.bookName);            List<Book> books;            try {                books = iBookManager.getBookList();                String formatStr = getResources().getString(R.string.tv_book_info);                formatStr = String.format(formatStr,books.size() + "");                placeholderFragment.tvBookInfo.setText( formatStr);            } catch (RemoteException e) {                 e.printStackTrace();            }        }    }

下面做添加监听器 并且注销监听器的操作，打印的日志如下：

 

我们会发现，在服务端是找不到这个Listener的，因为，客户端传过来的Listener，每次从服务端接口中获取，都是一个全新的，尽管看似都是一个对象，但是很显然他们的地址是不一样的。所以，直接匹配监听器对象来卸载是不现实的，那我们应该怎么做才能成功地注销监听器呢？

   

     一种方法是使用RemoteCallbackList，这个是系统专门提供的用于删除跨进程listener的接口，RemoteCallbackList是一个泛型，支持管理任意的AIDL接口。

    它的声明如下：

   

 public class RemoteCallbackList<E extends IInterface> 

    好了，在这边问一下，什么样的接口才能叫AIDL接口？我想，应该是实现了IInterface的接口。

    RemoteCallbackList 的工作原理很简单，在它的内部中有一个Map结构专门用来保存所有的AIDL接口，这个Map的key是IBinder类型，value是Callback类型，所以，其中key和value分别通过下面的方式来获取数得

 

   IBinder key = listener.asBinder();    Callback value = new Callback( listener , cookie);    

    下面，我们来使用RemoteCallbackList，首先把监听器列表类型改为RemoteCallbackList

    

private RemoteCallbackList<AddNewBookListener> mListenerList = new RemoteCallbackList<AddNewBookListener>();    

    然后修改resgisterListener 和unregisterListener 这两个接口是实现，如下：

    

    

public void registerListener( AddNewBookListener listener )    {        mListenerList.register( listener );    }    public void unregisterListener( AddNewBookListener listener)    {       mListenerList.unregister( listener );    }

    

    最后要修改addBook方法，有新书的时候就用纸所有已经注册的listener

    

 public void addBook( Book book ) throws RemoteException{       books.add( book );        final int N = mListenerList.beginBroadcast();        for( int i = 0 ; i < N ; i ++ )            {            AddNewBookListener listener = mListenerList.getBroadcastItem( i );            if( listener != null )            {                try{                        listener.onAddNewBook( book );                }catch( RemoteException exception)                {                    exception.printStackTrace();                }            }        }       mListener.finishBroadcast();    }

   这边需要注意，RemoteCallBackList它其实不是一个List所以，我们不能够像操作普通的List一样去操作它，所以我们只能够通过它的getBroadcastItem方法来获取其中的元素，而不能直接使用for进行遍历，而且beginBroadcast和finishBroadcast这两个方法，必须成对地使用。

    那上面就是系统提供给我们的监听器方法了，那还有别的方法可以做到注销监听器吗？其实是有的，比如我们给AddNewBookListener这个接口中，添加一个getId方法，然后把每个listener对象和一个id绑定，就可以实现Listener和id绑定。只会，我们就可以根据id匹配listener，这样就可以正常地注销listener对象了。

    在这边，我们考虑这样一种情况，客户端想要获取服务端有多少本书，服务端查询的时候，加入需要花费一些时间，那么，会发生什么样的情况呢？我们在服务端的getBookList方法改成如下：

    

<span style="white-space:pre"></span>@Override        public List<Book> getBookList() throws RemoteException {            SystemClock.sleep(3000);             return books;        }

    然后，我们点击按钮添加书本，并且获取几次获取图书列表，就会发现出现ANR了。这是因为，客户端执行AIDL接口方法的时候，会挂起当前的线程，然后去调用服务端的Binder线程，所以，如果在服务端的接口方法中做了耗时操作，就会造成无响应，ANR。

    所以我们应该尽量避免在服务端的接口方法上做耗时操作，如果这个接口方法是耗时的，我们就应该是用子线程去调用。

    同理，对于listener方法也是，服务端应该避免在主线程调用客户端的耗时方法。可以的话，可以在子线程中调用。

    

    9.4.2 处理Binder意外死亡事件

    

    为了程序的健壮性，我们接下来还要继续完善这个AIDL代码。比如当服务端进程挂掉了，那么就会导致Binder死亡，这时候，我们需要做一些相应的操作，比如重新连接远程服务端、或者是在客户端提醒远程服务可不用。

    一般来说，有两种方法来处理，第一种是设置Binder的死亡代理。

    

    这就需要使用到Binder很重要的两个方法linkToDeath和unlinkToDeath，在linkToDeath方法中，我们可以为Binder设置一个死亡代理，当Binder死亡的时候，我们就能够收到通知，这样我们就可以重新连接请求从而恢复连接。

    第一种是为Binder设置一个死亡代理，首先我们需要声明一个DeathRecipient对象，DeathRecipient是一个接口，这个接口只有一个方法就是binderDied，很明显在，在Binder死亡的时候，系统会回调这个方法。然后，我们就可以移除之前绑定的binder代理并且，重新绑定远程服务。如下：

 

       private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() {        @Override        public void binderDied() {            if( iBookManager == null )                return ;            iBookManager.asBinder().unlinkToDeath(mDeathRecipient, 0 );            iBookManager = null;        }    };

     其次，在客户端绑定了远程服务成功以后，给binder设置死亡代理:

    

<span style="white-space:pre"></span>@Override        public void onServiceConnected(ComponentName service, IBinder binder) {             Log.i(TAG, "连接远程服务成功:"+service.getClassName());            iBookManager = IBookManager.Stub.asInterface(binder);            List<Book> books;            try {                //远程调用获取书本数量的方法                books = iBookManager.getBookList();                String formatStr = getResources().getString(R.string.tv_book_info);                formatStr = String.format(formatStr,books.size() + "");                placeholderFragment.tvBookInfo.setText( formatStr);                //绑定死亡代理                binder.linkToDeath(mDeathRecipient, 0);            } catch (RemoteException e) {                 e.printStackTrace();            }        } 

    其中第二参数是个标记位，一般设置为0就可以了。这样子，我们就成功地为客户端绑定了远程的Binder的死亡代理，这样Binder死亡的时候我们就可以接收到通知了，另外，通过Binder的方法,isBinderAlive也可以判断Binder是否死亡。

    

    第二种方法，是在客户端的onServiceDisconnected中重连远程服务，这两种方法，我们可以随便选择一种来使用，它们的区别在于，onServiceDisconnected在客户端的UI线程中被回调，而binderDied在客户端的Binder线程池中被回调，也就是说，在binderDied方法中，我们是不能访问UI的，这就是它们的区别。

    

    9.4.3 设置AIDL服务端的权限

    默认情况下，我们的远程服务，是允许任何人都可以连接的，但是这样会带来一些风险，因此，我们必须在服务上加入权限验证的功能，验证的方法很多。下面介绍两种常用的方法：

    第一种，可以使用权限来验证。

    首先，在服务端的AndroidManifest.xml中加入权限定义：

 <!-- 加入自定义的权限 -->

    <permission android:name="com.zhenfei.aidl.ACCESS_SERVER_SERVICE" android:protectionLevel="normal"></permission>

    然后，在Service中声明所需要的权限

 

<span style="white-space:pre"></span><service             android:name="com.zhenfei.aidl.ServerService"            android:permission="com.zhenfei.aidl.ACCESS_SERVER_SERVICE"            >            <intent-filter                 >                <action android:name="com.zhenfei.myaidl"/>            </intent-filter>        </service>

    之后，在客户端就可以使用这个权限来绑定服务，在客户端Androidmanifest.xml中加入如下权限：

        <uses-permission android:name="com.zhenfei.aidl.ACCESS_SERVER_SERVICE"/>

    这样就可以了。

    第二种，可以在服务端的onTransact方法中进行权限验证，如果验证失败，返回false，这样服务端就不会执行AIDL中的方法，验证的方法可以使用getCallingUid和getCallingPid来获取客户端所属应用的Uid和Pid，然后在通过这两个参数做一些验证工作，比如验证包名什么的。

    如下：

    public boolean onTransact( int code, Parcel data,Parcel reply , int flags) throws RemoteException    {        int check = checkCallingOrSelfPermission( "com.zhenfei.aild.ACCESS_SERVR_SERVICE");        if( check == PackageManager.PERMISSION_DENIED)        {            return false;        }        String packageName = null;        String[] packaghes = getPackageManager().getPackagesForUid( getCallingUid());        if( package != null && packages.length>0)            packageName = packages[0];                if( !packageName.startWith( "com.zhenfei")){            return false;        }        return super.onTransact( code, data , reply ,flags);    }

    上面的代码，服务端在new一个Stub对象的时候，覆盖重写即可。

    好了，关于AIDL的介绍就到这为止，IPC方式还有一种很常用的，那就是四大组件之一：ContentProvider。

    

9.5 Content Provider简介

    ContentProvider是Android提供的专门用于不同应用之间进行数据共享的方式，因此，ContentProvider天生就支持进程之间通信。和Messenger一样，ContentProvider的底层也是用Binder来实现的，只是由于系统为我们封装了许多，因此，使用起来，比AIDL简单多了。在这边就先不重点介绍了。

    

9.6 使用Socket进行IPC

    Socket也就是我们常说的套接字，我们经常使用Socket来实现网络编程，分为流式套接字和用户数据报套接字。分别对应网络传输协议的TCP协议和UDP协议。TCP协议是面对连接的协议，而UDP协议是面对无连接的协议。Socket编程是属于Java基础范畴的，这里就不进行详细的描述，大致就是服务端打开个端口，让客户端访问。