本章内容总结：
主要介绍 Serializable 、 Parcelable 、 Binder 。
Serializable接口
1. Serializable 是Java提供的一个序列化接口（空接口），为对象提供标准的序列化和反序列化操作。
2. 只需要一个类去实现 Serializable 接口并声明一个 serialVersionUID 即可实现序列化。
3. 如果不手动指定 serialVersionUID 的值，反序列化时当前类有所改变（比如增删了某些成员变量），那么系统就会重新计算当前类的hash值并赋值给 serialVersionUID。这个时候当前类serialVersionUID 就和序列化数据中的 serialVersionUID不一致，导致反序列化失败，程序就出现crash。*
4. 静态成员变量属于类不属于对象，不参与序列化过程，其次 transient 关键字标记的成员变量不参与序列化过
Parcelable接口
1. Parcelable 内部包装了可序列化的数据。
2. 序列化功能由 writeToParcel 方法完成,最终是通过 Parcel 的一系列writer方法来完成。
@Override public void writeToParcel(Parcel out, int flags) { out.writeInt(code); out.writeString(name); }
3. 反序列化功能由 CREATOR 来完成，其内部表明了如何创建序列化对象和数组，通过 Parcel 的一系列read方法来完成。
4. 内容描述功能由 describeContents 方法完成，几乎所有情况下都应该返回0，仅当当前对象中存在文件描述符时返回1。
public int describeContents() { return 0 }
5. Serializable 是Java的序列化接口，使用简单但开销大，序列化和反序列化过程需要大量I/O操作。而 Parcelable 是Android中的序列化方式，适合在Android平台使用，效率高但是使用麻烦。 Parcelable
主要在内存序列化上， Parcelable 也可以将对象序列化到存储设备中或者将对象序列化后通过网络传输，但是稍显复杂，推荐使用Serializable
Binder
1. Binder是Android中的一个类，实现了 IBinder 接口。从IPC角度说，Binder是Andoird的一种跨进程通讯方式。从Android Framework角度来说，Binder是 ServiceManager 连接各种Manager( ActivityManager· 、 WindowManager )和相应 ManagerService 的桥梁。从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当bindService时，服务端返回一个包含服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务器端提供的服务或者数据（包括普通服务和基于AIDL的服务）。
2. Android中Binder主要用于 Service ，包括AIDL和Messenger。普通Service的Binder不涉及进程间通信，Messenger的底层其实是AIDL，所以下面通过AIDL分析Binder的工作机制。
1.1 由系统根据AIDL文件自动生成.java文件 1. Book.java
表示图书信息的实体类，实现了Parcelable接口。 2. Book.aidl
Book类在AIDL中的声明。
package com.ryg.chapter_2.aidl; parcelable Book;* 3. IBookManager.aidl
定义的管理Book实体的一个接口，包含 getBookList 和 addBook 两个方法。
系统为IBookManager.aidl生产的Binder类，在 gen 目录下的IBookManager.java类。
IBookManager继承了 IInterface 接口，所有在Binder中传输的接口都需要继承IInterface接
口。结构如下：
1. 声明了 getBookList 和 addBook 方法，还声明了两个整型id分别标识这两个方法，用于标识在 transact 过程中客户端请求的到底是哪个方法。
2.声明了一个内部类 Stub ，这个 Stub 就是一个Binder类，当客户端和服务端位于同一进程时，方法调用不会走跨进程的 transact 。当二者位于不同进程时，方法调用需要走 transact 过程，这个逻辑有 Stub 的内部代理类 Proxy
来完成。
3. 这个接口的核心实现就是它的内部类 Stub 和 Stub 的内部代理类 Proxy
1.2 Stub和Proxy类的内部方法和定义
1. DESCRIPTOR
Binder的唯一标识，一般用Binder的类名表示。
2. asInterface(android.os.IBinder obj)
将服务端的Binder对象转换为客户端所需的AIDL接口类型的对象，如果C/S位于同一进程，此方法返回就是服务端的Stub对象本身，否则返回的就是系统封装后的Stub.proxy对象。
3. asBinder
返回当前Binder对象。
4. onTransact
这个方法运行在服务端的Binder线程池中，由客户端发起跨进程请求时，远程请求会通过
系统底层封装后交由此方法来处理。该方法的原型是* java public Boolean onTransact(int code,Parcelable data,Parcelable reply,int flags)
i. 服务端通过code确定客户端请求的目标方法是什么，
ii. 接着从data取出目标方法所需的参数，然后执行目标方法。
iii. 执行完毕后向reply写入返回值（如果有返回值）。
iv. 如果这个方法返回值为false，那么服务端的请求会失败，利用这个特性我们可以来做权限验证。
5. Proxy#getBookList 和Proxy#addBook
i. 这个方法运行在客户端，首先该方法所需要的输入型对象Parcel对象_data，输出型 Parcel对象_reply和返回值对象List。
ii. 然后把该方法的参数信息写入_data（如果有参数）
iii. 接着调用transact方法发起RPC（远程过程调用），同时当前线程挂起，
iv. 然后服务端的onTransact方法会被调用知道RPC过程返回后，当前线程继续执行，
并从_reply中取出RPC过程的返回结果，最后返回_reply中的数据。之所以提供AIDL文件，是为了方便系统为我们生成代码，我们完全可以自己实现Binder。
1.3 可以给Binder设置一个死亡代理，当Binder死亡时，我们就会收到通知。
1. 声明一个 DeathRecipient 对象。 DeathRecipient 只有一个方法 binderDied ，当Binder死亡的时候，系统就会回调 DeathRecipient 方法。
private IBinder.DeathRecipient mDeathRecipient = new
IBinder.DeathRecipient(){ @Override public void binderDied(){
if(mBookManager == null){ return; }
mBookManager.asBinder().unlinkToDeath(mDeathRecipient,0); mBookManager
= null; // TODO：接下来重新绑定远程Service } }
2. Binder有两个很重要的方法 linkToDeath 和 unlinkToDeath 。通过 linkToDeath 为Binder设置一个死亡代理
mService = IBookManager.Stub.asInterface(binder);
binder.linkToDeath(mDeathRecipient,0);
3. 另外，可以通过Binder的 isBinderAlive 判断Binder是否死亡。
.
.
本节主要介绍IPC中的一些基础概念，主要包含三方面内容：Serializable接口、Parcelable接口以及Binder，只有熟悉这三方面的内容后，我们才能更好地理解跨进程通信的各种方式。Serializable和Parcelable接口可以完成对象的序列化过程，当我们需要通过
Intent和Binder传输数据时就需要使用Parcelable或者Serializable。还有的时候我们需要把对象持久化到存储设备上或者通过网络传输给其他客户端，这个时候也需要使用Serializable来完成对象的持久化，下面先介绍如何使用Serializable来完成对象的序列化。
1. Serializable接口
Serializable是Java所提供的一个序列化接口，它是一个空接口，为对象提供标准的序列化和反序列化操作。使用Serializable来实现序列化相当简单，只需要在类的声明中指定一个类似下面的标识即可自动实现默认的序列化过程。
private static final long serialVersionUID = 871136882801008304在Android中也提供了新的序列化方式，那就是Parcelable接口，使用Parcelable来实现对象的序列号，其过程要稍微复杂一些，本节先介绍Serializable接口。上面提到，想让一个对象实现序列化，只需要这个类实现Serializable接口并声明一个serialVersionUID即可，实际上，甚至这个serialVersionUID也不是必需的，我们不声明这serialVersionUID同样也可以实现序列化，但是这将会对反序列化过程产生影响，具体什么影响后面再介绍。User类就是一个实现了Serializable接口的类，它是可以被序列化和反序列化的，如下所示
USer uSer = new USer(1,"你好啊！！！",false);
//序列化过程
try {
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("cache.txt"));
out.writeObject(uSer);
out.close();
} catch (IOException e) {
e.printStackTrace();
}
//反序列化过程
try {
ObjectInputStream in = new ObjectInputStream(new FileInputStream("cache.txt"));
USer newUser = (USer) in.readObject();
} catch (IOException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}上述代码演示了采用Serializable方式序列化对象的典型过程，很简单，只需要把实现了Serializable接口的User对象写到文件中就可以快速恢复了，恢复后的对象newUser和user的内容完全一样，但是两者并不是同一个对象。这个serialVersionUID是用来辅助序列化和反序列化过程的，原则上序列化后的数据中的serialVersionUID只有和当前类的serialVersionUID相同才能够正常地被反序列化。serialVersionUID的详细工作机制是这样的：序列化的时候系统会把当前类serialVersionUID写入序列化的文件中（也可能是其他中介），当反序列化的时候系统会去检测文件中的serialVersionUID，看它是否和当前serialVersionUID一致，如果一致就说明序列化的类的版本和当前类的版本是相同的，这个时候可以成功反序列化；否则就说明当前类和序列化的类相比发生了某些变换，比如成员变量的数量、类型可能发生了改变，这个时候是无法正常反序列化的，因此会报如下错误
java.io.InvalidClassException: Main;
local class incompatible: streamclassdesc serial-VersionUID = 8711368828010083043。以下两点需要特别提一下，首先静态成员变量属于类不属于对象，所以不会参与序列化过程；其次用transient关键字标记的成员变量不参与序列化过程。
2. Parcelable接口
上一节我们介绍了通过Serializable方式来实现序列化的方法，本节接着介绍另一种序列化方式：Parcelable。Parcelable也是一个接口，只要实现这个接口，一个类的对象就可以实现序列化并可以通过Intent和Binder传递。下面的示例是一个典型的用法。
package com.nextvpu.myapplication.mode;
import android.os.Parcel;
import android.os.Parcelable;
public class Book implements Parcelable {
public int bookId;
public String bookName;
public Book(int bookId, String bookName) {
this.bookId = bookId;
this.bookName = bookName;
}
public Book() {
}
protected Book(Parcel in) {
bookId = in.readInt();
bookName = in.readString();
}
/**
* 反序列化
*/
public static final Creator<Book> CREATOR = new Creator<Book>() {
@Override
public Book createFromParcel(Parcel in) {
return new Book(in);
}
@Override
public Book[] newArray(int size) {
return new Book[size];
}
};
/**
* 内容描述功能
* @return
*/
@Override
public int describeContents() {
return 0;
}
/**
* 序列化
* @param dest
* @param flags
*/
@Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(bookId);
dest.writeString(bookName);
}
@Override
public String toString() {
return super.toString();
}
}
这里先说一下Parcel，Parcel内部包装了可序列化的数据，可以在Binder中自由传输。从上述代码中可以看出，在序列化过程中需要实现的功能有序列化、反序列化和内容描述。序列化功能由writeToParcel方法来完成，最终是通过Parcel中的一系列write方法来完成的；反序列化功能由CREATOR来完成，其内部标明了如何创建序列化对象和数组，并通过Parcel的一系列read方法来完成反序列化过程；内容描述功能由describeContents方法来完成，几乎在所有情况下这个方法都应该返回0，仅当当前对象中存在文件描述符时，此方法返回1。需要注意的是，在User(Parcel in)方法中，由于book是另一个可序列化对象，所以它的反序列化过程需要传递当前线程的上下文类加载器，否则会报无法找到类的错误。详细的方法说明请参看表2-1。
系统已经为我们提供了许多实现了Parcelable接口的类，它们都是可以直接序列化的，比如Intent、Bundle、Bitmap等，同时List和Map也可以序列化，前提是它们里面的每个元素都是可序列化的。
既然Parcelable和Serializable都能实现序列化并且都可用于Intent间的数据传递，那么二者该如何选取呢？Serializable是Java中的序列化接口，其使用起来简单但是开销很大，序列化和反序列化过程需要大量I/O操作。而Parcelable是Android中的序列化方式，因此更适合用在Android平台上，它的缺点就是使用起来稍微麻烦点，但是它的效率很高，这是Android推荐的序列化方式，因此我们要首选Parcelable。Parcelable主要用在内存序列化上，通过Parcelable将对象序列化到存储设备中或者将对象序列化后通过网络传输也都是可以的，但是这个过程会稍显复杂，因此在这两种情况下建议大家使用Serializable。以上就是Parcelable和Serializable和区别。
3.Bind
本节的侧重点是介绍Binder的使用以及上层原理。
直观来说，Binder是Android中的一个类，它继承了IBinder接口。从IPC角度来说，Binder是Android中的一种跨进程通信方式，Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder，该通信方式在Linux中没有；Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder，该通信方式在Linux中没有；从Android Framework角度来说，Binder是ServiceManager连接各种Manager（ActivityManager、WindowManager，等等）和相应ManagerService的桥梁；从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务。
Android开发中，Binder主要用在Service中，包括AIDL和Messenger，其中普通Service中的Binder不涉及进程间通信，所以较为简单，无法触及Binder的核心，而Messenger的底层其实是AIDL，所以这里选择用AIDL来分析Binder的工作机制。为了分析Binder的工作机制，我们需要新建一个AIDL示例，SDK会自动为我们生产AIDL所对应的Binder类，然后我们就可以分析Binder的工作过程。
新建三个文件Book.java、Book.aidl和IBookManager.aidl，代
码如下所示。
package com.nextvpu.myapplication.mode;
import android.os.Parcel;
import android.os.Parcelable;
public class Book implements Parcelable {
public int bookId;
public String bookName;
public Book(int bookId, String bookName) {
this.bookId = bookId;
this.bookName = bookName;
}
public Book() {
}
protected Book(Parcel in) {
bookId = in.readInt();
bookName = in.readString();
}
/**
* 反序列化
*/
public static final Creator<Book> CREATOR = new Creator<Book>() {
@Override
public Book createFromParcel(Parcel in) {
return new Book(in);
}
@Override
public Book[] newArray(int size) {
return new Book[size];
}
};
/**
* 内容描述功能
* @return
*/
@Override
public int describeContents() {
return 0;
}
/**
* 序列化
* @param dest
* @param flags
*/
@Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(bookId);
dest.writeString(bookName);
}
@Override
public String toString() {
return super.toString();
}
}// Book.aidl
package com.nextvpu.myapplication.aidl;
// Declare any non-default types here with import statements
parcelable Book;
// IBookManager.aidl
package com.nextvpu.myapplication;
// Declare any non-default types here with import statements
interface IBookManager {
List<Book> getBookList();
void addBook(in Book book);
void registerListener(IOnNewBookArrivedListener listener);
void unregisterListener(IOnNewBookArrivedListener listener);
}
上面三个文件中，Book.java是一个表示图书信息的类，它实现了Parcelable接口。Book.aidl是Book类在AIDL中的声明。IBookManager.aidl是我们定义的一个接口，里面有两个方法：getBookList和addBook，其中getBookList用于从远程服务端获取图书列表，而addBook用于往图书列表中添加一本书，当然这两个方法主要是示例用，不一定要有实际意义。IBookManager中仍然要导入Book类，这就是AIDL的特殊之处。下面我们先看一下系统为IBookManager.aidl生产的Binder类，在build目录下的com.nextvpu.myapplication.aidl包中有一个IBookManager.java的类，这就是我们要找的类。。接下来我们需要根据这个系统生成的Binder类来分析Binder的工作原理，代码如下：
/*
* This file is auto-generated. DO NOT MODIFY.
* Original file: F:\\gitclone\\ipc\\app\\src\\main\\aidl\\com\\nextvpu\\myapplication\\aidl\\IBookManager.aidl
*/
package com.nextvpu.myapplication.aidl;
//import com.nextvpu.myapplication.aidl.IOnNewBookArrivedListener;
public interface IBookManager extends android.os.IInterface {
/**
* Local-side IPC implementation stub class.
*/
public static abstract class Stub extends android.os.Binder implements com.nextvpu.myapplication.aidl.IBookManager {
private static final java.lang.String DESCRIPTOR = "com.nextvpu.myapplication.aidl.IBookManager";
/**
* Construct the stub at attach it to the interface.
*/
public Stub() {
this.attachInterface(this, DESCRIPTOR);
}
/**
* Cast an IBinder object into an com.nextvpu.myapplication.aidl.IBookManager interface,
* generating a proxy if needed.
*/
public static com.nextvpu.myapplication.aidl.IBookManager asInterface(android.os.IBinder obj) {
if ((obj == null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin != null) && (iin instanceof com.nextvpu.myapplication.aidl.IBookManager))) {
return ((com.nextvpu.myapplication.aidl.IBookManager) iin);
}
return new com.nextvpu.myapplication.aidl.IBookManager.Stub.Proxy(obj);
}
@Override
public android.os.IBinder asBinder() {
return this;
}
@Override
public 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_getBookList: {
data.enforceInterface(DESCRIPTOR);
java.util.List<com.nextvpu.myapplication.aidl.Book> _result = this.getBookList();
reply.writeNoException();
reply.writeTypedList(_result);
return true;
}
case TRANSACTION_addBook: {
data.enforceInterface(DESCRIPTOR);
com.nextvpu.myapplication.aidl.Book _arg0;
if ((0 != data.readInt())) {
_arg0 = com.nextvpu.myapplication.aidl.Book.CREATOR.createFromParcel(data);
} else {
_arg0 = null;
}
this.addBook(_arg0);
reply.writeNoException();
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements com.nextvpu.myapplication.aidl.IBookManager {
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.util.List<com.nextvpu.myapplication.aidl.Book> getBookList() throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.util.List<com.nextvpu.myapplication.aidl.Book> _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(Stub.TRANSACTION_getBookList, _data, _reply, 0);
_reply.readException();
_result = _reply.createTypedArrayList(com.nextvpu.myapplication.aidl.Book.CREATOR);
} finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
@Override
public void addBook(com.nextvpu.myapplication.aidl.Book book) throws android.os.RemoteException {
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
try {
_data.writeInterfaceToken(DESCRIPTOR);
if ((book != null)) {
_data.writeInt(1);
book.writeToParcel(_data, 0);
} else {
_data.writeInt(0);
}
mRemote.transact(Stub.TRANSACTION_addBook, _data, _reply, 0);
_reply.readException();
} finally {
_reply.recycle();
_data.recycle();
}
}
}
static final int TRANSACTION_getBookList = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
static final int TRANSACTION_addBook = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);
}
public java.util.List<com.nextvpu.myapplication.aidl.Book> getBookList() throws android.os.RemoteException;
public void addBook(com.nextvpu.myapplication.aidl.Book book) throws android.os.RemoteException;
}
这个类刚开始看起来逻辑混乱，但是实际上还是很清晰的，通过它我
们可以清楚地了解到Binder的工作机制。这个类的结构其实很简单，首先，它声明了两个方法getBookList和addBook，显然这就是我们在IBookManager.aidl中所声明的方法，同时它还声明了两个整型的id分别用于标识这两个方法，这两个id用于标识在transact过程中客户端所请求的到底是哪个方法。接着，它声明了一个内部类Stub，这个Stub就是一个Binder类，当客户端和服务端都位于同一个进程时，方法调用不会走跨进程的transact过程，而当两者位于不同进程时，方法调用需要走transact过程，这个逻辑由Stub的内部代理类Proxy来完成。这么来看，IBookManager这个接口的确很简单，但是我们也应该认识到，这个接口的核心实现就是它的内部类Stub和Stub的内部代理类Proxy，下面详细介绍针对这两个类的每个方法的含义。
DESCRIPTOR
Binder的唯一标识，一般用当前Binder的类名表示，比如本例中的“com.nextvpu.myapplication.aidl.IBookManager”。
asInterface(android.os.IBinder obj)
用于将服务端的Binder对象转换成客户端所需的AIDL接口类型的对象，这种转换过程是区分进程的，如果客户端和服务端位于同一进程，那么此方法返回的就是服务端的Stub对象本身，否则返回的是系统封装后的Stub.proxy对象。
asBind
此方法用于返回当前Binder对象。
onTransact
这个方法运行在服务端中的Binder线程池中，当客户端发起跨进程请求时，远程请求会通过系统底层封装后交由此方法来处理。该方法的原型为public Boolean onTransact(int code,android.os.Parcel data,android.os.Parcel reply,int flags)。服务端通过code可以确定客户端所请求的目标方法是什么，接着从data中取出目标方法所需的参数（如果目标方法有参数的话），然后执行目标方法。当目标方法执行完毕后，就向reply中写入返回值（如果目标方法有返回值的话），onTransact方法的执行过程就是这样的。需要注意的是，如果此方法返回false，那么客户端的请求会失败，因此我们可以利用这个特性来做权限验证，毕竟我们也不希望随便一个进程都能远程调用我们的服务。
Proxy#getBookList
这个方法运行在客户端，当客户端远程调用此方法时，它的内部实现是这样的：首先创建该方法所需要的输入型Parcel对象_data、输出型Parcel对象_reply和返回值对象List；然后把该方法的参数信息写入_data中（如果有参数的话）；接着调用transact方法来发起RPC（远程过程调用）请求，同时当前线程挂起；然后服务端的onTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果；最后返回_reply中的数据。
Proxy#addBook
这个方法运行在客户端，它的执行过程和getBookList是一样的，addBook没有返回值，所以它不需要从_reply中取出返回值。
通过上面的分析，读者应该已经了解了Binder的工作机制，但是有两点还是需要额外说明一下：首先，当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以如果一个远程方法是很耗时的，那么不能在UI线程中发起此远程请求；其次，由于服务端的Binder方法运行在Binder的线程池中，所以Binder方法不管是否耗时都应该采用同步的方式去实现，因为它已经运行在一个线程中了。为了更好地说明Binder，下面给出一个Binder的工作机制图，如图2-5所示。
从上述分析过程来看，我们完全可以不提供AIDL文件即可实现Binder，之所以提供AIDL文件，是为了方便系统为我们生成代码。系统根据AIDL文件生成Java文件的格式是固定的，我们可以抛开AIDL文件直接写一个Binder出来，接下来我们就介绍如何手动写一个Binder。还是上面的例子，但是这次我们不提供AIDL文件。参考上面系统自动生成的IBookManager.java这个类的代码，可以发现这个类是相当有规律的，根据它的特点，我们完全可以自己写一个和它一模一样的类出来，然后这个不借助AIDL文件的Binder就完成了。
们完全可以自己写一个和它一模一样的类出来，然后这个不借助AIDL文件的Binder就完成了。现这个类主要由两部分组成，首先它本身是一个Binder的接口（继承了IInterface），其次它的内部由个Stub类，这个类就是个Binder。还记得我们怎么写一个Binder的服务端吗？代码如下所示。
private Binder mBinder = new IBookManager.Stub() {
@Override
public List<Book> getBookList() throws RemoteException {
SystemClock.sleep(5000);
return mBookList;
}
@Override
public void addBook(Book book) throws RemoteException {
mBookList.add(book);
}
public boolean onTransact(int code, Parcel data, Parcel reply, int flags)
throws RemoteException {
int check = checkCallingOrSelfPermission("com.ryg.chapter_2.permission.ACCESS_BOOK_SERVICE");
Log.d(TAG, "check=" + check);
if (check == PackageManager.PERMISSION_DENIED) {
return false;
}
String packageName = null;
String[] packages = getPackageManager().getPackagesForUid(
getCallingUid());
if (packages != null && packages.length > 0) {
packageName = packages[0];
}
Log.d(TAG, "onTransact: " + packageName);
if (!packageName.startsWith("com.ryg")) {
return false;
}
return super.onTransact(code, data, reply, flags);
}
@Override
public void registerListener(IOnNewBookArrivedListener listener)
throws RemoteException {
mListenerList.register(listener);
final int N = mListenerList.beginBroadcast();
mListenerList.finishBroadcast();
Log.d(TAG, "registerListener, current size:" + N);
}
@Override
public void unregisterListener(IOnNewBookArrivedListener listener)
throws RemoteException {
boolean success = mListenerList.unregister(listener);
if (success) {
Log.d(TAG, "unregister success.");
} else {
Log.d(TAG, "not found, can not unregister.");
}
final int N = mListenerList.beginBroadcast();
mListenerList.finishBroadcast();
Log.d(TAG, "unregisterListener, current size:" + N);
};
};首先我们会实现一个创建了一个Stub对象并在内部实现IBookManager的接口方法，然后在Service的onBind中返回这个Stub对象。因此，从这一点来看，我们完全可以把Stub类提取出来直接作为一个独立的Binder类来实现，这样IBookManager中就只剩接口本身了，通过这种分离的方式可以让它的结构变得清晰点。
根据上面的思想，手动实现一个Binder可以通过如下步骤来完成：
（1）声明一个AIDL性质的接口，只需要继承IInterface接口即可，IInterface接口中只有一个asBinder方法。这个接口的实现如下：
package com.ryg.chapter_2.manualbinder;
import java.util.List;
import android.os.IBinder;
import android.os.IInterface;
import android.os.RemoteException;
public interface IBookManager extends IInterface {
static final String DESCRIPTOR = "com.ryg.chapter_2.manualbinder.IBookManager";
static final int TRANSACTION_getBookList = (IBinder.FIRST_CALL_TRANSACTION + 0);
static final int TRANSACTION_addBook = (IBinder.FIRST_CALL_TRANSACTION + 1);
public List<Book> getBookList() throws RemoteException;
public void addBook(Book book) throws RemoteException;
}
package com.nextvpu.myapplication.binder;
import android.os.Binder;
import android.os.IBinder;
import android.os.Parcel;
import android.os.RemoteException;
import android.support.annotation.NonNull;
import android.support.annotation.Nullable;
import com.nextvpu.myapplication.mode.Book;
import java.util.List;
public class BookManagerImpl extends Binder implements IBookManager {
public BookManagerImpl(){
this.attachInterface(this,DESCRIPTOR);
}
public static IBookManager asInterface(IBinder obj){
if (obj == null){
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin!=null)&&(iin instanceof IBookManager))){
return ((IBookManager)iin);
}
return new BookManagerImpl.Pr
}
@Override
public List<Book> getBookList() throws RemoteException {
return null;
}
@Override
public void addBook(Book book) throws RemoteException {
}
@Override
public IBinder asBinder() {
return this;
}
@Override
protected boolean onTransact(int code, @NonNull Parcel data, @Nullable Parcel reply, int flags) throws RemoteException {
switch (code){
/**
*
* int PING_TRANSACTION = ('_'<<24)|('P'<<16)|('N'<<8)|'G'; //(IBinder协议交互码:pingBinder())
*int DUMP_TRANSACTION = ('_'<<24)|('D'<<16)|('M'<<8)|'P'; //IBinder协议交互码:卸下内部状态
*int INTERFACE_TRANSACTION = ('_'<<24)|('N'<<16)|('T'<<8)|'F'; //IBinder协议交互码:询问交互接收方的规范接口描述符
*int TWEET_TRANSACTION = ('_'<<24)|('T'<<16)|('W'<<8)|'T'; //IBinder协议交互码:给目标对象传一个呼叫。在parcel中的数据是用于分发一个与对象结合的
* 共享信息服务。它可以是任何东西，只要它不超过130个UTF-8字符，保证适用于常见的信息服务。
* 作为 Build.VERSION_CODES#HONEYCOMB_MR2的一部分，所有的binder对象都支持这个协议，
* 为了在跨平台间完整推送。为了支持旧的交互码，一个默认的实现在主日志中记录了一个推送，作为
* 广播的一个简单模仿。并且，为了完成派送，对象必须返回给调用者一个说明，表明是旧的信息。
*
*int LIKE_TRANSACTION = ('_'<<24)|('L'<<16)|('I'<<8)|'K'; //IBinder协议交互码:异步地告诉app有调用者呼叫它。这个app负责计算和维护自己的呼叫者数目。
* 并且可以展示这个值来告诉用户app的状态。这个是可选的命令，app不需要掌管它，所以默认是实现是
* 数目都不做。
* <p>There is no response returned and nothing about the
* system will be functionally affected by it, but it will improve the
* app's self-esteem.
* 这是没有响应的，并且不会对系统带来影响，但是它提高了app的自尊(我真的不知道怎么翻译)。
*
*/
case INTERFACE_TRANSACTION:{ //IBinder协议交互码:询问交互接收方的规范接口描述符
reply.writeString(DESCRIPTOR);
return true;
}
case TRANSACTION_getBookList:{
data.enforceInterface(DESCRIPTOR);
List<Book> result = this.getBookList();
reply.writeNoException();
reply.writeTypedList(result);
return true;
}
case TRANSACTION_addBook:{
data.enforceInterface(DESCRIPTOR);
Book arg0;
if ((0!=data.readInt())){
arg0 = Book.CREATOR.createFromParcel(data);
}else{
arg0 = null;
}
this.addBook(arg0);
reply.writeNoException();
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements IBookManager{
private IBinder mRemote;
Proxy(IBinder mRemote){
mRemote = mRemote;
}
public java.lang.String getInterfaceDescriptor() {
return DESCRIPTOR;
}
@Override
public List<Book> getBookList() throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
List<Book> result;
try {
data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(TRANSACTION_getBookList,data,reply,0);
reply.readException();
result = reply.createTypedArrayList(Book.CREATOR);
}finally {
reply.recycle();
data.recycle();
}
return result;
}
@Override
public void addBook(Book book) throws RemoteException {
Parcel data = Parcel.obtain();
Parcel reply = Parcel.obtain();
try {
data.writeInterfaceToken(DESCRIPTOR);
if ((book != null)) {
data.writeInt(1);
book.writeToParcel(data, 0);
} else {
data.writeInt(0);
}
mRemote.transact(TRANSACTION_addBook, data, reply, 0);
reply.readException();
} finally {
reply.recycle();
data.recycle();
}
}
@Override
public IBinder asBinder() {
return mRemote;
}
}
}
AIDL文件的本质是系统为我们提供了一种快速实现Binder的工具，仅此而已。
接下来，我们介绍Binder的两个很重要的方法linkToDeath和unlinkToDeath.我们知道，Binder运行在服务端进程，如果服务端进程由于某种原因异常终止，这个时候我们到服务端的Binder连接断裂（称之为Binder死亡），会导致我们的远程调用失败。更为关键的是，如果我们不知道Binder连接已经断裂，那么客户端的功能就会受到影响。为了解决这个问题，Binder中提供了两个配对的方法linkToDeath和unlinkToDeath，通过linkToDeath我们可以给Binder设置一个死亡代理，当Binder死亡时，我们就会收到通知，这个时候我们就可以重新发起连接请求从而恢复连接。那么到底如何给Binder设置死亡代理呢？也很简单
package com.nextvpu.myapplication.manager;
import android.os.IBinder;
import com.nextvpu.myapplication.aidl.IBookManager;
public class BookManager {
private IBookManager mBookManager;
private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient() {
@Override
public void binderDied() {
if (mBookManager == null)
return;
mBookManager.asBinder().unlinkToDeath(mDeathRecipient,0);
mBookManager = null;
}
};
}
其次，在客户端绑定远程服务成功后，给binder设置死亡代理：
@Override
public void onServiceConnected(ComponentName name, IBinder service) {
mBinderPool = IBinderPool.Stub.asInterface(service);
try {
mBinderPool.asBinder().linkToDeath(mBinderPoolDeathRecipient, 0);
} catch (RemoteException e) {
e.printStackTrace();
}
mConnectBinderPoolCountDownLatch.countDown();
}其中linkToDeath的第二个参数是个标记位，我们直接设为0即可。经过上面两个步骤，就给我们的Binder设置了死亡代理，当Binder死亡的时候我们就可以收到通知了。另外，通过Binder的方法isBinderAlive也可以判断Binder是否死亡。