binder

结合了以下两篇文章的介绍，对 Android 的 Binder 机制概念开始有了一定的理解。分享给大家。 -------------------------------------分割线--------------------------------- 摘要 Binder是android 中一个很重要且很复杂的概念，它在系统的整体运作中发挥着极其重要的作用，不过本文并不打算从深层次分析Binder机制，有两点原因：1是目前网上已经 有2篇很好的文章了，2是对Binder机制进行深入底层乃至驱动的分析这一过程相当困难且相当耗时，因此并不适合重复造轮子。本文的角度是对 Android的Binder机制从整体和概念上进行分析，能够让大家很快明白到底什么是Binder，Binder是干什么的，Binder和应用开发 的关系是什么，总之，这篇文章还是很值得去看一看的。 什么是Binder 1. 直观来说，Binder是Android中的一个类，它继承了IBinder接口 2. 从IPC角度来说，Binder是Android中的一种跨进程通信方式，Binder还可以理解为一种虚拟的物理设备，它的设备驱动是/dev/binder，该通信方式在linux中没有 3. 从Android Framework角度来说，Binder是ServiceManager连接各种Manager

红茶一杯话 Binder （传输机制篇_中） 侯 亮 1 谈谈底层IPC机制吧 在上一篇文章的最后，我们说到BpBinder将数据发到了Binder驱动。然而在驱动层，这部分数据又是如何传递到BBinder一侧的呢？这里面到底藏着什么猫腻？另外，上一篇文章虽然阐述了4棵红黑树，但是并未说明红黑树的节点到底是怎么产生的。现在，我们试着回答这些问题。 1.1 概述 在Binder驱动层，和ioctl()相对的动作是binder_ioctl()函数。在这个函数里，会先调用类似copy_from_user()这样的函数，来读取用户态的数据。然后，再调用binder_thread_write()和binder_thread_read()进行进一步的处理。我们先画一张调用关系图： binder_ioctl()调用binder_thread_write()的代码是这样的： if (bwr.write_size > 0) { ret = binder_thread_write(proc, thread, ( void __user *)bwr.write_buffer, bwr.write_size, &bwr.write_consumed); if (ret < 0) { bwr.read_consumed = 0; if (copy_to_user(ubuf, &bwr, sizeof

最近学习了一下Android里面的Service的应用，在BindService部分小卡了一下，主要是开始没有彻底理解为什么要这么实现。 BindService和Started Service都是Service，有什么地方不一样呢： 1. Started Service中使用StartService（）方法来进行方法的调用，调用者和服务之间没有联系，即使调用者退出了，服务依然在进行【onCreate()- >onStartCommand()->startService()->onDestroy()】，注意其中没有onStart()，主要是被onStartCommand()方法给取代了，onStart方法不推荐使用了。 2. BindService中使用bindService()方法来绑定服务，调用者和绑定者绑在一起，调用者一旦退出服务也就终止了【onCreate()->onBind()->onUnbind()->onDestroy()】。 调用者Activity： MainAcitvity package com.zys.service; import com.zys.service.BindService.MyBinder; import android.R.bool; import android.app.Activity; import android.content

最近学习了一下Android里面的Service的应用，在BindService部分小卡了一下，主要是开始没有彻底理解为什么要这么实现。 BindService和Started Service都是Service，有什么地方不一样呢： 1. Started Service中使用StartService（）方法来进行方法的调用，调用者和服务之间没有联系，即使调用者退出了，服务依然在进行【onCreate()- >onStartCommand()->startService()->onDestroy()】，注意其中没有onStart()，主要是被onStartCommand()方法给取代了，onStart方法不推荐使用了。 2. BindService中使用bindService()方法来绑定服务，调用者和绑定者绑在一起，调用者一旦退出服务也就终止了【onCreate()->onBind()->onUnbind()->onDestroy()】。 调用者Activity： MainAcitvity package com.zys.service; import com.zys.service.BindService.MyBinder; import android.R.bool; import android.app.Activity; import android.content

红茶一杯话 Binder （传输机制篇_上） 侯 亮 1 Binder 是如何做到精确打击的？ 我们先问一个问题，binder机制到底是如何从代理对象找到其对应的binder实体呢？难道它有某种制导装置吗？要回答这个问题，我们只能静下心来研究binder驱动的代码。在本系列文档的初始篇中，我们曾经介绍过ProcessState，这个结构是属于应用层次的东西，仅靠它当然无法完成精确打击。其实，在binder驱动层，还有个与之相对的结构，叫做binder_proc。为了说明问题，我修改了初始篇中的示意图，得到下图： 1.1 创建binder_proc 当构造ProcessState并打开binder驱动之时，会调用到驱动层的binder_open()函数，而binder_proc就是在binder_open()函数中创建的。新创建的binder_proc会作为一个节点，插入一个总链表（binder_procs）中。具体代码可参考kernel/drivers/staging/android/Binder.c。 驱动层的binder_open()的代码如下： static int binder_open( struct inode *nodp, struct file *filp) { struct binder_proc *proc; . . . . . . proc = kzalloc

Binder底层是基于C实现的，因此可以作为Native进程与App层交互数据的渠道。其应用场景为：Native Service、Hal驱动设置、应用层JNI服务等。 Android 4.4引入SEAndroid/SELinux 安全机制,至Android 5.0以后，Android完全采用此安全机制，对应用访问和操作文件权限进行限制，采用管道、共享内存、LocalSocket等方式进行跨进程交互面临着文件访问权限问题，若非修改固件源码的sepolicy文件(AOSP给定路径为/device/manufacturer/device-name/sepolicy)赋予进程文件访问权限，则可能会发生通讯失败。 采用Binder进行进程间通讯，是相对标准、优雅、高效的方式。 C端： 在Android7.0以下，需继承IInterface.h（路径在/frameworks/native/include/binder/IInterface.h),通过Parcel类（/frameworks/native/include/binder/IParcel.h）完成交互数据传递。Android 7.0以上，可采用HIDL语言定义接口，编译SO库时系统解析生成C代码。 Android端： 可通过AIDL语言定义交互接口，引用Framework.jar( compileOnly files('libs

为什么在Android中使用binder通信机制？ 众所周知linux中的进程通信有很多种方式,比如说管道、消息队列、socket机制等。socket我们再熟悉不过了，然而其作为一款通用的接口，通信开销大，数据传输效率低，主要用在跨网络间的进程间通信以及在本地的低速通信。消息队列和管道都是采用存储-转发模式，效率上面也有点低，因为这种模式的数据传输要经过两次的内存拷贝，先从发送方的缓存区拷贝到内核开辟的缓存区中，然后再从内核拷贝到接受方的缓存区。传统的ipc没有任何的安全措施，两个进程之间没有办法鉴别对方的身份，而在Android中，每个应用在安装后都会被分配一个uid，所以这个身份也有了保障，也更安全。为了保障安全和高效率，Android提供了一套全新的ipc通信机制也就是binder。 binder通信模型 一个进程间通信可以简单理解成为Client-server模式，binder机制在Android系统中的一个模型如下： Client获得到server端的proxy对象。 Client通过调用proxy对象的方法向server发送请求。 proxy对象通过binder设备节点，把Client请求信息发送到linux内核空间，由binder驱动获取并发送到服务进程。 服务进程处理Client请求，通过linux内核的binder驱动把结果返回给proxy对象。

瞻仰了前辈们的研究成果, 并掺入了自己的理解, 如有不对, 敬请批评. 为什么Android要使用Binder Binder 作为一种 IPC 机制, 在 Linux 内有很多的前辈, 为什么 google 会创建这么一种新的方式呢? Linux 现有 IPC 方式有这几类: 管道：在创建时分配一个page大小的内存，缓存区大小比较有限； 消息队列：信息复制两次，额外的CPU消耗；不合适频繁或信息量大的通信； 共享内存：无须复制，共享缓冲区直接付附加到进程虚拟地址空间，速度快；但进程间的同步问题操作系统无法实现，必须各进程利用同步工具解决； 套接字：作为更通用的接口，传输效率低，主要用于不通机器或跨网络的通信； 信号量：常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。 信号: 不适用于信息交换，更适用于进程中断控制，比如非法内存访问，杀死某个进程等； 与以上方式相比较, Binder 有以下特点: 性能较好: 数据拷贝 Binder 只需要一次, 管道/消息队列/socket 都需要两次, Binder 仅次于共享内存(一次都不需要); 稳定性较好: 基于C/S架构的Binder在逻辑上更加解耦, 架构清晰, 而共享内存容易出现各种并发同步死锁问题; 安全性好: Android每个App都有自己的UID

一个bound service是一个client-server接口中的server端。一个bound service允许应用组件(比如activities)bind到它，发送请求，接收响应，甚至是执行进程间通信(IPC)。一个bound service在典型情况下，只有在它服务于另一个应用组件时才存活，而不是在后台无限期的运行。 这份文档向您说明了要如何创建bound service，包括在其他的应用组件中如何bind到service。然而，你也应该参考Services文档来 大体地 了解关于services的额外信息，比如如何在service中传送通知，设置service在前台运行，等等。 基本概念 一个bound service是一个 Service 类的实现，它允许其它应用bind到它并与它交互。为了给一个service提供binding功能，你必须实现 onBind() 回调方法。这个方法返回一个 IBinder 对象，该对象则定义了客户端可以用来与service进行交互的编程接口。 Binding到一个Started Service 如同在 Services 文档中讨论的那样，你可以创建一个service，既可以被started，也可以被bound。即，service可以通过调用 startService() 被started，从而允许service无限期的运行

在android系统中，通过binder进行IPC时，服务端总是会起一些Binder线程来响应客户端的请求。如下面的这个设备上，system_process进程中就可以看到许多名为"Binder_X"的线程： 那这些Binder线程又是如何创建，如何管理的呢？而这些Binder线程本身又有些什么样的特点呢？在android的java app进程被创建起来时，它就会去建立一个线程池，来专门处理那些binder IPC事务。在frameworks/base/cmds/app_process/app_main.cpp中我们可以看到下面的这两个方法： virtual void onStarted() { sp<ProcessState> proc = ProcessState::self(); ALOGV("App process: starting thread pool.\n"); proc->startThreadPool(); AndroidRuntime* ar = AndroidRuntime::getRuntime(); ar->callMain(mClassName, mClass, mArgC, mArgV); IPCThreadState::self()->stopProcess(); } virtual void onZygoteInit() { // Re