Android系统匿名共享内存（Anonymous Shared Memory）C++调用接口分析（2）
回到前面MemoryHeapBase类的构造函数中，将匿名共享内存映射到本进程的地址空间去后，还看继续设置这块匿名共享内存的读写属性：
上面调用mapfd函数来映射匿名共享内存时，指定这块内存是可读写的，但是如果传进来的参数flags设置了只读属性，那么还需要调用系统运行时库存层的ashmem_set_prot_region函数来设置这块匿名共享内存为只读，这个函数定义在system/core/libcutils/ashmem-dev.c文件，有兴趣的读者可以自己去研究一下。
这样，通过这个构造函数，一块匿名共享内存就建立好了，其余的三个成员函数getHeapID、getBase和getSize就简单了：
接下来我们再来看一下MemoryHeapBase在Client端实现的类图：
这个类图中的类也是可以划分为两部分，一部分是和业务相关的，即跟匿名共享内存操作相关的类，包括BpMemoryHeap、IMemoryBase和RefBase三个类，另一部分是和Binder机制相关的，包括IInterface、BpInterface、BpRefBase、IBinder、BpBinder、ProcessState和IPCThreadState七个类。
在和匿名共享内存操作相关的类中，BpMemoryHeap类是前面分析的MemoryHeapBase类在Client端进程的远接接口类，当Client端进程从Service Manager或者其它途径获得了一个MemoryHeapBase对象的引用之后，就会在本地创建一个BpMemoryHeap对象来代表这个引用。BpMemoryHeap类同样是要实现IMemoryHeap接口，同时，它是从RefBase类继承下来的，因此，它可以与智能指针来结合使用。
在和Binder机制相关的类中，和Server端实现不一样的地方是，Client端不需要实现BnInterface和BBinder两个类，但是需要实现BpInterface、BpRefBase和BpBinder三个类。BpInterface类继承于BpRefBase类，而在BpRefBase类里面，有一个成员变量mRemote，它指向一个BpBinder对象，当BpMemoryHeap类需要向Server端对象发出请求时，它就会通过这个BpBinder对象的transact函数来发出这个请求。这里的BpBinder对象是如何知道要向哪个Server对象发出请深圳市的呢？它里面有一个成员变量mHandle，它表示的是一个Server端Binder对象的引用值，BpBinder对象就是要通过这个引用值来把请求发送到相应的Server端对象去的了，这个引用值与Server端Binder对象的对应关系是在Binder驱动程序内部维护的。这里的ProcessSate类和IPCThreadState类的作用和在Server端的作用是类似的，它们都是负责和底层的Binder驱动程序进行交互，例如，BpBinder对象的transact函数就通过线程中的IPCThreadState对象来将Client端请求发送出去的。这些实现具体可以参考
Android系统进程间通信（IPC）机制Binder中的Client获得Server远程接口过程源代码分析
一文。
这里我们主要关注BpMemoryHeap类是如何实现IMemoryHeap接口的，这个类声明和定义在frameworks/base/libs/binder/IMemory.cpp文件中：
先来看构造函数BpMemoryHeap的实现：
它的实现很简单，只是初始化一下各个成员变量，例如，表示匿名共享内存文件描述符的mHeapId值初化为-1、表示匿名内共享内存基地址的mBase值初始化为MAP_FAILED以及表示匿名共享内存大小的mSize初始为为0，它们都表示在Client端进程中，这个匿名共享内存还未准备就绪，要等到第一次使用时才会去创建。这里还需要注意的一点，参数impl指向的是一个BpBinder对象，它里面包含了一个指向Server端Binder对象，即MemoryHeapBase对象的引用。
其余三个成员函数getHeapID、getBase和getSize的实现是类似的：
即它们在使用之前，都会首先调用assertMapped函数来保证在Client端的匿名共享内存是已经准备就绪了的：
在解释这个函数之前，我们需要先了解一下BpMemoryHeap是如何知道自己内部维护的这块匿名共享内存有没有准备就绪的。
在frameworks/base/libs/binder/IMemory.cpp文件中，定义了一个全局变量gHeapCache：
它的类型为HeapCache，这也是一个定义在frameworks/base/libs/binder/IMemory.cpp文件的类，它里面维护了本进程中所有的MemoryHeapBase对象的引用。由于在Client端进程中，可能会有多个引用，即多个BpMemoryHeap对象，对应同一个MemoryHeapBase对象（这是由于可以用同一个BpBinder对象来创建多个BpMemoryHeap对象），因此，当第一个BpMemoryHeap对象在本进程中映射好这块匿名共享内存之后，后面的BpMemoryHeap对象就可以直接使用了，不需要再映射一次，当然重新再映射一次没有害处，但是会是多此一举，Google在设计这个类时，可以说是考虑得非常周到的。
我们来看一下HeapCache的实现：
它里面定义了一个成员变量mHeapCache，用来维护本进程中的所有BpMemoryHeap对象，同时还提供了find_heap和get_heap函数来查找内部所维护的BpMemoryHeap对象的功能。函数find_heap和get_heap的区别是，在find_heap函数中，如果在mHeapCache找不到相应的BpMemoryHeap对象，就会把这个BpMemoryHeap对象加入到mHeapCache中去，而在get_heap函数中，则不会自动把这个BpMemoryHeap对象加入到mHeapCache中去。
这里，我们主要看一下find_heap函数的实现：
这个函数很简单，首先它以传进来的参数binder为关键字，在mHeapCache中查找，看看是否有对应的heap_info对象info存在，如果有的话，就增加它的引用计数info.count值，表示这个BpBinder对象多了一个使用者；如果没有的话，那么就需要创建一个heap_info对象info，并且将它加放到mHeapCache中去了。1