如果统观Binder中的各个组成元素，就会惊奇的发现它和TCP/IP网络有很多相似之处:

- Binder驱动 -> 路由器

- Service Manager -> DNS

- Binder Client -> 客户端

- Binder Server -> 服务端

TCP/IP中一个典型的服务连接过程（比如客户端通过浏览器方位Google主页）：

在这个简化的流程图中共出现了四种角色，即Client、Server、DNS和Router。它们的目标是让Client和Server建立连接，主要分为如下几个步骤。

- Client向DNS查询Google.com的IP地址。

显然，Client一定要先知道DNS的IP地址，才有可能向它发起查询。DNS的IP设置是在客户端接入网络前就完成了的，否则Client将无法正常访问域名服务器。当然，如果Client已经知晓了Server的IP，那么完全可以跨越这一步而直接与Server连接。比如Windows操作系统就提供了一个hosts文件，用于查询常用网址域名与其IP地址的对应关系。当用户需要访问某个网址时，系统会先从这个文件中判断是否已经存在有这个域名的对应IP。如果有就不需要再大费周折地向DNS查询了，从而加快访问速度。

- DNS将查询结果返回Client。

因为Client的IP地址对于DNS也必须是可知的，这些信息都会被封装在TCP/IP包中。

- Client发起连接。

- Client在得到Google.com的IP地址后，就可以据此来向Google服务器发起连接了。

在这一些列流程中，我们并没有特别提及Router的作用。因为它所担负的责任是将数据包投递到用户设定的目标IP中，即Router是整个通信结构中的基础。

从这个典型的TCP/IP通信中，我们还能得到什么提示呢？

首先，在TCP/IP参考模型中，对于IP层及以上的用户来说，IP地址是他们彼此沟通的凭证，任何用户在整个互联网中的IP标志符都是唯一的。

其次，Router是构建一个通信网络的基础，它可以根据用户填写的目标IP正确的把数据包发送到位。

最后DNS角色并不是必需的，它的出现是为了帮助人们使复杂难记的IP地址与可读性更强的域名建立关联，并提供查询功能。而客户端能使用DNS的前提是它已经正确配置了DNS服务器的IP地址。

Binder的本质目标用一句话来描述，就是进程1（客户端）希望与进程2（服务端）进行互访。但因为它们之间是跨进程（跨网络）的，所以必须借助于Binder驱动（路由器）来把请求正确投递到对方所在进程（网络）中。而参与通信的进程们需要持有Binder“颁发”的唯一标志（IP地址）。和TCP/IP网络类似，Binder中的DNS也并不是必需的，前提是客户端能记住它要访问的进程的Binder标志（IP地址）。而且要特别注意这个标志是动态IP，这就意味着即使客户端记住了本次通信过程中目标进程的唯一标志，下一次访问仍然需要重新获取，这无疑加大了客户端的难度。DNS的出现可以完美的解决这个问题，用于管理Binder标志与可读性更强的域名间的对应关系，并向用户提供查询功能。既然Service Manager是DNS，那么它的IP地址是什么呢？ Binder机制对此作了特别规定，Service Manager在Binder通信过程中的唯一标志永远都是0.

Linux内核提供了统一的framebuffer显示驱动。设备节点/dev/graphics/fb*或者/dev/fb*，其中fb0表示第一个Monitor，当前系统中只用到了一个显示屏。

Android的HAL层提供了Gralloc，包括fb和gralloc两个设备。前者负责打开内核中的framebuffer、初始化配置，并提供了post、setSwapInterval等操作接口。后者则管理帧缓冲区的分配和释放。这就意味着上层元素只能通过Gralloc来间接访问帧缓冲区，从而保证了系统对framebuffer的有序使用和统一管理。

另外，HAL层的另一重要模块是“Composer”，如其名所示，它为厂商自定制“UI合成”提供了接口。Composer的直接使用者是SurfaceFlinger中的HWComposer，后者除了管理Composer的HAL模块外，还负责VSync信号的产生和控制。VSync则是Project Butter工程中加入的一种同步机制，它既可以由硬件产生，也可以通过软件来moni（VsyncThread)。

Framebuffer是系内核系统提供的图形硬件的抽象描述。之所以称为buffer，是因为它也占用了系统存储空间的一部分，是一块包含屏幕显示信息的缓冲区。由此可见，在一切都是文件的Linux系统中，Framebuffer被看成了终端显示设备的化身。

另外，Framebuffer借助于Linux文件系统向上层应用提供了统一而高效的操作接口，从而让用户空间中运行的程序可以在不做太多修改的情况下去适配多种显示设备，无论它们属于哪家厂商、什么型号，都由Framebuffer内部来兼容。

在Android系统的GUI设计理念中，提供了两种本地窗口：

- 面向管理者（SurfaceFlinger）

既然SurfaceFlinger扮演了系统中所有UI界面的管理者，那么它无可厚非需要直接或间接地持有“本地窗口。这个窗口就是FramebufferNativeWindow。

- 面向应用程序

这类本地窗口是Surface。

打个比方，就像一出由N个演员参与的话剧：SurfaceFlinger是摄像机，WMS是导演，ViewRoot则是演员个体。摄像机（SurfaceFlinger）的作用是单一而规范的，它负责客观地捕获当前的画面，然后真是的呈现给观众。导演（WMS）则会考虑到话剧的舞台效果和视觉美感，如他需要根据实际情况来安排各个演员的排序站位，谁在前谁在后，都会影响到演出的”画面效果“与”剧情编排“，而各个演员的长相和标清（ViewRoot）则更多的取决于他们自身的条件与努力。正式通过这三者的”各司其职“，才能最终为观众呈现出异常美妙绝伦的”视觉盛宴“。

然后在这个新的进程中启动这个Activity或者Service。

无论以什么方式发起一个Activity的启动流程，最终都会调用到AMS的startActivity的函数。而在AMS真正启动一个Activity之前，需要经过众多烦琐的判断和准备工作，这些工作在AMS内部都是由一些列以startActivity开头的函数来进行逐步处理的。