android Binder

由于Android的Java层级只是一个外壳框架而已，大部分的系统组件(Android本身)都是在Nataive层(又称C/C++层)执行。这是Android的整体架构，所以我们的应用程序也必须考虑分为两层的必要性，才能完全的融入Android的整体架构里。我们看到的Android应用架构(Application Framework)其实只是Android整体架构里的外壳结构而已。Android应用框架就如同椅子的椅面，那么椅子的椅腿在哪里呢？

兹以Android系统来举例说明！

Binder系统是在Native层的C/C++组件。Java应用程序(如Activity体系等)是透过JNI界面去呼叫Binder系统(或称为组件)。

在Android里有一个ServiceManager掌管Java层级的Service物体。例如：

OnCreate(){

IServiceManageris=ServiceManager.getIServiceManager();

}

此时，会立即呼叫ServiceManagerNative物件，然后透过JNI函数：

BinderInternal.getContextObject()

取得C/C++层的BpServiceManager物件之参考(Reference)。也就是说，is所参考到

ServiceManager物件是转而呼叫到C/C++层的BpServiceManager物件，提供实质的远距(Remote)的ServiceBinding的服务。

当ServiceManager取得(经由JNI)了C/C++层的BpServiceManager物件之参考后，Java层的Binder物件就利用此物体参考建立关联了。Java层的Binder物体也提供了IBinder界面给远距的Client来使用。Binder类别体系的物理内涵有Proxy(代理)和stub标准的远距沟通结构，由ServiceManager在Client端诞生一个Proxy物件，给Client端(如Acitivity)能透过IBinder界面或有AIDL语言所定义的界面来呼叫Proxy物件，再由Proxy来与C/C++层的远距Service物件进行高效率的通讯。

所以，ServiceManager的工作大部分是在C/C++层执行的。Java层级的物件，以JNI方式呼叫C/C++层的Binder系统。

记得，Android的ServiceManager本身也是一个系统服务，它也是在Linux的一个进程(Process)里执行，这称为Servicemanagerprogress。从Java层的ServiceManager呼叫(JNI)到C/C++层的BpServiceManager之后，BpServiceManager还是将讯息转交到servicemanagerprogress里的组件。

由于椅腿直接地接触滴接触地面(即硬体Linux)，所以椅腿的技术决定椅子是否会稳定的关键因素。

注意事项：

1.维持一面的完整和稳定是首要目标，唯有如此，才能吸引众多的Android应用程序，进而吸引广大的手机用户

2.修正椅腿来配置地面(硬体),又能支撑椅面的完整。

对于Android而言，使用JNI介面是不是一种违章建筑(即不属于Android构架的一环)呢？修正应该很明了了，以Binder系统为例说明JNI也是Android系统本身的核心机制之一，应该不算是违章建筑！