安卓IPC机制（二）---Binder的工作机制

吐槽

中午起床后晕乎乎的，还是自己下午看书学东西，晚上写项目吧

Binder的理解

发现这个感觉真的是现在给我看好复杂啊，，，然后还是先了解下吧，以后自己看的时候会好受一点。

• 直观的说Binder是Android的一个类，它实现IBinder接口
• 从IPC的角度来看，Binder是一种跨进程通信的方式
• Binder还可以理解为一种虚拟的物理设备，它的驱动是/dev/binder
• 从Android Framework的角度讲，Binder是ServiceManager连接各种Manager和ManagerService的桥梁
• 从Android应用层来讲的话，Binder是客户端和服务端进行通信的媒介

建立一个AIDLDemo

先重新建个包
准备3个东西Book.java,Book.aidl和IBookMangager.aidi

先是Book.java 继承 parcelable

public class Book implements Parcelable {

    public int bookId;
    public String bookName;

    public Book(int bookId,String bookName){
        this.bookId = bookId;
        this.bookName = bookName;
    }

    protected Book(Parcel in) {
        bookId = in.readInt();
        bookName = in.readString();
    }

    public static final Creator CREATOR = new Creator() {
        @Override
        public Book createFromParcel(Parcel in) {
            return new Book(in);
        }

        @Override
        public Book[] newArray(int size) {
            return new Book[size];
        }
    };

    @Override
    public int describeContents() {
        return 0;
    }

    @Override
    public void writeToParcel(Parcel dest, int flags) {
        dest.writeInt(bookId);
        dest.writeString(bookName);
    }
}

然后是Book.aidl

package com.example.hasee.binderdemo;
parcelable Book;

最后是IBookManager.aidl
实现了两个方法，getBookList 和addBook
尽管Book类和IBookManager位于同一个包下，但是还是要导入Book类

package com.example.hasee.binderdemo;
import  com.example.hasee.binderdemo.Book;


interface IBookManager {
    List getBookList();
    void addBook(int Book );
 }

然后，你会发现按照书上这么写，，，会报错，找不到Book类
解决方法就是在app下的gradle里面android{}里面加入一段代码

 sourceSets {
        main {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            java.srcDirs = ['src/main/java', 'src/main/aidl']
            resources.srcDirs = ['src/main/java', 'src/main/aidl']
            aidl.srcDirs = ['src/main/aidl']
            res.srcDirs = ['src/main/res']
            assets.srcDirs = ['src/main/assets']
        }
        }

然后就好了

最后结果发行是好的情况是在
发现这块自动生成的一个IBookManager类

package com.example.hasee.binderdemo;
public interface IBookManager extends android.os.IInterface
{
/** Local-side IPC implementation stub class. */
public static abstract class Stub extends android.os.Binder implements com.example.hasee.binderdemo.IBookManager
{
private static final java.lang.String DESCRIPTOR = "com.example.hasee.binderdemo.IBookManager";
/** Construct the stub at attach it to the interface. */
public Stub()
{
this.attachInterface(this, DESCRIPTOR);
}
/**
 * Cast an IBinder object into an com.example.hasee.binderdemo.IBookManager interface,
 * generating a proxy if needed.
 */
public static com.example.hasee.binderdemo.IBookManager asInterface(android.os.IBinder obj)
{
if ((obj==null)) {
return null;
}
android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
if (((iin!=null)&&(iin instanceof com.example.hasee.binderdemo.IBookManager))) {
return ((com.example.hasee.binderdemo.IBookManager)iin);
}
return new com.example.hasee.binderdemo.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 _result = this.getBookList();
reply.writeNoException();
reply.writeTypedList(_result);
return true;
}
case TRANSACTION_addBook:
{
data.enforceInterface(DESCRIPTOR);
int _arg0;
_arg0 = data.readInt();
this.addBook(_arg0);
reply.writeNoException();
return true;
}
}
return super.onTransact(code, data, reply, flags);
}
private static class Proxy implements com.example.hasee.binderdemo.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 getBookList() throws android.os.RemoteException
{
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
java.util.List _result;
try {
_data.writeInterfaceToken(DESCRIPTOR);
mRemote.transact(Stub.TRANSACTION_getBookList, _data, _reply, 0);
_reply.readException();
_result = _reply.createTypedArrayList(com.example.hasee.binderdemo.Book.CREATOR);
}
finally {
_reply.recycle();
_data.recycle();
}
return _result;
}
@Override public void addBook(int 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);
_data.writeInt(Book);
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 getBookList() throws android.os.RemoteException;
public void addBook(int Book) throws android.os.RemoteException;
}

看的我一脸懵逼，，，，不知道这个是什么鬼

然后继续看书上的解释
上述代码是系统生成的，在gen目录下，可以看到根据IBookManager.aidl系统为我们生成了IBookManager.java这个类，它继承了IInterface这个接口，同时它自己也还是个接口，所有可以在Binder中传输的接口都需要继承IInterface接口。这个类刚开始看起来逻辑混乱，但是实际上还是很清晰的，通过它我们可以清除地了解到Binder的工作机制。这个类的结构其实很简单，首先它声明了两个方法getBookList()和addBook()，显然这就是我们在IBookManager.aidl中所声明的方法，同时它还声明了两个整型的id分别用于标识这两个方法，这两个id用于标识在transact过程中客户端所请求的到底是哪个方法。接着，它声明了一个内部类Stub，这个Stub就是一个Binder类，当客户端和服务端都位于同一个进程时，方法调用不会走跨进程的transact过程，而当两者位于不同进程时，方法调用需要走transact过程，这个逻辑由Stub的内部代理类Proxy来完成。这么来看，IBookManager这个接口的确很简单，但是我们也应该认识到，这个接口的核心实现就是它的内部类Stub和Stub的内部代理类Proxy。

里面的方法和重要的属性

DESCRIPTOR
Binder的唯一标识，一般用当前Binder的类名表示。

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是一样的，addBook没有返回值，所以它不需要从_reply中取出返回值。
通过上面的分析，读者应该已经了解了Binder的工作机制，但是有两点还是需要额外说明一下，首先，当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以如果一个远程方法是很耗时的，那么不能在UI线程中发起此远程请求，其次，由于服务端的Binder方法运行在Binder的线程池中，所以Binder方法不管是否耗时都应该采用同步的方式去实现，因为它已经运行在一个线程中了。为了更好地说明Binder，下面给出一个Binder的工作机制图。

注意点与总结

• 远程请求是耗时的。客户端发起请求时，当前线程会被挂起直到服务端返回数据，所以不能再UI线程进行远程请求
• 服务端的onTransact()运行在Binder线程池中，所以此Binder方法是否耗时，都应该采用同步方式去实现，因为它已经运行在一个单独线程中了。
• 如果因为某些原因，服务端进程异常终止，如果我们不知道连接已经断裂，那么客户端就会受到影响。应该通过Binder的linkToDeath和unlinkToDeath设置死亡代理。

自定义Binder类

这个实在是看不懂了，先留着这里

• 声明一个AIDL的接口
• 实现Stub类和Stunb类的Proxy代理类
• DeathRecipient对象，DeathRecipient是一个接口，其内部只有一个方法binderDied，我们需要实现这个方法，当Binder死亡的时候，系统就会回调binderDied方法，然后我们就可以移出之前绑定的binder代理并重新绑定远程服务

总结

自己还是好好写项目吧，真的是看书看的煎熬啊啊啊啊