Android IPC机制—Binder的工作机制

Posted 2020-10-27 遥望天涯

进程和线程的关系

IPC机制即为跨进程通信，是inter-Process Communication的缩写。是指两个进程之间进行通信。在说进程通信之前，我们的弄明白什么是线程，什么是进程。进程和线程是两个截然不同的概念。按照操作系统中的描述，线程是CPU调度的最小单位，同时线程也是一种有限的系统资源。而进程一般是指一个执行单元，在pc端或者移动端上是指一个程序或者一个应用。一个进程中可以包含一个或者是多个线程。所以他们的关系应该是包含和被包含的关系。

 

跨进程的种类

在android中跨进程通信的方式有很多种，Bundle,文件共享，AIDL,Messenger,ContentProvider,Socket,这些都能实现进程间之间的通信，当然，虽然都能够实现进程间通信，但是他们之间的实现原理或者说是底层的实现方式都是不一样的。下面，我们将会一一说明。

 

注：很多同学觉得创建进程就应该创建一个新的应用。其实不是的。只要我们在AndroidMenifest上加上这一句代码就可以了android:process=“:remote”具体的，同学们可以自己的了解。

 

 

在说IPC之前，先说一下一些基础概念，这样对后面的内容能够更好的理解。

1、Serializable，Parcelable接口

Serializable接口是java提供的一个序列化的接口，这是一个空的接口，为对象提供标准的序列化和反序列化操作。Serializable序列化和反序列化，都是采ObjectOutputStream 和ObjectInputStream就可以实现，当然这些系统基本已经为我们实现了。

 

Parcelable接口，是Android自带的一种序列化方式。序列化和反序列化都是通过writeToParcel方法来完成的。

 

两者的区别：Serializable是java的序列化接口使用简单，但是由于序列化和反序列化的过程需要大量的I/o操作，所以性能较差。Parcelable接口使用较为麻烦，但是效率很高，但是存在一个很大的缺点，就是被Parcelable将对象序列化以后，要将对象保存到磁盘中的，将会很麻烦。所以建议是使用Serializable。

 

Binder

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

在Android开发中，Binder主要用在Service中，包括AIDL和Messenger，由于Messenger的底层其实就是Aidl，所以现在我们以AIDL来分析一下binder的工作机制。

对AIDL还不懂使用的朋友可以看一下我以前写的一篇博客：http://www.cnblogs.com/huangjialin/p/7738104.html，下面就以这个例子来分析一下这个Binder的工作机制。

 

上代码：

  1 /*
  2 
  3  * This file is auto-generated.  DO NOT MODIFY.
  4 
  5  * Original file: /Users/huangjialin/MyApplication/service/src/main/aidl/aidl/MyAIDLService.aidl
  6 
  7  */
  8 
  9 package aidl;
 10 
 11 // Declare any non-default types here with import statements
 12 
 13  
 14 public interface MyAIDLService extends android.os.IInterface {
 15 
 16  
 17 
 18     /**
 19 
 20      * Local-side IPC implementation stub class.
 21 
 22      */
 23 
 24     public static abstract class Stub extends android.os.Binder implements aidl.MyAIDLService {
 25 
 26         private static final java.lang.String DESCRIPTOR = "aidl.MyAIDLService";
 27 
 28  
 29 
 30         /**
 31 
 32          * Construct the stub at attach it to the interface.
 33 
 34          */
 35 
 36         public Stub() {
 37 
 38             this.attachInterface(this, DESCRIPTOR);
 39 
 40         }
 41 
 42 
 43 
 44         /**
 45 
 46          * Cast an IBinder object into an aidl.MyAIDLService interface,
 47 
 48          * generating a proxy if needed.
 49 
 50          */
 51 
 52         public static aidl.MyAIDLService asInterface(android.os.IBinder obj) {
 53 
 54             if ((obj == null)) {
 55 
 56                 return null;
 57 
 58             }
 59 
 60             android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
 61 
 62             if (((iin != null) && (iin instanceof aidl.MyAIDLService))) {
 63 
 64                 return ((aidl.MyAIDLService) iin);
 65 
 66             }
 67 
 68             return new aidl.MyAIDLService.Stub.Proxy(obj);
 69 
 70         }
 71 
 72  
 73 
 74         @Override
 75 
 76         public android.os.IBinder asBinder() {
 77 
 78             return this;
 79 
 80         }
 81 
 82  
 83         @Override
 84 
 85         public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
 86 
 87             switch (code) {
 88 
 89                 case INTERFACE_TRANSACTION: {
 90 
 91                     reply.writeString(DESCRIPTOR);
 92 
 93                     return true;
 94 
 95                 }
 96 
 97                 case TRANSACTION_getString: {
 98 
 99                     data.enforceInterface(DESCRIPTOR);
100 
101                     java.lang.String _result = this.getString();
102 
103                     reply.writeNoException();
104 
105                     reply.writeString(_result);
106 
107                     return true;
108 
109                 }
110 
111             }
112 
113             return super.onTransact(code, data, reply, flags);
114 
115         }
116 
117 
118 
119         private static class Proxy implements aidl.MyAIDLService {
120 
121             private android.os.IBinder mRemote;
122 
123  
124 
125             Proxy(android.os.IBinder remote) {
126 
127                 mRemote = remote;
128 
129             }
130 
131  
132 
133             @Override
134 
135             public android.os.IBinder asBinder() {
136 
137                 return mRemote;
138 
139             }
140 
141  
142 
143             public java.lang.String getInterfaceDescriptor() {
144 
145                 return DESCRIPTOR;
146 
147             }
148 
149  
150 
151 
152             @Override
153 
154             public java.lang.String getString() throws android.os.RemoteException {
155 
156                 android.os.Parcel _data = android.os.Parcel.obtain();
157 
158                 android.os.Parcel _reply = android.os.Parcel.obtain();
159 
160                 java.lang.String _result;
161 
162                 try {
163 
164                     _data.writeInterfaceToken(DESCRIPTOR);
165 
166                     mRemote.transact(Stub.TRANSACTION_getString, _data, _reply, 0);
167 
168                     _reply.readException();
169 
170                     _result = _reply.readString();
171 
172                 } finally {
173 
174                     _reply.recycle();
175 
176                     _data.recycle();
177 
178                 }
179 
180                 return _result;
181 
182             }
183 
184         }
185 
186  
187 
188         static final int TRANSACTION_getString = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
189 
190     }
191 
192  
193 
194     public java.lang.String getString() throws android.os.RemoteException;
195 
196 }
197 
198  

 

上面这段代码是系统生成的，在gen目录下可以看到根据MyAIDLService.aidl系统为我们生成了MyAIDLService.java这个类。我们先来了解一下这个类中每个方法的含义：

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中写入返回值。这个方法的执行过程就是这样的。如果这个方法返回false，客户端是会请求失败的，所以我们可以在这个方法中做一些安全验证。

 

public java.lang.String getString() throws android.os.RemoteException：

这个方法运行在客户端中，当客户端调用此方法的时候，它的内部实现是这样的：首先创建该方法所需要的输入类型Parcel对象_data，然后调用transact方法发起远程调用请求，同时当前线程挂起，然后服务端的OnTransact方法会被调用，直到RPC过程返回后，当前线程继续执行，并从_reply中读取返回的数据。

 

如图：Binder的工作机制

 

从上面分析，我们明白了Binder的工作机制但是要注意一些问题：1、当客户端发起请求时，由于当前线程会被挂起，直到服务端返回数据，如果这个远程方法很耗时的话，那么是不能够在UI线程，也就是主线程中发起这个远程请求的。

2、由于Service的Binder方法运行在线程池中，所以Binder方法不管是耗时还是不耗时都应该采用同步的方式，因为它已经运行在一个线程中了。