Android Camera Subsystem 架构（Binder机制）及显示分析（2）

但是要问，这样一种组织如何将binder引入其中呢，这么多接口又是如何组织的？

首先，如果是我们自己一旦确定使用C/S架构。那么我们肯定会至少定义两个类，一个是Client类，一个是Server类。哪如何实现Client与Server之间的交互呢，或者通信呢？不用问肯定想到了网络通信Socket。因为很多时候大家只要提到Client和Server，第一本能好像就会联想到网络通信Socket，其实这个本能害人不小，让你失去了很多了解真相的机会。我们学过最基本的IPC能叫得上名字的至少有6种，其中socket只是其中的一种，也可以说socket是网络环境下最常用的一种通信方式。如果你了解linux内核，你就会知道socket的用处绝不仅限于此。说到底双方只要达到对消息结构的一致解释，就可以实现通信，完成相应的功能需求。那如果我告诉你，Client端和Server端运行在同一台机器上，使用同一根内存条。我们是不是又本能的想到了共享内存呢，这会你怎么没想到socket呢？我们能不能使用本地socket呢？其实Android中很多系统服务就是利用的本地socket来实现进程通信，通过在init的时候创建，然后在模块启动之后直接引用，因为socket无非就对应着本地文件么，创建了之后就放在那里。例如vold中就充分利用了socket。当然本地Socket、共享内存只是我们众多备选方案中最常用的两种。每次谈到IPC，很多人都觉得很难懂。其实很多时候是我们自己理解复杂了，将能用鼠标点到和眼睛看到的东西掉入了内存，就觉得摸不到了，结果给自己设置了一些障碍。举个例子，不考虑时间，最通俗的方法，你在随手建的文件夹test中写一个带main函数的程序，通过该程序在当前目录下创建并写了一个文件；随后你又在同一个目录下又创建了另一个带main函数的程序，执行该程序去访问先前程序创建的文件，你对文件又做了修改。这样两个进程实际上就实现了通信，你觉得这很容易理解，因为你将自己的思维定格在了这个test文件夹中，你能不能更深更远的拓展一下这种思维呢。而为让这种通信得到有效的保证，随后我们又提出同步，锁机制等等。

言归正传，一个进程和另一个进程要交换数据，或者要协同工作，抽象到程序上来说就是类与类之间的引用关系，函数之间的调用关系。我自己将其分为两类，一种是采用依赖调用的方式，另一种是消息机制。我在这里要说的意思是，通信双方要不要为对方提供完整的调用接口。如果我是采用依赖调用，我得知道我能调用你那些方法，这样就必须为调用者提供完整的调用接口；如果采用消息解析，我得知道我能发送那些消息或者命令，至于你能对这些命令做出符合协议规定的动作那是你的事，我只需要结果，那至少要维护一个命令接收和命令处理的状态机。两者的实质是一样，其实依赖调用按照面向对象来说也是一种消息机制。如果是依赖调用，那我们就必须提供一定的权限和完整的结构供对方调用。最基本的：如果是C函数，那你就不能把供别人调用的方法在实现文件中定义为static；如果是C++,那你就不能把它定义为private，protected（protected其实还说的过去，至少自己人可以访问）。如果是消息，我们得看看你响应的命令集或消息结构。

我第一次拿到Camera Subsystem的时候，就被从网上看到的这句话给蒙住了“ICamera/ICameraClient/ICameraServices三个类是按照Binder IPC要求的框架实现的”。我要问，到底是按什么框架要求实现的？我知道它的Client端和Service端用了Binder通信机制，但我一直捉摸不透，这个框架它为什么要求定义那么多接口，还有那么多所谓的Proxy Class和Native Class，还相互继承来继承去的。后来我总算明白了一点，他们是用了一些设计模式才会弄得这么复杂，给自己看不懂找点借口。后来我对自己产生怀疑，我问自己仅仅是设计模式的原因吗，你真的懂细节吗？我发现我还一时回答不了这个问题，我觉得还是我没搞清楚这些结构定义的目的和他们之间的调用关系。

回到Android的Binder。至少在Camera Subsystem中来看Binder通信。用我自己的理解，Binder通信机制正好是结合了依赖调用和消息机制。ICamera、ICameraClient、ICameraService为Camera Client端和Camera Service端之间的交互提供了完备的接口，这样实现了他们之间的相互调用，而隐含在这些接口下面的却是一块共享内存，这块共享内从由上层的ProcessState和IPCThreadState和内核的Binder Driver来管理。而Binder中的transact和OnTransact方法就分别对应着命令接收器和命令处理器。

再看Camera Subsystem。首先，如果不考虑Camera HAL层，在Camera Subsystem Native层存在三个主要对象：一个是充当Camera Client的Camera类；一个是充当Camera Server的CameraService类；还有另一个无名英雄类CameraService::Client类，说它是无名英雄，一点都不过分，它几乎干了CameraService的所有事情，也可以认为CameraService是个高明的管理者，它善于放权，把一切都交给CameraService::Client类来处理。如果是我，我肯定不会设计出CameraService::Client这个类来，我肯定是CameraService包揽一起，因为我还不懂得功能细化，最主要的原因是我还没有足够的经验和能力设计出它。首先站在Client的角度，要完成两件事，

一是与Server端建立连接，我自己都克制不住socket的思想又冒出来了，其实很简单，我们只要new 一个Client对象，把这个对象赋值给Server端内部维护的Client指针，同时在new一个Server对象，赋值给Client端内部的Server指针，只要双方能够彼此引用，那么连接就已经建立起来了；

二是通过各自内部保存的对方的句柄，调用相应的功能，完成请求和响应。而从Server端角度来说，一是我要响应Client端的请求，包括连接请求和功能请求，二是我必须维护对Client的管理，因为我这里可能并不是只针对一个Client。

考虑到Server端还要与HAL打交道，对Client端的请求做出响应。问题越来越清晰，Server端的功能可以明确的划分为两部分，一部分是专门实施对Client的管理，而另一部分则是完成Client的请求并作出响应。但是这种划分对Client来说是透明的，它看到的只有CameraService，在Client看来，他的所有请求都由CameraService完成。当然CameraService在公关场合，也体现出了这种能力，而在内部做了合理布局，这样CameraService就很自然的设计出了CameraService::Client类，帮助CameraService更好的为Client服务，同时CameraService::Client类的对象也正好与每一个Client相对应，CameraService只要维护本地CameraService::Client的对象，就能实现对Client的管理。

在这样一个基本框架形成之后，我们需要考虑细节，现在系统中存在Camera(CameraClient)、CameraService、CameraService::Client三个实体。而对于这三个实体，我们有了调用接口之后，我们还需要命令处理来完善他们之间的通信。我们首先想到的是：我们需要一个命令接收器、一个命令缓冲器（命令队列）和一个命令处理器。再看Binder，binder本质是共享内存，它告诉我们只需要一个命令接收器和命令处理器，而命令队列由Binder的驱动来完成。既然确定了必须要有一个命令接收器，和一个命令处理器，那从功能划分的思想来看，命令接收器肯定是要提供给调用者，这样调用者才能将命令投递到我们的接收器中，所以命令接收器必须是一个为对端开放的接口，而对端并不需要知道我们去如何处理这些命令，那么我们的命令处理器对对端来说应该是隐藏的。

通过分析，在我得到了上面这些信息之后，首先我会立马想到一个solution，我首先会定义一个抽象类叫BinderInterface, 然后里面至少有两个方法，就是transact和onTransact；然后定义transact为一个public的纯虚函数，定义onTransact为一个protected的纯虚函数。然后我们在BinderInterface的派生类中去分别实现这两个方法。其实按我自己的想法，觉得这样没有错。

到这里，还是回去看看binder的源码，看看实际系统是如何实现的，binder本地层源码给出了三个类：IBinder、BpBinder、BBinder（叫BnBinder更好）。其中IBinder相当于是我上面提到的BinderInterface类，但是按照我上面的想法，IBinder类中应该有transact和onTransact方法啊，可是找了半天，却只发现一个transact方法，但是transact方法确实是public权限，我有点疑惑，算了我还是看看BpBinder和BBinder类的定义吧。

class BpBinder : public IBinder class BBinder : public IBinder

原来BpBinder和BBinder都继承与IBinder，我继续往下看了看BpBinder和BBinder的函数结构，发现BpBinder和BBinder对IBinder中的纯虚方法都进行了申明，而且也是virtual函数，如果你思维够敏锐，对面向对象理解深刻，那基本可以猜到BpBinder和BBinder的作用了，那就是如果不出差错，利用他们基本可以构造出Binder的架构。即便如此，我没有断然做出定论，而是继续观察这两个类，因为我还有一桩心事未了，那就是还没看到onTransact方法，如果看不到onTransact，那我之前的推理至少是不合理的。突然眼前豁然开朗，在BBinder类中找到了onTransact，这时候就要问自己了，为什么Binder模块会将onTransact方法放在BBinder中，而没有将其一开始就放在IBinder中呢，我思考了一下，尽量使自己能理解这种设计的初衷。我想了想，难道？不错，就是设计模式，结合类的命名和我浅显的设计模式知识，这就是代理模式。IBinder既然作为一种接口，而接口的目的是供调用者使用的，那么onTransact作为一个内部方法，就不应该展现给调用者，所以在最高层的抽象中，并不会出现onTransact方法，而是在抽象层的下层利用设计模式，将这种职权进行划分，设计出一个Proxy类和Native类，将Proxy类呈献给调用者，而对调用者隐藏Native类，所以我们会在Proxy类中真正实现ontrasact方法，而在Native类中实现onTransact方法。这样我们上面设计的不合理性就会暴露出来。

在回到CameraSubsystem中，如果我们要实现Camera(CameraClient)、CameraService、CameraService::Client三个实体之间的Binder通信，那在每一个端，我们都必须去继承于BpBinder和BBinder类，来构造这种所谓的Proxy端和Native端。所以每个模块至少要有对应的两个类一个BpCamera***类，和一个BnCamera***类，在BpCamera***类中实现transact方法，在BnCamera***类中实现onTransact方法，最终达到各实体之间的数据交换。