android结构体

‘壹’ Android 重学系列 ion驱动源码浅析

上一篇文章，在解析初始化GraphicBuffer中，遇到一个ion驱动，对图元进行管理。首先看看ion是怎么使用的：

我们按照这个流程分析ion的源码。

如果对ion使用感兴趣，可以去这篇文章下面看 https://blog.csdn.net/hexiaolong2009/article/details/102596744

本文基于Android的Linux内核版本3.1.8

遇到什么问题欢迎来本文讨论 https://www.jianshu.com/p/5fe57566691f

什么是ion？如果是音视频，Camera的工程师会对这个驱动比较熟悉。最早的GPU和其他驱动协作申请一块内存进行绘制是使用比较粗暴的共享内存。在Android系统中使用的是匿名内存。最早由三星实现了一个Display和Camera共享内存的问题，曾经在Linux社区掀起过一段时间。之后各路大牛不断的改进之下，就成为了dma_buf驱动。并在 Linux-3.3 主线版本合入主线。现在已经广泛的运用到各大多媒体开发中。

首先介绍dma_buf的2个角色，importer和exporter。importer是dma_buf驱动中的图元消费者，exporter是dma_buf驱动中的图元生产者。

这里借用大佬的图片：

ion是基于dma_buf设计完成的。经过阅读源码，其实不少思路和Android的匿名内存有点相似。阅读本文之前就算不知道dma_buf的设计思想也没关系，我不会仔细到每一行，我会注重其在gralloc服务中的申请流程，看看ion是如何管理共享内存，为什么要抛弃ashmem。

我们先来看看ion的file_operation:

只有一个open和ioctl函数。但是没有mmap映射。因此mmap映射的时候一定其他对象在工作。

我们关注显卡英伟达的初始化模块。
文件：/ drivers / staging / android / ion / tegra / tegra_ion.c

mole_platform_driver实际上就是我之前经常提到过的mole_init的一个宏,多了一个register注册到对应名字的平台中的步骤。在这里面注册了一个probe方法指针，probe指向的tegra_ion_probe是加载内核模块注册的时候调用。

先来看看对应的结构体：

再来看看对应ion内的堆结构体：

完成的事情如下几个步骤：

我们不关注debug模式。其实整个就是我们分析了很多次的方法。把这个对象注册miscdevice中。等到insmod就会把整个整个内核模块从dev_t的map中关联出来。

我们来看看这个驱动结构体：

文件：/ drivers / staging / android / ion / ion_heap.c

这里有四个不同堆会申请出来，我们主要来看看默认的ION_HEAP_TYPE_SYSTEM对应的heap流程。

其实真正象征ion的内存堆是下面这个结构体

不管原来的那个heap，会新建3个ion_system_heap，分别order为8，4，0,大于4为大内存。意思就是这个heap中持有一个ion_page_pool 页资源池子，里面只有对应order的2的次幂，内存块。其实就和伙伴系统有点相似。

还会设置flag为ION_HEAP_FLAG_DEFER_FREE，这个标志位后面会用到。

文件：/ drivers / staging / android / ion / ion_page_pool.c

在pool中分为2个链表一个是high_items，另一个是low_items。他们之间的区分在此时就是以2为底4的次幂为分界线。

文件：/ drivers / staging / android / ion / ion.c

因为打开了标志位ION_HEAP_FLAG_DEFER_FREE和heap存在shrink方法。因此会初始化两个回收函数。

文件：/ drivers / staging / android / ion / ion_heap.c

此时会创建一个内核线程，调用ion_heap_deferred_free内核不断的循环处理。不过由于这个线程设置的是SCHED_IDLE，这是最低等级的时间片轮转抢占。和Handler那个adle一样的处理规则，就是闲时处理。

在这个循环中，不断的循环销毁处理heap的free_list里面已经没有用的ion_buffer缓冲对象。

文件：/ drivers / staging / android / ion / ion_system_heap.c

注册了heap的销毁内存的方法。当系统需要销毁页的时候，就会调用通过register_shrinker注册进来的函数。

文件：/ drivers / staging / android / ion / ion_page_pool.c

整个流程很简单，其实就是遍历循环需要销毁的页面数量，接着如果是8的次幂就是移除high_items中的page缓存。4和0则销毁low_items中的page缓存。至于为什么是2的次幂其实很简单，为了销毁和申请简单。__free_pages能够整页的销毁。

文件：/ drivers / staging / android / ion / ion.c

主要就是初始化ion_client各个参数，最后把ion_client插入到ion_device的clients。来看看ion_client结构体：

核心还是调用ion_alloc申请一个ion缓冲区的句柄。最后把数据拷贝会用户空间。

这个实际上就是找到最小能承载的大小，去申请内存。如果8kb申请内存，就会拆分积分在0-4kb，4kb-16kb，16kb-128kb区间找。刚好dma也是在128kb之内才能申请。超过这个数字就禁止申请。8kb就会拆成2个4kb保存在第一个pool中。

最后所有的申请的page都添加到pages集合中。

文件：/ drivers / staging / android / ion / ion_page_pool.c

能看到此时会从 ion_page_pool冲取出对应大小区域的空闲页返回上层，如果最早的时候没有则会调用ion_page_pool_alloc_pages申请一个新的page。由于引用最终来自ion_page_pool中，因此之后申请之后还是在ion_page_pool中。

这里的处理就是为了避免DMA直接内存造成的缓存差异(一般的申请，默认会带一个DMA标志位)。换句话说，是否打开cache其实就是，关闭了则使用pool的cache，打开了则不使用pool缓存，只依赖DMA的缓存。

我们可以看另一个dma的heap，它是怎么做到dma内存的一致性.
文件： drivers / staging / android / ion / ion_cma_heap.c

能看到它为了能办到dma缓存的一致性，使用了dma_alloc_coherent创建了一个所有强制同步的地址，也就是没有DMA缓存的地址。

这里出现了几个新的结构体，sg_table和scatterlist

文件：/ lib / scatterlist.c

这里面实际上做的事情就是一件：初始化sg_table.
sg_table中有一个核心的对象scatterlist链表。如果pages申请的对象数量<PAGE_SIZE/sizeof(scatterlist),每一项sg_table只有一个scatterlist。但是超出这个数字就会增加一个scatterlist。

用公式来说：

换句话说，每一次生成scatterlist的链表就会直接尽可能占满一页，让内存更好管理。

返回了sg_table。

初始化ion_handle，并且记录对应的ion_client是当前打开文件的进程，并且设置ion_buffer到handle中。使得句柄能够和buffer关联起来。

每当ion_buffer需要销毁，

‘贰’ Android之Binder通信篇

Binder跨进程通信的本质是依赖内核驱动将属于不同Binder进程的数据，从原始进程复制到目标进程，这样就完成了跨进程通信了。

Binder通过独特的内存映射机制，在跨进程通信时，可以做到一次拷贝，两个空间同时使用！如下图：

Binder跨进程通信是要传递数据的，既然有数据必然要占用内存空间，Android系统规定每一个进程都有一块Binder内存区，也就是图1中的 共享内存 ，系统最多只能给该区域分配4M的物理内存，由于申请这块内存是通过系统的mmap函数完成的，所以整个映射机制又被称为mmap机制
为了把这部分说明白，就再盗图一张，命名图2吧！

对于Binder驱动，通过 binder_procs 链表记录所有创建的 binder_proc 结构体，binder 驱动层的每一个 binder_proc 结构体都与用户空间的一个用于 binder 通信的进程一一对应，且每个进程有且只有一个 ProcessState 对象，这是通过单例模式来保证的。在每个进程中可以有很多个线程，每个线程对应一个 IPCThreadState 对象，IPCThreadState 对象也是单例模式，即一个线程对应一个 IPCThreadState 对象，在 Binder 驱动层也有与之相对应的结构，那就是 Binder_thread 结构体。在 binder_proc 结构体中通过成员变量 rb_root threads，来记录当前进程内所有的 binder_thread。

Binder 线程池：每个 Server 进程在启动时创建一个 binder 线程池，并向其中注册一个 Binder 线程；之后 Server 进程也可以向 binder 线程池注册新的线程，或者 Binder 驱动在探测到没有空闲 binder 线程时主动向 Server 进程注册新的的 binder 线程。对于一个 Server 进程有一个最大 Binder 线程数限制，默认为16个 binder 线程，例如 Android 的 system_server 进程就存在16个线程。对于所有 Client 端进程的 binder 请求都是交由 Server 端进程的 binder 线程来处理的。

‘叁’ Android中mmap原理及应用简析

mmap是Linux中常用的系统调用API，用途广泛，Android中也有不少地方用到，比如匿名共享内存，Binder机制等。本文简单记录下Android中mmap调用流程及原理。mmap函数原型如下：

几个重要参数

返回值是void *类型，分配成功后，被映射成虚拟内存地址。

mmap属于系统调用，用户控件间接通过swi指令触发软中断，进入内核态（各种环境的切换），进入内核态之后，便可以调用内核函数进行处理。 mmap->mmap64->__mmap2->sys_mmap2-> sys_mmap_pgoff ->do_mmap_pgoff

而 __NR_mmap在系统函数调用表中对应的减值如下：

通过系统调用，执行swi软中断，进入内核态，最终映射到call.S中的内核函数：sys_mmap2

sys_mmap2最终通过sys_mmap_pgoff在内核态完成后续逻辑。

sys_mmap_pgoff通过宏定义实现

进而调用do_mmap_pgoff：

get_unmapped_area用于为用户空间找一块内存区域，

current->mm->get_unmapped_area一般被赋值为arch_get_unmapped_area_topdown，

先找到合适的虚拟内存（用户空间），几经周转后，调用相应文件或者设备驱动中的mmap函数，完成该设备文件的mmap，至于如何处理处理虚拟空间，要看每个文件的自己的操作了。

这里有个很关键的结构体

它是文件驱动操作的入口，在open的时候，完成file_operations的绑定，open流程跟mmap类似

先通过get_unused_fd_flags获取个未使用的fd，再通过do_file_open完成file结构体的创建及初始化，最后通过fd_install完成fd与file的绑定。

重点看下path_openat：

拿Binder设备文件为例子，在注册该设备驱动的时候，对应的file_operations已经注册好了，

open的时候，只需要根根inode节点，获取到file_operations既可，并且，在open成功后，要回调file_operations中的open函数

open后，就可以利用fd找到file，之后利用file中的file_operations *f_op调用相应驱动函数，接着看mmap。

Binder机制中mmap的最大特点是一次拷贝即可完成进程间通信 。Android应用在进程启动之初会创建一个单例的ProcessState对象，其构造函数执行时会同时完成binder mmap，为进程分配一块内存，专门用于Binder通信，如下。

第一个参数是分配地址，为0意味着让系统自动分配，流程跟之前分子类似，先在用户空间找到一块合适的虚拟内存，之后，在内核空间也找到一块合适的虚拟内存，修改两个控件的页表，使得两者映射到同一块物力内存。

Linux的内存分用户空间跟内核空间，同时页表有也分两类，用户空间页表跟内核空间页表，每个进程有一个用户空间页表，但是系统只有一个内核空间页表。而Binder mmap的关键是：也更新用户空间对应的页表的同时也同步映射内核页表，让两个页表都指向同一块地址，这样一来，数据只需要从A进程的用户空间，直接拷贝拷贝到B所对应的内核空间，而B多对应的内核空间在B进程的用户空间也有相应的映射，这样就无需从内核拷贝到用户空间了。

binder_update_page_range完成了内存分配、页表修改等关键操作：

可以看到，binder一次拷贝的关键是，完成内存的时候，同时完成了内核空间跟用户空间的映射，也就是说，同一份物理内存，既可以在用户空间，用虚拟地址访问，也可以在内核空间用虚拟地址访问。

普通文件的访问方式有两种：第一种是通过read/write系统调访问，先在用户空间分配一段buffer，然后，进入内核，将内容从磁盘读取到内核缓冲，最后，拷贝到用户进程空间，至少牵扯到两次数据拷贝；同时，多个进程同时访问一个文件，每个进程都有一个副本，存在资源浪费的问题。

另一种是通过mmap来访问文件，mmap()将文件直接映射到用户空间，文件在mmap的时候，内存并未真正分配，只有在第一次读取/写入的时候才会触发，这个时候，会引发缺页中断，在处理缺页中断的时候，完成内存也分配，同时也完成文件数据的拷贝。并且，修改用户空间对应的页表，完成到物理内存到用户空间的映射，这种方式只存在一次数据拷贝，效率更高。同时多进程间通过mmap共享文件数据的时候，仅需要一块物理内存就够了。

共享内存是在普通文件mmap的基础上实现的，其实就是基于tmpfs文件系统的普通mmap，有机会再分析，不再啰嗦。

Android中mmap原理及应用简析

仅供参考，欢迎指正

‘肆’ Android通信方式篇（七）-Binder机制（Native层（下））

本篇文章针对向ServiceManager注册服务 和 获取服务两个流程来做总结。在这两个过程中，ServiceManager都扮演的是服务端，与客户端之间的通信也是通过Binder IPC。

在此之前先了解下Binder的进程与线程的关系：

用户空间 :ProcessState描述一个进程，IPCThreadState对应一个进程中的一个线程。
内核空间 ：binder_proc描述一个进程，统一由binder_procs全局链表保存，binder_thread对应进程的一个线程。
ProcessState与binder_proc是一一对应的。

Binder线程池 ：每个Server进程在启动时会创建一个binder线程池，并向其中注册一个Binder线程；之后Server进程也可以向binder线程池注册新的线程，或者Binder驱动在探测到没有空闲binder线程时会主动向Server进程注册新的的binder线程。对于一个Server进程有一个最大Binder线程数限制15，(#define DEFAULT_MAX_BINDER_THREADS 15)。对于所有Client端进程的binder请求都是交由Server端进程的binder线程来处理的。我的理解是：binder线程是进程进行binder ipc时的一条数据处理路径。

MediaPlayerService向ServiceManager注册过程如下：

相关类：

整个过程总结如下：
1 获取BpServiceManager 与 BpBinder
由defaultServiceManager()返回的是BpServiceManager，同时会创建ProcessState对象和BpBinder对象。然后通过BpBinder执行transact，把真正工作交给IPCThreadState来处理。

2 BpBinder transact
Binder代理类调用transact()方法，真正工作还是交给IPCThreadState来进行transact工作。

3 通过IPCThreadState 包装并转换数据并进行transact事务处理
每个线程都有一个IPCThreadState，每个IPCThreadState中都有一对Parcel变量：mIn、mOut。相当于两根数据管道：

最后执行talkWithDriver。

writeTransactionData：将BC Protocol + binder_transaction_data结构体 写入mOut， 然后执行waitForResponse：

由talkWithDriver将数据进一步封装到binder_write_read结构体，通过ioctl（BINDER_WRITE_READ）与驱动通信。同时等待驱动返回的接收BR命令，从mIn取出返回的数据。

mIn包装的数据结构(注册服务handle = 0 ，code 为ADD_SERVICE_TRANSACTION)：

4 Binder Driver
把binder_write_read结构体write_buffer里数据取出来，分别得到BC命令和封装好数据的事务binder_transaction_data, 然后根据handler，在当前binder_proc中，找到相应的binder_ref，由binder_ref再找到目标binder_node实体，由目标binder_node再找到目标进程binder_proc。然后就是插入数据：当binder驱动可以找到合适的线程，就会把binder_transaction节点插入到servciemanager的线程的todo队列中，如果找不到合适的线程，就把节点之间插入servciemanager的binder_proc的todo队列。

5 ServiceManager
经过Binder Driver的处理，数据已经到了ServiceManager进程，在BR_TRANSACTION的引导下，在binder_loop（）中执行binder_parser（）取出数据，执行do_add_service（）操作，最终向 svcinfo 列表中添加已经注册的服务（没有数据的返回）。最后发送 BR_REPLY 命令唤醒等待的线程，通知注册成功。结束MediaPlayerService进程 waitForResponse()的状态，整个注册过程结束。

获取服务的过程与注册类似，首先 ServiceManager 向 Binder 驱动发送 BC_TRANSACTION 命令携带 CHECK_SERVICE_TRANSACTION 命令，同时获取服务的线程进入等待状态 waitForResponse()。Binder 驱动收到请求命令向 ServiceManager 的发送 BC_TRANSACTION 查询已注册的服务，会区分请求服务所属进程情况。

查询到直接响应 BR_REPLY 唤醒等待的线程。若查询不到将与 binder_procs 链表中的服务进行一次通讯再响应。

以startService为例来简单总结下执行流程：

3.1 从方法执行流程来看：

Client ：

1 AMP.startService 标记方法以及通过Parcel包装数据；

2 BinderProxy.transact 实际调用native的 android_os_BinderProxy_transact 传递数据；

3 获取BpServiceManager 与 BpBinder 同时会创建ProcessState。然后通过BpBinder执行transact，把真正工作交给IPCThreadState来处理；

4 IPC.transact 主要执行writeTransactionData，将上层传来的数据重新包装成binder_transaction_data，并将BC Protocol + binder_transaction_data结构体 写入mOut；

5 IPC waitForResponse talkWithDriver + 等待返回数据；

6 talkWithDriver 将数据进一步封装成binder_write_read，通过ioctl（BINDER_WRITE_READ）与驱动通信；

Kernel :

7 binder ioctl 接收BINDER_WRITE_READ ioctl命令；

8 binder_ioctl_write_read 把用户空间数据ubuf拷贝到内核空间bwr；

9 binder_thread_write 当bwr写缓存有数据，则执行binder_thread_write；当写失败则将bwr数据写回用户空间并退出；

10 binder_transaction 找到目标进程binder_proc并插入数据到目标进程的线程todo队列，最终执行到它
时，将发起端数据拷贝到接收端进程的buffer结构体；

11 binder_thread_read 根据binder_transaction结构体和binder_buffer结构体数据生成新的binder_transaction_data结构体，写入bwr的read_buffer，当bwr读缓存有数据，则执行binder_thread_read；当读失败则再将bwr数据写回用户空间并退出；最后，把内核数据bwr拷贝到用户空间ubuf。

12 binder_thread_write + binder_ioctl BR命令和数据传递

Server:

13 IPC.executeCommand 解析kernel传过来的binder_transaction_data数据，找到目标BBinder并调用其transact()方法;

14 IPC.joinThreadPool 采用循环不断地执行getAndExecuteCommand()方法, 处理事务。当bwr的读写buffer都没有数据时,则阻塞在binder_thread_read的wait_event过程. 另外,正常情况下binder线程一旦创建则不会退出.

15 BBinder.transact 到Binder.exeTransact 调用 AMN.onTransact

16 AMN.onTransact 把数据传递到AMS.starService去执行

17 AMS.starService Server处理了Client的请求了

然后原路replay回去，talkWithDriver 到Kernel ，然后找到Client进程，把数据拷贝到read_buffer里，最终唤醒IPC，把反馈传递回AMP.startService。完成启动服务。

3.2 从通信协议流程来看：

非oneWay:

oneway:

oneway与非oneway区别: 都是需要等待Binder Driver的回应消息BR_TRANSACTION_COMPLETE. 主要区别在于oneway的通信收到BR_TRANSACTION_COMPLETE则返回,而不会再等待BR_REPLY消息的到来. 另外，oneway的binder IPC则接收端无法获取对方的pid.

3.3 从数据流来看

从用户空间开始：

进入驱动后：

回到用户空间：

参考：
http://gityuan.com/2016/09/04/binder-start-service/
http://gityuan.com/2015/11/28/binder-summary/
http://gityuan.com/2015/11/14/binder-add-service/
http://gityuan.com/2015/11/15/binder-get-service/

‘伍’ Android图形系统系统篇之HWC

HWC （hwcomposer）是Android中进行窗口（ Layer ）合成和显示的HAL层模块，其实现是特定于设备的，而且通常由显示设备制造商 (OEM)完成，为 SurfaceFlinger 服务提供硬件支持。

SurfaceFlinger 可以使用 OpenGL ES 合成 Layer ，这需要占用并消耗GPU资源。大多数GPU都没有针对图层合成进行优化，当 SurfaceFlinger 通过GPU合成图层时，应用程序无法使用GPU进行自己的渲染。而 HWC 通过硬件设备进行图层合成，可以减轻GPU的合成压力。

显示设备的能力千差万别，很难直接用API表示硬件设备支持合成的 Layer 数量， Layer 是否可以进行旋转和混合模式操作，以及对图层定位和硬件合成的限制等。因此HWC描述上述信息的流程是这样的：

虽然每个显示设备的能力不同，但是官方要求每个 HWC 硬件模块都应该支持以下能力：

但是并非所有情况下 HWC 都比GPU更高效，例如：当屏幕上没有任何变化时，尤其是叠加层有透明像素并且需要进行图层透明像素混合时。在这种情况下， HWC 可以要求部分或者全部叠加层都进行GPU合成，然后 HWC 持有合成的结果Buffer，如果 SurfaceFlinger 要求合成相同的叠加图层列表， HWC 可以直接显示之前合成的结果Buffer，这有助于提高待机设备的电池寿命。

HWC 也提供了 VSync 事件，用于管理渲染和图层合成时机，后续文章会进行介绍。

Android7.0提供了HWC和HWC2两个版本，默认使用HWC，但是手机厂商也可以选择HWC2，如下所示：

SurfaceFlinger 通过 HWComposer 使用 HWC 硬件能力， HWComposer 构造函数通过 loadHwcMole 方法加载HWC模块，并封装成 HWC2::Device 结构，如下所示：

上述通过 hw_get_mole 方法（hardware\libhardware\hardware.c）加载 hwcomposer 模块，此模块由硬件厂商提供实现，例如：hardware\libhardware\moles\hwcomposer\hwcomposer.cpp是 hwcomposer 模块基于HWC1的default实现，对应的共享库是 hwcomposer.default.so ；hardware\qcom\display\msm8994\libhwcomposer\hwc.cpp是高通MSM8994基于HWC1的实现，对应的共享库是 hwcomposer.msm8994.so 。
如果是基于HWC2协议实现，则需要实现hwcomposer2.h中定义的 hwc2_device_t 接口，例如： class VendorComposer : public hwc2_device_t 。Android7.0的 hwcomposer 模块默认都是基于HWC1协议实现的。
每个HAL层模块实现都要定义一个 HAL_MODULE_INFO_SYM 数据结构，并且该结构的第一个字段必须是 hw_mole_t ，下面是高通MSM8994 hwcomposer 模块的定义：

frameworks\native\services\surfaceflinger\DisplayHardware\HWC2.h主要定义了以下三个结构体：

它们是对 HWC 硬件模块的进一步封装，方便进行调用。 HWC2::Device 持有一个 hwc2_device_t ，用于连接硬件设备，它包含了很多HWC2_PFN开头的函数指针变量，这些函数指针定义在 hwcomposer2.h 。
在 HWC2::Device 的构造函数中，会通过 Device::loadFunctionPointers -> loadFunctionPointer(FunctionDescriptor desc, PFN& outPFN) -> hwc2_device_t::getFunction 的调用链从硬件设备中获取具体的函数指针实现。关键模板函数如下所示：

这些函数指针主要分为三类：

通过上述函数指针可以与 hwc2_device_t 表示的硬件合成模块进行交互。三类指针分别选取了一个示例：

可以通过类图，直观感受下引用关系。

HWC2::Device 构造函数除了完成获取函数指针实现以外，还会通过 Device::registerCallbacks 向硬件设备注册三个 Display 的回调：热插拔，刷新和VSync信号，如下所示：

总结一下， HWC2::Device 构造函数向硬件设备注册三个 Display 回调：热插拔，刷新和VSync信号。当 HWC2::Device 收到这些回调时，会通过监听器向外回调到对应的HWComposer函数： HWComposer::hotplug / HWComposer::invalidate / HWComposer::vsync 。HWComposer再通过这些信息驱动对应工作，后续文章进行介绍。

上文提到 HWC2::Device 中的函数指针是hardware\libhardware\include\hardware\hwcomposer2.h中定义的，除此之外，该头文件还定义了一些重要的结构体，这里介绍两个比较重要的：

DisplayType 表示显示屏类型，上面注释已经介绍，重点看下Layer合成类型：

那么一个 Layer 的合成方式是怎么确定的那？大致流程如下所示：

本篇文章只是简单介绍了HWC模块的相关类： HWComposer 、 HWC2::Device 、 HWC2::Display 和 HWC2::Layer ，以及它们的关系。此外，还着重介绍了Layer的合成方式和合成流程。后续文章会更加全面的介绍 SurfaceFlinger 是如何通过HWC模块完成Layer合成和上屏的（虚拟屏幕是到离屏缓冲区）。