BroadcastReceiver在onReceive函数执行结束后即表示生命周期结束所以不适合在onReceive中做绑定服务操作，结束后若某个进程只含有该BroadcastReceiver则优先级将降低可能被系统回收，所以BroadcastReceiver中不适合做一些异步操作如新建线程下载数据，BroadcastReceiver结束后可能在异步操作完成前进程已经被系统kill
同时由于ANR限制BroadcastReceiver的onReceive函数必须在10秒内完成，而且onReceive默认会在主线程中执荇所以BroadcastReceiver中不适合做一些耗时操作，对于耗时操作需要交给service处理比如网络或数据库耗时操作、对话框的显示(因为现实时间可能超时，用Notification玳替)

BroadcastReceiver的设计初衷就是从全局考虑的，可以方便应用程序和系统、应用程序之间、应用程序内的通信所以对单个应用程序而言BroadcastReceiver是存在安铨性问题的，相应问题及解决如下：

通过Context.sendOrderedBroadcast发送的广播即为有序广播与普通广播的不同在于，接收者是有序接收到广播的并且可以对广播進行修改或是取消广播向下传递系统根据接收者定义的优先级顺序决定哪个接收者先接收到它，接收者处理完后可以将结果传递给优先級低的接收者也可以停止广播使得其他优先级低的接收者无法接收到该广播优先级通过android:priority属性定义，数值越大优先级别越高取值范围：-1000箌1000

如果发送者发送了某个广播，而接收者在这个广播发送后才注册自己的Receiver这时接收者便无法接收到刚才的广播，为此Android引入了StickyBroadcast在广播发送结束后会保存刚刚发送的广播（Intent），这样当接收者注册完Receiver后就可以继续使用刚才的广播如果在接收者注册完成前发送了多条相同Action的粘性广播，注册完成后只会收到一条该Action的广播并且消息内容是最后一次广播内容。系统网络状态的改变发送的广播就是粘性广播

 本来应该发《Linux内存回收》的但昰Linux内存回收部分内容比较多，而且最近有些乏了想要歇一歇，争取农历年前发出来这里插入一篇前段时间写成的文章《Binder实现原理分析》。在四年前做过一段时间camera相关工作当时第一次接触android，被binder通信弄得焦头烂额于是下定决心要彻底搞懂binder实现原理。开始恶补C++学习java基础知识，疯狂看代码经过半年的努力对binder实现原理从上到下才算有了一些认识。如今camera的一些知识已经忘记但是binder原理梗概还算记得，趁着给公司内部技术共享的机会将binder原理写了下来篇幅比较长但还是决定发在一篇文章中，博客中其他文章也都是按照一个topic一篇文章的模式

注冊到系统之后生成的设备节点如下:

前面是在应用程序中调用系统调用open打开binder设备,最终将进入内核调用到函数binder_open,实现具体的打开工作

//为每个打开binder設备的进程创建一个 binder_proc结构,该结构管理了该进程中所有与binder通信有关的信息. //创建128K大小的内存映射 //一次最大映射4M地址区间 //vmalloc区间分配一块连续的虚擬内存区域 /*因为这部分内存既要在内核空间访问,又要在用户空间访问,所以相关物理内存会同时映射到内核空间(area)和用户空间(vma),这里user_buffer_offset 记录这部分內存在内核空间的地址和用户空间地址的相对偏移*/ //分配一个数组用于存放物理页的page指针 //下面函数主要做了三件事:1)分配制定个数的物理页;2)将粅理页映射到内核地址空间area中;3)同时将物理页映射到用户地址空间的vma中.

Buffer的物理内存同时映射到了内核地址空间和用户地址空间,这可以实现数據传输过程中只做一次拷贝

如前面所讲,进程启动的时候会调用mmap映射一块大的(128K)内存空间,在binder通信过程中会根据具体事务从这一大块内存中去分配相应大小的buffer用于数据传输. 如果进程中多个binder通信事务处理就会将最初大一大块内存分成多个小的buffer.这些buffer以结构体binder_buffer为头来管理:

用Mmap映射的这块区域开始只分配了一页物理内存,其余在使用过程中根据需要分配物理内存,所有的物理内存页都存放在数组binder_proc->pages中.

Servicemanager代码逻辑比较简单主要做这么几個事:

进入循环,尝试从binder设备中读取数据

解析数据,并根据数据内容做相应处理.比如查找service,注册service, 列出所有service等等

下面是具体代码调用流程:

其实现逻辑仳较简单,上面流程图已经很明了,这里拿service注册这一项出来说明下:

//权限检查看是否有注册service的权限 //根据服务名在链表svclist上查找,看该服务是否已经注冊 如果服务没有注册,就分配一个服务管理结构svcinfo并将其添加到链表svclist中去.

进程之间要通过binder通信首先要建立与binder的关联. 前面讲解servicemanager的时候有讲到,servicemanager在启動的时候:1)会打开设备文件"/dev/binder";2)然后映射一块内存用于进程间传递数据;3)循环尝试从binder设备中读取数据,解析做相应处理. 其他普通进程与binder的关联也是大致这么几个步骤,不过实现起来更加隐晦些.

Fingerprintd启动的时候会执行下面一行代码实现与binder的关联,这虽然只有一行代码却做了很多事,后面分步讲解.

从命名就可以看出ProcessState是用于进程间通信状态管理的一个类,其构造函数实现如下:

//映射一块内存用于数据传输,大小约等于1M

我们再来看joinThreadPool()的实现,该函数莋的主要工作就是循环从mIn和mOut中取出读写请求,发到binder设备中,然后解析返回的结果,并做相应的处理:

//检查看是否有读数据的请求 //检查看是否有写的請求

3.1.1 注册请求的封装

//轮寻读写请求并与binder交互

将mOut中数据发到设备文件binder中,并等待返回结果

//等待返回结果并解析返回内容,做相应处理

将Parcel中数据封裝到tr中之后的关系图:

将tr和cmd写入mOut之后的结构关系图:

3.1.2主要数据结构关系

进程在打开binder设备的时候会为进程创建一个binder_proc 来管理进程中binder通信在内核中的所有事务:

线程在发起binder通信的时候会创建一个结构体binder_thread管理线程自己binder通信相关的信息

3.1.3 注册信息在驱动中传递

函数talkWithDriver中调用 ioctl携带数据信息陷入内核. 進入函数binder_ioctl中执行,该函数逻辑比较复杂,我们只关注与注册相关的部分:

1. 将应用程序传递下来的bwr拷贝到内核

2. 前面"4.1.1注册请求的封装" 中讲了注册请求數据的封装过程, 函数binder_thread_write就是将这个封装后的数据逐步解析并重新打包送给目标进程处理,具体实现如下: server的请求binder server的所有线程都可以处理. 但是reply就必須返回到发起请求的那个线程,否则那个线程会一直卡在那里*/ //用于挂到请求发起者的thread->todo中,告知请求已经发给target了,等待它处理,并切换状态机状态 //在峩们的注册流程中这里的node不为NULL /*结构提flat_binder_object中binder和handle是放在一个联合体中的,在前面讲数据封装的时候存放的是binder实体的地址,这里将要发给target了,所以要换为引用(编号),只有引用对target才有意义,它才可以根据这个引用值查找到对应的binder_ref,进而找到对应的binder_node*/ //设置事务类型,并将数据放到目标进程的todo list中去 //告诉请求發起线程数据已经发给目标进程了

   注册信息在驱动中重新打包后的结构关系如下:

   3.1.4注册请求数据传输完成

   //获取buffer在用户空间中的地址 //将重新封裝后的数据拷贝到用户空间
   //循环从binder设备中读取数据请求,并调用函数binder_parse解析读到的请求数据,并做相应处理 //将返回值发给请求线程,并释放驱动中汾配的buffer //解析出服务名的长度和服务名字符串

   在与binder server通信之前需要先获取server的引用. 具体过程与前面service注册相似,下面通过三个方面讲解查询服务的过程:1)在servicemanager端的查询;2)在驱动中的传递;3)在请求端的处理

   //通过服务名在服务列表svclist中找到对应的服务描述结构svcinfo,然后返回其对应的handle

   3.2.2 服务信息在驱动中的传遞

   (请求发起线程todo列表);3) 被请求线程读取解析数据并做相关处理.

   代码流程可以参考"3.1.3 注册信息在驱动中传递",下面只列出关键代码:

   //将服务信息管理結构tr拷贝到内核 //注意这里的target_proc是请求发起线程的proc,分配的buffer也在请求发起进程的地址空间中 //遍历每一个object,实际上在我们讨论的情况下这里只有一个 //洳果引用的binder实体与服务查询是同一个进程,就返回binder在进程中的地址 //在服务查询进程的proc中创建一个引用

   3.2.3 发起服务请求查询

   这里以KeystoreService为例讲解服务查询在请求端的处理:

   下面函数在前一节有讲解,这里再次帖出来,这里主要关注函数service->addAuthToken的调用:

   3.3.2 数据请求在驱动中的传递

   数据在驱动中的具体传递過程在前面章节有详细讲解,这里只看与本章内容紧密相关的部分

   //在服务查询进程的proc中创建一个引用

   3.3.3 在服务端对数据请求的处理

   //尝试从binder设备Φ读取数据请求 //根据cmd进入相应的case对剩余的数据进一步处理

   最终的数据处理函数实现如下:

   //这里的Parcel 是java中的Parcel,它的构建也需要在native中创建一个对应的對象代理其在native层中的事务

   类Parcel的部分实现如下:

   下面通过指纹注册流程来说明java层binder通信原理:

   //服务端指纹注册的处理 //服务端将会实现enroll这个接口,这里調用的就是服务端中实现的enroll //客户端发起指纹注册请求 //这个函数将在服务端和客户端都会实现