IPC机制-Android中的IPC方式一-Bundle、文件共享、Messenger、AIDL

每一段往上的路都是辛苦的，我们也都有累到想休息的时候，但如果我们就此停下来，甚至往回走，我们就永远到不了山顶了

本节开始详细分析各种跨进程通信（IPC）方式。具体方式有很多，比如可以通过在Intent中附加extras来传递信息（使用Bundle），或者通过共享文件来共享数据，还可以采用Binder方式来跨进程通信，另外，ContentProvider天生就是支持跨进程访问的，因此我们也可以采用它来进行IPC。另外，通过网络通信也是可以实现数据传递的，所以Socket也可以实现IPC。下面会一一进行展开。

使用Bundle

四大组件中的三大组件（Activity、Service、BroadcastReceiver）都是支持在Intent中传递Bundle数据的，由于Bundle实现了Parcelable接口，所以它可以方便地在不同的进程间传输。基于这一点，当我们在一个进程中启动另一个进程的Activity、Service、Receiver，我们就可以在Bundle中附加我们需要传输给远程进程的信息并通过Intent发送出去。当然，我们传输的数据必须能够被序列化，比如基本类型、实现了Parcelable接口的对象、实现了Serializable接口的对象以及一些Android支持的特殊对象，具体内容可以参看Bundle这个类，就可以看到所有它支持的类型。Bundle不支持的类型我们无法通过它在进程间传递数据。这是一种最简单的进程间通信方式。

解决Bundle不支持携带的数据进行跨进程通信的问题？

除了直接传递数据这种典型的使用场景，它还有一种特殊的使用场景。比如A进程正在进行一个计算，计算完成之后它要启动B进程的一个组件并把计算结果传递给B进程，可是遗憾的是这个计算结果不支持放入Bundle中，因此无法通过Intent来传递，这个时候如果我们用其他IPC方式就会略显复杂。可以考虑如下方式：我们通过Intent启动进程B的一个Service组件（比如IntentService），让Service也运行在B进程中，所以目标组件就可以不用跨进程方式来获取计算结果（可以使用SharedPreferences等方式）了，这样一来就轻松解决了跨进程的问题。这种方式的核心思想在于将原来需要在A进程的计算任务转移到B进程的后台Service中去执行，这样就成功地避免了进程间通信问题，而且只用了很小的代价。

使用文件共享

共享文件也是一种不错的进程间通信方式，两个进程通过读/写同一个文件来交换数据，比如A进程把数据写入文件，B进程通过读取这个文件来获取数据。在Windows中，一个文件如果被加了排斥锁将会导致其他线程无法对其他进行访问，包括读和写，而由于Android系统基于Linux，使得其并发读/写文件可以没有限制地进行，甚至两个线程同时对同一个文件进行写操作都是允许的，尽管这可能会出现问题。通过文件交换数据，除了可以交换一些文本信息外，我们还可以序列化一个对象到文件系统中的同时从另一个进程中恢复这个对象，下面就展示这种使用方式。

我们在MainActivity的onResume方法中序列化一个User对象到sd卡上的一个文件里，然后在SecondActivity的onResume中去反序列化，我们期望在SecondActivity中能够正确地恢复User对象的值。代码如下：

MainActivity：

//序列化User对象    
private void persistToFile(){

    new Thread(new Runnable(){

        @Override
        public void run() {
            User user = new User(1,"hello world",false);
            File dir = new File(MyConstants.ANDROIDDEMO_2_PATH);
            if(!dir.exists()) {
                dir.mkdirs();
            }
            File cachedFile = new File(MyConstants.CACHE_FILE_PATH);
            ObjectOutputStream objectOutputStream = null;
            try {
                objectOutputStream = new ObjectOutputStream(new FileOutputStream(cachedFile));
                objectOutputStream.writeObject(user);
                Log.e(TAG, "persist user:"+user);
            } catch (IOException e) {
                e.printStackTrace();
            } finally {
                MyUtils.close(objectOutputStream);
            }
        }
    }).start();
}

SecondActivity：

//反序列化User
private void recoverFromFile(){

    new Thread(new Runnable(){

        @Override
        public void run() {
            User user = null;
            File cachedFile = new File(MyConstants.CACHE_FILE_PATH);
            if(cachedFile.exists()) {
                ObjectInputStream objectInputStream = null;
                try {
                    objectInputStream = new ObjectInputStream(new FileInputStream(cachedFile));
                    user = (User) objectInputStream.readObject();
                    Log.e(TAG, "recover user:"+user);
                } catch (IOException e) {
                    e.printStackTrace();
                } catch (ClassNotFoundException e) {
                    e.printStackTrace();
                } finally {
                    MyUtils.close(objectInputStream);
                }
            }
        }
    }).start();
}

User：

public class User implements Parcelable, Serializable {

    private static final long serialVersionUID = 519067123721295773L;

    public int userId;
    public String userName;
    public boolean isMale;

    public Book book;

    public User() {
    }

    public User(int userId, String userName, boolean isMale) {
        this.userId = userId;
        this.userName = userName;
        this.isMale = isMale;
    }

    public int describeContents() {
        return 0;
    }

    public void writeToParcel(Parcel out, int flags) {
        out.writeInt(userId);
        out.writeString(userName);
        out.writeInt(isMale ? 1 : 0);
        out.writeParcelable(book, 0);
    }

    public static final Parcelable.Creator<User> CREATOR = new Parcelable.Creator<User>() {
        public User createFromParcel(Parcel in) {
            return new User(in);
        }

        public User[] newArray(int size) {
            return new User[size];
        }
    };

    private User(Parcel in) {
        userId = in.readInt();
        userName = in.readString();
        isMale = in.readInt() == 1;
        book = in.readParcelable(Thread.currentThread().getContextClassLoader());
    }

    @Override
    public String toString() {
        return "User:{userId:"+userId+", userName:"+userName+", isMale:"+isMale+"}, with child:{"+book+"}";
    }
}

MyConstants：

public class MyConstants {

    public static final String ANDROIDDEMO_2_PATH = Environment
            .getExternalStorageDirectory().getPath()
            + "/androiddemo2/";

    public static final String CACHE_FILE_PATH = ANDROIDDEMO_2_PATH + "usercache";

    public static final int MSG_FROM_CLIENT = 0;
    public static final int MSG_FROM_SERVICE = 1;
}

MyUtils：

public class MyUtils {

    public static void close(Closeable closeable) {
        try {
            if (closeable != null) {
                closeable.close();
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

下面看一下log，很显然，在SecondActivity中成功地从文件中恢复了之前存储的User对象的内容，这里之所以说内容，是因为反序列化得到的对象只是在内容上和序列化之前的对象是一样的，但它们本质上还是两个对象。

通过文件共享这种方式来共享数据对文件格式是没有具体要求的，只要读/写双方约定数据格式即可。不过通过文件共享的方法也是有局限性的，比如并发读/写的问题，像上面的那个例子，如果并发读/写，那么我们读出的内容就有可能不是最新的，如果是并发写的话那就更严重了。因此我们要尽量避免并发写这种情况的发生或者考虑使用线程同步来限制多个线程的写操作。通过上面的分析，可以知道，文件共享方式适合在对数据同步要求不高的进程之间进行通信，并且要妥善处理并发读/写的问题。

当然，SharedPreferences是个特例，众所周知，SharedPreferences是Android中提供的轻量级存储方案，它通过键值对的方式来存储数据，在底层实现上它采用XML文件来存储键值对，每个应用的SharedPreferences文件都可以在当前包所在的data目录下查看到。从本质上来说，SharedPreferences也属于文件的一种，但是由于系统对它的读/写有一定的缓存策略，即在内存中会有一份SharedPreferences文件的缓存，因此在多进程模式下，系统对它的读/写就变得不可靠，当面对高并发的读/写访问，SharedPreferences有很大几率会丢失数据，因此，不建议在进程间通信中使用SharedPreferences。

使用Messenger

Messenger可以翻译为信使，顾名思义，通过它可以在不同进程中传递Message对象，在Message中放入我们需要传递的数据，就可以轻松地实现数据的进程间传递了。Messenger是一种轻量级的IPC方案，它的底层实现是AIDL，为什么这么说呢？我们大致看一下Messenger这个类的构造方法就知道了。下面是Messenger的两个构造方法，从构造方法的实现上我们可以明显看出AIDL的痕迹，不管是IMessenger还是Stub.asInterface，这种使用方法都表明它的底层是AIDL。

Messenger的使用方法很简单，它对象AIDL做了封装，Messenger实现了Parcelable接口，使得我们可以更简便地进行进程间通信。同时，由于它一次处理一个请求，因此在服务端我们不用考虑线程同步的问题，这是因为服务端中不存在并发执行的情形。实现一个Messenger有如下几个步骤，分为服务端和客户端。

服务端进程

首先，我们需要在服务端创建一个Service来处理客户端的连接请求，同时创建一个Handler并通过它来创建一个Messenger对象，然后在Service的onBind方法中返回这个Messenger对象底层的Binder即可。

客户端进程

客户端进程中，首先要绑定服务端的Service，绑定成功后用服务端返回的IBinder对象创建一个Messenger，通过这个Messenger就可以向服务端发送消息了，发消息类型为Message对象。如果需要服务端能够响应客户端，就和服务端一样，需要创建一个Handler并创建一个新的Messenger，并把这个Messenger对象通过Message的replyTo参数传递给服务端，服务端通过这个replyTo参数就可以回应客户端。

下面来看一个简单点的例子，在这个例子当中服务端无法回应客户端：

首先看服务端的代码，可以看到MessengerHandler用来处理客户端发送的消息，并从消息中取出客户端发来的文本消息。而mMessenger是一个Messenger对象，它和MessengerHandler相关联，并在onBind方法中返回它里面的Binder对象，可以看出，这里Messenger的作用是将客户端发送的消息传递给MessengerHandler处理。

public class MessengerService extends Service {

    public static final String TAG = "MessengerService";

    private static class MessengerHandler extends Handler {

        @Override
        public void handleMessage(Message msg) {
            switch(msg.what) {
            case MyConstants.MSG_FROM_CLIENT :
                Log.e(TAG, "receive msg from client:"+msg.getData().getString("msg"));
                break;

            default:
                super.handleMessage(msg);
            }
        }
    }

    private final Messenger mMessenger = new Messenger(new MessengerHandler());

    @Override
    public IBinder onBind(Intent intent) {
        return mMessenger.getBinder();
    }
}

接下来再看看客户端的实现，客户端的实现也比较简单，首先需要绑定远程进程的MessengerService，绑定成功后，根据服务端返回的binder对象创建Messenger对象并使用此对象向服务端发送消息。下面的代码在Bundle中向服务端发送了一句话，在上面的服务端代码中会打印出这句话。

public class MessengerActivity extends Activity{

    private Messenger mService;

    private ServiceConnection mConnection = new ServiceConnection(){

        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            mService = new Messenger(service);
            Message msg = Message.obtain(null, MyConstants.MSG_FROM_CLIENT);
            Bundle data = new Bundle();
            data.putString("msg", "hello, this is client.");
            msg.setData(data);
            try {
                mService.send(msg);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {

        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Intent intent = new Intent(this, MessengerService.class);
        bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
    }

    @Override
    protected void onDestroy() {
        unbindService(mConnection);
        super.onDestroy();
    }
}

然后，注册Service让其运行在单独的进程中，以及注册Activity：

<activity 
    android:name=".messenger.MessengerActivity"
    android:label="@string/app_name" >

    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

<service 
    android:name=".messenger.MessengerService"
    android:process=":remote"/>

最后，运行程序，查看log：

通过上面的例子可以看出，在Messenger中进行数据传递必须将数据放入Message中，而Messenger和Message都实现了Parcelable接口，因此可以跨进程传输。简单来说，Message中所支持的数据类型都是Messenger所支持的传输类型。实际上，通过messenger来传输Message，Message中能使用的载体只有what、arg1、arg2、Bundle以及replyTo。Message中的另一个字段object在同一个进程中是很实用的，但是在进程间通信的时候，在Android2.2以前object字段不支持跨进程传输，即便是2.2以后，也仅仅是系统提供的实现了Parcelable接口的对象才能通过它来传输。这就意味着我们自定义的Parcelable对象是无法通过object字段来传输，这也导致了object字段的实用性大大降低，所幸我们还有Bundle，Bundle中可以支持大量的数据类型。

上面的例子演示了如果在服务端接收客户端中发送的消息。下面就介绍如何实现服务端回应客户端这种效果。

首先看服务端的修改，服务端只需要修改MessengerHandler，当收到消息后，会立即回复一条消息给客户端。

private static class MessengerHandler extends Handler {

    @Override
    public void handleMessage(Message msg) {
        switch(msg.what) {
        case MyConstants.MSG_FROM_CLIENT :
            Log.e(TAG, "receive msg from client:"+msg.getData().getString("msg"));

            //回应客户端
            Messenger client = msg.replyTo;
            Message replyMessage = Message.obtain(null, MyConstants.MSG_FROM_SERVICE);
            Bundle bundle = new Bundle();
            bundle.putString("reply", "ok, Nice...");
            replyMessage.setData(bundle);
            try {
                client.send(replyMessage);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
            break;

        default:
            super.handleMessage(msg);
        }
    }
}

接着再看客户端的修改，为了接收服务端的回复，客户端也需要准备一个接收消息的Messenger和Handler，如下所示：

private Messenger mGetReplyMessenger = new Messenger(new MessengerHandler());

private static class MessengerHandler extends Handler {
    @Override
    public void handleMessage(Message msg) {
        switch(msg.what) {
        case MyConstants.MSG_FROM_SERVICE:
            Log.e(TAG,"receive msg from Service:"+msg.getData().getString("reply"));
            break;

        default:
            super.handleMessage(msg);
        }
    }
};

除了上述修改，还有很关键的一点，当客户端发送消息的时候，需要把接收服务端回复的Messenger通过Message的replyTo参数传递给服务端，如下所示：

private ServiceConnection mConnection = new ServiceConnection(){

    @Override
    public void onServiceConnected(ComponentName name, IBinder service) {

        mService = new Messenger(service);
        Message msg = Message.obtain(null, MyConstants.MSG_FROM_CLIENT);
        Bundle data = new Bundle();
        data.putString("msg", "hello, this is client.");
        msg.setData(data);
        //通过Message的replyTo参数传递给服务端，用于回应
        msg.replyTo = mGetReplyMessenger;

        try {
            mService.send(msg);
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }

    @Override
    public void onServiceDisconnected(ComponentName name) {

    }
};

我们再运行程序，查看log：

到这里，已经把采用Messenger进行进程间通信的方法都介绍完了，下面给出一张Messenger的工作原理图以方便更好的理解Messenger：

以上的示例有很多读者也许会有很多异议，怎么都是针对同一个应用的，有没有针对不同应用的？其实同一个应用的不同组件，如果它们运行在不同进程中，那么和它们分别属于两个应用没有本质区别！

使用AIDL

Messenger的局限性：

以上介绍了如何使用Messenger来进行进程间通信的方法，可以发现，Messenger是以串行的方式处理客户端发来的消息，如果大量的消息同时发送到服务端，服务端仍然只是一个个处理，如果有大量的并发请求，那么用Messenger就不太合适了。同时，Messenger的作用主要是为了传递消息，很多时候我们可能需要跨进程调用服务端的方法，这种情形用Messenger就无法实现了，但是我们可以使用AIDL来实现跨进程的方法调用。AIDL也是Messenger的底层实现，因此Messenger本质上也是AIDL，只不过系统为我们做了封装从而方便上层的调用而已。在上节中，我们介绍了Binder的概念，相信大家对Binder也有一定的了解，在Binder的基础上我们可以更加容易的理解AIDL。这里先介绍使用AIDL来进行进程间通信的流程，分为服务端和客户端两个方面。

服务端

服务端首先要创建一个Service用来监听客户端的连接请求，然后创建一个AIDL文件，将暴露给客户端的接口在这个AIDL文件中声明，最后在Service中实现这个AIDL接口即可。

客户端

客户端所要做的事情稍微简单一些，首先需要绑定服务端的Service，绑定成功后，将服务端返回的Binder对象转成AIDL接口所属的类型，接着就可以调用AIDL中的方法了。

其实AIDL的实现过程远不止这么简单，接下来会对其中的细节和难点进行详细介绍，并完善我们在Binder那一节所提供的实例。

AIDL接口的创建

首先看AIDL接口的创建，如下所示，我们创建了一个后缀为AIDL的文件，在里面声明了一个接口和两个接口方法。

IBookManager.aidl：

package com.zaenlove.androiddemo2.aidl;
import com.zaenlove.androiddemo2.aidl.Book;

interface IBookManager {
    List<Book> getBookList();
    void addBook(in Book book);
}

在AIDL文件中，并不是所有的数据类型都是可以使用的，那么AIDL文件到底支持哪些数据类型呢？如下所示：

• 基本数据类型（int、long、char、boolean、double等）；

• String和CharSequence；

• List：只支持ArrayList，里面每个元素都必须能够被AIDL支持；

• Map：只支持HashMap，里面每个元素都必须能够被AIDL支持；

• Parcelable：所有实现了Parcelable接口的对象；

• AIDL：所有的AIDL接口本身也可以在AIDL文件中声明。

以上6中数据类型就是AIDL所支持的所有类型，其中自定义的Parcelable对象和AIDL对象必须要显式import进来，不管它们是否和当前的AIDL文件位于同一个包内。比如IBookManager.aidl这个文件，里面用到了Book这个类，这个类实现了Parcelable接口并且和IBookManager位于同一个包中，但是遵守AIDL的规范，我们仍然需要显式地import进来：import com.zaenlove.androiddemo2.aidl.Book。

另外一个需要注意的地方是，如果AIDL文件中用到了自定义的Parcelable对象，那么必须新建一个和它同名的AIDL文件，并在其中声明它为Parcelable类型。如在IBookManager.aidl文件中，我们用到了Book这个类，所以，我们必须要创建Book.aidl文件，然后在里面添加如下内容：

package com.zaenlove.androiddemo2.aidl;
parcelable Book;

除此之外，AIDL中除了基本数据类型，其他类型的参数必须标上方向：in、out或者inout，in表示输入型参数，out表示输出型参数，inout表示输入输出型参数；如IBookManager.aidl文件中的void addBook(in Book book)。我们要根据实际需要去指定参数类型，不能一概使用out或者inout，因为这在底层实现是有开销的。最后AIDL接口中只支持方法，不支持声明静态常量，这一点区别于传统的接口。

为了方便AIDL的开发，建议把所有和AIDL相关的类和文件全部放入同一个包中，这样做的好处，就是当客户端是另一个应用的时候，你可以直接把整个包复制到客户端工程中。需要注意的是，AIDL的包结构在服务端和客户端要保持一致，否则运行会出错，这是因为客户端需要反序列化服务端中和AIDL接口相关的所有类，如果类的完整路径不一样的话，就无法成功反序列化，程序也就无法正常运行。这里我把所有示例都放在同一个工程中进行，但是读者要理解，一个工程和两个工程的多进程本质是一样的，两个工程的情况，除了需要复制AIDL接口所相关的包到客户端，其他完全一样。

远程服务端Service的实现

接下来实现这个接口，我们创建一个Service，称为BookManagerService，代码如下：

/**
 * 远程服务端的实现
 * @author Zane
 *
 */
public class BookManagerService extends Service {

    private CopyOnWriteArrayList<Book> mBookList = new CopyOnWriteArrayList<Book>();

    private Binder mBinder = new IBookManager.Stub() {

        @Override
        public List<Book> getBookList() throws RemoteException {
            return mBookList;
        }

        @Override
        public void addBook(Book book) throws RemoteException {
            mBookList.add(book);
        }
    };

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

    @Override
    public void onCreate() {
        super.onCreate();
        mBookList.add(new Book(1,"Android"));
        mBookList.add(new Book(2,"Ios"));
    }
}

上面是一个服务端Service的典型实现，首先在onCreate中初始化添加了两本图书的信息，然后创建了一个Binder对象（IBookManger.aidl 和 Book.java文件在上一节讲Binder时已经创建）并在OnBind中返回它，这个对象继承自IBookManager.Stub并实现了它内部的AIDL方法，这个过程是因为：

这个Stub就是一个Binder类，当客户端和服务端都位于同一个进程时，方法调用不会走跨进程的transact过程，而当两者位于不同进程时，方法调用需要走transact过程，这个逻辑由Stub的内部代理类Proxy来完成。

这里主要看getBookList和addBook两个AIDL方法的实现，这里采用了CopyOnWriteArrayList，这个CopyOnWriteArrayList支持并发读/写。在前面我们提到，AIDL方法是在服务端的Binder线程池中执行的，因此当多个客户端同时连接的时候，会存在多个线程同时访问的情形，所以我们要在AIDL方法中处理线程同步，而我们这里直接使用CopyOnWriteArrayList来进行自动的线程同步。

在上面我写到，AIDL中能够使用的List只有ArrayList，但是我们这里却使用了CopyOnWriteArrayList（注意它不是直接继承自ArrayList），为什么能够正常工作呢？这是因为AIDL中所支持的是抽象的List，而List只是一个接口，因此虽然服务端返回的是CopyOnWriteArrayList，但是在Binder中会按照List的规范去访问数据并最终形成一个新的ArrayList传递给客户端。所以，我们在服务端采用CopyOnWriteArrayList是完全可以的。和此类似的还有ConcurrentHashMap。

接下来就是在清单文件中注册Service，如下所示：

<service 
        android:name=".aidl.service.BookManagerService"
        android:process=":remote"/>

注意BookManagerService是运行在独立进程中的，它和客户端的Activity不在同一个进程中，这样就构成了进程间通信的场景。

客户端的实现

首先绑定远程服务，绑定成功后将服务端返回的Binder对象转成AIDL接口，然后就可以通过这个接口去调用服务端的远程方法了，代码如下所示：

/**
 * 客户端的实现
 * @author Zane
 *
 */
public class BookManagerActivity extends Activity {

    private ServiceConnection mConnection = new ServiceConnection(){

        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            //将服务端返回的Binder对象转成AIDL接口
            IBookManager bookManager = IBookManager.Stub.asInterface(service);
            try {
                //调用服务端的远程方法
                List<Book> list = bookManager.getBookList();
                Log.e("--->","query book list, list type:"+list.getClass().getCanonicalName());
                Log.e("--->","query book list:"+list.toString());
            } catch (RemoteException e) {
                e.printStackTrace();
            }

        }

        @Override
        public void onServiceDisconnected(ComponentName name) {

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

        //绑定远程服务
        Intent intent = new Intent(this,BookManagerService.class);
        bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
    }

    protected void onDestroy() {
        unbindService(mConnection);
        super.onDestroy();
    };
}

绑定成功后，会通过bookManager去调用getBookList方法，然后打印出来所获取的图书信息。需要注意的是，服务端的方法有可能需要很久才能执行完毕，这个时候下面的代码就会导致ANR，这一点需要注意哦~，后面会再介绍这种情况，现在之所以这样写是让读者更好地了解AIDL的实现步骤。

记得在清单文件中注册Activity，运行程序，log如下所示：

可以发现，虽然我们在服务端返回的是CopyOnWriteArrayList类型，但是客户端收到的仍然是ArrayList类型，这也证实了上面所做的分析。

接下来，我们再调用另外一个接口addBook，在客户端给服务端添加一本书，然后在获取一次，看程序是否能正常运行。在上面的代码onServiceConnected方法中做如下改动：

public void onServiceConnected(ComponentName name, IBinder service) {
    IBookManager bookManager = IBookManager.Stub.asInterface(service);
    try {

        List<Book> list = bookManager.getBookList();
        Log.e("--->","query book list:"+list.toString());

        //添加图书
        Book newBook = new Book(3,"JavaScript");
        bookManager.addBook(newBook);

        //获取图书
        List<Book> newLists = bookManager.getBookList();
        Log.e("--->","add book list:"+newLists.toString());
    } catch (RemoteException e) {
        e.printStackTrace();
    }
}

运行程序，log如下所示：

现在我们考虑一种情况，假设有一种需求：用户不想时不时地去查询图书列表了，太累了，于是，他去问图书馆，“当有新书时能不能把书的信息告诉我呢？”。这是典型的观察者模式，下面我们就来模拟这种情形。首先，需要提供一个AIDL接口，每个用户都需要实现这个接口并且向图书馆申请新书的提醒功能，当然用户也可以随时取消这种提醒。创建一个IOnNewBookArrivedListener.aidl文件，我们所期望的情况是：当服务端有新书到来时，就会通知每一个已经申请提醒功能的用户。从程序上来说就是调用所有IOnNewBOOKArrivedListener对象中的onNewBookArrived方法，并把新书的对象通过参数传递给客户端，代码如下所示：

package com.zaenlove.androiddemo2.aidl;
import com.zaenlove.androiddemo2.aidl.Book;

interface IOnNewBookArrivedListener{
    void onNewBookArrived(in Book newBook);
}

除了要新加一个AIDL接口，还需要在原有的接口中添加两个新方法，代码如下所示：

package com.zaenlove.androiddemo2.aidl;
import com.zaenlove.androiddemo2.aidl.Book;
import com.zaenlove.androiddemo2.aidl.IOnNewBookArrivedListener;

interface IBookManager {
    List<Book> getBookList();
    void addBook(in Book book);

    void registerListener(IOnNewBookArrivedListener listener);
    void unregisterListener(IOnNewBookArrivedListener unlistener);
}

接着在IBookManager.Stub中实现这两个方法，同时在BookManagerService中还开启一个线程，每隔5s就向书库中加一本新书并通知所有感兴趣的用户，整个代码如下所示：

public class BookManagerService extends Service {

    private AtomicBoolean mIsServiceDestoryed = new AtomicBoolean(false);

    private CopyOnWriteArrayList<Book> mBookList = new CopyOnWriteArrayList<Book>();
    private CopyOnWriteArrayList<IOnNewBookArrivedListener> mListenerList = new CopyOnWriteArrayList<IOnNewBookArrivedListener>();

    private Binder mBinder = new IBookManager.Stub() {

        @Override
        public List<Book> getBookList() throws RemoteException {
            return mBookList;
        }

        @Override
        public void addBook(Book book) throws RemoteException {
            mBookList.add(book);
        }

        @Override
        public void registerListener(IOnNewBookArrivedListener listener)
                throws RemoteException {

            if(!mListenerList.contains(listener)) {
                mListenerList.add(listener);
            }else {
                Log.e("---->","already exists.");
            }
            Log.e("---->", "registerListener, size:"+mListenerList.size());
        }

        @Override
        public void unregisterListener(IOnNewBookArrivedListener unlistener)
                throws RemoteException {

            if(mListenerList.contains(unlistener)) {
                mListenerList.remove(unlistener);
                Log.e("---->","unregister Listener succeed.");
            }else {
                Log.e("---->","not found, can not unregister.");
            }
            Log.e("---->", "unregisterListener, current size:"+mListenerList.size());
        }
    };

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

    @Override
    public void onCreate() {
        super.onCreate();
        mBookList.add(new Book(1,"Android"));
        mBookList.add(new Book(2,"Ios"));

        new Thread(new ServiceWorker()).start();
    }

    private class ServiceWorker implements Runnable{

        @Override
        public void run() {
            while(!mIsServiceDestoryed.get()) {
                try {
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                int bookId = mBookList.size() + 1;
                Book newBook = new Book(bookId,"new Book#"+bookId);
                try {
                    //新书信息通知
                    onNewBookArrived(newBook);
                } catch (RemoteException e) {
                    e.printStackTrace();
                }
            }
        }
    };

    public void onNewBookArrived(Book newBook) throws RemoteException {
        mBookList.add(newBook);
        Log.e("---->","onNewBookArrived, notify listeners:"+mListenerList.size());
        for(IOnNewBookArrivedListener listener : mListenerList) {
            Log.e("---->","onNewBookArrived, notify listeners:"+listener);
            listener.onNewBookArrived(newBook);
        }
    }

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

最后，我们还需要修改一下客户端的代码，主要由两个方面：首先客户端要注册IOnNewBookArrivedListener到远程服务端，这样当有新书时服务端才能通知当前客户端，同时我们要在Activity退出时解除这个注册；另一方面，当有新书时，服务端会回调客户端的IOnNewBOOKArrivedListener对象中的onNewBookArrived方法，但是这个方法是在客户端的Binder线程池中执行的，因此，为了便于进行UI操作，我们需要有一个Handler可以将其切换到客户端的主线程中去执行。代码如下：

public class BookManagerActivity extends Activity {

    private static final int MESSAGE_NEW_BOOK_ARRIVED = 1;

    private IBookManager mRemoteBookManager;

    private Handler mHandler = new Handler(){

        @Override
        public void handleMessage(Message msg) {
            switch(msg.what) {
            case MESSAGE_NEW_BOOK_ARRIVED:
                Log.e("---->","receive new book :"+msg.obj);
                break;
                default:
                    super.handleMessage(msg);
            }
        };
    };

    private ServiceConnection mConnection = new ServiceConnection(){

        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            IBookManager bookManager = IBookManager.Stub.asInterface(service);
            try {
                mRemoteBookManager = bookManager;

                List<Book> list = bookManager.getBookList();
                Log.e("----->","query book list, list type:"+list.getClass().getCanonicalName());
                Book newBook = new Book(3,"HTML5");
                bookManager.addBook(newBook);
                Log.e("----->","add book:"+newBook.toString());
                List<Book> newLists = bookManager.getBookList();
                Log.e("----->","query book list:"+newLists.toString());

                //注册新书信息通知
                bookManager.registerListener(mOnNewBookArrivedListener);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {
            mRemoteBookManager = null;
            Log.e("---->","binder died.");
        }
    };

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

        //绑定远程服务
        Intent intent = new Intent(this,BookManagerService.class);
        bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
    }

    private IOnNewBookArrivedListener mOnNewBookArrivedListener = new IOnNewBookArrivedListener.Stub() {

        @Override
        public void onNewBookArrived(Book newBook) throws RemoteException {
            mHandler.obtainMessage(MESSAGE_NEW_BOOK_ARRIVED, newBook).sendToTarget();
        }
    };

    protected void onDestroy() {
        if(mRemoteBookManager != null && mRemoteBookManager.asBinder().isBinderAlive()) {
            try {
                Log.e("---->","unregister listener:"+mOnNewBookArrivedListener);
                mRemoteBookManager.unregisterListener(mOnNewBookArrivedListener);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }
        unbindService(mConnection);
        super.onDestroy();
    };
}

运行程序，log如下所示：

从上面的代码可以看出，当BookManagerActivity关闭时，我们会在onDestory中去解除已经注册到服务端的listener。因此当我们按back键退出BookManagerActivity，log信息是这样的：

一系列值得注意的地方：

为什么会解注册失败？

从上面的log可以看出，程序没有像我们所预期的那样执行。在解注册的过程中，服务端竟然无法找到我们之前注册的那个listener，在客户端我们注册和解注册时明明传递的是同一个listener！最终，服务端由于无法找到要解除的listener而宣告解注册失败!其实，这是必然的，这种解注册的处理方式在日常开发过程中时常使用到，但是放到多进程中却无法奏效，因为Binder会把客户端传递过来的对象重新转化并生成一个新的对象。虽然我们在注册和解注册过程中使用的是同一个客户端对象，但是通过Binder传递到服务端后，却会产生两个全新的对象，因为对象是不能跨进程直接传输的，对象的跨进程传输本质都是反序列化的过程，这就是为什么AIDL中的自定义对象都必须要实现Parcelable接口的原因。

那么到底该怎么做才能实现解注册功能呢？答案是使用RemoteCallbackList，这看起来很抽象，不过没关系，请看接下来的详细分析。

RemoteCallbackList是系统专门提供的用于删除跨进程listener的接口。RemoteCallbackList是一个泛型，支持管理任意的AIDL接口，这点从它的声明就可以看出，因为所有的接口都继承自IInterface接口。

public class RemoteCallbackList<E extends IInterface>

它的工作原理很简单，在它的内部有一个Map结构专门用来保存所有的AIDL回调，这个Map的key是IBinder类型，value是Callback类型，如下所示：

ArrayMap<IBinder, Callback> mCallbacks = new ArrayMap<IBinder, Callback>();

其中Callback中封装了真正的远程listener。当客户端注册listener的时候，它会把这个listener的信息存入mCallbacks中，其中key和value分别通过下面的方式获得：

IBinder binder = callback.asBinder();
Callback cb = new Callback(callback, cookie);

//存入到mCallbacks当中
mCallbacks.put(binder, cb);

虽然说多次跨进程传输客户端的同一个对象会在服务端生成不同的对象，但是这些新生成的对象有一个共同点，那就是它们底层的Binder对象是同一个，利用这个特性，就可以实现上面我们无法实现的功能。当客户端解注册的时候，只要遍历服务端所有的listener，找出那个和解注册listener具有相同Binder对象的服务端listener并把它删除即可，这就是RemoteCallbackList为我们做的事情。同时RemoteCallbackList还有一个很有用的功能，那就是当客户端进程终止后，它能够自动移除客户端所注册的listener。另外，RemoteCallbackList内部自动实现了线程同步的功能，所以我们使用它来注册和解注册时，不需要做额外的线程同步工作。

下面就演示如何使用RemoteCallbackList来完成解注册：

修改一下BookManagerService，首先要创建一个RemoteCallbackList对象来替代之前的CopyOnWriteArrayList，如下所示：

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

然后修改registerListener和unregisterListener这两个接口的实现：

@Override
public void registerListener(IOnNewBookArrivedListener listener)
        throws RemoteException {

    mListenerList.register(listener);
    final int N = mListenerList.beginBroadcast();
    mListenerList.finishBroadcast();
    Log.d("---->", "registerListener, current size:" + N);
}

@Override
public void unregisterListener(IOnNewBookArrivedListener unlistener)
        throws RemoteException {

    boolean success = mListenerList.unregister(unlistener);

    if (success) {
        Log.d("---->", "unregister success.");
    } else {
        Log.d("---->", "not found, can not unregister.");
    }
    final int N = mListenerList.beginBroadcast();
    mListenerList.finishBroadcast();
    Log.d("---->", "unregisterListener, current size:" + N);
}

everybody，是不是很简单，接着要修改onNewBookArrived方法，当有新书的时候，就要通知所有已注册的listener，如下所示：

public void onNewBookArrived(Book newBook) throws RemoteException {
    mBookList.add(newBook);
    final int N = mListenerList.beginBroadcast();
    for (int i = 0; i < N; i++) {
        IOnNewBookArrivedListener l = mListenerList.getBroadcastItem(i);
        if (l != null) {
            try {
                l.onNewBookArrived(newBook);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }
    }
    mListenerList.finishBroadcast();
}

BookManagerService修改完毕，我们一起验证程序的功能，查看log：

02-27 22:39:24.171: D/----->(15702): register listener:com.zaenlove.androiddemo2.aidl.BookManagerActivity$3@425c10e0
02-27 22:39:24.171: D/---->(15719): registerListener, current size:1
02-27 22:40:27.021: D/---->(15702): unregister listener:com.zaenlove.androiddemo2.aidl.BookManagerActivity$3@425c10e0
02-27 22:40:27.021: D/---->(15719): unregister success.
02-27 22:40:27.021: D/---->(15719): unregisterListener, current size:0

分析log我们知道，使用RemoteCallbackList的确可以完成跨进程的解注册功能。

使用RemoteCallbackList，有一点需要注意，我们无法像操作List一样去操作它，尽管它的名字中也带有List，但是它并不是一个List。遍历RemoteCallbackList，必须要按照下面的方式，其中beginBroadcast和finishBroadcast必须要配对使用，哪怕仅仅是想要获取RemoteCallbackList中的元素个数。

final int N = mListenerList.beginBroadcast();
for (int i = 0; i < N; i++) {
    IOnNewBookArrivedListener l = mListenerList.getBroadcastItem(i);
    if (l != null) {
        //TODO handle l
    }
}
mListenerList.finishBroadcast();

到这里，AIDL的基本使用方法已经介绍完了，但是有几点需要再说明一下：

导致ANR异常，以及如何解决ANR异常？

客户端调用远程服务的方法，被调用的方法运行在服务端的Binder线程中池中，同时客户端线程会被挂起，这个时候如果服务端方法执行比较耗时，就会导致客户端线程长时间地阻塞在这里，而如果这个客户端是UI线程的话，就会导致客户ANR。因此，如果我们明确知道某个远程方法是耗时的，那么就要避免在客户端的UI线程中去访问远程方法。由于客户端的onServiceConnected和onServiceDisconnected方法都运行在UI线程中，所以也不可以在它们里面直接调用服务端的耗时方法。另外，由于服务端的方法本身就运行在服务端的Binder线程池中，所以服务端方法本身就可以执行大量耗时操作，这个时候切记不要再服务端方法中开线程去进行异步任务。

下面稍微改造一下服务端的getBookList方法，假设这个方法是耗时的，那么服务端可以这样实现：

public List<Book> getBookList() throws RemoteException {
    SystemClock.sleep(5000);
    return mBookList;
}

然后在客户端中放一个按钮，单击它的时候就会调用服务端的getBookList方法，可以预知，连续单击几次，客户端就ANR了。代码如下：

public void onButton1Click(View view) {
    Toast.makeText(this, "click button1", Toast.LENGTH_SHORT).show();
    if (mRemoteBookManager != null) {
        try {
            List<Book> newList = mRemoteBookManager.getBookList();
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }
    /*new Thread(new Runnable() {

        @Override
        public void run() {
            if (mRemoteBookManager != null) {
                try {
                    List<Book> newList = mRemoteBookManager.getBookList();
                } catch (RemoteException e) {
                    e.printStackTrace();
                }
            }
        }
    }).start();*/
}

如图所示：

避免出现上诉这种ANR其实很简单，我们只需要把调用放在非UI线程即可，如下所示：

public void onButton1Click(View view) {
    Toast.makeText(this, "click button1", Toast.LENGTH_SHORT).show();
    new Thread(new Runnable() {

        @Override
        public void run() {
            if (mRemoteBookManager != null) {
                try {
                    List<Book> newList = mRemoteBookManager.getBookList();
                } catch (RemoteException e) {
                    e.printStackTrace();
                }
            }
        }
    }).start();
}

同理，当远程服务端需要调用客户端的listener中的方法时，被调用的方法也运行在Binder线程池中，只不过是客户端的线程池。所以，我们同样不可以在服务端中调用客户端的耗时方法。比如针对BookManagerService的onNewBookArrived方法，在其内部调用了客户端的IOnNewBOOKArrivedListener中的onNewBookArrived方法，如果客户端的这个onNewBookArrived方法比较耗时的话，那么请确保BookManagerService中的onNewBookArrived运行在非UI线程中，否则会导致服务端无法响应哦~

另外，由于客户端的IOnNewBookArrivedListener中的onNewBookArrived方法运行在客户端的Binder线程池中，所以不能在它里面访问UI相关的内容，如果要访问UI，请使用Hnadler切换到UI线程，这一点上述的代码中已有所体现。

Binder意外死亡如何解决？

Binder是可能意外死亡的，这往往是由于服务端进程意外停止了，这时我们需要重新连接服务。有两种方法，第一种方法是给Binder设置DeathRecipient监听，当Binder死亡时，我们会收到binderDied方法的回调，在binderDied方法中我们可以重新远程服务，具体方法在Binder那一节中已经介绍过了，这里不再描述了。另一种方法是在onServiceDisconnected中重连远程服务。这两种方法的区别在于：onServiceDisconnected在客户端的UI线程中被回调，而binderDied在客户端的Binder线程池中被回调。也就是说，在binderDied方法中我们不能访问UI，这就是它们的区别。

下面验证一下二者之间的区别，首先通过DDMS杀死服务端进程，接着在这两个方法中打印出当前线程的名称，如下所示：

方法一：

private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() {
    @Override
    public void binderDied() {
        Log.d("---->", "binder died. tname:" + Thread.currentThread().getName());
        if (mRemoteBookManager == null)
            return;
        mRemoteBookManager.asBinder().unlinkToDeath(mDeathRecipient, 0);
        mRemoteBookManager = null;
        // TODO:这里重新绑定远程Service
    }
};

private ServiceConnection mConnection = new ServiceConnection(){

    @Override
    public void onServiceConnected(ComponentName name, IBinder service) {
        IBookManager bookManager = IBookManager.Stub.asInterface(service);
        try {
            mRemoteBookManager = bookManager;
            mRemoteBookManager.asBinder().linkToDeath(mDeathRecipient, 0);
        } catch (RemoteException e) {
            e.printStackTrace();
        }
    }
}；

方法二：

private ServiceConnection mConnection = new ServiceConnection(){

    ...

    @Override
    public void onServiceDisconnected(ComponentName name) {
        mRemoteBookManager = null;
        // TODO:这里重新绑定远程Service
        Log.d("---->", "onServiceDisconnected. tname:" + Thread.currentThread().getName());
    }
};

运行程序，查看log：

从上面的log可以看出，onServiceDisconnected运行在main线程中，即UI线程，而binderDied运行在“Binder_3”这个线程中，很显然，它是Binder线程池中的一个线程。

如何在AIDL中使用权限验证功能？

默认情况下，我们的远程服务任何人都可以连接，但这应该不是我们愿意看到的，所以我们必须给服务加入权限验证功能，权限验证失败则无法调用服务中的方法。在AIDL中进行权限验证，这里介绍两种常用的方法。

第一种方法：

我们可以在服务端中的onBind中进行验证，验证不通过就直接返回null，这样验证失败的客户端直接无法绑定服务，至于验证方式可以有多种，比如使用permission验证。使用这样验证方式，我们要先在AndroidMenifest中声明所需的权限，比如：

<permission 
    android:name="com.zaenlove.androiddemo2.permission.ACCESS_BOOK_SERVICE"
    android:protectionLevel="normal"/>

定义了权限以后，就可以在BookManagerService的onBind方法中做权限验证了，如下所示：

public IBinder onBind(Intent intent) {
    int check = checkCallingOrSelfPermission("com.zaenlove.androiddemo2.permission.ACCESS_BOOK_SERVICE");
    if(check == PackageManager.PERMISSION_DENIED) {
        Log.e("---->","亲，您没有权限哦~请前往清单文件中添加权限...");
        return null;
    }
    return mBinder;
}

还没完，如果我们自己内部的应用想绑定到我们的服务中，只需要在它的AndroidMenifest文件中采用如下方式使用permission即可。

<uses-permission android:name="com.zaenlove.androiddemo2.permission.ACCESS_BOOK_SERVICE" />

这样就欧了，一个应用来绑定我们的服务时，会验证这个应用的权限，如果它没有使用这个权限，onBind方法就会直接返回null，最终结果是这个应用无法绑定到我们的服务，这样就达到了权限验证的效果，这种方法同样适合于Messenger。

在MessengerService中：

public IBinder onBind(Intent intent) {
    int check = checkCallingOrSelfPermission("com.zaenlove.androiddemo2.permission.ACCESS_BOOK_SERVICE");
    if(check == PackageManager.PERMISSION_DENIED){
        Log.e("---->","亲，您没有权限哦~");
        return null;
    }
    return mMessenger.getBinder();
}

其余在清单文件定义权限和以上的方式一样一样的。

第二种方法：

可以在服务端的onTransact方法中进行权限验证，如果验证失败就直接返回false，这样服务端就不会终止执行AIDL中的方法从而达到保护服务端的效果，至于具体的验证方式有很多，可以采用permission验证，具体实现方式和第一种方法一样。还可以采用Uid和Pid来做验证，通过getCallingUid和getCallingPid可以拿到客户端所属应用的Uid和Pid，通过这两个参数我们可以做一些验证工作，比如验证包名。在下面的代码中，既验证了permission，又验证了包名。一个应用如果想用远程调用服务端中的方法，首先要使用我们的自定义权限“com.zaenlove.androiddemo2.permission.ACCESS_BOOK_SERVICE”，其次包名必须以“com.zaenlove”开始，否则调用服务端的方法会失败。

在清单文件中加上如下代码，如：

<permission 
    android:name="com.zaenlove.androiddemo2.permission.ACCESS_BOOK_SERVICE"
    android:protectionLevel="normal"/>
<uses-permission android:name="com.zaenlove.androiddemo2.permission.ACCESS_BOOK_SERVICE" />

在BookManagerService中：

private Binder mBinder = new IBookManager.Stub() {

    ...

    public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws RemoteException {
        int check = checkCallingOrSelfPermission("com.zaenlove.androiddemo2.permission.ACCESS_BOOK_SERVICE");
        if(check == PackageManager.PERMISSION_DENIED) {
            Log.e("---->","亲，您没有权限哦~~~~");
            return false;
        }

        String packageName = null;
        String[] packages = getPackageManager().getPackagesForUid(getCallingUid());
        if(packages != null && packages.length > 0){
            packageName = packages[0];
        }
        if(!packageName.startsWith("com.zaenlove")){
            return false;
        }

        return super.onTransact(code, data, reply, flags);
    };
};

上面介绍了两种AIDL中常用的权限验证方法，但是肯定还有其他方法可以做权限验证，比如为Service指定android:permission属性等。到这里为止，本节的内容就已经完毕了！敬请期待下节(IPC机制-Android中的IPC方式二-ContentProvider、Socket)