Android是如何实现跨进程通信的,大家熟悉的Binder是什么,怎么设计的,进程间的数据如何发送接收的。本文将以及解析,并对Binder驱动实现、Native层实现、Java层实现三块做一个总结分析。
昨天正好有一个网友和我讨论一个问题,他给我看下面这个图,我说这个应该是Android 8.0以及之前版本的流程图。
Android 内核源码地址 : https://android.googlesource.com/kernel/
Android系统的成功离不开其强大的IPC(Inter-Process Communication)机制,其中最引人注目的就是Binder。本文将深入探讨Binder的技术原理,解释其工作方式以及相关的关键概念。
从整体架构以及通信协议的角度来阐述了Binder架构。那对于binder线程是如何管理的呢,又是如何创建的呢?其实无论是system_server进程,还是app进程,都是在进程fork完成后,便会在新进程中执行onZygoteInit()的过程中,启动binder线程池。
我们在使用binder时候的大致流程是先获取servicemanger的binder,然后通过该binder获取目标服务的binder,最后调用该binder的接口。本篇就介绍下第一步的内容,涉及了从native到驱动,fwk部分先不涉及,希望可以完全理解servicemanager的获取流程。
Binder可以说是整个Android框架最重要的一个基础。如果不能吃透Binder,就谈不上对Android有多么深刻的理解。这个道理相信大部分Android开发者都清楚。但是Binder整个框架又看起来好像深不可测,上至Java,下至kernel。又横跨众多进程和服务。想看看源代码来学习。看着看着就看不明白了,不由得发出“我是谁?我在哪里?”这样的疑问。这篇文章就想从作者个人的经验来聊聊如何学习Binder。
之前看过一篇关于Binder设计相关的文章,但是之前的连接打不开了。于是在网上搜索很久才找到原文地址:https://blog.csdn.net/universus/article/details/6211589。这篇文章写得非常好,建议在学习Binder的小伙伴都可以保存下来多读几遍。唯一有点瑕疵的就是,这篇文章可能是作者翻译的,有些语法读起来不是很通顺。这里也自己记录一份,顺便做些标记,方便以后复习,也防止以后找不到。
ServiceManager是Binder IPC通信过程中的守护进程,本身也是一个Binder服务,但并没有采用libbinder中的多线程模型来与Binder驱动通信,而是自行编写了binder.c直接和Binder驱动来通信,并且只有一个循环binder_loop来进行读取和处理事务,这样的好处是简单而高效。
Binder机制在Android中的地位举足轻重,是用于通信的机制,我们需要掌握的很多原理都和Binder有关。其中系统服务的获取过程也与Binder有关。获取系统服务前需要了解ServiceManager的启动过程,这样更有助于理解系统服务的注册过程和获取过程。
在Android领域,Binder作为进程间通信的核心机制,是每位Android技术人员都应该深入了解的重要知识点。本文将从面试官的角度出发,围绕Android Binder展开一系列高级疑难问题。通过问题分析与问题简答,旨在帮助大家更好的理解Binder,并在面试中游刃有余。
今天完成了 王小二图解Android【010】Binder应用篇的直播,说实话这次我只能给自己打一个59分数。回去我在不断思考,最后觉得这个Binder培训就根本不应该采用1对多的培训模式,其实我在昨晚就给一个毕业半年左右的网友一对一的试讲过,中途我们会不断地交流,给他补了很多知识,最后效果我觉得有85分。 但是今天一整天我一直心有不甘,我觉得还是有必要为自己今天的直播课上一个补课。
本文主要分析ServiceManager系统服务管理进程对binder的管理流程。
当service经常被远程调用时,我们经常常使用到aidl来定一个接口供service和client来使用,这个事实上就是使用Binder机制的IPC通信。当client bind service成功之后,系统AM会调用回调函数onServiceConnected将service的IBinder传递给client, client再通过调用aidl生成的asInterface()方法获得service的调用接口,此时一个bind过程结束了,我们在client端就能够远程调用service的方法了。比如
本篇是第二篇,主要是涉及线程与进程的唤醒,数据传输的封装与解析, Binder线程的睡眠与唤醒(请求线程睡在哪个等待队列上,唤醒目标端哪个队列上的线程) Binder协议中BC与BR的区别 Binder在传输数据的时候是如何层层封装的--不同层次使用的数据结构(命令的封装) Binder驱动传递数据的释放(释放时机) 一个简单的Binder通信C/S模型 Client端线程睡眠在哪个队列上,唤醒Server端哪个等待队列上的线程 先看第一部分:发送端线程睡眠在哪个队列上? 发送端线程一定睡眠在自己binde
原本是没有这篇文章的,因为原来写Binder的时候没打算写Binder驱动,不过我发现后面大量的代码都涉及到了Binder驱动,如果不讲解Binder驱动,可能会对大家理解Binder造成一些折扣,我后面还是加上了这篇文章。主要内容如下:
先复制一段来自于android官方文档的文字 https://source.android.google.cn/devices/architecture/hidl/binder-ipc
Binder 是 Android 系统的进程间通信机制,是了解 Android 运行机制必须要掌握的一个知识点,更是一线企业面试必问的知识点!比如:
经过前面三章的学习,各位对Binder框架,AIDL机制已经有一个宏观的概念了,更多的细节,各位需要自己再去研究,推荐老罗的《Android系统源代码情景分析》,市面上讲Binder讲的组好的书,没有之一,这一篇也是完结篇,我眼中的Binder
1、什么是Binder? 直观来说,Binder是Android中的一个类,它继承了IBinder接口。 从IPC角度来说,Binder是Android中的一种跨进程通信方式,Binder还可以理解为一种虚拟的物理设备,它的设备驱动是/dev/binder,该通信方式在linux中没有。 从Android Framework角度来说,Binder是ServiceManager连接各种Manager(ActivityManager、WindowManager,etc)和相应ManagerService的桥梁。
上图是一次binder调用的通信流程,Client是应用进程,Server是系统服务,应用进程通过binder调用请求系统服务,Client向binder驱动发送BC_Transaction指令,binder在收到该指令指令之后回向Client返回BR_Transaction_Complete指令,同时binder驱动会向系统服务发送BR_Transaction指令,并等待系统服务的处理,系统服务处理完成之后会向binder发送BC_Reply的回持,binder驱动在收到系统服务的回执之后,也会向系统服务发送BR_Transation_Complete的回执,同时向应用进程发送BR_Reply,将处理结果发送给应用进程。
应用程序中执行 getService() 需与 ServiceManager 通过 binder 跨进程通信,此过程中会贯穿 Framework、Natve 层以及 Linux 内核驱动。
binder_transaction堆栈及唤醒那个队列 Binder承担了绝大部分Android进程通信的职责,可以看做是Android的血管系统,负责不同服务模块进程间的通信。在对Binder的理解上,可大可小,日常APP开发并不怎么涉及Binder通信知识,最多就是Service及AIDL的使用会涉及部分Binder知识。Binder往小了说可总结成一句话:一种IPC进程间通信方式,负责进程A的数据,发送到进程B。往大了说,其实涉及的知识还是很多的,如Android 对于原Binder驱动的扩展、Zyg
由于服务注册会涉及到具体的服务注册,网上大多数说的都是Media注册服务,我们也说它。
在上一篇博客 【Binder 机制】Native 层 Binder 机制分析 ( service_manager.c | 开启 Binder | 注册 Binder 进程上下文 | 开启 Binder 循环 ) 中分析了 Binder Native 实现中的 service_manager.c 中的 main 函数的启动过程 ;
Binder机制是 Android系统中进程间通讯(IPC)的一种方式,Android中ContentProvider、Intent、aidl都是基于Binder。
这篇文章会先对照Binder机制与Linux的通信机制的区别,了解为什么Android会另起炉灶,採用Binder。接着,会依据Binder的机制,去理解什么是Service Manager,在C/S模型中扮演什么角色。最后,会从一次完整的通信活动中,去理解Binder通信的过程。
这篇文章我酝酿了很久,参考了很多资料,读了很多源码,却依旧不敢下笔。生怕自己理解上还有偏差,对大家造成误解,贻笑大方。又怕自己理解不够透彻,无法用清晰直白的文字准确的表达出 Binder 的设计精髓。直到今天提笔写作时还依旧战战兢兢。
承接Binder: addService初探这篇文章,我们已经知道Client端通过BpBinder的transact方法与service端进行通信,在BpBinder的transact方法中又通过IPCThreadState的transact方法将数据传递到service端。
binder通信是一种client-server的通信结构, 1.从表面上来看,是client通过获得一个server的代理接口,对server进行直接调用; 2.实际上,代理接口中定义的方法与server中定义的方法是一一对应的; 3.client调用某个代理接口中的方法时,代理接口的方法会将client传递的参数打包成为Parcel对象; 4.代理接口将该Parcel发送给内核中的binder driver. 5.server会读取binder driver中的请求数据,如果是发送给自己的,解包Parcel对象,处理并将结果返回; 6.整个的调用过程是一个同步过程,在server处理的时候,client会block住。
大家都知道App进程是AMS通过通过Socket通信通知Zygote孵化出来的,借用gityuan的图就是图中的第2步,能否用Binder通信替换Socket通信?我们只讨论技术上实现的可能性,不讨论两者性能上的差异。
众所周知,Binder是Android系统中最主要的进程间通信套件,更具体一点,很多文章称之为Binder驱动,那为什么说它是一个驱动呢,驱动又是何物,让我们自底向上,从内核中的Binder来一步步揭开它的面纱。本文重点在帮助读者对于Binder系统有一个简略的了解,所以写得比较笼统,后续文章会详细分析。
binder_node 代表的是Binder实体对象,每一个service组件或者ServiceManager在Binder驱动程序中的描述,Binder驱动通过强引用和弱引用来维护其生命周期,通过node找到空间的Service对象
要看得懂android代码,首先要了解binder机制。binder机制也是android里面比较难以理解的一块,这里记录一下binder的重要概念以及实现,作为备忘。部分内容来源于网上,如有侵权,请及时告知。 1.binder通信机制概述 binder通信是一种client-server的通信结构, 1.从表面上来看,是client通过获得一个server的代理接口,对server进行直接调用; 2.实际上,代理接口中定义的方法与server中定义的方法是一一对应的; 3.client调用某个代理接口中的
毫不夸张地说,Binder是Android系统中最重要的特性之一;正如其名“粘合剂”所喻,它是系统间各个组件的桥梁,Android系统的开放式设计也很大程度上得益于这种及其方便的跨进程通信机制。
Spring Cloud Stream是一个用于构建基于消息传递的微服务应用程序的框架。它通过抽象出消息传递中的常见概念,例如消息通道和消息处理器,使得开发者可以更加容易地开发和维护基于消息传递的应用程序。在Spring Cloud Stream中,Binder是连接应用程序和消息中间件之间的适配器。本文将介绍如何定义和使用自定义Binder。
Binder是Android系统进程间通信(IPC)方式之一。Linux已经拥有的进程间通信IPC手段包括(Internet Process Connection): 管道(Pipe)、信号(Signal)和跟踪(Trace)、插口(Socket)、报文队列(Message)、共享内存(Share Memory)和信号量(Semaphore)。本文详细介绍Binder作为Android主要IPC方式的优势。 Binder机制概述: 基于Client-Server的通信方式广泛应用于从互联网和数据库访问到嵌
继介绍性能设计概述、性能优化建议后,本文将重点介绍影响性能的不良实现,主要包含Binder共享内存耗尽、Binder线程池耗尽、创建大量BpBinder或Binder对象等方面。
Init 进程 启动 Zygote , Zygote 启动 System Server 进程 ;
servicemanager是android中binder服务的管家,一般binder服务会先注册到servicemanager中,然后其他客户端会通过servicemanager来获取目标binder的proxy binder,这时候就可以通过获取的proxy binder进行ipc调用了,本篇介绍下servicemanager的工作流程。
之前一直对 Binder 理解不够透彻,仅仅知道一些皮毛,所以最近抽空深入理解一下,并在这里做个小结。
只需要序列化的时候将String和int写个某个内存区域,反序列化的时候读取这个内存区域,重新构造一个Person对象。
移动设备的操作系统阵营之一的Android,底层基于Linux内核,中间为Native&Runtime层和Framework层。我们知道Linux本身有着很成熟的IPC(进程间通信)机制,比如管道、消息队列、共享内存、socket、信号和信号量等。然而,Android却使用Binder来作为它的IPC的方案,这是为何呢?接下来,就把我之前学习Binder的心得写下来。
挺多概念的是吧,其实就说了一件事,Binder就是用来进程间通信的,是一种IPC方式。后面所有的解释都是Binder实际应用涉及到的内容。
谈到到Binder相对于其他传统进程间通信方式的优点的时候,我们总会说Binder只需要做“一次拷贝”就行了,而其他传统方式需要“两次拷贝”。这确实是Binder的优点,但再进一步思考就会碰到两个问题:
在上一篇博客 【Binder 机制】Native 层 Binder 机制分析 ( binder_loop | svcmgr_handler | binder.c | binder_parse ) 中 , 简单介绍了 在 service_manager.c 中的 main 函数中调用了 binder_loop 方法 , 在 binder_loop 方法中 , 传入了 svcmgr_handler 方法作为回调函数 , svcmgr_handler 中可以接收不同的消息 , 处理不同的业务 ;
我们知道在Linux系统中,进程间的通信方式有socket,named pipe,message queue, signal,sharememory等。这几种通信方式的优缺点如下:
Binder是一个类似于C/S架构的通信框架,有时候客户端可能想知道服务端的状态,比如服务端如果挂了,客户端希望能及时的被通知到,而不是等到再起请求服务端的时候才知道,这种场景其实在互为C/S的时候最常用,比如AMS与APP,当APP端进程异常退出的时候,AMS希望能及时知道,不仅仅是清理APP端在AMS中的一些信息,比如ActivityRecord,ServiceRecord等,有时候可能还需要及时恢复一些自启动的Service。Binder实现了一套”死亡讣告”的功能,即:服务端挂了,或者正常退出,Bi
领取专属 10元无门槛券
手把手带您无忧上云