皮皮网

1.Framework层的源码Binder（源码分析篇）
2.一文分析Binder机制和AIDL的理解
3.Android小白学习之路(5)——Binder介绍
4.你对Framework 底层中的 Binder机制原理了解多少？
5.Android Framework——Binder 监控方案
6.ibinderandroid ibinder类接口

Framework层的Binder（源码分析篇）

       本文以android-.0.0_r的AOSP分支为基础，解析framework层的源码Binder工作原理。

       从ServiceManager的源码getService方法入手，其核心代码是源码通过getIServiceManager().getService(name)获取服务。首先，源码ServiceManager的源码有声小程序源码实现与进程中的ProcessState密切相关，ProcessState是源码单例，负责打开和映射Binder驱动。源码构造函数中，源码它会初始化驱动、源码验证版本并设置线程数，源码接着进行binder映射。源码

       在ProcessState的源码getContextObject方法中，调用native函数android_util_Binder.cpp中的源码getContextObject()。这个函数通过handle 0（ServiceManager的源码handle）获取BpBinder对象，然后通过javaObjectForIBinder函数将其转换为Java中的类型。

       进一步分析，BpBinder与java层的Binder之间存在对应关系，通过BinderProxy NativeData创建单例的BinderProxy。然后，每个服务的BinderProxy实例化和计数处理都在这个过程中完成。ServiceManagerNative.asInterface方法简化了getIServiceManager的调用，通过调用asInterface实例化ServiceManagerProxy。

       IServiceManager接口通过AIDL生成，其代理类ServiceManagerProxy实际上是不必要的。aidl文件在编译时生成对应java代码，用于binder通信。通过aidl文件，我们可以看到如queryLocalInterface等方法的实现细节。

       在Parcel的协助下，客户端与服务端进行数据传递，通过序列化和反序列化进行交互。在transact函数中，对Parcel大小进行检查，避免数据传输过大导致的问题。最后，客户端与binder驱动的修改sdk的源码通信过程涉及了Transaction数据的写入、等待响应、数据处理和内存回收等步骤。

       总的来说，framework层的Binder工作涉及服务管理、数据转换、通信协议和内存管理等环节，理解这些有助于深入掌握Binder的工作机制。

一文分析Binder机制和AIDL的理解

       深入了解Android进程间通信机制，如同破解系统奥秘的钥匙，它在源码探索和问题解决中扮演着核心角色。Binder机制，源自OpenBinder，正是这个领域的主角，它弥补了Linux原生通信方式在性能和安全性的短板。它的运作涉及驱动层与应用层的无缝对接，包括与系统服务如Activity Manager Service (AMS) 的深度协作。

       Binder，作为Java编写的通信工具包，是Android多进程通信的基石。尽管AIDL（Android Interface Definition Language）常用于简化这一过程，但并非不可或缺。让我们通过一个实例，不依赖AIDL，来揭示Binder通信的内在机制。想象一个简单的场景：一个客户端（ClientBinder）与服务端（ServerBinder，继承自Binder并实现onTransact方法）之间的字符串传递，透彻理解Binder通信的运作原理。

       项目框架中，服务端在Service的onBind方法中返回一个ServerBinder实例。对比手动实现与AIDL生成的代码，AIDL的便捷性便一目了然。客户端通过ServiceConnection，如下面这段代码，与远程服务建立连接：

       1. 创建ServiceConnection，获取远程服务的IBinder

       2. intent设置服务类名："com.binder.server.RemoteService"

       3. bindService(intent, serviceConnection, Context.BIND_AUTO_CREATE)

       4. 若未连接，尝试bindService

       5. 传递数据：通过IBinder调用mStingEditText的量能博弈指标源码文本，如data.writeString(text)

       6. 成功连接后，调用transact方法传递请求

       接收数据的环节，服务端将数据展示在tvShowMessage上，通过新线程处理，如`new Handler().post(() -> ServerMainActivity.tvShowMessage.setText(message));`。当连接断开时，serviceConnection的onServiceDisconnected方法会被触发。

       关键在于客户端如何通过IBinder获取服务端对象并调用transact进行跨进程通信。AIDL的引入让这个过程更加优雅，例如在ClientMainActivityUseAidl中，服务连接成功后，通过IBinder代理mServer，调用自定义接口IShowMessageAidlInterface的showMessage方法。

       在交互过程中，客户端通过IShowMessageAidlInterface的Stub内部类，将本地的IBinder转换为接口，这样数据的发送就通过showMessage方法进行。AIDL的asInterface方法负责封装本地或远程处理，Proxy类则负责数据的打包和跨进程传输，确保数据的无缝传递。

       总结来说，客户端利用AIDL的asInterface处理远程IBinder，而Proxy类则是这一切的幕后功臣。服务端的onBind方法返回AIDL生成的Stub，它在客户端调用transact时负责接收和处理请求，执行showMessage方法。这样，AIDL生成的Stub和Proxy成为客户端发送数据的桥梁，而在服务端，它们则是数据处理的核心所在。

       掌握Binder机制和AIDL的精髓，你将解锁Android进程间通信的无尽可能，为你的应用开发增添无限力量。无论何时，当你深入探索Android源码，这些核心原理都将是fguilib.dll 源码你不可或缺的指南。

Android小白学习之路(5)——Binder介绍

       Binder是Android系统中实现进程间通信（IPC）的关键类，它通过IBinder接口提供跨进程通信能力。从系统架构的角度，Binder充当ServiceManager连接各Manager和服务的桥梁，为应用层提供服务端和服务间的通信媒介。具体应用中，Binder主要用于Service，包含AIDL和Messenger，其中普通Service不涉及进程间通信，而Messenger底层基于AIDL实现。

       在开发中，AIDL（Android Interface Definition Language）作为接口定义语言，用于描述服务端和客户端通信接口，生成用于IPC的代码。通过AIDL，开发者可以定义服务方法，自动生成相应的Binder类，从而实现应用间的数据共享。例如，通过绑定服务调用方法获取书籍列表并添加书籍。

       在创建示例时，首先定义Book类表示图书信息，实现Parcelable接口。接着创建Book.aidl文件描述Book类，BookController.aidl文件定义接口，包括获取图书列表和添加书籍的方法。系统会根据AIDL文件自动生成BookController.java类，该类继承IInterface接口，用于承载Binder的功能。

       BookController.java类声明了getBookList()和addBook()方法，分别对应BookController.aidl中的方法。通过内部类Stub，实现服务端和客户端之间的调用，根据进程位置选择不同的代理类。此外，onTransact()方法处理跨进程调用，mysql mac源码安装确定调用方法并执行，返回结果或异常。

       客户端通过transact()方法发起请求，调用服务端方法。服务端接收到请求后，通过onTransact()方法处理调用，执行对应方法并将结果返回。客户端通过Parcel对象接收返回值，完成数据交换。

       值得注意的是，Binder的管理方法linkToDeath()和unlinkToDeath()确保服务端异常终止时，客户端能够及时察觉并恢复连接，避免功能中断。

       总之，通过分析Binder的工作原理，包括其方法和机制，理解了进程间通信的基础。结合Serializable和Parcelable接口的介绍，对IPC的基础内容有了全面了解。未来将探讨更多进程间通信方式。

你对Framework 底层中的 Binder机制原理了解多少？

       Binder 是一种高效、方便、安全的进程间通信方式，用于 Android 中的系统服务和应用程序间的交互。其通信模型涉及四方：Binder 驱动层、Client 端、Service 端和 ServiceManager。Client 端和 Service 端通过 ServiceManager 作为上下文管理者来注册和获取服务。

       Client 和 Service 通过 binder_open 打开驱动，根据返回的文件描述符进行内存映射，分配缓冲区，并启动 binder 线程。ServiceManager 的主要功能是注册和获取服务，通过 binder_open 打开驱动，注册为大管家，并进入 binder_loop 循环处理请求。

       Service 注册时，首先启动 binder 机制，注册线程，然后初始化服务，最后通过 ServiceManager 注册。ServiceManager 获取服务的 Binder 代理对象，通过 defaultServiceManager 和 getStrongProxyForHandle(0) 方法实现。

       Client 获取服务同样通过 ServiceManager 的代理对象实现。Binder 驱动层在处理请求时，根据 handle 值封装 BinderProxy 对象，完成注册过程。

       IPC 通信流程涉及 Proxy、Binder、Parcel 和 BpBinder。从应用层的 Proxy 的 transact 函数开始，传递到 Java 层的 BinderProxy，再到 Native 层的 BpBinder 的 transact。BpBinder 的 transact 实际上是调用 IPCThreadState 的 transact 函数，通过 handle 值找到 Binder 实体对象。

       Service 端的通信涉及 Binder 线程、getAndExecuteCommand 和 executeCommand。在执行命令时，通过 onTransact 函数处理请求，然后发送 BC_REPLY 响应。Binder 对象在 Parcel 中通过 readStrongBinder/writeStrongBinder 存储，存储原理是 flat_binder_object。

       OneWay 是异步调用机制，不需要等待返回结果。系统服务常使用 OneWay，如 Activity 启动。Framework 中使用管道、Socket、共享内存和信号进行进程间通信，这些机制各有特点，用于不同场景。

       对于 Android Framework 的深入理解，不仅包括底层原理，还应理解如何在实际开发中运用。为了帮助开发者更深入地掌握 Framework 底层原理，《Android Framework核心笔记》及相关学习资料提供了全面的指导。这些资源涵盖了 Handler、Binder、Zygote、AMS、PMS、WMS 等关键组件的实现细节，是提升 Android 开发能力的宝贵资源。

Android Framework——Binder 监控方案

       在Android应用开发中，Binder作为普遍使用的IPC机制，监控其主要出于以下目的：一，监控特定系统服务，借助ServiceManager和AIDL设计，通过动态代理替换当前进程对应的Proxy对象实现监控；二，实现进程内全局Binder监控，需考虑拦截transact方法。

       针对监控需求，ProxyTransactListener在Android 引入，可在Binder调用前后触发回调，适用于SystemUI监控主线程的Binder调用。尽管ProxyTransactListener和相关接口被隐藏，但可绕过限制，通过动态代理创建实例，实现对进程内Java Binder调用的全局监控。

       绕过hidden api限制的方案包括在Android 系统禁用元反射后，使用Native线程Attach获取JNIEnv，构造没有Java caller的情况。原理在于系统在回溯Java堆栈找不到caller时，信任调用不做hidden api拦截，实现全局hidden api白名单。此方案简单且兼容性好，但存在缺点，即无法监控Native的Binder调用。

       基于JNI Hook可以hook BinderProxy.transactNative，实现全版本进程内Java Binder调用的全局监控，获取完整参数和返回结果。JNI Hook基于JNI边界hook Java对应的Native函数实现，稳定性较高。具体操作是找到原Native函数并替换，无需手动触发Binder调用。考虑到BpBinder.transact为导出虚函数且动态绑定，直接PLT Hook libbinder.so中对该函数的调用即可。

       拦截BpBinder.transact调用后，获取Binder对象的描述符及传输数据大小，通过调用导出接口实现。String处理需自定义类，利用其稳定布局及私有属性mString。通过调用Parcel::dataSize接口获取数据大小，并声明空类承接data参数实现引用转换。

       监控Binder调用仅是第一步，关键在于数据处理，挖掘IPC耗时卡顿和数据过大导致的问题。堆栈信息、调用描述符和code是定位问题的重要信息。了解Android Framework框架中的核心知识点对开发者至关重要，推荐《Android Framework学习手册》，几乎覆盖了Framework相关的知识点，包括Handler、Binder、AMS、WMS、PMS、事件分发机制、UI绘制等，还有Android面试题。

       深入理解Android Framework底层对现代Android开发至关重要，因为它提供了基础服务和API，使得应用能够与操作系统进行交互和通信。

ibinderandroid ibinder类接口

       在Android开发中，关键的类目录android.os.IBinder起着远程对象操作的基础接口角色。它的直接子类Binder提供了高性能和轻量级的进程间与跨进程调用的核心机制。IBinder接口的核心功能体现在transact()方法及其在直接子类Binder中的onTransact()实现，这些方法分别用于发送和接收调用请求。

       简单来说，IBinder是Android远程调用的核心，无论是进程内还是进程间通信，都是通过它来实现的。它定义了与远程对象交互的抽象协议，但通常并不直接实现，而是通过从Binder派生类来实现。transact()方法允许你向远程的IBinder对象发送请求，而onTransact()则使得远程对象能响应这些请求，它们都是同步执行的。

       发送给transact()的数据是Parcel，这是一种包含数据和元数据的缓冲区。元数据确保了IBinder引用在进程间传递时的持久性，使得即使IBinder在不同进程中，也能保持其标识。系统通过维护每个进程的交互线程池，确保跨进程调用的顺利进行，就像进程内的调用一样无缝。

       对于远程对象的有效性检查，开发者可以借助transact()的异常处理，pingBinder()的返回值，以及linkToDeath()方法注册死亡接收者来实现。在实现支持远程调用时，一般通过aidi工具从Binder派生类，但这并非唯一选择，也可以直接派生或使用原始Binder作为进程间共享的令牌。

defaultServiceManager介绍

       æˆ‘们在使用binder时候的大致流程是先获取servicemanger的binder，然后通过该binder获取目标服务的binder，最后调用该binder的接口。本篇就介绍下第一步的内容，涉及了从native到驱动，fwk部分先不涉及，希望可以完全理解servicemanager的获取流程。

        整个流程的起点是IServiceManager::defaultServiceManager()

        可以看到这是一个单例，在首次调用的时候会进行初始化获取servicemanager的binder，然后用智能指针封装一下。

        可以看到这儿还是一个单例，对于参与binder IPC的进程，和binder驱动交互部分就是通过ProcessState实现的。

        对于android，有三种binder驱动节点，下面列一下区别：

        接下来看下ProcessState的构造方法：

        这儿有两个和驱动交互的部分，一个是open_driver，一个是mmap，这里先介绍下open_driver：

        这儿的流程比较直接，就是打开节点，用ioctl获取了版本号，设置了线程池数量，设置了允许异步调用检测。接下来看下open 的内容，这时候就会进入内核，因为binder驱动定义了自己的open，ioctl，mmap方法。

        接下来看下init_binder_device的实现：

        这儿就是将binder驱动设备注册为一个misc设备，并指定了它的操作实现方法。

        因为上层是先调用的open，因此看下这儿binder_open的实现：

        这儿主要就是创建了一个binder_proc结构，并和当前用户态进程current关联起来。

        再看下ioctl的内容：

        看到这一块，之前的三个ioctl命令内容就清楚了。接下来需要看下一个关键的地方，就是mmap，对应的实现就是binder_mmap:

        这儿没做啥，看下binder_alloc_mmap_handler：

        这时候驱动做的事情就是将用户态的地址保存到proc自己的结构里面。 mmap暂时告一段落。

        继续回到用户态，继续ProcessState::self()->getContextObject(nullptr) 获取serviemanager的binder过程，前一部分介绍完了，接下来应该是getContextObject部分，看下实现：

        对于servicemanager，handle为0，看下getStrongProxyForHandle的内容：

        如果本地没有servicemanager的proxy binder，那么就需要用驱动获取。继续看下获取流程：

        看下transact：

        可以看到transact里面的流程就是封装数据包和与驱动交互，如果有返回值，则直接写入reply。先看下如何封装的数据包：

        这时候就把请求相关的写入了parcel，接下来看下waitForResponse：

        看下talkWithDriver：

        这儿就是将请求写入binder_write_read，并和驱动进行交互。在进入驱动前，先看下binder_write_read的结构：

        在驱动中，ioctl的操作如下：

        先看下binder_get_thread的操作：

        binder_get_thread_ilocked的逻辑如下：

        拿到线程后，接下来就是binder_ioctl_write_read：

        这儿就是读取内容，然后解析出命令，对于我们，命令是BC_TRANSACTION， 然后调用binder_transaction进行操作：

        到这里，过去servicemanager的binder流程就结束了。最后再简单看下binder_proc_transaction的内容：

        介绍到这里，defaultServiceManager涉及的流程就介绍完了，最后用一个流程图总结下：

        本篇介绍了下servicemanager proxy的获取流程，涉及了ProcessState(进程单例)， IPCThreadState(线程单例)。 binder驱动的open，mmap，ioctl部分。该流程比起其他调用流程稍微简单一些，不过对于熟悉binder 工作流程还是很有帮助的。

Binder基础介绍

       在Android系统中，应用以独立进程运行，进程间通信机制(IPC)用于实现数据共享。常用IPC方式包括共享内存、管道、信号处理、socket、Binder等，Android根据不同场景选择合适的方式。本文重点介绍Android系统中的Binder机制。

       Binder机制分为四个部分，其运作方式主要由客户端和服务器端通过mRemote对象进行消息传递。客户端使用transact()方法发起请求，服务端在onTransact()方法处理请求并返回结果，实现了进程间数据交互。

       Proxy/Stub模式简化了Activity与Service间通信，通过中介代理实现业务关注点与实现细节分离。AIDL(Android Interface Define Language)是用于生成可在Android设备上进行IPC的代码，通过代理存根结构实现跨进程调用。HIDL(Android Hardware Interface Definition Language)在Android 8后引入，用于更特定的硬件接口定义。

       Android 8引入Treble机制，解耦Android框架与供应商接口，简化更新流程。新Binder机制引入了“binder”,“hwbinder”,“vndbinder”三个域，满足不同场景需求。VndBinder提供给供应商服务使用，HwBinder用于跨系统和供应商分区通信。这些变化优化了系统更新流程，提高了安全性与稳定性。

       综上所述，Android系统通过Binder机制实现了进程间高效通信，通过AIDL和HIDL等接口定义语言简化了通信逻辑。Treble机制进一步提升了系统可维护性和更新效率，为Android系统的长期稳定发展奠定了基础。