By 高焕堂 2011/09/09
[ IT史上最完整、最经典的软件框架开发技术宝典 (上百篇经典文章&eBooks) ]
[Go Back]
HAL(Hardware Abstraction Layer)技术观点(9)：
如何让App开发者来使用Native Service/HAL呢?
1. 基本动作：开发一个Native Service
首先以C++语言开发一个Native Service，取名为POSService.cpp，它透过HAL接口呼叫HAL Stub模块。将它编译和连结成为*.SO动态库。将此*.SO放入Android的/system/lib裡；然后启动它，让他执行于一个进程(Process)里，如下图：
图1、C++层Client跨进程取得SQRService的服务
2. C++ 层的App
C++层的AP开发者，只需要撰写他的App，例如取名为myAP.cpp。此时他只要使用指令：
sp<IServiceManager> sm = defaultServiceManager();
m_ib = sm->getService(String16("misoo.myservice"));
其首先呼叫ServiceManager去绑定myService服务，绑定完成时，会在AP的进程里，诞生一个BpBinder物件，并将其IBinder接口回传给myAP.cpp应用程序。如下图：
图2、C++层Client跨进程取得POSService的服务(一)
图3、C++层Client跨进程取得POSService的服务(二)
3. 一致的getSystemService()服务接口
关于这个，Jollen在其文章 http://www.jollen.org/blog/2010/02/override-context-getsystemservice.html 里写道：
「 Context.getSystemService() 是一个很重要的 API，也是Android 应用程控硬件的起点。在一个开发项目中，如何扩展 getSystemService() 的实作成为一个重要的课题。几天前与客户进行技术讨论时，适巧讨论到这个议题，因此在这里做一个简单的纪录与大家分享。应用程序要存取手机上的 Sensor 装置时，须取得 SensorManager 对象，程序写法如下：
public class mokoidSensor extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
SensorManager sensor = (SensorManager)getSystemService(SENSOR_SERVICE);
sensor.getSensors();
/* Do something. */
}}
如果手机上有一个「马达」装置，程序代码的写法，依此逻辑来推论，设想的程序代码会是这样：
MotorManager motor = (MotorManager)getSystemService(MOTOR_SERVICE);
// 省略后续部分
// ……
」
如何实践这条Android Service途径，Jollen在其著名的Android系列课程里，有非常出色的呈现。
4. SensorService的「Native化」
关于这个议题，Jollen在其2011年的文章： << Android 2.3 的更新：SensorService 的「Native 化」>>
http://www.jollen.org/blog/2011/01/andriod-23-sensorservice-native.html 里写道：
「 近期在进行 Android 2.3 的新框架程序代码研究，Android 2.3 在 Platform (Framework) 部份包含了许多重大的更新，其中一个部份就是 SensorService 改写成 Native Service 形式。在 Android 2.2 以前的框架，SensorService 包含在 SystemServer 里，实务上，可能也会对 SensorService 做小幅度改写，以增进效能，或是将 SensorService 独立成为一个 process。
在 Android 2.3 里的 SystemServer 已经找不到 SensorService 了，这个重要的 Android Service 被改写成 Native Service。「如何将 Android Service 改写为 Native Service」，以及「Native Service」的开发，从 Android 2.3 开始，将成为重量级主题。
由于 Android 2.2/2.3 可能是并行的关系，而非取代关系。因此，Android 2.2 以及 Android 2.3 的学习必要性很高；意思是，最好能由 2.1/2.2 的框架开发开始学习。了解 Android 2.1/2.2 的 SensorService 架构，再对 Android 2.3 的 SensorService 进行了解，除了可比较其设计与实作差异外，也能知道「效能改进之道」。了解过去 SensorService 架构与实作上的不足，以及 Android 2.3 的改写，解决了什么问题。Android 2.3 的 libhardware 没有太大变动。从 Anroid 2.1/2.2 开始的开发者，可以由 Android 2.3 的 SensorService 做为「更新知识」的进入点。」
在Jollen文章里并没有说明，Android 2.3版里将SensorService从Android Service移出来的幕后原因；我也还没去探究这个Native化的SensorService是否仍跑在SystemServer进程里，或是与CameraService等跑在同一个进程。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
5. Native Service的弹性
基于我在日本开发Android-based POS产品的经验，采取Native Service来呈现POS专属HAL Stub服务，最主要的优点就是弹性。如下图所示：
图4、Native Service主要的优点是：弹性
其弹性的观点如下：
- Native Service可以自主决定跑在哪一个进程里，尤其是跑在独立的进程里。
- 可以让C/C++的Client(如上图的POSService.cpp)使用此Native Service。
- 可以撰写C/C++模块来加强 Native层的数据处理，例如加速QR-code等影像处理。
- 放弃getSystemService()接口的束缚，让Java层更能百花齐放，创造多样化，例如可以衔接到应用程序里的SDK Service，成为专属的应用程序。
- 还有其它弹性的组合。
6. 结语
基于Android的开源和开放平台，我们能自主性地决定如何将专属硬件的创新功能呈现于应用程序上。至于如何将应用程序与驱动程序衔接起来，本文所述的两种途径都是可行的。Jollen在Android Service途径上，已经有非常完整的说明和范例。关于Native Service途径，我的文章也有很完整的叙述和范例。希望这些经验能加速你的系统或产品开发和上市。◆
[Go Back]
