论山寨手机与Android 【13】SmartPhone AP部分软件系统

在第9章中我们提到，从功能上讲对于智能手机的一个粗略的概括是，智能手机 == 电脑 + 移动网卡，或者更准确地说，智能手机的硬件结构分为应用程序处理器AP，和基带处理器BP两个部分。这里隐含着两个问题，

1. BP部分与AP部分的集成。

2. 传统的功能手机只配备了出厂时预装的应用软件，而不允许用户自主下载并安装第三方应用软件，而智能手机突破了这一限制，因此智能手机的AP部分，必须有相应的开放机制，方便第三方软件的开发与安装，同时尽可能降低第三方软件造成对整个系统，包括其它软件的恶意伤害。更进一步说，智能手机的开放机制，不仅针对第三方软件，而且也针对手机生产厂家，允许手机生产厂家更换手机系统的部分硬件设备，或者增设其它外设硬件设备，做到一个通用平台可以出货多个手机型号，帮助手机生产厂家尽可能降低手机研发费用。

对于第一个问题，BP部分如何与AP部分集成，解决方案的思路很简单。翻开任何一本操作系 统教科书，都可以看到标准的分层结构，应用软件 >> 操作系统 >> 驱动器 >> 硬件。不妨把BP与AP的集成，与操作系统中的文件系统的构成相比较。

文件系统通常包括虚拟文件系统（Virtual File System，VFS）与实际存储设备（Storage Device）两部分。实际存储设备包括闪存或者硬盘等等存储硬件，以及相应驱动器。虚拟文件系统通过驱动器操纵存储硬件，在这个基础上实现文件和文件夹的建立与删除，文件读写等等功能。虚拟文件系统之所以被称为虚拟，是因为应用软件通过标准的接口（APIs），来调用虚拟文件系统实现的文件和文件夹的功 能，而与实际存储设备究竟用的是哪一家厂商出品的硬件和驱动器无关[1]。

如果把文件系统中的实际存储系统类比成智能手机的BP部分，那么虚拟文件系统相对应的是AP部分中的Telephony Stack。Telephony Stack提供三个功能，

1. 与BP部分的系统间通讯（Inter-Processor Communication，IPC），给BP部分下达指令，建立通信通道，发送及接受语音和数据信息。IPC的实现方式可以是通过传递AT-Command，也可以是利用共享内存来实现数据交换。

2. 围绕BP部分提供的三大基础功能，即语音通话，短信等数据通信，以及SIM卡管理，加上与之密切相关的电话本（Address Book），提供以下服务，
– 拨打电话：发起或接受语音电话。
– 短信管理：编辑短信，发送短信，接受短信，删除，回复或者转发短信等等。
– 通话历史。
– 电话本。
– 手机振铃及振动设置。
– SIM卡管理。

3. 提供标准的调用接口（Telephony APIs， TAPI），方便应用软件调用上述服务。

Figure 13-1描述的是WinMobile 6的AP系统中，Telephony Stack的内部结构。图中紫色部分的模块，严格来说，并不属于Telephony Stack，它们是应用软件，它们通过调用Telephony APIs来使用黄色部分模块的功能。黄色部分的模块，负责实现拨打电话，短信管理，SIM卡管理，通话历史等等功能，称作cellcore，由 cellcore.dll提供，手机设计厂家不可以更改cellcore。蓝色部分模块，主要是RIL（Radio Interface Layer），它负责AP部分与BP部分之间的系统间通讯。RIL部分是硬件相关的，由手机设计厂家完成。

Figure 13-1. WinMobile Telephony Stack.
Courtesy http://farm5.static.flickr.com/4030/4461979382_a450147727_o.png

第一个问题，BP与AP的集成，比较容易解决。第二个问题，AP的开放机制，提供调用系统资源的标准接口，既方便第三方软件的开发与安装，同时也尽可能降低开放的风险，这个问题不太容易解决。什么方式的调用接口才算方便，什么程度的风险控制才算安全，这两个指标都缺乏公认的衡量准则。在当前情况下我们能做的，或许是比较几个智能手机的AP部分的设计，分析一下谁更方便更安全。

Figure 13-2描述的是，Telephony Stack在整个WinMobile系统中的位置，由红色方框界定。WinMobile为第三方软件提供了Win32 APIs，Win32 APIs不仅提供了分配内存，控制进程与线程，读写文件，连接网络等等基本功能的调用接口（APIs），也提供了开启和关闭窗口，以及控制窗口控件的 GUI相关的APIs。

Figure 13-2. WinMobile Architecture.
Courtesy http://farm3.static.flickr.com/2756/4497998261_22aa6faf22_o.png

Win32 APIs功能全面，但是使用难度大。很多APIs附带的参数很多，很多重复性的工作没有被封装，导致应用软件的开发，不仅代码量大，而且容易出错。 有鉴于此，微软把纯C的Win32 APIs，用VC++重新包装，形成MFC（Microsoft Foundation Classes）。作为一种Object-Oriented语言，VC++具有封装（Encapsulation），多态（Polymorphism）， 继承（Inheritage）等等特性。MFC利用 VC++这些特性，大大简化了对Win32 APIs的调用方式，程序员可以用更精简的代码，完成应用软件的开发。

微软把MFC称为一种Application Framework。Application Framework这个概念的兴起，源于寻求降低GUI开发的难度。GUI的开发，涉及图形，布局，事件捕捉与响应，消息传递等等诸多技术，不仅入门难，而且容易出错。Application Framework借助多种编程环境（IDE），工具集，和软件系统定式，例如MVC定式，不仅简化了编程的复杂度，而且通过规范编程方式，降低了出错的风险[2]。

MFC中的Object，可以直接分配内存，所以当清除Object时，需要手工清除内存分配，不留残余。防范内存泄漏，不仅是应用软件开发过程中的难点，而且也容易出bug。如果把MFC中的Object，称为原生态的Object（Native Object），那么Jave和C#/.NET中的Object，是受管制的Object（Managed Object）。所谓受管制，主要体现在Virtual Machine中的垃圾收集器（Garbage Collector）负责管理它们占用的内存空间，而不需要编程者手工分配内存，与清除内存。

Google的智能手机 OS，Android，把Telephony功能封装成Java Object，Telephony Manager。依此类推，把GPS功能也封装成Java Object，Location Manager，此外还有Resource Manager等等。通过这些Manager Java Object，把外设硬件（peripheral）的功能封装起来，提供简单的调用接口，降低了应用软件开发的难度，提高了程序员的生产力。同时，还提供 Activity Manager，Window Manager，Content Provider，View System，Notification Manager等等，简化并规范GUI的开发[3,4]。

这些Java Object运行在Virtual Machine上，它们的内存占用受Garbage Collector管制，从而降低了内存泄露的风险。另外，Android给每个应用软件都分配了独立的VM实体，如果某个应用软件出错，导致支撑其运行的VM实体崩溃，但是通常不会殃及运行其它应用软件的VM实体，从而提高了系统的整体安全。

与MFC相比，Android的 Application Framework，更方便，更安全。当然也有代价，代价是损耗了运行速度。

Figure 13-3. Android Architecture [4].
Courtesy http://farm3.static.flickr.com/2713/4497986885_7b1f93c360_o.png

Android的开放机制，不仅体现在Application Framework，而且还体现在Hardware Abstraction Layer（HAL）。关于设置HAL的意义，Google有三点说明[4]，

1. 为各种硬件器件制订标准的驱动器接口。

2. 由于Android的内核是开源的，服从GPL许可。而有些硬件器件厂商不愿意开源他们的驱动器程序，有了HAL这个隔离带，就可以解决开源的内核与不开源的硬件驱动器之间的矛盾。

3. Android对于硬件驱动器有一定要求。

这三点说明涉及手机制造产业链上的三个参与 者，

1. 如果有标准的驱动器接口，最大的受益者是手机生产厂商。只要硬件外设生产商按照标准接口提供相应的硬件驱动程序，手机生产商就可以自由选择各种配件，大大简化了手机的集成的难度和时间。

2. 不必开源的驱动器程序，受益者是硬件器件生产厂商，而且不给手机生产厂商制造困扰。

3. 比较难以理解的是Android对硬件驱动器会有哪些要求，Android为什么要提出这些要求。为了理解这个问题，不妨分析一个实例，看看 Android HAL是如何处理Telephony的。

Figure 13-4描述的是与Telephony相关的各个层次之间的协作关系。我们关心的HAL，在图中以Libraries（User Space）命名，Telephony HAL的内部结构以绿色标注，包含两个构件，Radio Daemon和Vendor RIL。

1. Radio Daemon，它是由Android提供的，不随BP硬件的生产厂家和型号而改变。在Android启动时，Radio Daemon就被激活，并一直处于运行状态，直到Android关闭[4]。

2. Vendor RIL（Radio Interface Layer）。Vendor RIL由BP部分生产厂家提供，不同品牌的BP，以及不同型号的BP，绑定不同的Vendor RIL。Vendor RIL的存在形式是一个函数库文件，文件命名必须服从约定的规范，libril-<companyname>-<RIL version>.so，方便Radio Daemon查找可用的Vendor RIL[5]。

在实时运行时，应用软件调用 Telephony Stack，而Telephony Stack指示Radio Daemon去发现当前可用的Vendor RIL，并动态载入相应的.so函数库。也就是说，让Radio Daemon去实现热拔插（Plug-and-Play）的功能。Vendor RIL函数库负责AP与BP之间的IPC。至此，从应用软件，到Telephony Stack，到HAL中的Radio Daemon和Vendor RIL，到BP部分的硬件和驱动器，全线贯通。全线贯通后，应用软件就可以处理拨打电话，发送短信等等通信业务了[4,5,6]。

虽然 Figure 13-4仅仅描述了与Telephony相关的各个层次之间的协作关系，但是对于其它功能，各个层次之间的协作关系也大致相仿，例如音响控制，和电源管理等等。

Android HAL隐含的意义在于，允许Android手机外接其它硬件设备，例如温度计，扩大手机的功能。

Figure 13-4. Android Telephony system architecture [5].
Courtesy http://farm5.static.flickr.com/4066/4498024565_4c10a45173_o.png

总结一下，智能手机AP部分与BP部分集成，类似于文件系统中通用的VFS与不同厂家提供的Storage Device的集成。BP部分提供基础的通话，数据通信，和SIM卡功能。而AP部分围绕这些基础功能，提供丰富的服务，例如通话记录，短信的编辑回复和转发等等。这些服务，囊括在Telephony Stack函数库中。

为了方便第三方软件的安装和运行，Android提供了Application Framework，它以Java Object的形式，封装了Telephony Stack函数库的功能，GUI功能，和其它外设硬件设备的功能。Application Framework不仅降低了第三方应用软件的开发难度，而且降低了第三方应用软件出错的可能性，另外还降低了万一第三方应用软件出错，所造成的对整个系统的破坏。

为了方便集成来源广泛的硬件设备，Android提供了Hardware Abstraction Layer。与文件系统中VFS与Storage Device的协作方式类似，一方面，HAL提炼出不同硬件厂商都必须提供的共同的功能，把它们囊括进通用的模块，例如Radio Daemon，通用的模块与硬件的品牌和型号无关。另一方面，HAL要求硬件厂商提供符合Android规范的IPC函数库，例如Vendor RIL，以便建立起通用的模块与不同品牌和型号的硬件设备之间的通讯渠道。

Reference，

[1] Introduction to Virtual File System. (http://en.wikipedia.org/wiki/Virtual_file_system)
[2] Introduction to Application Framework. (http://en.wikipedia.org/wiki/Application_framework)
[3] Inside the Android Application Framework.
(http://www.slideshare.net/viswanath7/inside-the-android-application-framework-google-io-2009)
[4] The anatomy and physiology of Android.
(http://www.slideshare.net/viswanath7/anatomy-of-android-google-io)
[5] Android Telephony Porting Guide. (http://www.kandroid.org/android_pdk/telephony.html)
[6] Android驱动开发关键技术HAL及移植要领. (http://www.slideshare.net/pandodo)