我也想聊聊Binder机制

GitCode8

读完需要

25

分钟

速读仅需9分

作者:GitCode8 链接:https://juejin.im/post/5d18ed91e51d45776031b03d

1

前言

想写篇关于Binder的文章,可对其一无所知,无从下手。在阅读了大量的优秀文章后,心惊胆战的提笔,不怕文章被贻笑大方,怕的是误人子弟!望各位大佬抽空阅读本文的同时,能够对文章的知识点持怀疑态度,共同探讨,共同进步!

2

序列化

日常开发中,通过Intent携带数据跳转Activity时,数据通常要通过实现Serializable或Parcelable接口,才能在被Intent所携带,而Serializable接口和Parcelabel接口主要是完成对象的序列化过程。将对象持久化到设备上或者网络传输同样也需要序列化。

2.1

Serializable 接口

Serializable接口是Java所提供的,为对象提供标准的序列化和反序列化操作。通常一个对象实现Serializable接口,该对象就具有被序列化和反序列化的能力,而且几乎所有工作有系统自动完成。Serializable接口内serialVersionID可指定也可以不指定,其作用是用来判断序列化前和反序列化的类版本是否发生变化。该变量如果值不一致,表示类中某些属性或者方法发生了更改,反序列化则出问题。(静态成员变量和transient关键字标记的成员不参与序列化过程)

2.2

Parcelable 接口

Parcelable 接口是Android所提供的,其实现相对来说比价复杂。实现该接口的类的对象就可以在Intent和Binder进行传递。

2.3

两者的区别

Serializable是Java提供的接口,使用简单,但序列化与反序列化需要大量的IO操作,所以开销比较大。Parcelable是Android提供的序列化方法,使用麻烦当效率高。在Android开发中,将对象序列化到设备或者序列化后通过网络传输建议使用Serializable接口,其他情况建议是用Parcelable接口,尤其在内存的序列化上。例如Intent和Binder传输数据。

3

AIDL

在Java层,想利用Binder进行夸进程的通信,那就得通过AIDL(Android 接口定义语言)了,AIDL是客户端与服务使用进程间通信 (IPC) 进行相互通信时都认可的编程接口,只有允许不同应用的客户端用 IPC 方式访问服务,并且想要在服务中处理多线程时,才有必要使用 AIDL,如果是在单应用(单进程),建议使用Messager。

3.1

AIDL支持的数据类型

Java 编程语言中的所有原语类型(如 int、long、char、boolean 等等)String 和 CharSequence所有实现了Parcelable接口的对象AIDL接口List,目前List只支持ArrayList类型,持有元素必须是以上讲到类型。Map,目前只支持HashMap类型,持有元素必须是以上讲到类型。

自定义的Parcelable对象和AIDL接口必须显示导入到AIDL文件中。

数据的走向

Parcelable对象和AIDL接口在使用前必须标明数据的走向:

  • in 客户端流向服务端
  • out 服务端流向客户端
  • inout 服务端与客户端可进行交互

示例:

1void addUser(inout User user);

3.2

服务端的实现

定义数据对象

定义一个实现了Parcelable 接口,作为客户端和服务端传输的数据对象。

 1public class User implements Parcelable {
 2
 3    private String username;
 4
 5    private String address;
 6
 7    public User() {
 8    }
 9
10    public User(String username, String address) {
11        this.username = username;
12        this.address = address;
13    }
14
15    User(Parcel in) {
16       readFromParcel(in);
17    }
18    //系统默认生成,反序列化过程,我们只需要要构造方法读取相关值就可以
19    public static final Creator<User> CREATOR = new Creator<User>() {
20        @Override
21        public User createFromParcel(Parcel in) {
22            return new User(in);
23        }
24
25        @Override
26        public User[] newArray(int size) {
27            return new User[size];
28        }
29    };
30     //系统默认生成,内容描述功能,几乎所有情况下都返回0,
31     //仅仅当前存在文件描述符,才返回1
32    @Override
33    public int describeContents() {
34        return 0;
35    }
36    //序列化过程,通过一系列的write将值写到Parcel 对象
37    @Override
38    public void writeToParcel(Parcel dest, int flags) {
39        dest.writeString(username);
40        dest.writeString(address);
41    }
42
43    @Override
44    public String toString() {
45        return username+":"+address;
46    }
47
48    public void readFromParcel(Parcel in){
49        username=in.readString();
50        address=in.readString();
51    }
52}

抽象服务端服务

通过下面方法,建立一个UserManger.aidl文件,表示服务端能为客户端提供什么样的服务。

下面代码通过建立UserManager.aidl文件,为客户端提供addUser和getUser的能力。UserManager可以理解为,服务端和客户端的共同约定,两者能进行怎么样的交互。

 1package com.gitcode.server;
 2
 3// 在这里要导入传递对象的类型,例如User
 4import com.gitcode.server.User;
 5
 6interface UserManager {
 7
 8    void addUser(inout User user);
 9
10    User getUser(int index);
11}

定义UserManager.aidl文件后,系统默认会生成UserManager.java文件。

UserManager.java的代码如下,为了减少篇幅,去掉了一些实现。

 1public interface UserManager extends android.os.IInterface {
 2
 3    public static abstract class Stub extends android.os.Binder implements com.gitcode.server.UserManager {
 4        private static final String DESCRIPTOR = "com.gitcode.server.UserManager";
 5
 6        public Stub() {
 7            this.attachInterface(this, DESCRIPTOR);
 8        }
 9
10        public static com.gitcode.server.UserManager asInterface(android.os.IBinder obj) {
11            if ((obj == null)) {
12                return null;
13            }
14            android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);
15            if (((iin != null) && (iin instanceof com.gitcode.server.UserManager))) {
16                return ((com.gitcode.server.UserManager) iin);
17            }
18            return new Stub.Proxy(obj);
19        }
20
21        @Override
22        public android.os.IBinder asBinder() {
23            return this;
24        }
25
26        @Override
27        public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags) throws android.os.RemoteException {
28           ......
29        }
30
31        private static class Proxy implements com.gitcode.server.UserManager {
32            private android.os.IBinder mRemote;
33
34            Proxy(android.os.IBinder remote) {
35                mRemote = remote;
36            }
37
38            @Override
39            public android.os.IBinder asBinder() {
40                return mRemote;
41            }
42
43            public String getInterfaceDescriptor() {
44                return DESCRIPTOR;
45            }
46
47            @Override
48            public void addUser(com.gitcode.server.User user) throws android.os.RemoteException {
49                 ......
50            }
51
52            @Override
53            public com.gitcode.server.User getUser(int index) throws android.os.RemoteException {
54                .....
55            }
56        }
57
58        static final int TRANSACTION_addUser = (android.os.IBinder.FIRST_CALL_TRANSACTION + 0);
59        static final int TRANSACTION_getUser = (android.os.IBinder.FIRST_CALL_TRANSACTION + 1);
60    }
61
62    public void addUser(com.gitcode.server.User user) throws android.os.RemoteException;
63
64    public com.gitcode.server.User getUser(int index) throws android.os.RemoteException;
65}

从上文可知,UserManager本身是一个接口,并继承IInterface接口。UserManager.java声明了addUser和getUser,和在UserManager.aidl的声明是一致的。同时声明两个整型TRANSACTION_addUser和TRANSACTION_getUser,用于在transact()方法中标识调用服务端哪个方法。如果服务端和客户端在不同进程,方法调用会走transact()方法,逻辑由Stub 和Proxy 内部类完成。

内部类Stub的一些概念和方法含义:

  • DESCRIPTOR

Binder的唯一标识,一般用当前的类名全名标识。

  • asInterface(IBinder obj)

将服务端的Binder对象转换成客户端的AIDL接口类型的对象,如果客户端和服务端同一进程,直接返回Stub对象本身,不在同一进程,则返回由系统封装的Stub.proxy对象。

  • asBinder

返回当前Binder对象

  • onTransact(int code, Parcel data, Parcel reply, int flags)

运行在服务端Binder线程池,当客户端跨进程发起请求后,系统封装后交由此方法来处理。code表示调用服务端什么方法,上文声明的整型。data表示客户端传递过来的数据,reply为服务端对客户端的回复。

内部代理类 Poxy,表示客户端远程能对服务端进行的操作。addUser运行在客户端,当客户端远程调用时,

在相同目录下创建User.aidl,可以直接复制UserManager.aidl,内容修改如下。

1package com.gitcode.server;
2
3parcelable User;

在服务端中,服务一般以Service体现,定义UserServcie,继承Service。

 1public class UserService extends Service {
 2    private static final String TAG = "Server";
 3    private List<User> list = new ArrayList<>();
 4
 5    @Override
 6    public void onCreate() {
 7        super.onCreate();
 8        list.add(new User("GitCode", "深圳"));
 9    }
10
11    @Override
12    public IBinder onBind(Intent intent) {
13        Log.i(TAG,"on Bind");
14        return stub;
15    }
16
17
18    private UserManager.Stub stub = new UserManager.Stub() {
19        @Override
20        public void addUser(User user) throws RemoteException {
21            list.add(user);
22            Log.i(TAG,"add user:"+user);
23        }
24
25        @Override
26        public User getUser(int index) throws RemoteException {
27            Log.i(TAG,"get user,index:"+index);
28            return list.size() > index && index >= 0 ? list.get(index) : null;
29        }
30    };
31}

在AndroidManifest.xml文件声明Service,以两个组件形成单独的app来体现两个进程,通过AIDL进行数据交互。在客户端通过bindService()来启动该服务。

1<service android:name="com.gitcode.server.UserService"
2    android:enabled="true"
3    android:exported="true">
4        <intent-filter>
5            <action android:name="com.gitcode.server.userservice"/>
6            <category android:name="android.intent.category.DEFAULT"/>
7        </intent-filter>
8</service>

3.3

客户端的实现

客户端主要是通过共同的约定(UserManger.aidl)向服务端进行请求,服务端响应客户端的请求。为了提高效率和减少出错,通过拷贝来实现客户端的AIDL文件。将服务端的aidl整个文件拷贝到客户端的main目录下,不做任何修改。

在客户端建立与服务端User类同包的目录,并将User类拷贝过来,不做任何修改。

在Activity中绑定服务端的Service,绑定成功后进行数据交互。

 1public class MainActivity extends AppCompatActivity {
 2    private static final String TAG = "Client";
 3    private UserManager mUserManager;
 4    @Override
 5    protected void onCreate(Bundle savedInstanceState) {
 6        super.onCreate(savedInstanceState);
 7        setContentView(R.layout.activity_main);
 8        toBindService();
 9    }
10
11    private void toBindService() {
12        Intent intent = new Intent("com.gitcode.server.userservice");
13        intent.setPackage("com.gitcode.server");
14        bindService(intent, connection, Context.BIND_AUTO_CREATE);
15    }
16
17    private ServiceConnection connection = new ServiceConnection() {
18        @Override
19        public void onServiceConnected(ComponentName name, IBinder service) {
20            mUserManager = UserManager.Stub.asInterface(service);
21
22            try {
23                User user = mUserManager.getUser(0);
24                Log.e(TAG, user.toString());
25
26                mUserManager.addUser(new User("张三","北京"));
27            } catch (RemoteException e) {
28                e.printStackTrace();
29            }
30        }
31
32        @Override
33        public void onServiceDisconnected(ComponentName name) {
34        }
35    };
36}

运行效果:客户端:

服务端:

3.4

小结

客户端调用服务的方法,被调用的方法运行在服务端的的Binder线程池,同时客户端会被挂起,如果服务端方法执行耗时操作,就会导致客户端ANR,所以不要在客户端主线程访问远程服务方法。同时服务端不应该自己新建新建线程运行服务方法,因为方法会交由线程池处理,同时对数据也要做好并发访问处理。

AIDL可以说为应用层开发提供了封装,不用过多的了解Binder的机制,通过生成的UserManager.java,初步可以了解Binder的IPC机制。使用AIDL在进程之间进行数据通信,更注重的是细节和业务的实现。

上文demo地址:

https://link.juejin.im/?target=https%3A%2F%2Fgithub.com%2FGitCode8%2FAIDL

4

Binder

Binder是Android系统提供的一种IPC机制。由于Android是基于Linux内核,因此,除了Binder以外,还有其他的IPC机制,例如Socket,共享内存,管道和消息队列等。之所有不使用原有的 IPC机制,是因为使用Binder机制,能从性能、稳定性、安全性带来更好的效果。例如,Socket是一套通用的接口,传输速率低下,适合网络传输这种情况,而管道和消息队列需要数据的两次拷贝,共享内容难以管控等。而Binder对数据只需要一次拷贝,使用C/S架构,职责明确,容易维护和使用。

通过下图可以了解到,Binder机制通过内存映射实现跨进程通信,Binder在IPC机制只是作为一个数据的载体,当进程A向虚拟内存空间中写入数据,数据会被实时反馈到进程B的虚拟内存空间。整个发送数据的过程,只从用户空间拷贝一次到虚拟内存空间。

在Binder机制中,主要涉及到Client、Server、ServiceManger三个端,三者通过Binder进行跨进程通信,支持着Android这个大网络。它们的关系如下图。

4.1

Server

Server进程需要注册一些Service到ServiceManger中,以对外告知其可提供的服务。例如上文AIDL中,会注册UserService,并为Client提供添加User和获取User的操作。注册的过程,Server进程就是客户端,而ServiceManger就是服务端。

4.2

Client

对Sever进程进行业务逻辑操作。通过Service的名称在ServiceManger查找对应的Service。

4.3

ServiceManager

ServiceManger集中管理系统内的所有Service,服务通过注册Service到ServiceManger的查找表中,当Client根据Service名称请求ServiceManger在查找表中查询对应的Service。图表示三者的C/S架构,例如Client查询向ServiceManger查询Service时,Client就是客户端,而ServiceManger就是服务端。而虚线则表示两者之间通过Binder进行进程间的通信,因此通过了解一条虚线的流程,就可以知道Binder的机制。

4.4

Service的注册过程

通过Server进程的注册Service过程,可以了解到Binder机制的工作原理。

BpServcieManger和BnServcieManger是客户端与服务端进程业务层辑实现的封装,而BpBinder和BBinder是IPC机制的方式。此时Server进程是客户端,ServiceManger是服务端。

ProcessState

每个进程通过单例模式创建了唯一的ProcessState对象,在其构造器中,通过open_driver()方法打开了/dev/binder设备,相当于Server进程打开了与内核的Binder驱动交互的通道,并设置最大支持线程数为15。binder设备是Android在内核中为完成进程间通信而专门设置的一个虚拟设备。

BpBinder和BBinder

BpBinder与BBinder都是Android与Binder通信相关的代表,两者一一对应,都从IBinder派生而来。如果说BpBinder代表客户端,那么BBinder就代表服务端,一个BpBinder通过handler标识与对应的BBinder进行交互。在Binder系统,handler标识为0代表着ServiceManger所对应的BBinder。BpBinder与BBinder并没有直接操作ProcessState打开的binder设备。

BpServiceManger和BnserviceManger

两者继承至IServiceManger,与业务逻辑相关,可以说将业务层的逻辑架构到Binder机制上。BnserviceManger从IServiceManger BBinder派生而来,可直接参与Binder的通信,而BpServiceManger通过mRemote指向BpBinder。

注册相关Service

通过上文三小节,BpServiceManger对象实现对IServiceManger的业务函数,又有BpBinder作为通信代表,下面分析一下注册的过程。将字符串名字和Service对象作为参数传到BpServiceManger对象的addService()函数,该方法将参数数据打包后传递给BpBidner的transact()函数。业务层的逻辑到此就结束,主要作用是将请求信息打包交给通信层去处理。在BpBinder的transact()函数调用了IPCThreadState对象的transact()函数,所以说BpBinder本身没有参与Binder设备的交互。每个线程都有一个IPCThreadState对象,其拥有一个mOut、mIn的缓冲区,mOut用来存储转发Binder设备的数据,而mIn用来接收Binder设备的数据。通过ioctl方式与Binder设备进行交互。

小结

通过上文Service的注册过程,分析了Binder的机制。Binder只是通信机制,业务可以基于Binder机制,也可以基于其他IPC方式的机制,也就是上文为啥有BpServiceManger和BpBinder。Binder之所以复杂,是Android通过层层的封装,巧妙的将业务与通信融合在一起。主要还是设计理想很牛逼。

4.5

ServiceManger

通过1小节的分析,是否应该也有一个类继承自BnServiceManger来处理远方请求呢?

很可惜的是在服务端并没有BnServiceManger子类来响应远程客户端的请求,而是交给了ServiceManger来处理。

成为Service管理中心

ServiceManger通过binder_open函数打开binder设备,并映射内存。通过handler等于0标识自己,让自己成为管理中心,所有service向ServiceManger注册时,都是通过handle标识为的0的BpBinder找到ServiceManger对应的BBinder,ServiceManager会保存要注册的Service的相关信息,方便Client查找。并不是所有的Service都可以在ServiceManger注册,如果Server进程的权限不够root或system,那么需要在allowed添加相应的项。

ServiceManger集中管理带来的好处

  • 统一管理,施加管控权
  • 通知字符串名称查找Service
  • Server进程生命无常,通过ServiceManger,Client可以实时知道Server进程的最行动态。

4.6

Client

Client想要使用Server进程提供的Service,又该进行哪些步骤呢?

查询ServiceManger

Client想要得到某个Service的信息,就得与ServiceManager打交道,通过调用getService()方法来获取对应Service信息。Client通过服务名称向ServiceManger查询对应的Service。如果Service未注册,则循环等待直到该Service注册;如果已注册,则会对应封装了一个能与远程Service通信的BpBinder的BpXXXService,通过该Service,Client客户调用相关业务逻辑函数。

请求信息的处理

Client调用的业务函数,莫非就是将请求参数打包发送给Binder驱动,BpBinder通过handler的值找到对应端的Service来处理。在1.4小节中,说到IPCThreadState对象,在其executeCommand函数中,通过调用实现了BnServiceXXX的对象onTransact函数,直接定位到业务层。这就是在AIDL中,为什么在onTransact()函数中处理响应数据。

4.7

总结

通过对Binder机制的学习,了解Android是如何通过层层封装将Binder机制集成要应用程序,对Binder机制有一个较深入的理解。可以通过第Java层AIDL的使用,加深对Binder机制的理解。个人水平有限,有误请帮忙勘正,谢谢大佬。喜欢就帮忙点个赞呗。

原文发布于微信公众号 - Android补给站(PayneDev)

原文发表时间:2019-07-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券