Android进阶笔记-5. IPC机制 & Binder 原理

最新推荐文章于 2022-05-02 10:37:30 发布

今阳

最新推荐文章于 2022-05-02 10:37:30 发布

阅读量860

点赞数

分类专栏： Android进阶笔记文章标签： android java binder 源码

本文链接：https://blog.csdn.net/o118abcdef/article/details/122459866

版权

Android进阶笔记专栏收录该内容

17 篇文章 1 订阅

订阅专栏

IPC机制

一次进程间通信至少包含两个进程，由于进程隔离机制的存在，通信双方必然需要借助 IPC（进程间通信，inter-Process Communication）来实现；

Linux中的IPC机制种类

管道（pipe）

继承自Unix，半双工通信方式（数据只能在一个方向上流动）;
原理：通信双方利用内存的共享文件来传递信息；

信号（sinal）

异步通信方式,软件层对中断机制的一种模拟,例如内核通知用户空间进程发生了哪些系统事件
不适用于信息交换，适用于进程中断控制;

信号量（semophore）

是一个计数器，控制多个进程对共享资源的访问，常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源;
主要作为进程间以及同一进程内不同线程之间的同步手段;

消息队列（Message）

具有特定格式的消息链表，存放在内存中并由消息队列标识符标识，并且允许一个或多个进程向它写入与读取消息;
信息会复制两次，因此对于频繁或者信息量大的通信不宜使用消息队列;

共享内存（Share Memory)

多个进程读写一块内存空间，由需要访问的进程将其映射到自己的私有地址空间，不需要进行数据的拷贝，效率较高;

套接字（Socket）

可用于不同机器之间的进程间通信

Android中的IPC机制

序列化

Serializable: java提供,空接口,开销大,大量的IO操作;
Parcelable: android提供,通过intent,binder传递,效率要更高,我们常用的Bundle就是其实现类;

Serializable与Parcelable区别

Serializable：Java 序列化接口，在硬盘上读写，读写过程中有大量临时变量的生成，内部执行大量的i/o操作，效率很低;
Parcelable：Android 序列化接口，效率高, 使用麻烦, 在内存中读写（AS有相关插件一键生成所需方法），对象不能保存到磁盘中;

AIDL

服务端:

创建要操作的实体类，实现 Parcelable 接口
新建aidl文件夹，在其中创建接口aidl文件以及实体类的映射aidl文件
Make project
服务service中实现AidlInterface.Stub对象, 并在onBind方法中返回

客户端:

copy服务端提供的aidl文件夹和实体类
Make project
ServiceConnection.onServiceConnected方法中调用AidlInterface.Stub.asInterface(IBinder)创建AidlInterface实例,并调用其方法

Bundle

实现了Parcelable接口，所以它可以方便的在不同的进程间传输。
四大组件中的Activity,Service,Receiver都支持使用Bundle传递数据,所以当我们启动不同进程的组件时,就可以用Intent+bundle进行数据传递

共享文件和SharedPreferences

两个进程通过读写同一个文件来交换数据
对象可以通过序列化和反序列化进行读写
SharedPreferences本质就是读写文件

Messenger(信使,轻量级的IPC方案)

通过它可以在不同进程间传递Message对象
底层其实就是AIDL, 只是进一步进行了封装, 以方便使用,从下面这个构造方法就可以看出

public Messenger(IBinder target) {
    mTarget = IMessenger.Stub.asInterface(target);
}

Socket

分为流式套接字和用户数据报套接字两种, 分别对应于网络的传输控制层中的TCP和UDP协议
TCP: 面向连接的协议,提供稳定的双向通信功能,连接的建立需要经过三次握手才能完成,
为了提供稳定的数据传输功能,其本身提供了超时重传机制
UDP: 无连接,提供不稳定的单向通信功能(也可以实现双向通信),具有更好的效率,但不能保证数据一定能
正确传输,尤其是在网络拥塞的情况下

ContentProvider

Android中提供的专门用于不同应用间进行数据共享的方式,天生就适合进程间通信
底层实现同样也是Binder,而且比AIDL要简单
需要注意的: CRUD操作,防止SQL注入,权限控制
系统中预制了许多ContentProvider,如通讯录,日程表信息等
query,insert,delete,update是运行在Binder线程中的, 存在多线程并发访问,方法内部要做好线程同步
,例如BookProvider中采用了SQLite,并且只有一个SQLiteDatabase的链接, 所以可以正确的应对多线程情况,
因为SQLiteDatabase内部对数据库的操作是有同步处理的
onCreate运行在main线程(UI线程),不能进行耗时操作

Binder

基于Binder的: AIDL,Messenger,ContentProvider
从Android Framework角度讲,Binder是ServiceManager链接各种Manager(ActivityManager,WindowManager等)和ManagerService的桥梁
从Android 应用层来说,Binder是客户端和服务端进行通信的媒介(bindService)
Binder主要用在Service中,包括普通的Service,AIDL和Messenger
普通的Service中的Binder不涉及进程间通信,没有触及到Binder的核心

Binder 跨进程通信原理

为什么要使用Binder

1. 性能

主要影响的因素是拷贝次数：

管道、消息队列、Socket的拷贝次书都是两次，性能不是很好；
共享内存不需要拷贝，性能最好；
Binder拷贝1次，性能仅次于共享内存；

Linux 下传统的进程间通信原理与不足

内核程序在内核空间分配内存并开辟一块内核缓存区，发送进程通过copy_from_user函数将数据拷贝到到内核空间的缓冲区中。同样的，接收进程在接收数据时在自己的用户空间开辟一块内存缓存区，然后内核程序调用 copy_to_user() 函数将数据从内核缓存区拷贝到接收进程。这样数据发送进程和数据接收进程完成了一次数据传输，也就是一次进程间通信；其有两点不足之处：

一次数据传递需要经历：用户空间 –> 内核缓存区 –> 用户空间，需要2次数据拷贝，效率不高。
接收数据的缓存区由数据接收进程提供，但是接收进程并不知道需要多大的空间来存放将要传递过来的数据，因此只能开辟尽可能大的内存空间或者先调用API接收消息头来获取消息体的大小，浪费了空间或者时间。

2. 稳定性

Binder是基于C/S架构的，技术上已经很成熟，稳定；
共享内存没有分层，难以控制，并发同步访问临界资源时，可能还会产生死锁；

从稳定性的角度讲，Binder是优于共享内存的。

3. 安全

Android是一个开源的系统，并且拥有开放性的平台，市场上应用来源很广，因此安全性对于Android 平台而言极其重要。
传统的IPC接收方无法获得对方可靠的进程用户ID/进程ID（UID/PID），无法鉴别对方身份。Android 为每个安装好的APP分配了自己的UID，
通过进程的UID来鉴别进程身份。另外，Android系统中的Server端会判断UID/PID是否满足访问权限，而对外只暴露Client端，加强了系统的安全性。

4. 语言

Linux是基于C语言，C语言是面向过程的，Android应用层和Java Framework是基于Java语言，Java语言是面向对象的。
Binder本身符合面向对象的思想，因此作为Android的通信机制更合适。

Android中Binder的来源

Binder是基于开源的OpenBinder实现的，OpenBinder最早并不是由Google公司开发的，而是Be Inc公司开发的，接着由Palm, Inc.公司负责开发。后来OpenBinder的作者Dianne Hackborn加入了Google公司，并负责Android平台的开发工作，顺便把这项技术也带进了Android。

Linux的动态内核可加载模块

跨进程通信是需要内核空间做支持的, 传统的 IPC 机制如管道、Socket 都是内核的一部分，因此通过内核支持来实现进程间通信自然是没问题的。但是 Binder 并不是 Linux 系统内核的一部分，那怎么办呢？
这就得益于 Linux 的动态内核可加载模块（Loadable Kernel Module，LKM）的机制；模块是具有独立功能的程序，它可以被单独编译，但是不能独立运行。它在运行时被链接到内核作为内核的一部分运行。这样，Android 系统就可以通过动态添加一个内核模块运行在内核空间，用户进程之间通过这个内核模块作为桥梁来实现通信。

Binder 驱动

在 Android 系统中，这个运行在内核空间，负责各个用户进程通过 Binder 实现通信的内核模块就叫 Binder 驱动（Binder Dirver）。
Binder驱动是Android专用的，但底层的驱动架构与Linux驱动一样。binder驱动在以misc设备进行注册，作为虚拟字符设备，没有直接操作硬件，只是对设备内存的处理。主要是驱动设备的初始化(binder_init)，打开 (binder_open)，映射(binder_mmap)，数据操作(binder_ioctl)。
Binder是基于内存映射来实现的，内存映射通常是用在有物理介质的文件系统上的，而 Binder 并不存在物理介质，因此 Binder 驱动使用 mmap() 并不是为了在物理介质和用户空间之间建立映射，而是用来在内核空间创建数据接收的缓存空间, 是为了跨进程传递数据。

内核空间(KernelSpace)和用户空间(UserSpace)

为了保证内核的安全，不能让用户进程直接操作内核，操作系统从逻辑上将虚拟空间划分为用户空间和内核空间，即使用户的程序崩溃了，内核也不会受到影响，内核空间的数据是可以进程间共享的；

进程隔离

一个进程不能直接操作或者访问另一个进程

系统调用

系统调用是用户空间访问内核空间的唯一方式，保证了所有的资源访问都是在内核的控制下进行的，避免了用户程序对系统资源的越权访问，提升了系统安全性和稳定性。
copy_from_user：将用户空间的数据拷贝到内核空间。
copy_to_user：将内核空间的数据拷贝到用户空间。

内存映射（Memory Map）

由于应用程序不能直接操作设备硬件地址，所以操作系统提供了一种机制：内存映射，把设备地址映射到进程虚拟内存区
例如用户空间读取磁盘文件，如果不采用内存映射，那么就需要在内核空间建立一个页缓存，页缓存去拷贝磁盘上的文件，然后用户空间拷贝页缓存的文件，这就需要两次拷贝。如果采用内存映射，由于新建了虚拟内存区，那么磁盘文件和虚拟内存区域就可以直接映射，少了一次拷贝。
在Linux中通过系统调用函数mmap来实现内存映射。将用户空间的一块内存区域映射到内核空间。映射关系建立后，用户对这块内存区域的修改可以直接反应到内核空间，反之亦然。内存映射能减少数据拷贝次数，实现用户空间和内核空间的高效互动。

Binder驱动通过内存映射进行跨进程通信的步骤

Binder驱动在内核空间创建一个数据接收缓存区。
在内核空间开辟一块内核缓存区，建立内核缓存区和数据接收缓存区之间的映射关系，以及数据接收缓存区和接收进程用户空间地址的映射关系。
发送方进程通过copy_from_user()函数将数据拷贝到内核中的内核缓存区，由于内核缓存区和接收进程的用户空间存在内存映射，
因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信，整个过程只使用了1次拷贝，效率更高。

系统中并不是所有的进程通信都是采用了Binder，而是根据场景选择最合适的，比如Zygote进程与AMS通信使用的是Socket，Kill Process采用的是信号。

基于Binder通信的C/S架构

系统在启动时，SystemServer进程启动后会创建Binder线程池，目的是通过Binder，使得在SystemServer进程中的服务（如AMS、PMS）可以和其他进程进行通信；
我们常说的AMS、PMS都是基于Binder来实现的，再比如Client端的MediaPlayer和Server端的MeidaPlayerService不是运行在一个进程中的，同样需要Binder来实现通信。

Binder 是基于 C/S 架构的,其中 Client进程、Server进程、Service Manager进程运行在用户空间，Binder驱动运行在内核空间。Client、Server 和 ServiceManager 之间的交互通过系统调用 open、mmap 和 ioctl 来访问设备文件 /dev/binder（Binder驱动，在内核空间通过mmap实现跨进程通信），间接的实现跨进程通信。
Binder驱动，Service Manager进程属于 Android基础架构（系统已经实现好了）；
Client 进程和 Server 进程属于Android应用层（需要开发者自己实现）

Binder机制在Android中的具体实现

Binder机制在 Android中的实现主要依靠 Binder类，其实现了IBinder 接口

Binder 通信过程

1. 启动ServiceManager

ServiceManager是init进程负责启动的，具体是在解析init.rc配置文件时启动的，init进程是在系统启动时启动的；
servicemanager的入口函数在service_manager.c中

int main(int argc, char** argv)
{
    //binder_state结构体用来存储binder的三个信息:
    //int fd; //binder设备的文件描述符
    //void *mapped; //binder设备文件映射到进程的地址空间
    //size_t mapsize; //内存映射后，系统分配的地址空间的大小，默认为128KB
    struct binder_state *bs;
    union selinux_callback cb;
    char *driver;

    if (argc > 1) {
        driver = argv[1];
    } else {
        driver = "/dev/binder";
    }

    //binder_open:打开binder设备文件，调用mmap函数进行内存映射,申请128k字节大小的内存空间
    bs = binder_open(driver, 128*1024);
    ...
    //binder_become_context_manager:将servicemanager注册成为Binder机制的上下文管理者,这个管理者在整个系统只有一个
    if (binder_become_context_manager(bs)) {
        ALOGE("cannot become context manager (%s)\n", strerror(errno));
        return -1;
    }
    ...
    if (getcon(&service_manager_context) != 0) {
        ALOGE("SELinux: Failed to acquire service_manager context. Aborting.\n");
        abort();
    }
    //servicemanager成功注册成为Binder机制的上下文管理者后，servicemanager就是Binder机制的“总管”了，
    //它需要在系统运行期间处理client端的请求，由于client端的请求不确定何时发送，因此需要通过无限循环来实现
    binder_loop(bs, svcmgr_handler);

    return 0;
}

上面代码可以看出，servicemanager的入口函数主要做了三件事

打开binder设备文件，调用mmap函数进行内存映射,申请128k字节大小的内存空间
将servicemanager注册成为Binder机制的上下文管理者,这个管理者在整个系统只有一个
servicemanager成功注册成为Binder机制的上下文管理者后，servicemanager就是Binder机制的“总管”了，它需要在系统运行期间通过无限循环处理client端的请求

用户态和内核态

当一个进程在执行用户自己的代码时处于用户态，比如open函数，它运行在用户空间，当前的进程处于用户态。
当一个进程因为系统调用进入内核代码中执行时就处于内核态，比如open函数通过系统调用（__open()函数），查找到了open函数在Kernel Binder对应的函数为binder_open，这时binder_open运行在内核空间，当前的进程由用户态切换到内核态。

2. 注册服务

Server通过Binder驱动向 ServiceManager 中注册 Binder（Server 中的 Binder 实体），表明可以对外提供服务。Binder 驱动为这个 Binder 创建位于内核中的实体节点以及 ServiceManager 对实体的引用，将名字以及新建的引用打包传给 ServiceManager，ServiceManger 将其填入查找表。
例如MediaPlayerService是Server端，MediaPlayerService是系统多媒体服务的一种，系统多媒体服务是由一个叫做MediaServer的服务进程提供的；
在Android系统启动时，MediaServer也被启动，入口函数如下

int main(int argc __unused, char **argv __unused)
{
    signal(SIGPIPE, SIG_IGN);
    //获取ProcessState实例,打开/dev/binder设备，设定Binder最大的支持线程数
    //并使用mmap为Binder驱动分配一个虚拟地址空间用来接收数据。
    sp<ProcessState> proc(ProcessState::self());
    //获取ServiceManager，其他进程就可以和当前的ServiceManager进行交互
    //ServiceManager中使用了Binder通信(BpBinder)，它自身也是属于Binder体系的
    //这里得到的实例是BpServiceManager，它实现了IServiceManager，并且通过BpBinder来实现通信
    sp<IServiceManager> sm(defaultServiceManager());
    ALOGI("ServiceManager: %p", sm.get());
    InitializeIcuOrDie();
    //注册MediaPlayerService，
    //其中调用了defaultServiceManager()->addService将数据打包发送给BpBinder来进行处理
    //BpBinder新建一个IPCThreadState对象，并将通信的任务交给IPCThreadState
    //IPCThreadState的writeTransactionData函数用于将命令协议和数据写入到mOut中
    //IPCThreadState的waitForResponse函数主要做了两件事，
    //一件事是通过ioctl函数操作mOut和mIn来与Binder驱动进行数据交互，另一件事是处理各种命令协议。
    MediaPlayerService::instantiate();
    ResourceManagerService::instantiate();
    registerExtensions();
    //启动Binder线程池
    ProcessState::self()->startThreadPool();
    //当前线程加入到线程池
    IPCThreadState::self()->joinThreadPool();
}

- BpBinder，BBinder是Binder通信的“双子星”，都继承了IBinder;
- BpBinder是Client端与Server交互的代理类，而BBinder则代表了Server端。
- BpBinder和BBinder是一一对应的，BpBinder会通过handle来找到对应的BBinder
- BpBinder和BBinder负责Binder的通信，而IServiceManager用于处理ServiceManager的业务

MediaServer通过Binder驱动，使用mmap接收数据;
获取一个IServiceManager的实例BpServiceManager，其并且通过BpBinder来实现通信;
通过defaultServiceManager注册MediaPlayerService，这里MediaPlayerService是Client端，用于请求添加系统服务。而Server端则是指的是ServiceManager，用于完成系统服务的添加，两端通过向Binder驱动发送命令协议来完成系统服务的添加；

3. 获取服务

Client进程通过Binder驱动向 ServiceManager进程获取相应的Service信息（Binder代理对象，具有和 Binder 一样的方法，但这些方法并没有 Server 进程中 Binder 对象那些方法的能力，这些方法只需要把把请求参数交给Binder驱动即可。对于 Client 进程来说和直接调用 Binder 中的方法是一样的）
系统服务的注册流程中，在Kernel Binder中会调用do_add_service函数，其内部会将包含服务名和handle值的svcinfo保存到svclist列表中。同样的，在获取服务的流程中，find_svc函数中会遍历svclist列表，根据服务名查找对应服务是否已经注册，如果已经注册就会返回对应的svcinfo，如果没有注册就返回NULL。
服务端ServiceManager处理请求：servicemanager的入口函数中调用了binder_loop函数，其在无限循环中不断的调用ioctl函数，它不断的使用BINDER_WRITE_READ指令查询Binder驱动中是否有新的请求；
仍旧以MediaPlayerService为例，获取MediaPlayerService需要调用getMediaPlayerService函数

IMediaDeathNotifier::getMediaPlayerService()
{
    ALOGV("getMediaPlayerService");
    Mutex::Autolock _l(sServiceLock);
    if (sMediaPlayerService == 0) {
        sp<IServiceManager> sm = defaultServiceManager();//实例为BpServiceManager
        sp<IBinder> binder;
        do {
            //获取名为”media.player”的系统服务（MediaPlayerService），返回的值为BpBinder
            binder = sm->getService(String16("media.player"));
            if (binder != 0) {
                break;
            }
            //这个时候MediaPlayerService可能还没有向ServiceManager注册
            //所以休眠0.5s后继续调用getService，直到获取服务对应的为止
            usleep(500000); //4
        } while (true);

        if (sDeathNotifier == NULL) {
            sDeathNotifier = new DeathNotifier();
        }
        binder->linkToDeath(sDeathNotifier);
        //interface_cast通过BpBinder的handle来找到对应的服务，即BpMediaPlayerService。
        sMediaPlayerService = interface_cast<IMediaPlayerService>(binder);
    }
    ALOGE_IF(sMediaPlayerService == 0, "no media player service!?");
    return sMediaPlayerService;
}

通过getMediaPlayerService获取名为”media.player”的系统服务（MediaPlayerService），其中调用interface_cast通过BpBinder的handle来找到对应的服务，即BpMediaPlayerService

4. 使用服务

Client进程根据获取到的 Service信息（Binder代理对象BinderProxy），通过Binder驱动建立与该Service所在Server进程通信的链路，并开始使用服务
Binder和BinderProxy实现了IBinder接口，Binder是服务端的代表，而BinderProxy是客户端的代表; Parcel是一个数据包装器，它可以在进程间进行传递，Parcel既可以传递基本数据类型也可以传递Binder对象，Binder通信就是通过Parcel来进行客户端与服务端数据交互。
例如之前的Android进阶笔记-3. Service 启动过程 & 绑定过程中讲过的ContextImpl的startService方法

private ComponentName startServiceCommon(Intent service, boolean requireForeground, UserHandle user) {
    try {
        ...
        //
        ComponentName cn = ActivityManager.getService().startService(
                mMainThread.getApplicationThread(), service,
                service.resolveTypeIfNeeded(getContentResolver()), requireForeground,
                getOpPackageName(), getAttributionTag(), user.getIdentifier());
        ...
        return cn;
    } catch (RemoteException e) {
        throw e.rethrowFromSystemServer();
    }
}

上面代码调用ActivityManager.getService()获取到ActivityManagerService的代理类，并调用了startService方法，而startService方法的实现是在ActivityManagerService中
ActivityManager.getService()代码如下, 其中调用了ServiceManager.getService(Context.ACTIVITY_SERVICE)

@UnsupportedAppUsage
public static IActivityManager getService() {
    return IActivityManagerSingleton.get();
}

@UnsupportedAppUsage
private static final Singleton<IActivityManager> IActivityManagerSingleton =
    new Singleton<IActivityManager>() {
        @Override
        protected IActivityManager create() {
            final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
            final IActivityManager am = IActivityManager.Stub.asInterface(b);
            return am;
        }
    };

从不同角度看Binder定义

从IPC角度：Binder是Android中的一种跨进程通信方式，该通信方式在linux中没有，是Android独有；
从Android Driver层：Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder；
从Android Framework层：Binder是各种Manager（ActivityManager、WindowManager等）和相应xxxManagerService的桥梁；
从Android APP层：Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的 Binder对象，通过这个Binder对象，客户端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务
从 Server 进程的角度，Binder 指的是 Server 中的 Binder 实体对象；
从 Client 进程的角度，Binder 指的是对 Binder 代理对象，是 Binder 实体对象的一个远程代理
从传输过程的角度，Binder 是一个可以跨进程传输的对象；Binder 驱动会对这个跨越进程边界的对象对一点点特殊处理，自动完成代理对象和本地对象之间的转换。

参考

我是今阳，如果想要进阶和了解更多的干货，欢迎关注微信公众号 “今阳说” 接收我的最新文章

今阳

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
Android进阶笔记-5. IPC机制 & Binder 原理

IPC机制一次进程间通信至少包含两个进程，由于进程隔离机制的存在，通信双方必然需要借助 IPC（进程间通信，inter-Process Communication）来实现；Linux中的IPC机制种类管道（pipe）继承自Unix，半双工通信方式（数据只能在一个方向上流动）;原理：通信双方利用内存的共享文件来传递信息；信号（sinal）异步通信方式,软件层对中断机制的一种模拟,例如内核通知用户空间进程发生了哪些系统事件不适用于信息交换，适用于进程中断控制;信号量（semophore
复制链接

扫一扫