在Android系统中,每一个应用程序都是由一些Activity和Service组成的,一般Service运行在独立的进程中,而Activity有可能运行在同一个进程中,也有可能运行在不同的进程中。那么,不在同一个进程的Activity或者Service是如何通信的呢?这就是本文中要介绍的Binder进程间通信机制了。
我们知道,Android系统是基于Linux内核的,而Linux内核继承和兼容了丰富的Unix系统进程间通信(IPC)机制。有传统的管道(Pipe)、信号(Signal)和跟踪(Trace),这三项通信手段只能用于父进程与子进程之间,或者兄弟进程之间;后来又增加了命令管道(Named Pipe),使得进程间通信不再局限于父子进程或者兄弟进程之间;为了更好地支持商业应用中的事务处理,在AT&T的Unix系统V中,又增加了三种称为“System V IPC”的进程间通信机制,分别是报文队列(Message)、共享内存(Share
Memory)和信号量(Semaphore);后来BSD Unix对“System V IPC”机制进行了重要的扩充,提供了一种称为插口(Socket)的进程间通信机制。若想进一步详细了解这些进程间通信机制,建议参考Android学习启动篇一文中提到《Linux内核源代码情景分析》一书。
但是,Android系统没有采用上述提到的各种进程间通信机制,而是采用Binder机制,难道是因为考虑到了移动设备硬件性能较差、内存较低的特点?不得而知。Binder其实也不是Android提出来的一套新的进程间通信机制,它是基于OpenBinder来实现的。OpenBinder最先是由Be Inc.开发的,接着Palm Inc.也跟着使用。现在OpenBinder的作者Dianne Hackborn就是在Google工作,负责Android平台的开发工作。
前面一再提到,Binder是一种进程间通信机制,它是一种类似于COM和CORBA分布式组件架构,通俗一点,其实是提供远程过程调用(RPC)功能。从英文字面上意思看,Binder具有粘结剂的意思,那么它把什么东西粘结在一起呢?在Android系统的Binder机制中,由一系统组件组成,分别是Client、Server、Service Manager和Binder驱动程序,其中Client、Server和Service Manager运行在用户空间,Binder驱动程序运行内核空间。Binder就是一种把这四个组件粘合在一起的粘结剂了,其中,核心组件便是Binder驱动程序了,Service
Manager提供了辅助管理的功能,Client和Server正是在Binder驱动和Service Manager提供的基础设施上,进行Client-Server之间的通信。Service Manager和Binder驱动已经在Android平台中实现好,开发者只要按照规范实现自己的Client和Server组件就可以了。说起来简单,做起难,对初学者来说,Android系统的Binder机制是最难理解的了,而Binder机制无论从系统开发还是应用开发的角度来看,都是Android系统中最重要的组成,因此,很有必要深入了解Binder的工作方式。要深入了解Binder的工作方式,最好的方式莫过于是阅读Binder相关的源代码了,Linux的鼻祖Linus
Torvalds曾经曰过一句名言RTFSC:Read The Fucking Source Code。
虽说阅读Binder的源代码是学习Binder机制的最好的方式,但是也绝不能打无准备之仗,因为Binder的相关源代码是比较枯燥无味而且比较难以理解的,如果能够辅予一些理论知识,那就更好了。闲话少说,网上关于Binder机制的资料还是不少的,这里就不想再详细写一遍了,强烈推荐下面两篇文章:
Android深入浅出之Binder机制
Android Binder设计与实现 – 设计篇
Android深入浅出之Binder机制一文从情景出发,深入地介绍了Binder在用户空间的三个组件Client、Server和Service Manager的相互关系,Android Binder设计与实现一文则是详细地介绍了内核空间的Binder驱动程序的数据结构和设计原理。非常感谢这两位作者给我们带来这么好的Binder学习资料。总结一下,Android系统Binder机制中的四个组件Client、Server、Service Manager和Binder驱动程序的关系如下图所示:
1. Client、Server和Service Manager实现在用户空间中,Binder驱动程序实现在内核空间中
2. Binder驱动程序和Service Manager在Android平台中已经实现,开发者只需要在用户空间实现自己的Client和Server
3. Binder驱动程序提供设备文件/dev/binder与用户空间交互,Client、Server和Service Manager通过open和ioctl文件操作函数与Binder驱动程序进行通信
4. Client和Server之间的进程间通信通过Binder驱动程序间接实现
5. Service Manager是一个守护进程,用来管理Server,并向Client提供查询Server接口的能力
至此,对Binder机制总算是有了一个感性的认识,但仍然感到不能很好地从上到下贯穿整个IPC通信过程,于是,打算通过下面四个情景来分析Binder源代码,以进一步理解Binder机制:
1. Service Manager是如何成为一个守护进程的?即Service Manager是如何告知Binder驱动程序它是Binder机制的上下文管理者。
2. Server和Client是如何获得Service Manager接口的?即defaultServiceManager接口是如何实现的。
3. Server是如何把自己的服务启动起来的?Service Manager在Server启动的过程中是如何为Server提供服务的?即IServiceManager::addService接口是如何实现的。
4 Service Manager是如何为Client提供服务的?即IServiceManager::getService接口是如何实现的。
在接下来的四篇文章中,将按照这四个情景来分析Binder源代码,都将会涉及到用户空间到内核空间的Binder相关源代码。这里为什么没有Client和Server是如何进行进程间通信的情景呢? 这是因为Service Manager在作为守护进程的同时,它也充当Server角色。因此,只要我们能够理解第三和第四个情景,也就理解了Binder机制中Client和Server是如何通过Binder驱动程序进行进程间通信的了。
为了方便描述Android系统进程间通信Binder机制的原理和实现,在接下来的四篇文章中,我们都是基于C/C++语言来介绍Binder机制的实现的,但是,我们在Android系统开发应用程序时,都是基于Java语言的,因此,我们会在最后一篇文章中,详细介绍Android系统进程间通信Binder机制在应用程序框架层的Java接口实现:
5.Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析。
在Android系统中,每一个应用程序都是由一些Activity和Service组成的,一般Service运行在独立的进程中,而Activity有可能运行在同一个进程中,也有可能运行在不同的进程中。那么,不在同一个进程的Activity或者Service是如何通信的呢?这就是本文中要介绍的Binder进程间通信机制了。
我们知道,Android系统是基于Linux内核的,而Linux内核继承和兼容了丰富的Unix系统进程间通信(IPC)机制。有传统的管道(Pipe)、信号(Signal)和跟踪(Trace),这三项通信手段只能用于父进程与子进程之间,或者兄弟进程之间;后来又增加了命令管道(Named Pipe),使得进程间通信不再局限于父子进程或者兄弟进程之间;为了更好地支持商业应用中的事务处理,在AT&T的Unix系统V中,又增加了三种称为“System V IPC”的进程间通信机制,分别是报文队列(Message)、共享内存(Share
Memory)和信号量(Semaphore);后来BSD Unix对“System V IPC”机制进行了重要的扩充,提供了一种称为插口(Socket)的进程间通信机制。若想进一步详细了解这些进程间通信机制,建议参考Android学习启动篇一文中提到《Linux内核源代码情景分析》一书。
但是,Android系统没有采用上述提到的各种进程间通信机制,而是采用Binder机制,难道是因为考虑到了移动设备硬件性能较差、内存较低的特点?不得而知。Binder其实也不是Android提出来的一套新的进程间通信机制,它是基于OpenBinder来实现的。OpenBinder最先是由Be Inc.开发的,接着Palm Inc.也跟着使用。现在OpenBinder的作者Dianne Hackborn就是在Google工作,负责Android平台的开发工作。
前面一再提到,Binder是一种进程间通信机制,它是一种类似于COM和CORBA分布式组件架构,通俗一点,其实是提供远程过程调用(RPC)功能。从英文字面上意思看,Binder具有粘结剂的意思,那么它把什么东西粘结在一起呢?在Android系统的Binder机制中,由一系统组件组成,分别是Client、Server、Service Manager和Binder驱动程序,其中Client、Server和Service Manager运行在用户空间,Binder驱动程序运行内核空间。Binder就是一种把这四个组件粘合在一起的粘结剂了,其中,核心组件便是Binder驱动程序了,Service
Manager提供了辅助管理的功能,Client和Server正是在Binder驱动和Service Manager提供的基础设施上,进行Client-Server之间的通信。Service Manager和Binder驱动已经在Android平台中实现好,开发者只要按照规范实现自己的Client和Server组件就可以了。说起来简单,做起难,对初学者来说,Android系统的Binder机制是最难理解的了,而Binder机制无论从系统开发还是应用开发的角度来看,都是Android系统中最重要的组成,因此,很有必要深入了解Binder的工作方式。要深入了解Binder的工作方式,最好的方式莫过于是阅读Binder相关的源代码了,Linux的鼻祖Linus
Torvalds曾经曰过一句名言RTFSC:Read The Fucking Source Code。
虽说阅读Binder的源代码是学习Binder机制的最好的方式,但是也绝不能打无准备之仗,因为Binder的相关源代码是比较枯燥无味而且比较难以理解的,如果能够辅予一些理论知识,那就更好了。闲话少说,网上关于Binder机制的资料还是不少的,这里就不想再详细写一遍了,强烈推荐下面两篇文章:
Android深入浅出之Binder机制
Android Binder设计与实现 – 设计篇
Android深入浅出之Binder机制一文从情景出发,深入地介绍了Binder在用户空间的三个组件Client、Server和Service Manager的相互关系,Android Binder设计与实现一文则是详细地介绍了内核空间的Binder驱动程序的数据结构和设计原理。非常感谢这两位作者给我们带来这么好的Binder学习资料。总结一下,Android系统Binder机制中的四个组件Client、Server、Service Manager和Binder驱动程序的关系如下图所示:
1. Client、Server和Service Manager实现在用户空间中,Binder驱动程序实现在内核空间中
2. Binder驱动程序和Service Manager在Android平台中已经实现,开发者只需要在用户空间实现自己的Client和Server
3. Binder驱动程序提供设备文件/dev/binder与用户空间交互,Client、Server和Service Manager通过open和ioctl文件操作函数与Binder驱动程序进行通信
4. Client和Server之间的进程间通信通过Binder驱动程序间接实现
5. Service Manager是一个守护进程,用来管理Server,并向Client提供查询Server接口的能力
至此,对Binder机制总算是有了一个感性的认识,但仍然感到不能很好地从上到下贯穿整个IPC通信过程,于是,打算通过下面四个情景来分析Binder源代码,以进一步理解Binder机制:
1. Service Manager是如何成为一个守护进程的?即Service Manager是如何告知Binder驱动程序它是Binder机制的上下文管理者。
2. Server和Client是如何获得Service Manager接口的?即defaultServiceManager接口是如何实现的。
3. Server是如何把自己的服务启动起来的?Service Manager在Server启动的过程中是如何为Server提供服务的?即IServiceManager::addService接口是如何实现的。
4 Service Manager是如何为Client提供服务的?即IServiceManager::getService接口是如何实现的。
在接下来的四篇文章中,将按照这四个情景来分析Binder源代码,都将会涉及到用户空间到内核空间的Binder相关源代码。这里为什么没有Client和Server是如何进行进程间通信的情景呢? 这是因为Service Manager在作为守护进程的同时,它也充当Server角色。因此,只要我们能够理解第三和第四个情景,也就理解了Binder机制中Client和Server是如何通过Binder驱动程序进行进程间通信的了。
为了方便描述Android系统进程间通信Binder机制的原理和实现,在接下来的四篇文章中,我们都是基于C/C++语言来介绍Binder机制的实现的,但是,我们在Android系统开发应用程序时,都是基于Java语言的,因此,我们会在最后一篇文章中,详细介绍Android系统进程间通信Binder机制在应用程序框架层的Java接口实现:
5.Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析。
分享到:
相关推荐
Android进程间通信(IPC)机制Binder简要介绍和学习计划
简要介绍Android IPC机制Binder
本文主要介绍 Android进程间通信(IPC)机制Binder简要介绍,这里介绍了Binder机制如何实现进程通信机制,有研究Android源码的朋友可以看下
上一篇文章Android进程间通信(IPC)机制Binder简要介绍和学习计划简要介绍了Android系统进程间通信机制Binder的总体架构,它由Client、Server、Service Manager和驱动程序Binder四个组件构成。本文着重介绍组件...
在前面一篇文章浅谈Service Manager成为Android进程间通信(IPC)机制Binder守护进程之路中,介绍了Service Manager... 在阅读本文之前,希望读者先阅读Android进程间通信(IPC)机制Binder简要介绍和学习计划一文提到
这是一个IPC进程间AIDL方式通信的简单Demo。...目的在于协助该博客讲解binder与service之间跨进程通信机制。所有大家读源码时务必同时读该博客。 http://blog.csdn.net/chenliqiang12345678/article/details/50487284
Binder通信机制说来简单,但是在使用的过程的遇到了一些问题,最后终于解决了,在这总结一下,一并分享给大家: 1、要使用Binder通信,首先要定义接口,然后实现服务端BnInterface***和客户端BpInterface***,说到底...
为什么Android非要用Binder来进行进程间通信呢.从我个人的理解角度,曾尝试着在知乎回答同样一个问题为什么Android要采用Binder作为IPC机制?.这是我第一次认认真真地在知乎上回答问题,收到很多网友的点赞与回复,让我...
Flying-PigeonFlying-Pigeon 是一个IPC跨进程通信组件,把跨进程通信简化到极致,并且突破binder 1MB内存大小限制。引入Gradleimplementation 'com.github.Justson:flying-pigeon:v1.0.7'方式一Serverprivate Api ...
>Android 进程间通信最牛方案,为简单而生 Github 源码: ABridge 一、介绍 做Android开发的小伙伴们是不是经常有遇到同一个公司有多个App,而这些App之间需要进行通信业务。于是需要解决这种IPC问题,而ABridge可...
AndroidStudio使用AIDL简单完成IPC,适合对Binder和AIDL不熟练的初学者学习机制
首先介绍 Android 序列化机制、Binder 工作原理,然后再通过创建 AIDL 进行进程间通信,一步步分析 AIDL 原理还有工作流程。前言在这里首先介绍 Android 序列化机制、Binder 主要是因为 AIDL 与这两个家伙密切相关,...
除了标准的Linux内核外,Android还增加了内核的驱动程序:Binder(IPC)驱动、显⽰驱动、输⼊设备驱 动、⾳频系统驱动、摄像头驱动、WiFi驱动、蓝⽛驱动、电源管理。 b) 程序库 (LIBRARIES) 程序库是指可供使⽤的各种...
对于研究Android C++层的Binder机制,了解IPC通信最简单例子
插件化代码的编写,涉及到的知识点主要有java中的反射,动态代理,静态代理以及android中的AIDL跨进程通信,binder机制,ClassLoader加载机制,四大组件的运行原理等等。本项目代码主要参考和。在此基础上做了大量的...
它也适用于BroadcastReceiver,但针对Service只有较少的覆盖,Service通常更加广泛地应用Binder接口而不是针对IPC的Intent。该工具只能针对一个Activity进行fuzz测试,一次不能针对所有的Activity进行测试。另外,也...
附件包含客户端demo和服务端demo共两个app,使用不超过100行代码,向你展示极简、傻瓜级AIDL使用教程,让你彻底玩转AIDL使用方法。 附件包含客户端demo和服务端demo,演示客户端app如何调用服务端app的接口方法。