Binder:欠你的,还你!

作者: 最有文化的码农 | 来源:发表于2019-04-24 18:03 被阅读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的源码的设计模式,个人感觉这真的是权威的,教科书级别。

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

    相关文章

      网友评论

        本文标题:Binder:欠你的,还你!

        本文链接:https://www.haomeiwen.com/subject/vxpwgqtx.html