Android之IPC4————Bander1 概述与Bander驱动

最新推荐文章于 2023-04-24 18:30:54 发布
最新推荐文章于 2023-04-24 18:30:54 发布
阅读量884 收藏 1
点赞数 2
分类专栏： Android 应用层 文章标签： android binder
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_38499859/article/details/83833539
版权

Android之IPC4————Bander1 概述与Bander驱动

文章目录

一.概述

最近才看AndroidIPC中，Binder一直是绕不过的坎，他是AndroidIPC很重要的一种方式，在Android系统中也有着举足轻重的作用。在之前的博客里，特别是AIDL中，我们只是说了AIDL实际上是实现的binder的接口。也在文章的最后简单说了一下，binder是如何进行数据通信的。但是由于Binder的封装，我还是没有发现，binder是如何做的跨进程通信的。

在这段时间里，我也是翻看了许多资料，也查看了许多博客。但是，多数博客，要不然讲的只是Frameworks层，要不然只是云里雾里长篇大论，要不然是很简单的描述了一下大体框架。

不过，后来发现一位大神的博客，跟着他的思考路看源码，从Driver层看到native层，再从native看到Frameworks层，看的脑袋很晕，但是收获也很大。所以想将看的过程记录下来，做一个学习笔记。

Binder系列—开篇

二.储备知识

在正式讲之前，先简单介绍一些基础知识

1.进程空间的划分

进程空间
每个Android的进程中，都只能运行在自己进程所拥有的虚拟地址空间，对应一个4GB的虚拟地址空间，其中3GB是用户空间，1GB是内核空间。当然两者的大小时可以进程跳转的。

用户空间：不同进程之间无法共享
内核空间: 不同进程之间可以共享

2.进程隔离和跨进程通信

进程隔离： 为了保证安全性和独立性，一个进程不能直接操作和访问另一个进程
进程间通信： 不同进程之间传递数据

3.Android的框架

让我们来看一看，Android的整体框架
android框架

从下往上依次为：

  • 内核层:Linux内核和各类硬件设备的驱动，BInderIPC驱动也就是在这一层
  • 硬件抽象层：封装内核层的硬件驱动，提供系统服务层统一的硬件接口
  • 系统层:提供核心服务，并且提供可供「应用程序框架层」调用的接口
  • BinderIPC层：作为系统服务层与应用程序框架的IPC桥梁，互相传递接口调用的数据，实现跨进层的停下
  • 应用程序框架层：这一层可以理解为 Android SDK，提供四大组件，View 绘制体系等平时开发中用到的基础部件

在上面的层次里，内核层与硬件抽象层均使用C/C++实现，系统服务是以Java实现，硬件层抽象编译为so文件，以jni的形式提供给系统服务层使用，系统服务层中的服务随系统的启动而启动，这些服务提供给手机诸如，短信接收，电话的接听，Activity的管理等等功能。每一个服务都运行在一个独立进程的Dalvik虚拟机中，那么问题来了，开发者的app运行在一个新的进程空间，如果调用系统服务层中的接口呢？答案就是ipc，而Android中大多数的ipc都是通过Binder实现的。

三.Binder概述

1.Binder是什么

Binder中文意思为粘合剂，意思是粘合了两个不同的进程

而在不同的语境下，Binder有不同的含义。

  • 从机制，模型来说,Binder是指Android中实现Ipc的一种方式。
  • 从模型的结构中来说,Binder来说是一种虚拟的物理层设备，即Binder驱动。
  • 从代码的角度来说，Binder是一个类，实现类IBInder接口。
2.Binder的优势

Android是基于linux的操作系统，而操作系统中已经有了多种IPC机制，为什么还要Binder机制?

看看Linux中现有的IPC机制：

  • 管道:在创建是分配一个page大小的内存，缓存区比较有限
  • 消息队列:信息复制两次，有额外的CPU消耗，不适合频繁或者信息量大的通信
  • 共享内存:无需复制，共享缓冲区直接付附加到进程虚拟地址空间，速度快；但进程间的同步问题操作系统无法实现，必须各进程利用同步工具解决；
  • socket：作为更通用的接口，传输效率低，主要用于不通机器或跨网络的通信；

多个角度说明为什么使用Binder：

  • 从性能上来说：Binder数据拷贝只需要一次，而管道，消息内存，Socket都需要两次，共享内存不需要。从性能上来说，Binder性能仅次于共享内存。
  • 从稳定性来说，Binder基于c/s架构，架构清晰，稳定性较好
  • 从安全性来说，Binder中，客户端和服务端通信时，会根据UID/PID进行一次安全检查
  • 从语言来说，linux中的机制都是基于c，也就是说面向过程。而android是基于Java,binder也正好是符合面向对象的思想。
3.Binder原理

binder通信采用C/S架构，从组件的角度来说，Binder分为Client，Service，ServiceManager，binder驱动。构架图如下：
binder

图中处理客户端和服务端外，还有两个角色，即ServiceManager和BInder驱动。下面分别简单介绍一下。

  • ServiceManager:此处的Service并非指framework层的，而是指Native层的。它是整个Binder通信机制的大管家。它的作用就是给服务端提供注册服务，给客户端提供获取服务的功能。
  • Binder驱动，binder驱动是一种虚拟字符设备，没有直接操作硬件。它的作用是连接服务端进程，客户端进程，ServiceManager的桥梁。它提供了4个方法。驱动设备的初始化(binder_init)，打开 (binder_open)，映射(binder_mmap)，数据操作(binder_ioctl)

图中出现了IPC时需要的三步，即：

  • 注册服务:Server进程要先注册Service到ServiceManager。该过程：Server是客户端，ServiceManager是服务端。
  • 获取服务:Client进程使用某个Service前，须先向ServiceManager中获取相应的Service。该过程：Client是客户端，ServiceManager是服务端。
  • 使用服务：Client根据得到的Service信息建立与Service所在的Server进程通信的通路，然后就可以直接与Service交互。该过程：client是客户端，server是服务端。

图中Client，Service，ServiceManager之间交互是虚线表示，但他们都处于不同的进程，所以他们之间并不是真正的交互，而是通过与Binder驱动进行交互，从而实现IPC通信方式。

4.Binder框架

上面的图主要是native层Binder的框架，下面的图是Binder在android中整体框架
在这里插入图片描述

  • 图中红色部分表示整个framwork层binder框架相关组件
  • 蓝色组件表示Native层Binder架构相关组件；
  • 上层framework层的Binder逻辑是建立在Native层架构基础之上的，核心逻辑都是交予Native层方法来处理。

Binder涉及的类
在这里插入图片描述

5. C/S模式

BpBinder(客户端)和BBinder(服务端)都是Android中Binder通信相关的代表，它们都从IBinder类中派生而来，关系图如下：

image

  • 客户端：BpBinder.transact()来发送事物请求
  • 服务端：BBinder.onTransact()会接收到相应事务。

四.Binder驱动

1.概述

Binder驱动是Android专用的，但底层的驱动框架和Linux驱动一样，binder驱动在以misc设备进行注册，作为虚拟字符设备，没有直接操作硬件，只是对设备内存的处理。主要操作有：

  • 通过init()创建/dev/binder设备节点
  • 通过open()获取Binder1驱动文件描述符
  • 通过mmap()在内核上分配一块内存，用于存放数据
  • 通过ioctl()将IPC数据作为参数传递给binder驱动
2.系统调用

用户态程序调用Kernel层驱动是需要陷入内核态，进行系统调用(syscall),比如调用Binder驱动方法调用链为：open-> __open() -> binder_open()。 open()为用户空间的方法，__open()便是系统调用中相应的处理方法，通过查找，对应调用到内核binder驱动的binder_open()方法，至于其他的从用户态陷入内核态的流程也基本一致。

简单来说，当用户空间调用open()方法，最终会调用binder驱动的binder_open()方法，mmap()/ioctl都是如此。

3.binder_open

binder_init的主要工作就是注册misc设备。并没有什么可说的，我们就直接从第二个方法来看。

binder_open()作用是打开binder驱动，并进行如下过程：

  • 创建binder_proc，将当前进程的信息保存保存在binder_porc对象总，该对象管理IPC所需的各种信息并具有其他结构体的根结构体，在把binder_proc对象保存到文件指针filp，以及把binder_proc加入到全局链表binder_procs。
  • binder_proc结构体中包含了进程节点，binder实体/引用/线程所组成红黑树的根节点，内存信息，线程信息等等
3. binder_mmap

主要功能：首先在内核虚拟地址空间中，申请一块与用户虚拟内存大小相同的内存。在申请一个page大小的物理内存，再讲同一块物理内存分别映射到内核虚拟地址空间个用户虚拟内存空间，从而实现了用户空间的Buffer和内核空间的Buffer同步操作的功能。最后创建一块Binder_buffer对象，并放入当前binder_proc的proc->buffers链表。

内存机制

上图就是，使用mmap后的内存机制，虚拟进程地址空间(vm_area_struct))和虚拟内核地址空间(vm_struct)都映射到同一块物理内存空间。当客户端和服务端发送数据是，客户端先从自己的进程空间吧ipc通信数据复制到内核空间，而Server端作为数据接受端与内核共享数据，所以不需要在拷贝数据，而是通过内存地址的偏移量，即可获得内存地址。整个过程只发送一次内存复制。

比较关注的一个点就在，在这其中，空闲的内存块和已用的内存块都是用红黑树记录的。

4.binder_ioctl

binder_ioctl()函数负责在两个进程间收发IPC数据和IPC reply数据

ioctl(文件描述符，ioctl命令，数据类型)

  • 文件描述符：是通过open()方法打开的binder内核后的返回层。
  • ioctl命令

header 1 | header 2

row 1 col 1 | row 1 col 2
row 2 col 1 | row 2 col 2

ioctl命令数据类型操作使用场景
BINDER_WRITE_READstruct binder_write_read收发Binder IPC数据binder读写交互场景
BINDER_SET_MAX_THREADS__u32设置Binder线程最大个数初始化ProcessState对象，初始化ProcessState对象
BINDER_SET_CONTEXT_MGR__s32设置Service Manager节点servicemanager进程成为上下文管理
BINDER_THREAD_EXIT__s32释放Binder线程
BINDER_VERSIONstruct binder_version获取Binder版本信息初始化ProcessState
BINDER_SET_IDLE_TIMEOUT__s64没有使用
BINDER_SET_IDLE_PRIORITY__s32没有使用

这一块，简单介绍了binder内核，包括binder内核提供的四个方法和binder是什么。更详细的内容，深入到源码层的分析可以查看文章：Binder系列1—Binder Driver初探

五.启动ServiceManager

接下来来看binder机制另一个很重要的角色，ServiceManager是客户端和服务端沟通的桥梁。首先看看ServiceManager的启动。

ServiceManager是通过init进程通过解析init.rc文件，而创建的，所对应的可执行程序/system/bin/servicemanager，所对应的源文件是service_manager.c，进程名为/system/bin/servicemanager。

1.启动过程

启动Service Manager的入口函数是service_manager.c中的main()方法，代码如下：

int main(int argc, char **argv) {
    struct binder_state *bs;
    //打开binder驱动，申请128k字节大小的内存空间 
    bs = binder_open(128*1024);
    ...

    //成为上下文管理者 
    if (binder_become_context_manager(bs)) {
        return -1;
    }

    selinux_enabled = is_selinux_enabled(); //selinux权限是否使能
    sehandle = selinux_android_service_context_handle();
    selinux_status_open(true);

    if (selinux_enabled > 0) {
        if (sehandle == NULL) {  
            abort(); //无法获取sehandle
        }
        if (getcon(&service_manager_context) != 0) {
            abort(); //无法获取service_manager上下文
        }
    }
    ...

    //进入无限循环，处理client端发来的请求 
    binder_loop(bs, svcmgr_handler);
    return 0;
}

由上面的代码可以看到，启动过程主要涉及以下几个阶段：

  • 打开binder驱动 binder_open
  • 注册成为binder服务的大管家：binder_become_context_manager；
  • 进入死循环，处理client端发来的请求：binder_loop

我们一点点来看

2.打开binder驱动
struct binder_state *binder_open(size_t mapsize)
{
    struct binder_state *bs;【见小节2.2.1】
    struct binder_version vers;

    bs = malloc(sizeof(*bs));
    if (!bs) {
        errno = ENOMEM;
        return NULL;
    }

    //通过系统调用陷入内核，打开Binder设备驱动
    bs->fd = open("/dev/binder", O_RDWR);
    if (bs->fd < 0) {
        goto fail_open; // 无法打开binder设备
    }

     //通过系统调用，ioctl获取binder版本信息
    if ((ioctl(bs->fd, BINDER_VERSION, &vers) == -1) ||
        (vers.protocol_version != BINDER_CURRENT_PROTOCOL_VERSION)) {
        goto fail_open; //内核空间与用户空间的binder不是同一版本
    }

    bs->mapsize = mapsize;
    //通过系统调用，mmap内存映射，mmap必须是page的整数倍
    bs->mapped = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, bs->fd, 0);
    if (bs->mapped == MAP_FAILED) {
        goto fail_map; // binder设备内存无法映射
    }

    return bs;

fail_map:
    close(bs->fd);
fail_open:
    free(bs);
    return NULL;
}

打开binder驱动的先关操作：

先调用open()打开binder设备，open即上一节所说的binder内核提供的方法之一，最终会调用binder内核中的binder_open()，其方法作用间上一节.

之后调用mmap()方法进行内存映射。

3.注册成为binder服务的大管家
int binder_become_context_manager(struct binder_state *bs) {
    //通过ioctl，传递BINDER_SET_CONTEXT_MGR指令【见小节2.3.1】
    return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);
}

在这里面用过调用ioctl方法，发送 BINDER_SET_CONTEXT_MGR，最终经过系统调用，进入binder驱动层的binder_ioctl()方法.

static int binder_ioctl_set_ctx_mgr(struct file *filp)
{
    int ret = 0;
    struct binder_proc *proc = filp->private_data;
    kuid_t curr_euid = current_euid();

    //保证只创建一次mgr_node对象
    if (binder_context_mgr_node != NULL) {
        ret = -EBUSY; 
        goto out;
    }

    if (uid_valid(binder_context_mgr_uid)) {
        ...
    } else {
        //设置当前线程euid作为Service Manager的uid
        binder_context_mgr_uid = curr_euid;
    }

    //创建ServiceManager实体
    binder_context_mgr_node = binder_new_node(proc, 0, 0);
    ...
    binder_context_mgr_node->local_weak_refs++;
    binder_context_mgr_node->local_strong_refs++;
    binder_context_mgr_node->has_strong_ref = 1;
    binder_context_mgr_node->has_weak_ref = 1;
out:
    return ret;
}

创建一个ServiceManager实体

static struct binder_node *binder_new_node(struct binder_proc *proc,
                       binder_uintptr_t ptr,
                       binder_uintptr_t cookie)
{
    struct rb_node **p = &proc->nodes.rb_node;
    struct rb_node *parent = NULL;
    struct binder_node *node;
    //首次进来为空
    while (*p) {
        parent = *p;
        node = rb_entry(parent, struct binder_node, rb_node);

        if (ptr < node->ptr)
            p = &(*p)->rb_left;
        else if (ptr > node->ptr)
            p = &(*p)->rb_right;
        else
            return NULL;
    }

    //给新创建的binder_node 分配内核空间
    node = kzalloc(sizeof(*node), GFP_KERNEL);
    if (node == NULL)
        return NULL;
    binder_stats_created(BINDER_STAT_NODE);
    
 
    rb_link_node(&node->rb_node, parent, p);
    rb_insert_color(&node->rb_node, &proc->nodes);
    node->debug_id = ++binder_last_id;
    
    node->proc = proc; //将open操作中创建的的proc赋值
    node->ptr = ptr; //指向用户空间binder_node的指针
    node->cookie = cookie;
    node->work.type = BINDER_WORK_NODE; //设置binder_work的type
    INIT_LIST_HEAD(&node->work.entry);
    INIT_LIST_HEAD(&node->async_todo);
    return node;
}

在这里面，在binder中创建ServiceManager实体()。并在创建是，将open操作中创建的proc，存入ServiceManager的proc中。

4.进入死循环中
void binder_loop(struct binder_state *bs, binder_handler func) {
    int res;
    struct binder_write_read bwr;
    uint32_t readbuf[32];

    bwr.write_size = 0;
    bwr.write_consumed = 0;
    bwr.write_buffer = 0;

    readbuf[0] = BC_ENTER_LOOPER;
    //将BC_ENTER_LOOPER命令发送给binder驱动，让Service Manager进入循环 
    binder_write(bs, readbuf, sizeof(uint32_t));

    for (;;) {
        bwr.read_size = sizeof(readbuf);
        bwr.read_consumed = 0;
        bwr.read_buffer = (uintptr_t) readbuf;

        //通过ioctl向binder驱动发起读写请求
        res = ioctl(bs->fd, BINDER_WRITE_READ, &bwr); //进入循环，不断地binder读写过程
        if (res < 0) {
            break;
        }

        // 解析binder信息 
        res = binder_parse(bs, 0, (uintptr_t) readbuf, bwr.read_consumed, func);
        if (res == 0) {
            break;
        }
        if (res < 0) {
            break;
        }
    }
}

解析Binder信息

...
//初始化reply
     bio_init(&reply, rdata, sizeof(rdata), 4);
     
//从txn解析binder_io
      bio_init_from_txn(&msg, txn);
      
//调用Service_manager中的svcmgr_handler，进行它的工作
res = func(bs, txn, &msg, &reply);

binder_send_reply(bs, &reply, txn->data.ptr.buffer, res);
...

根据binder驱动返回的信息进行相应的操作

int svcmgr_handler(struct binder_state *bs,
                   struct binder_transaction_data *txn,
                   struct binder_io *msg,
                   struct binder_io *reply)
{
 .....

    switch(txn->code) {
    case SVC_MGR_GET_SERVICE:
    case SVC_MGR_CHECK_SERVICE: //查找
        s = bio_get_string16(msg, &len); //服务名
        //根据名称查找相应服务 
        handle = do_find_service(bs, s, len, txn->sender_euid, txn->sender_pid);
        //【见小节3.1.2】
        bio_put_ref(reply, handle);
        return 0;

    case SVC_MGR_ADD_SERVICE: //注册
        s = bio_get_string16(msg, &len); //服务名
        handle = bio_get_ref(msg); //handle
        allow_isolated = bio_get_uint32(msg) ? 1 : 0;
         //注册指定服务 
        if (do_add_service(bs, s, len, handle, txn->sender_euid,
            allow_isolated, txn->sender_pid))
            return -1;
        break;

    case SVC_MGR_LIST_SERVICES: {  
        uint32_t n = bio_get_uint32(msg);

        if (!svc_can_list(txn->sender_pid)) {
            return -1;
        }
        si = svclist;
        while ((n-- > 0) && si)
            si = si->next;
        if (si) {
            bio_put_string16(reply, si->name);
            return 0;
        }
        return -1;
    }
    default:
        return -1;
    }

    bio_put_uint32(reply, 0);
    return 0;
}

总结：在这个循环里，ServiceManager通过ioctl向binder驱动发起读写请求,根据请求返回的数据，去进行相应的注册服务和查询服务。

六.总结

本篇文章中，先简单介绍了一些操作系统中关于跨进程通信的基础知识，之后介绍了binder的优势以及binder的框架。

然后介绍了binder内核，主要介绍了binder内核提供的4个方法

  • init()注册misc设备
  • open()打开binder驱动。并创建binder_proc,并保存在全局链表中
  • mmap()在内存中分配一块内存，用于存放数据，实现是采用的是内存映射机制，将内核和Service映射在同一块物理地址中
  • ioctl()负责在两个进程间传递转发ipc数据和回复数据

之后介绍了ServiceManager的启动，ServiceManager是通过init进程加载init.rc文件而创建的，创建步骤如下：

  • 首先调用open()打开binder驱动，并调用mmap()申请128k字节大小的内存空间。
  • 之后使用ioctl发送BINDER_SET_CONTEXT_MGR，成为Service的管家，在这里会在binder内核中创建一个ServiceManager实体，该实体是内核全局变量，并把open操作中创建的proc，放入该实体中。
  • 最后会启动一个死循环，在这个循环中，ServiceManager通过ioctl不断从binder内核中读写数据，并根据信息进行相应的操作，即注册服务，获取服务。

之后的文章：

  • BinderNative层分析
  • Binderframework层的分析
  • Binder通信过程
  • Binder线程池
  • Binder的使用
  • Binder总结

七.参考资料

Binder系列—开篇
Binder系列3—启动ServiceManager
Android跨进程通信：图文详解 Binder机制 原理
轻松理解 Android Binder，只需要读这一篇

冰炭不投day
关注
专栏目录
Android Binder——基础简介（一）
小旭的专栏
10-21 286
Binder 是 Android 系统中的一种进程间通信（IPC）机制，用于实现不同进程之间的通信和数据传递。它是一种高效、安全和稳定的机制，被广泛应用于 Android 系统中的各种组件和服务，包括 Activity、Service、ContentProvider 等。
Android IPC机制（二）用Messenger进行进程间通信
Android进阶三部曲 - 刘望舒
01-03 7436
本来想写Binder的，笔者很多年前研究Android Native Framework时才了解到的，实话说对应用层的开发帮助不大，网上文章也比较多，如果想了解可以参考Android Bander设计与实现 - 设计篇这篇文章。另外在看这篇文章前最好看一下本文章的前篇Android IPC机制（一）开启多进程。 首先我们先写服务端(MessengerService.java)，在onBind方法
Android Bander设计与实现 - 设计篇
热门推荐
universus的专栏
02-27 19万+
关键词 Binder Android IPC Linux 内核 驱动 摘要 Binder是Android系统进程间通信（IPC）方式之一。Linux已经拥有管道，system V IPC，socket等IPC手段，却还要倚赖Binder来实现进程间通信，说明Binder具有无可比拟的优势。深入了解Binder并将之与传统IPC做对比有助于我们深入领会进程间通信的实现和性能优化。本文将对Binder的设计细节做一个全面的阐述，首先通过介绍Binder通信模型和Binder通信协议了解Binder的设计
linux管道
周翔的专栏
09-24 1137
管道是单向的字节流，它将某个进程的标准输出连接到另一个进程的标准输入。管道和有名管道是最早的进程间通信机制之一，管道可用于具有亲缘关系进程间的通信，有名管道克服了管道没有名字的限制，因此，除具有管道所具有的功能外，它还允许无亲缘关系进程间的通信。管道和有名管道的读写规则是在程序中应用它们的关键。  管道相关的概念    在linux中管道是通过指向同一个临时的VFS inode的两个file数
android bander
最新发布
01-24
Android Bander是一个用于Android平台的广告管理工具。它可以帮助开发者有效地管理应用中的广告资源，从而更好地实现广告的展示和收益最大化。Android Bander具有以下几个主要特点： 首先，Android Bander可以方便...
Bander进程间通讯
weixin_44389338的博客
08-18 656
Bander进程间通讯（浅讲）
Android Bander设计与实现
geekCode
10-12 333
关键词 Binder Android IPC Linux 内核 驱动 摘要 Binder是Android系统进程间通信（IPC）方式之一。Linux已经拥有管道，system V IPC，socket等IPC手段，却还要倚赖Binder来实现进程间通信，说明Binder具有无可比拟的优势。深入了解Binder并将之与传统IPC做对比有助于我们深入领会进程间...
写给 Android 应用工程师的 Binder 原理剖析
weixin_34174132的博客
04-10 1380
一. 前言 这篇文章我酝酿了很久，参考了很多资料，读了很多源码，却依旧不敢下笔。生怕自己理解上还有偏差，对大家造成误解，贻笑大方。又怕自己理解不够透彻，无法用清晰直白的文字准确的表达出 Binder 的设计精髓。直到今天提笔写作时还依旧战战兢兢。 Binder 之复杂远远不是一篇文章就能说清楚的，本文想站在一个更高的维度来俯瞰 Bind...
【Android】Binder机制在Android中的原理和使用
偶素雾霾的博客
04-24 1566
Binder机制运用的是一个C/S(Client/Server)架构,客户端进程发送请求,服务端进程接收请求并返回结果。Binder机制的实现是基于Linux的Binder驱动,Binder驱动可以理解为一个消息传递的通道,各个进程通过读取和写入这个通道来实现跨进程通信。当Client进程调用Server中的binder方法时,Binder驱动会将这个方法调用转换成一条Binder消息,这条消息会发送到Server进程。
Android Binder的原理与使用
QG
08-25 2000
Android Binder的原理与使用
Android中的binder机制详解
QG
08-25 4206
Android中的binder机制详解
Android mmap+Binder机制
zenmela2011的专栏
06-14 2790
1.Binder ①Binder是什么？ 机制：Binder是一种进程间通信的机制 驱动：Binder是一个虚拟物理设备驱动 应用层：Binder是一个能发起进程间通信的JAVA类 Binder就是Android中的血管，在Android中使用Activity、Service等组件时都需要和AMS（system_server）进行通信，这种跨进程的通信都是通过Binder完成。 Activity、Service等组件和AMS不是同一个进程，其实也是多进程通信。 ②为什么要用多进程？ 虚拟机给
一篇文章了解相见恨晚的 Android Binder 进程间通讯机制
jeanboy
04-11 7万+
Android-Binder进程间通讯机制 概述 最近在学习Binder机制，在网上查阅了大量的资料，也看了老罗的Binder系列的博客和Innost的深入理解Binder系列的博客，都是从底层开始讲的，全是C代码，虽然之前学过C和C++，然而各种函数之间花式跳转，看的我都怀疑人生。毫不夸张的讲每看一遍都是新的内容，跟没看过一样。后来又看到了Gityuan的博客看到了一些图解仿佛发现了新大...
【Android进阶】浅析Android Binder机制
大圣代的技术专栏
03-03 1万+
APP内存的使用，是评价一款应用性能高低的一个重要指标。虽然现在智能手机的内存越来越大，但是一个好的应用应该将效率发挥到极致，精益求精。本文是【Android 性能优化】系列的第二篇文章，我们在第一篇【Android 性能优化】—— UI篇中主要介绍了Android界面的优化的原理以及方法，这一篇中我们将着重介绍Android的内存优化。本文的篇幅很长，但是请不要嫌烦
Android Binder原理从开始到放弃
三木仔
01-02 5754
Binder是Android系统IPC通信的一块基石，不管是AMS、WMS都可以看到Binder 的身影，如果搞不清楚的话，看Android源码的时候就会搞不清，比如为什么需要各种代理？怎么突然就跳跃了？ Binder内部细节太多了，然后个人只想搞清楚整体的机制而又不想深究内部的细节。不过一些东西又必须要弄清楚，比如IBinder、BBinder、BPBinder、Binder Proxy、ServiceManager等，所以尽可能以流程图的形式帮助理解，但是也包含一些关键数据结构。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值