Android技术Android系统方面那些事

Binder:欠你的,还你!

2019-04-24  本文已影响256人  最有文化的码农

一. 为何要学习Binder?


binder在Android中的逼格和份量,不用我明说了吧,从事Android的人无论是工作还是面试估计都会被提及到binder的影子,毫无不客气的说binder在我看来是Android的大动脉,它牵引着你的app如何在Android当中行走。你若想懂你的app,你首先得懂这条大动脉,所以我们要彻底干倒它!

二. Binder在Android当中的存在感


Binder可以说在Android当中是一种高逼格的存在。是Android跨进程实现的基石,关联着Android上层和底层,起着通讯的桥梁作用。

一张图诠释binder要解决的问题:

三. Binder的家庭组织


了解一个知识点就像是去了解一个人,你必须先搞清楚他的人际关系,七大姑八大姨,然后去繁为简。才能直入重点。下面就直接上图吧。

大组织:

说明:

1. Binder是集成ibinder实现的,ibinder会返回binder的接口对象从而调用底层的方法。

2. Binder的跨进程实现的基本原理是通过物理的共享内存实现的,主要是通过数据的层层复制最终实现数据的传递,而内存中的数据传输必须是二进制的形式,因此用到了parcel序列化,而跨进程需要统一的协议,aidl就是为此而生的。

3. Binder的所有执行都是被动的,他的接受都是上层以及和下层传达的命令,上层的大管家是AMS,下层的大管家是SM,两者在不同的进程内都指示着binder为其谋事。

名词解释

四. 怎么学习Binder?


1)了解Binder的架构

全世界的程序员都画着同样的架构图,在这里我就盗用一张我认为比较好的图。

图形解说:

1. Binder的实现模式是C/S的模式,即是Client - Servier,可以说很形象的说明了确实是跨进程的。

2.从binder的架构可以看出,Binder在每层都有自己的影子出现,只不过是披着不同的人皮,只是为了适应每层的语言环境。

3. ioctl是设备驱动程序中对设备的I/O通道进行管理的函数,通过这个最终打开内核的驱动程序。

4. 总体来说client送一个请求,会在jni的servicemanager.cpp里面去找对应的服务(这个服务是server注册的),找到后jni层返回给java层一个binder代理,再有binder发送请求,此时会有类似于meassge的loop一样,会有binder-loop进行数据copy,把要传输的数据copy的内存共享空间。再有内核的驱动层自己的binder进程进行处理,检索服务的注册表,找到对应的服务再从共享内存中把数据copy出来。完成跨进程的数据通信。

2)熟悉Binder实现跨进程通信的原理

其实在上面讲到架构的时候也是分析原理的过程。总结一句话就是,server像binder驱动注册服务,client向binder驱动获取服务,而服务的管理都都是ServiceManager的责任。实现的途径就是借助内存地址映射,实现内核空间和用户空间的数据映射。

核心方法:onTransact(code, data, reply, flags)。看过源码的人都会清楚这个方法从应用层的binder代理调到jni层再调到驱动层。

public finalboolean transact(intcode, Parcel data, Parcel reply,intflags) throws RemoteException{

if(data !=null) {

data.setDataPosition(0);

}

booleanr = onTransact(code, data, reply, flags);

if(reply !=null) {

reply.setDataPosition(0);

}

returnr;}

五. Binder的延伸


1.为什么 Activity 间传递对象需要序列化?

解答:Android规定不同进程之间进行数据传递一定要序列化,以便能够数据保存的持久性和ipc的通信。即便是同一进程的activity通过intent进行数据传送,Android也会自动序列化,这是固有的机制。当然,同一进程不想通过这种方式传递数据,可以通过全局变量或者本地数据存储的方式进行传递,但是前者可能会引发内存泄漏,后者会造成性能慢。

2.App的启动流程是什么?

解答:讲到这的时候AMS派上用场了,先看一张图。

启动activity:

图形解说:

a.  整个app的启动其实也是一个跨进程的通信。

b. 点击app的时候首先唤醒的是launcher的进程,launcher通过binder的机制通知到AMS,再向zygote索要app的进程(大家熟知每一个app都有一个自己的主进程,就是这样来的),然后ActivityThread通过bindApplication此方法绑定自己的application。

c. 系统拥有了该application的进程后开始真正的执行startactivity了开始了activity生命周期

3.四大组件底层的通信机制是怎样的?

解答:不讲了底层通信机制都是binder的那套。包括view的绘制其实也是模仿的binder的那套。所以为什么一开始就说,binder是高逼格且重要的存在。

4.AIDL 内部的实现原理是什么?

解答:AIDL其实就是通过Binder实现的。

验证方法:在as里面创建一个aidl文件,as会自动帮你生成一个实体类的接口,这个接口里面有一个stub的内部静态类。如:

public static abstract class Stub extends android.os.Binder implements lyl.test.demo.Manager{

private static final java.lang.String DESCRIPTOR ="lyl.test.demo.Manager";

public static lyl.test.demo.Manageras Interface(android.os.IBinder obj){

if ((obj ==null))         

  {

return null;

  }       

android.os.IInterface iin = obj.queryLocalInterface(DESCRIPTOR);

if(((iin !=null) && (iin instanceof lyl.test.demo.Manager)))            {

return ((lyl.test.demo.Manager) iin);         

}

return new lyl.test.demo.Manager.Stub.Proxy(obj);     

}

@Override

public android.os.IBinderasBinder() {

return this; 

}

@Override

public boolean onTransact(intcode, android.os.Parcel data, android.os.Parcel reply,intflags) throws android.os.RemoteException{

switch(code)           

{caseINTERFACE_TRANSACTION:             

  { reply.writeString(DESCRIPTOR);return true;  }

caseTRANSACTION_getName:  {

data.enforceInterface(DESCRIPTOR);                   

java.lang.String _result =this.getName(); 

reply.writeNoException();                 

reply.writeString(_result);returntrue;                }

caseTRANSACTION_getOtherName:             

{  data.enforceInterface(DESCRIPTOR);                 

java.lang.String _result =this.getOtherName();                 

reply.writeNoException();                   

reply.writeString(_result);returntrue;                }         

}

return super.onTransact(code, data, reply, flags);        }

}

1. 可以看到Stub中的常量,其中两个int常量是用来标识我们在接口中定义的方法的。

2. DESCRIPTOR常量是 Binder的唯一标识。

3. asInterface 方法用于将服务端的Binder对象转换为客户端所需要的接口对象,该过程区分进程,如果进程一样,就返回服务端Stub对象本身,否则呢就返回封装后的Stub.Proxy对象。

4. onTransact 方法是运行在服务端的Binder线程中的,当客户端发起远程请求后,在底层封装后会交由此方法来处理。通过code来区分客户端请求的方法,注意一点的是,如果该方法返回false的换,客户端的请求就会失败。

六. 对Binder的感悟


binder的机制博大精深,每一个知识点都值得去做深入的研究,牵扯的知识面也非常广,此篇文章只是对整体原理和机制的梳理,不可否认的是binder的机制如果吃的比较透彻,整个Android binder的架构模式其实可以运用到我们很多的代码设计甚至架构设计当中,这里面的牵扯的知识点更是给我们暴露了很多可能性,比如丢掉服务端可以做到跨app间的通信。曾经我都尝试过语音im的通信,当然这仅限于消息的及时性,依旧不可存储性。

总之,Android的每一个模块的知识点其实都是一个值得研究和借鉴的架构模式,仔细研究下来,会发现每个知识点的关联性可以贯穿整个Android源码。

就个人而言,我觉得我们学习各种新的架构和技术设计模式,不如学习Android的源码的设计模式,个人感觉这真的是权威的,教科书级别。

最后,不喜勿碰,有些知识点有错误的地方还希望留言纠正!期待一起交流学习!

上一篇下一篇

猜你喜欢

热点阅读