论山寨手机与 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)
