[转载]android操作系统

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

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

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

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

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

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

2.围绕BP部分提供的三大基础功能，即语音通话，短信等数据通信，以及SIM卡管理，加上与之密切相关的电话本（AddressBook），提供以下服务，

-拨打电话：发起或接受语音电话。

-短信管理：编辑短信，发送短信，接受短信，删除，回复或者转发短信等等。

-通话历史。

-电话本。

-手机振铃及振动设置。

-SIM卡管理。

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

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

Figure13-1.WinMobileTelephonyStack.

Courtesyhttp://farm5.static.flickr.com/4030/4461979382_a450147727_o.png

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

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

Figure13-2.WinMobileArchitecture.

Courtesyhttp://farm3.static.flickr.com/2756/4497998261_22aa6faf22_o.png

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

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

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

Google的智能手机OS，Android，把Telephony功能封装成JavaObject，TelephonyManager。依此类推，把GPS功能也封装成JavaObject，LocationManager，此外还有ResourceManager等等。通过这些ManagerJavaObject，把外设硬件（peripheral）的功能封装起来，提供简单的调用接口，降低了应用软件开发的难度，提高了程序员的生产力。同时，还提供ActivityManager，WindowManager，ContentProvider，ViewSystem，NotificationManager等等，简化并规范GUI的开发[3,4]。

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

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

Figure13-3.AndroidArchitecture[4].

Courtesyhttp://farm3.static.flickr.com/2713/4497986885_7b1f93c360_o.png

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

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

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

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

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

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

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

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

Figure13-4描述的是与Telephony相关的各个层次之间的协作关系。我们关心的HAL，在图中以Libraries（UserSpace）命名，TelephonyHAL的内部结构以绿色标注，包含两个构件，RadioDaemon和VendorRIL。

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

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

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

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

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

Figure13-4.AndroidTelephonysystemarchitecture[5].

Courtesyhttp://farm5.static.flickr.com/4066/4498024565_4c10a45173_o.png

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

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

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

转自：http://hi.baidu.com/idean/item/aa80bfecf114bf05570f1d25