Android SurfaceFlinger服务代理对象获取过程源码分析
Binder进程间通信机制在Android系统中无处不在，SurfaceFlinger服务依然采用Binder通信方式，每个应用程序进程在请求SurfaceFlinger服务时，首先需要获取SurfaceFlinger服务的代理对象，通过该 代理对象请求SurfaceFlinger为该应用程序进程在SurfaceFlinger服务端创建一个Client对象，该 对象专门接收处理当前应用程序的请求。Android系统中SurfaceFlinger的设计框架如下：
在Android SurfaceFlinger服务启动过程源码分析中已经介绍了SurfaceFlinger服务可以以服务进程方式启动，也可以以服务线程方式启动，当SurfaceFlinger服务以服务进程启动时，SurfaceFlinger运行在SurfaceFlinger进程中，当SurfaceFlinger服务以服务线程方式启动时，SurfaceFlinger服务运行在SystemServer进程中。Android应用程序也运行在独立的进程中，因此Android应用程序与SurfaceFlinger服务的交互就涉及到了Binder进程间通信。在学习SurfaceFlinger之前，需要先了解Android系统的Binder进程间通信方式，关于Binder进程间通信在Binder通信模块中通过一系列文章进行了详细的分析介绍。下图就是SurfaceFlinger在Binder通信框架下的类关系图：
当应用程序需要请求SurfaceFlinger服务时，首先需要构造SurfaceComposerClient对象，通过SurfaceComposerClient对象就可以访问SurfaceFlinger服务了。
在SurfaceFlinger服务进程中为每一个应用程序进程创建了对应的Client对象，用于接收应用程序进程的RPC请求，但Client并不处理客户端发送过来的请求，而是转交给SurfaceFlinger来处理。SurfaceFlinger服务中的代理对象到此就介绍完了，应用程序在构造SurfaceComposerClient对象时，获得了SurfaceFlinger服务的远程代理对象BpSurfaceComposer，Client的远程代理对象BpSurfaceComposerClient及匿名共享内存MemoryHeapBase的远程代理对象BpMemoryHeap，他们与SurfaceFlinger的关系如下：
