在前面一篇文章Android系统匿名共享内存Ashmem（Anonymous Shared Memory）驱动程序源代码分析中，我们系统地介绍了Android系统匿名共享内存的实现原理，其中着重介绍了它是如何辅助内存管理系统来有效地管理内存的，在再前面一篇文章Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划中，我们还提到，Android系统匿名共享内存的另外一特点是通过Binder进程间通信机制来实现进程间共享的，本文中，将详细介绍Android系统匿名共享内存是如何使用Binder进程间通信机制来实现进程间共享的。
由于Android系统匿名共享内存在进程间共享的原理涉及到Binder进程间通信机制的相关知识，所以希望读者在继续阅读本文之前，最好对Android系统的Binder进程间通信机制有一定的了解，具体可以参考Android进程间通信（IPC）机制Binder简要介绍和学习计划这篇文章。
在Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划这篇文章中，我们举了一个例子来简要地介绍了Android系统的匿名共享内存机制及其使用方法，在这篇文章中，我们继续以这个实例来说明Android系统的匿名共享内存是如何使用Binder进程间通信机制来实现进程间共享的。为了方便描述，结合前面的Binder进程间通信机制知识，我们通过下面这个序列图来总结这个实例中的匿名共享内存文件的文件描述符在进程间传输的过程：
这里， 我们需要关注的便是虚线框部分了，它在Binder驱动程序中实现了在两个进程中共享同一个打开文件的方法。我们知道，在Linux系统中，文件描述符其实就是一个整数。每一个进程在内核空间都有一个打开文件的数组，这个文件描述符的整数值就是用来索引这个数组的，而且，这个文件描述符只是在本进程内有效，也就是说，在不同的进程中，相同的文件描述符的值，代表的可能是不同的打开文件。因此，在进程间传输文件描述符时，不能简要地把一个文件描述符从一个进程传给另外一个进程，中间必须做一过转换，使得这个文件描述在目标进程中是有效的，并且它和源进程的文件描述符所对应的打开文件是一致的，这样才能保证共享。
在浅谈Service Manager成为Android进程间通信（IPC）机制Binder守护进程之路一文中，我们介绍了用来传输的Binder对象的数据结构struct flat_binder_object，它定义在kernel/common/drivers/staging/android/binder.h 文件中：
/* * This is the flattened representation of a Binder object for transfer * between processes. The 'offsets' supplied as part of a binder transaction * contains offsets into the data where these structures occur. The Binder * driver takes care of re-writing the structure type and data as it moves * between processes. */ struct flat_binder_object { /* 8 bytes for large_flat_header. */ unsigned long type; unsigned long flags; /* 8 bytes of data. */ union { void *binder; /* local object */ signed long handle; /* remote object */ }; /* extra data associated with local object */ void *cookie; };域type是一个枚举类型，它的取值范围是：