【Android

参考资料：

1、《Android开发艺术探索》第二章2.3.3 Binder

2、【Android Binder设计与实现-设计篇】

3、【Android Binder机制介绍】

1、 什么是Binder

Binder从不同角度上的定义：

• 直观来说，Binder是Android中的一个类，它实现了IBinder接口；
• 从IPC角度来说，Binder是Android中的一种跨进程通信方式，该通信方式在Linux中没有；
• 从Android Framework角度来说，Binder是ServiceManager连接各种Manager和相应ManagerService的桥梁；
• 从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据了。

Binder机制具体有两层含义：

• Binder是一种跨进程通信（IPC，Inter-Process Communication）的手段；
• Binder是一种远程过程调用（RPC，Remote Procedure Call）的手段。

2、 为什么使用Binder

　　Android系统是基于Linux系统的，理论上应该使用Linux内置的IPC方式。Linux中的IPC方式有管道、信号量、共享内存、消息队列、Socket，Android使用的Binder机制不属于Linux。Android不继承Linux中原有的IPC方式，而选择使用Binder，说明Binder具有一定的优势。

　　Android系统为了向应用开发者提供丰富的功能，广泛的使用了Client-Server通信方式，如媒体播放、各种传感器等，Client-Server的通信方式是Android IPC的核心，应用程序只需要作为Client端，与这些Server建立连接，即可使用这些功能服务。

　　下面通过一些功能点，一一排除Linux系统中五种IPC方式，解释为什么Android选择使用Binder：

• 从通信方式上说，我们希望得到的是一种Client-Server的通信方式，但在Linux的五种IPC机制中，只有Socket支持这种通信方式。虽然我们可以通过在另外四种方式的基础上架设一些协议来实现Client-Server通信，但这样增加了系统的复杂性，在手机这种条件复杂、资源稀缺的环境下，也难以保证可靠性；
• 从传输性能上说，Socket作为一款通用接口，其传输效率低，开销大，主要用在跨网络的进程间通信和本机上进程间的低速通信；消息队列和管道采用存储-转发方式，即数据先从发送方拷贝到内存开辟的缓存区中，然后再从内核缓存区拷贝到接收方缓存区，至少有两次拷贝过程；共享内存虽然无需拷贝，但控制复杂，难以使用；而Binder只需要拷贝一次；
• 从安全性上说，Android作为一个开放式的平台，应用程序的来源广泛，因此确保只能终端的安全是非常重要的。Linux传统的IPC没有任何安全措施，完全依赖上层协议来确保，具体有以下两点表现：第一，传统IPC的接收方无法获得对方可靠的UID/PID（用户ID/进程ID），从而无法鉴别对方身份，使用传统IPC时只能由用户在数据包里填入UID/PID，但这样不可靠，容易被恶意程序利用；第二，传统IPC的访问接入点是开放的，无法建立私有通信，只要知道这些接入点的程序都可以和对端建立连接，这样无法阻止恶意程序通过猜测接收方的地址获得连接。

　　基于以上原因，Android需要建立一套新的IPC机制来满足系统对通信方式、传输性能和安全性的要求，这就是Binder。

　　综上，Binder是一种基于Client-Server通信模式的通信方式，传输过程只需要一次拷贝，可以为发送方添加UID/PID身份，支持实名Binder和匿名Binder，安全性高。

3、 Binder的组成

Binder由四部分组成：Binder客户端、Binder服务端、Binder驱动、服务登记查询模块。

• Binder客户端：

Binder客户端是想要使用服务的进程。

• Binder服务端：

Binder服务端是实际提供服务的进程。

• Binder驱动：

我们在客户端先通过Binder拿到一个服务端进程中的一个对象的引用，通过这个引用，直接调用对象的方法获取结果。在这个引用对象执行方法时，它是先将方法调用的请求传给Binder驱动；然后Binder驱动再将请求传给服务端进程；服务端进程收到请求后，调用服务端“真正”的对象来执行所调用的方法；得出结果后，将结果发给Binder驱动；Binder驱动再将结果发给我们的客户端；最终，我们在客户端进程的调用就有了返回值。Binder驱动，相当于一个中转者的角色。通过这个中转者的帮忙，我们就可以调用其它进程中的对象。

• Service Manager（服务登记查询模块）：

我们调用其它进程里面的对象时，首先要获取这个对象。这个对象其实代表了另外一个进程能给我们提供什么样的服务（再直接一点，就是：对象中有哪些方法可以让客户端进程调用）。首先服务端进程要在某个地方注册登记一下，告诉系统我有个对象可以公开给其它进程来提供服务。当客户端进程需要这个服务时，就去这个登记的地方通过查询来找到这个对象。

4、 Binder机制简述

　　上面说到，Binder有两个含义，分别是进程间通信和远程过程调用。Android的整个跨进成机制都是基于Binder的，这种机制不但会在底层调用，也会在上层调用，所以必须提供C++和Java两个层次的支持。下面是两种情况下Binder的原理图。

 

进程间通信的Binder原理图

　　上图是进程间通信时的Binder原理图。图中进程A中的小圆圈代表“Binder代理方”BpBinder，用于向远方发送语义；进程B中的方块代表“Binder响应方”BBinder，主要用于响应语义。

 

远程过程调用的Binder原理图

　　上图是远程过程调用时的Binder原理图。此时，进程A不再直接和Binder代理BpBinder打交道，而是通过聚合了BpBinder的“接口代理”BpInterface的成员函数来完成远程调用；而进程B则通过Binder响应方BBinder的继承类“接口实现体”BnInterface来响应进程A发来的请求。如此依赖，在远程过程调用的操作中，客户端需要完成Binder代理和接口代理，而服务端需要完成接口实现体。

　　需要说明的是，上面两图中的BpBinder、BpInterface、BBinder和BnInterface都是C++中的层次概念，Java中没有这些。

　　这里只针对Java中的Binder层次进行解释，不涉及C++的代码。

5、 Binder工作流程

　　假设：客户端的程序Client运行在进程A中，服务端的程序Server运行在进程B中。

　　由于进程的隔离性，Client不能读写Server中的内容，但内核可以，而Binder驱动就是运行在内核态，因此Binder驱动帮我们进行请求的中转。

　　有了Binder驱动，Client和Server之间就可以打交道了，但是为了实现功能的单一性，我们为Client和Server分别设置一个代理：Client的代理Proxy和Server的代理Stub。这样，由进程A中的Proxy和进程B中的Stub通过Binder驱动进行数据交流，Server和Client直接调用Stub和Proxy的接口返回数据即可。

　　此时，Client直接调用Proxy这个聚合了Binder的类，我们可以使用一系列的Manager来屏蔽掉Binder的实现细节，Client直接调用Manager中的方法获取数据，这样做的好处是Client不需要知道Binder具体怎么工作。

　　最后还有一个问题，就是Client想要获得的服务多种多样，那么它是怎么获取Proxy或Manager的呢？答案是通过Service Manager进程来获取的。Service Manager总是第一个启动的服务，其他服务端进程启动后，可以在Service Manager中注册，这样Client就可以通过Service Manager来获取服务器的服务列表，进而选择具体调用的服务器进程方法。

　　上面的叙述总结为如下图所示的工作流程图：

 

6、 Binder示例代码

　　在Android开发中，Binder主要用在Service中，其中普通的Service中的Binder不涉及进程间通信，所以较为简单，而AIDL和基于AIDL的Messenger涉及到进程间通信，因此，这里选择使用AIDL来分析Binder的工作机制。

　　在这个例子中，我们将通过AIDL的方式将一个Book实体类的对象从服务端传递到客户端进行展示。

　　先创建一个Book实体类，为了能在进程间传递，需要序列化Book，代码如下：

public class Book implements Parcelable {
    private int bookId;
    private 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<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];
        }
    };

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

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

　　创建一个Book.aidl文件，代码如下：

package my.itgungnir.ipc.binder;

parcelable Book;

　　创建一个IBookManager.aidl文件，代码如下：

package my.itgungnir.ipc.binder;

import my.itgungnir.ipc.binder.Book; // 虽然这个文件和Book.aidl文件在同一个包下，但还是要导入类，这就是AIDL的特点

interface IBookManager {
    Book getBook();
}

　　创建了这三个文件之后，运行一遍项目，这时会在项目的build/generated/source/aidl/debug/包名目录下生成一个IBookManager.java的文件，这个类是系统根据我们编写的IBookManager.aidl文件自动生成的Binder类。这个类的代码如下：

package my.itgungnir.ipc.binder;

public interface IBookManager extends android.os.IInterface {
    /**
     * Local-side IPC implementation stub class.
     */
    public static abstract class Stub extends android.os.Binder implements my.itgungnir.ipc.binder.IBookManager {
        private static final java.lang.String DESCRIPTOR = "my.itgungnir.ipc.binder.IBookManager";

        /**
         * Construct the stub at attach it to the interface.
         */
        public Stub() {
            this.attachInterface(this, DESCRIPTOR);
        }

        /**
         * Cast an IBinder object into an my.itgungnir.ipc.binder.IBookManager interface,
         * generating a proxy if needed.
         */
        public static my.itgungnir.ipc.binder.IBookManager asInterface(android.os.IBinder obj) {
            if ((obj == null)) {
                return null;
            }
            android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
            if (((iin != null) && (iin instanceof my.itgungnir.ipc.binder.IBookManager))) {
                return ((my.itgungnir.ipc.binder.IBookManager) iin);
            }
            return new my.itgungnir.ipc.binder.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_getBook: {
                    data.enforceInterface(DESCRIPTOR);
                    my.itgungnir.ipc.binder.Book _result = this.getBook();
                    reply.writeNoException();
                    if ((_result != null)) {
                        reply.writeInt(1);
                        _result.writeToParcel(reply, android.os.Parcelable.PARCELABLE_WRITE_RETURN_VALUE);
                    } else {
                        reply.writeInt(0);
                    }
                    return true;
                }
            }
            return super.onTransact(code, data, reply, flags);
        }

        private static class Proxy implements my.itgungnir.ipc.binder.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 my.itgungnir.ipc.binder.Book getBook() throws android.os.RemoteException {
                android.os.Parcel _data = android.os.Parcel.obtain();
                android.os.Parcel _reply = android.os.Parcel.obtain();
                my.itgungnir.ipc.binder.Book _result;
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    mRemote.transact(Stub.TRANSACTION_getBook, _data, _reply, 0);
                    _reply.readException();
                    if ((0 != _reply.readInt())) {
                        _result = my.itgungnir.ipc.binder.Book.CREATOR.createFromParcel(_reply);
                    } else {
                        _result = null;
                    }
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
                return _result;
            }
        }

        static final int TRANSACTION_getBook = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
    }

    public my.itgungnir.ipc.binder.Book getBook() throws android.os.RemoteException;
}

　　这个类中的结构如下图所示：

 

　　下面来逐一解释这个类中的每个元素代表的含义：

• 最外层的getBook()：一个抽象方法，就是我们在IBookManager.aidl文件中声明的方法；
• TRANSACTION_getBook：一个整形的ID，用于表示客户端请求的是哪个方法；
• DESCRIPTOR：Binder的唯一标识，一般用当前Binder的包路径表示；
• asInterface()：判断当前进程是服务端进程还是客户端进程，如果是服务端进程则返回Stub对象，否则返回Stub.Proxy对象；
• asBinder()：返回当前的Binder对象；
• onTransact(int code, Parcel data, Parcel reply, int flag)：这个方法运行在服务端的Binder线程池中，当客户端发起请求时，就由这个方法来处理请求。服务端通过code获取客户端想要访问的目标方法；通过data来获取目标方法所需的参数；执行完目标方法后，将返回值写入到reply中。另外，如果这个方法返回false，则客户端请求失败，我们可以通过这一点来判断客户端是否有权访问我们的服务；
• Proxy#getBook()：这个方法运行在客户端，其内部实现是这样的：首先创建三个对象，_data用来存储这个方法的参数信息；_reply用来存储从服务端返回的数据；_result用来作为返回值返回，然后调用transact()方法发起RPC（远程过程调用）请求，调用服务端的onTransact()方法，同时当前线程挂起；当RPC过程返回后，当前线程继续执行，经过一系列处理后返回_result结果。

使用Binder还需要注意：

　　当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以如果一个远程方法是耗时的，那么不能放到UI线程中。