2.IPC基础概念---Binder

直观来说，Binder是Android中的一个类，它实现了IBinder接口。从IPC角度来说，Binder是Android中的一种跨进程通信方式
Binder还可以理解为一种虚拟的物理设备，它的驱动是/dev/binder，该通信方式在Linux中没有；
从Android Framework角度来说，Binder是ServiceManager连接各种Manager（ActivityManager、WindowsManager，等等）和相应ManagerService的桥梁；
从Android应用层来说，Binder是客户端和服务器进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务。
Android开发中，Binder主要在Service中，包括AIDL和Messenger，其中普通Service中的Binder不涉及进程间通信，较为简单，无法触及Binder核心，Messenger的底层其实是AIDL，所以这里选用AIDL来分析Binder的工作机制。首先新建一个AIDL示例，SDK胡自动为我们生产AIDL所对应的Binder类，然后我们就可以分析Binder的工作过程。新建Java包com.ryg.aidl，然后新建三个文件Book.java,Book.aidl和IBookManager.aidl，代码如下所示

package com.example.aidl;
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 int describeContents(){
        return 0;
    }
    public void writeToParcel(Parcel out,int flags){
        out.writeInt(bookId);
        out.writeString(bookName);
    }
    public static final Parcelable.Creator<Book> CREATOR = new Parcelable.Creator<Book>() {
        public Book createFromParcel(Parcel in) {
            return new Book(in);
        }

        public Book[] newArray(int size) {
            return new Book[size];
        }
    };
        private Book(Parcel in){
            bookId = in.readInt();
            bookName = in.readString();
        }
    }//Book.java
``
```java
package com.example.aidl;
parcelable Book;//Book.ai
``
```java
package com.example.aidl;
import com.example.aidl.Book;
interface IBookManager{
List<Book> getBookList();
void addBook(in Book book);//IBookManager.aidl
}

Book.java是一个表示图书信息的类，它实现了Parcelable接口。Book.aidl是Book类在AIDL中的声明。IBookManage.aidl是我们定义的一个接口，里面有两个方法：getBookList和addBook，其中getBookList用于从远程服务端获取图书列表，addBook用于往图书列表中添加一本书。尽管Book类已经和IBookManager位于相同的包中，但是在IBookManager中依然要导入Book类，这就是AIDL的特殊之处。下面我们先看一下系统为IBookManager.aidl生产的Binder类，在g根目录下的com.example.AIDL.aidl包中有一个IBookManager.java的类，这就是我们要找的类。




上述代码是系统生成的。IBookManager.java这个类继承了IInterface这个接口，同时它自己也是接口，所有可以在Binder中传输的接口都需要继承IInterface这个接口。这个类的接口其实很简单，首先，它声明了两个方法getBookList和addBook，就是我们在IBookManager.aidl中声明的方法，同时它还声明了两个整型的id分别用于标识这两个方法，用于标识在transact过程中客户端所请求的到底是哪个方法。接着，声明了一个内部类Stub，这个Stub就是一个Binder类，当服务器与客户端都位于同一个进程时，方法调用不会走跨进程的transact过程，当两者位于不同进程时，方法调用需要走transact过程，这个逻辑由Stub的内部代理类Proxy来完成。IBookManager这个接口的核心实现就是它内部类Stub和Stub的内部代理类Proxy，下面消息介绍针对这两个类的每个方法的含义。
DESCRIPTOR
Binder的唯一标识，一般用当前Binder的类名标识，比如本例中的“com.example.AIDL.aidl.IBookManager”。
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中写入返回值（如果有的话），onTransact方法的执行过程就是这样的。注：如果此方法返回false，那么客户端的请求会失败，因此我们可以利用这个特性来做权限验证，毕竟我们也不希望随便一个进程都能远程调用我们的服务。
Proxy#getBookList
这个方法运行在客户端，当客户端远程调用此方法时，它的内部实现时是这样的：首先创建该方法所需要的输入型Parcel对象_data、输出型Parcel对象_reply和和返回值对象List；然后把该方法的参数信息写入_data中（如果有参数的话）；接着调用transact方法来发起RPC（远程过程调用）请求，同时当前线程挂起；然后服务器的onTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果；最后返回_reply中的数据。
Proxy#addBook
这个方法运行在客户端，它的执行过程和getBookList是一样的，addBoook没有返回值，所以它不需要从_reply取出返回值。
通过上面的分析，你应该已经了解了Binder的工作机制，但还有两点说明：首先，当客户端发起远程请求时，由于当前线程会被挂起直至服务器进程返回数据，所以如果一个远程方法是很耗时的，那么不能在UI线程中发起此远程请求；其次，由于服务端的Binder方法运行在Binder线程池中，所以Binder方法不管是否耗时都应该采用同步的方式去实现，因为它已经运行在一个线程中了，下图展示了Binder的工作机制：
我们完全可以不提供AIDL文件即可实现Binder，之所以提供AIDL文件，是为了方便系统为我们生成代码。系统根据AIDL文件生成Java文件的格式是固定的，我们可以抛开AIDL文件直接写一个Binder出来，还是上面的例子，不提供AIDL文件，参考IBookManager.java类diamante，可以写一个和它一模一样的类出来，然后这个不借助AIDL文件的Binder就完成了。但是我们发现系统生成的类看起来结构不清晰，试着对它进行结构上的调整，这个类主要由两部分组成，首先它本身是一个Binder的接口（继承了IInterface），其次它的内部有个Stub类，这个类就是个Binder。Binder服务端代码：

private final IBookManager.Stub mBinder = new IBookManager.Stub(){
    @Override
    public List<Book> getBookList() throws RemoteException{
        synchronized(mBookList){
            return mBookList;
        }
    }
    @Override
    public void addBook(Book book) throws RemoteException{
        synchronized(mBookList){
            if(!mBookList.contains(book)){
                mBookList.add(book);
            }
        }
    }
}

首先我们会实现一个创建了一个Stub对象并在内部实现IBookManager的接口方法，然后再Service的onBind中返回这个Stub对象。因此，从这一点来看，我们完全可以把Stub类提取出来直接作为一个独立的Binder类来实现，这样IBookManager中就只剩接口本身了，通过这种分离的方式可以让它的结构变得清晰。
步骤如下：
（1）声明一个AIDL性质的接口，只需要继承IInterface接口即可，IInterface接口中只有一个asBinder方法。这个接口的实现如下;

public interface IBookManager extends IInterface{
  static final String DESCRIPTOR = "com.ryg.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;
}

可以看到，在接口中声明了一个Binder描述符和另外两个id，这两个id分别表示的是getBookList和addBook方法，这段代码原本也是系统生成的，我们仿照系统生成的规则去手动书写这部分代码。
（2）实现Stub类和Stub类中的Proxy代理类，这段代码只需要参考系统生成的代码即可。




上述代码和系统生成的代码相比简直一模一样。那我们为什么要手动去写呢？我们在实际开发中完全可以通过AIDL文件让系统去自动生成，手动去写的意义在于可以让我们更加理解Binder的工作原理，同时也提供了一种不通过AIDL文件来实现Binder的新方式。AIDL并不是实现Binder的必需品。如果是手写的Binder，只需要在服务端创建一个BookManagerImpl的对象并在Service的onBind方法中返回即可。最后，是否手动实现Binder没有本质区别，AIDL文件的本质是系统为我们快速实现Binder的工具。
接下来，介绍Binder的两个很重要的方法：linkToDeath和unlinkToDeath。我们知道，Binder运行在服务端进程，如果服务端进程由于某种原因异常终止，这个时候到服务端的Binder链接断裂（Binder死亡），会导致我们的远程调用失败。更关键的是，如果我们不知道Binder链接已经断裂，那么客户端的功能就会受到影响。为了解决这个问题，Binder中提供了两个配对的方法linkToDeath和unlinkToDeath,通linkToDeath我们可以给Binder设置一个死亡代理，当Binder死亡时，我们就会收到通知，这个时候我们就可以重新发起连接请求从而恢复连接。给Binder设置死亡代理步骤如下：
首先，声明一个DeathRecipient对象。DeathRecipient是一个接口，其内部只有一个方法bindeDied，我们需要实现这个方法，当Binder死亡的时候，系统就会回调binderDied方法，然后我们就可以移出之前绑定的binder代理并重新绑定远程服务：

private IBinder.DeathRecipient mDeathRecipient = new IBinder.DeathRecipient(){
  @Override
  public void bindDied(){
   if(mBookManager == null)
     return ;
   mBookManager .asBinder().unlinkToDeath(mDeathRecipient ,0);
   mBookManager = null;
  //TODO：这里重新绑定远程Service
 }
}

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

mService = IMessageBoxManager.Stub.asInterface(binder);
binder.linkToDeath(mDeathRecipient,0)

其中linkToDeath的第二个参数是标记位，直接设为0即可。经过上面两步骤，就给我们的Binder设置了死亡代理，当Binder死亡的时候我们就可以收到通知了。另外，通过Binder的方法isBinderAlive也可以判断Binder是否死亡。