Android进阶之路Android技术知识Android开发经验谈

Android跨进程通信技术-Binder

2019-06-19  本文已影响13人  夏天吃冰棍

本文为个人学习笔记分享,没有任何商业化行为,对其他文章的引用都会标记。如有侵权行为,请及时提醒更正!如需转载请表明出处
本文主要来源是 任玉刚大神的《Android开发艺术探索》

Binder是android中的一个类,它实现了IBinder接口。从IPC角度来说,Binder是Android的一种跨进程通信方式,Binder还可以理解为一种虚拟的物理设备,它的设备驱动是/dev/binder,该通信方式在Linux上没有;从Android Framework角度来说,Binder是ServiceManager连接各种Message(ActivityMessage、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
public class Book implements Parcelable {
    private int bookId;
    private String bookName;

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

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

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

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

    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];
        }
    };
}
//Book.aidl
package com.liupei.aidl;
parcelable Book;

// IBookManager.aidl
package com.liupei.aidl;
import com.liupei.aidl.Book;
interface IBookManager {
   List<Book> getBookList();
   void addBook(in Book book);
}

在上面三个文件中,Book.java是一个表示图书信息类,它实现了Parcelable接口。Book.aidl是Book类在AIDL中得声明。IBookManager是我们自定义得一个接口,里面有两个方法:getBookList和addBook,其中getBookList用于从远程服务端获取图书列表,而addBook用于往图书列表中添加一本书,当然这两个方法主要是示例,不一定要有实际意义。我们可以看导,尽管Book类已经和IBookManager位于相同得包中,但是IBookManager仍要导入Book类,这就是AIDL的特殊之处。编译过后。下面我们先看一下系统为IBookManager.aidl生成得Binder类,在Android Studio 得build


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

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

        /**
         * Cast an IBinder object into an com.liupei.aidl.IBookManager interface,
         * generating a proxy if needed.
         */
        public static com.liupei.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.liupei.aidl.IBookManager))) {
                return ((com.liupei.aidl.IBookManager) iin);
            }
            return new com.liupei.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.liupei.aidl.Book> _result = this.getBookList();
                    reply.writeNoException();
                    reply.writeTypedList(_result);
                    return true;
                }
                case TRANSACTION_addBook: {
                    data.enforceInterface(DESCRIPTOR);
                    com.liupei.aidl.Book _arg0;
                    if ((0 != data.readInt())) {
                        _arg0 = com.liupei.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.liupei.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.liupei.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.liupei.aidl.Book> _result;
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    mRemote.transact(Stub.TRANSACTION_getBookList, _data, _reply, 0);
                    _reply.readException();
                    _result = _reply.createTypedArrayList(com.liupei.aidl.Book.CREATOR);
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
                return _result;
            }

            @Override
            public void addBook(com.liupei.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.liupei.aidl.Book> getBookList() throws android.os.RemoteException;

    public void addBook(com.liupei.aidl.Book book) throws android.os.RemoteException;
}

上面一大堆的代码都是由系统生成的,它继承了IInterface接口,同时自己也是一个接口,所以可以在Binder中传输的接口都需要集成IInterface接口,这个类刚开始看起来逻辑十分复杂,但实际上很清晰,通过它我们可以清楚的了解Binder得工作机制。这个类得结构其实很简单,首先,它声明了两个方法getBookList和addBook,显然就是我们aidl文件中声明得方法。同时它还声明了两个整型得id分别用于标识这两个方法,这两个id用于标识在transcat过程中客户端到底要请求哪个方法。接着,它声明了一个内部类Stub,这个Stub就是一个Binder类,当客户端和服务端位于同一个进程时,方法调用不会走跨进程得transact过程,而当两者位于不同的进程时,方案调用需要走transact过程,这个逻辑有Stub得内部代理类Proxy来完成。这么看来,IBookManager这个接口的确很简单,但是我们也应该认识到,这个接口得核心实现就是它得内部类Stub和Stub的内部代理类Proxy。

DESCRIPTOR
Binder的唯一标识,一般用当前Binder的类名表示,比如本例中的

  private static final java.lang.String DESCRIPTOR = "com.liupei.aidl.IBookManager";

asInterface(android.os.IBinder obj)
用于将服务器的Binder对象转化成客户端所需的AIDL接口类型的对象,这种转换过程是区分进程的,如果处于同一进程,就返回返回服务器的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、输出型对象_reply和返回值对象list;然后把该方法的参数信号写入_data中;接着调用transact方法来发起RPC请求,同时当前线程挂起;然后服务端的onTransact方法会被调用,知道RPC过程返回,当前线程继续执行,并从reply中取出RPC过程返回结果;最后返回_reply中的data。
Proxy#addBook
这个方法和getBooklist 一样,addBook没有返回值,所以它不需要从_reply中取出返回值。

通过上面的分析,我们差不多了解了Binder的工作机制,但是有两点还是需要额外说明一下:首先,当客户端发起请求时,由于当前线程会被挂起直到服务端进程返回数据,所以如果一个远程方法时耗时的,那么不能在UI线程中发起此远程请求;其次,由于服务器的Binder方法运行在Binder的线程池中,所以Binder方法不管是否耗时都应该采用同步的方法去实现,因为它已经运行在一个线程中了。

Binder的出生与死亡
我们上面讲了Binder的交互机制,那么接下来我们讲Binder的两个很重要的方法linkToDeath和unlinkToDeath。我们知道,Binder运行在服务端进程,如果服务进程由于某种原因终止了。这个时候我们到服务端的Binder链接断裂了(称之为Binder死亡),会导致我们的远程调用失败。更为关键的是,如果我们不知道Binder已经断裂了,那么客户端的功能就会受到影响。为了解决这个问题,Binder提供了两个配对的方法linkToDeath和unlinkToDeath,通过linkToDeath可以给Binder设置一个死亡代理,当Binder死亡时,我们就会收到通知,这个时候我们就可以重新发起链接请求链接恢复了。那么如何给Binder添加死亡代理呢?

private IBinder.DeathRecipient mDeathRecipient=new IBinder.DeathRecipient(){
      @Overrid
      public void binderDied(){
          if(mBookManager==null)
                return;
          mBookManager.asBinder().unlinkToDeath(mDeathRecipient,0);
          mBookManager=null;
          //TODO 重新绑定
  
      }
}

整理写作不易,请小伙伴多多支持,麻烦请点赞关注支持一下,😘😘😘。

上一篇下一篇

猜你喜欢

热点阅读