By 高焕堂 2011/09/09
[ IT史上最完整、最经典的软件框架开发技术宝典 (上百篇经典文章&eBooks) ]
[Go Back]
HAL(Hardware Abstraction Layer)技术观点(8)：
为什么要继承ISensorService.Stub基类呢?
1. 前言
只要是Java 层的系统服务(Core Service)类别都会继承IXXXService.Stub基类。例如SensorService.java类别就继承ISensorService.Stub基类，如下述的程序代码：
// framework/base/services/java/SensorService.java
class SensorService extends ISensorService.Stub {
//…………………………………………….
// (省略)
//-------------------------------------------------------
private static native int _sensors_control_init();
private static native ParcelFileDescriptor _sensors_control_open();
private static native boolean _sensors_control_activate(int sensor, boolean activate);
private static native int _sensors_control_set_delay(int ms);
private static native int _sensors_control_wake();
}
再如BluetoothA2dpService .java类别就继承IBluetoothA2dp.Stub基类，如下述的程序代码：
//frameworks/base/core/java/android/server/BluetoothA2dpService.java
public class BluetoothA2dpService extends IBluetoothA2dp.Stub {
//…………………………………………….
// (省略)
//-------------------------------------------------------
private native boolean initNative();
private native void cleanupNative();
private synchronized native String[] listHeadsetsNative();
private synchronized native String createHeadsetNative(String address);
private synchronized native boolean removeHeadsetNative(String path);
private synchronized native String getAddressNative(String path);
private synchronized native boolean connectSinkNative(String path);
private synchronized native boolean disconnectSinkNative(String path);
private synchronized native boolean isSinkConnectedNative(String path);
}
再如FallbackCheckinService .java类别就继承ICheckinService.Stub基类，如下述的程序代码：
//frameworks/base/core/java/android/server/checkin/FallbackCheckinService.java
public final class FallbackCheckinService extends ICheckinService.Stub {
//…………………………………………….
// (省略)
//-------------------------------------------------------
}
为甚么呢? 有些人对这个感到很好奇。
2. 简单的目的和理由
其目的很简单，就是要包装IBinder接口而已。因为系统服务与其Client之间都是跨进程的IPC沟通，天生就必须具有IBinder接口，让其Client能跨进程来取得它的服务。然而，IBinder接口是由Android的Binder Driver开发者所设计的接口，Client只能呼叫其内含的单一transact()函数。为什么这些服务不直接提供ISensorService、ICheckinService接口呢? 这个问题就像家庭墙壁上的插座，不能支持两孔插头、三孔插头等，只能要求各种电器提供商(如同各领域的服务开发者)自备转接器(Adapter)。所以ISensorService.Stub 、ICheckinService.Stub等就是扮演转接器的角色。
难度高的SensorService开发途径
例如，在没有转接器的情形下，Java Client与核心服务之间就只能透过IBinder接口来沟通，如下图：
图1、没有封装IBinder的架构
这里的SensorService类别继承了Binder基类而得到IBinder接口。由于Binder基类有个抽象函数：onTransact()。这个SensorService类别必须实作(Implements)之。然而，对于SensorService类别的开发者而言，必须将onTransact()函数转换成对他有意义的setOn()和setOff()函数，增加了开发SensorService类别的困难度。 [歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
较简单的SensorService开发途径
如果有个ISensorService.Stub类别能将onTrasact()函数封装起来，转而呼叫setOn()和setOff()抽像函数，就解决掉上述的困难了，如下图：
图2、封装了IBinder的架构
此刻，SensorService服务开发者，就不需要在意onTransact()函数的写法了，直接实作他所熟悉的setOn()和setOff()函数即可了，因而减轻了SensorService服务开发这的负担了。
Client端的Adapter类别
上述的ISensorService.Stub类别是服务端(进程)的转接器，简化了SensorService.java类别的复杂度。此外，在Client端(进程)也能设计一个转接器，来简化Java Client本身的复杂度。如下图：
图3、Client端的Adapter
就Java Client模块的开发而言，此刻只需要使用ISensorService接口来呼叫所熟悉的setOn()和setOff()函数即可，不必知道IBinder的存在及其写法，因而简化许多了。◆
[Go Back]
