Android 系统架构

Android系统架构INCLUDEPICTURE"http://tw.f14.yahoofs.com/myper/KK7iL7aRGBZahfOWRo9uPeo-/blog/ap_20071124061939843.jpg?TTy3jVHBVyUpboNF"\*MERGEFORMATINET前言在AppleiPhone引起了广大群众和业界对于高阶行动装置应用的注目，另外也在市面上掀起了一阵波澜。从许多角度观看iPhone，iPhone可以说是一个销售不错的单一产品。然而iPhone能否持续热潮也是相当值得注意的事。而Microsoft一直有着自己的手持式平台WindowsCE/Mobile与相关的合作伙伴。在这块市场上目光也集中在另一个软件巨头-Google，对于Google在这块市场的后续行动，或许iPhone的炒作起了作用，iPhone单一产品的思维让人们一直不断地传言Google将类似AppleiPhone也推出自己的手机终端产品gPhone。甚至有人对于该预期存在的gPhone的产品规划和网络应用方面，都有相当的预测。而在2007年11月，Google公布了Android计划，一方面映证了Google确实对于MobileDevice有着长久的计划和行动，一方面也否定了gPhone这样单一的产品存在。如预期的网络上出现了许多关于Android的评论，综观这些评论，有的是浅尝即止，有的是过于聚焦在技术层面的政治争议，不然就是忽略了平台技术在应用上的影响和差异差异而大放市场策略的预测，更甚者拿着现有的AndroidEmulator说着不知所以的说着gPhone抄袭iPhone的UI的可笑话。本文希望从系统和技术层面上探讨Android对于应用层面的影响，或许透过对于Android正确的认知，可以对于市场策略上的分析能有更正确的判断。JustAnotherMobileLinuxPlatform?乍看之下Android只是个有如OpenMoko/MobiLin/GreenPhone等众多开放式手持Linux平台的一个，并没有甚么特别之处，然而进一步了解之后，就不难了解Android平台在系统建构上独到的设计。可以说Android重点并不在于Linux，而Android项目采用了这样的组合，在整体规划上考虑了相当广的的层面，自个人/第三方软件开发，系统开发建构，实际应用性到系统平台开放性。而Android计划除了制定了系统架构外，还针对这个平台提供了完善的软件开发工具与环境，在IDE上采用了开放式开发平台Eclipse，在该IDE上建构了Android专属的plugin。另外还以自由软件QEMU为基础提供了Android平台专属的Emulator，让个人/第三方软件商迅速开发软件，无需依靠实际硬件开发软件。Application/ApplicationFramework对于开发者而言，开发LinuxMobile/Embedded软件时，多半采用C/C++做为软件开发语言，由于C/C++目前的开发工具与底层硬件平台有相当的相关性，因此首先遭遇到的问题是cross-toolchain的使用和开发环境的架设，再来就是每个MobileLinux组织所制定出不同的embeddedlinux平台有相当迥异的systemarchitecture/runtimeenvironment，而各组织所提供的软件开发环境，也并不如WinCE/Mobiles单一系统一般有一致的架构及API，更不用说对于硬件平台的多样性更有着软件兼容性的问题，因此即便API能做到有如WindowsCE/Mobiles一般的一致，在各种硬件平台(ex:ARM/MIPS/PowerPC..)也无法建立单一且能够兼容且运作的binary，相较于在现在以x86为主要硬件平台的开发环境，行动装置硬件平台的多样性对于软件开发和使用性上无疑增添了不少硬件限制，而Java软件虽能够解决这方面的问题，然而Java因为设计上的缘故，在应用性上更为局限。在这方面Android很特别的，采用了JavaLanguage来做为App的撰写语言。采用Java语言的好处相当多，对象导向语法相较于常用的C语言更便于GUIProgrammingModel的建置，另一方面Java开发及执行环境的建构在Desktop上相当容易，参考文件的维护也较为容易，而且Java相关的开发工具已经很齐全且成熟，再者Java所制定的bytecode，没有所需要对应平台的问题。尽管最后在Android平台上执行的并非Javabytecode，而是自有的dex格式，然而dex格式也有如Javabytecode般取决于VM的实作，而VM的角色在Android平台终适度的隐藏了底层硬件的差异。RuntimeEnvironment-Libraries&DalvikVM在Rutime方面的library层面上，为了提供基本且的功能，Android还是针对平台的执行环境制定了一套标准的C/C++Libraryset，从现有的标准模块看来，主要是针对网络/多媒体/GUI以及安全性提供底层的实作，值得注意的是在此Android特别将OpenGLES/SQLite的纳入，使得系统对于3D/数据库有着标准支持。而尽管平台上有着C/C++libraries，这部分并不让开发者在开发软件时直接地使用，C/C++libraries在使用上还是间接地透过上层的ApplicationFramework，并且透过VirtualMachine(VM)使用类似JavaJNI技术来桥接libraries与VM的运行。由于软件开发上使用了JavaLanguage，若要使用JavaVM这对于一般使用者与开发者而言难免存在着应用性相当局限，执行效率不佳，系统资源需求过高，以及JavaME授权等问题的存在。为了解决上述这些问题，Google特地实作了DalvikVM，Dalvik并非是JavaVM，因此所执行的也并非是bytecode，目前需要依靠转换工具将Javabytecode转为DalvikVM执行时特有的dex(DalvikEXcutable)格式。DalvikVM相较于JavaVM最大的不同在于JavaVM为Stack-based，而Dalvik是register-based。以技术层面考虑Register-basedVM的特性有个很大的好处，那就是对于现有主流的硬件架构，如此很容易与现有系统整合且最佳化，而所需要的资源也相对较少。甚至在硬件实作VM上会比较容易实现。最重要的是Dalvik并非是JavaME的实作，因此没有JavaME授权相关的议题。由android目前的介绍可以看出Dalvik目前实作在Linux平台[2]，仅依靠Linuxkernel作低阶动作与memorymanagement。而从这一点的延伸更可以看出Android平台中的重点为负责执行层面的DalvikVM而非Linux，也因此Linux在Android平台中所扮演的角色并非是举足轻重的主角，也可以想见Google采用Linux的原因是Linux本身所具有的自由开放的特性，而另外在手持式装置中Linux已经具有相当质量的软件开发资源，另外就是VM的使用，考虑到的就是软件在各式硬体上的通用性，所以对于有些人猜测Android最后还是会开放C/C++API供开发者使用，若是如此，Android就失去了最大的特点，与LiMo/OpenMoko之类的MobileLinux平台无异，所以这是太不可能发生的。既然采用了VM的方式，这么一来，DalvikVM在其它平台上建构也不无可能，或许这样的推敲或许也能合理解释在OpenHandsetAlliance成员中有着长期耕耘WindowsMobile平台的HTC在列。EclipseIDE+AndroidEmulator针对特定平台提供完善的开发/除错工具，以及整合式的开发环境是开发行动应用软件的另一个困难点，针对此点Google为Android平台开发了一系列的开发/侦除错工具。一系列的工具中最引人注目的莫过于EclipseADT-plugin和AndroidEmulator。现今，独立的IDE软件开发需要投注相当多的人力和时间，因此以提供eclipseplug-in的方式来达到提供完善的IDE目的，对于许多开放项目或商业产品而言，这样的作法已经是首选。而提供Emulator更可以解决在软件开发阶段对于硬件平台需求的问题。从AndroidEmulator的程序代码[3]看来是以QEMU为基础，延伸打造了该Emulator，功能上除了一些无法以软件仿真的功能外(USB联机，SD插拔，Audio-In，Camera，电池/AC状态…等等)，甚至许多的侦错功能是与Emulator环境整合的(有兴趣的话可以下载SDK和EclipseADT来玩，在Eclipse上所开发的程序可以很直接地输出到Emulator上执行，无需制作image或是安装)，在硬件仿真程度上相当的全面。在开发工具上，Android透过QEMU/Eclipse的方式，以很务实简单的作法达到了这样的目的。Google在Android平台上大量采用了开放和自由的软件，不害怕公开程序或视之为洪水猛兽，这样的作法相较于Symbian/PalmOS/WindowsMobile而言，宣告了软件上的高价值不在于封闭进而贩卖程序代码和SDK工具本身，透过采用开放/自由软件的力量，更能加速达到目的和增加自身的价值。Java的美丽与哀愁-Dalvik所引来技术上的政治争议这个部分写的有点长，是个人看了一些讨论后的想法，没有兴趣的话请跳过。在Android平台采用Java语言做为程序开发语言的同时，提出了DalvikVM。这样的举动引起最广泛探讨的是：Android是否分裂了Java。在讨论这样的问题之前，或许该讨论Java本身的问题，在这里个人提供另一个思考观点，Sun在Java的提出之后，一度曾经想过将Java交由ISO标准化，然而或许是透过JCP对于Java在各应用上制定的完全主导，让Sun由Java在各方面确实地获得了相当的利益，所以即便面对Microsoft提出.NET这样对于许多人而言美好又开放的平台的挑战，长久以来Sun还是一直以相同的论调来否决开放Java这个语言，而这个论调就是："这会分裂Java"。从Java的出现，在软件开发的历史上确实有着相当的意义，然而Java的提出到现在经过的时间并不算短，即便是历史最悠久的JavaSE在现今Desktop应用上还是相当局限，这样的结果或许可以去检讨的是，或许Java沦落到现今这样的局面是Sun自己导致的。多年来Sun封闭了Java让Java只在他们允许的方式下运作，在bytecode+stackVM低落的效能和反应下，多少开发者期望能用Java语言开发原生(Native)程序，而又有多少开发者在AWT/Swing这样既具有难以有效驾驭的UIModel而且又与系统本身的Look&Feel格格不入的情况下充满挫折，更不用说许多难以理解的各种不实用的应用Framework(ex:JMF/Java3D).而这许多问题当人们尝试自己解决而提出不错的，像是GCJ和EclipseSWT，换得的是Sun的无视或敌对。而许多的方案换得的是:"Java已经有了XXX，这样的做法会分裂Java"。这么一句总是出现的话，到底是不是因为它本身真的很有道理？至少Sun达到目的了，与Java扯上的问题第一个被讨论的总是"它会不会分裂Java？"，Sun这么多年来是否有心改进Java？这个问题或许Sun应该扪心自问，在人们对于Java在应用上的各种需求的改进有所要求的同时，Sun对于Java是否真的针对贴近人们本质需求而改进？检视过去Sun到底做了甚么，在"分裂Java"这样的保护伞下，原本大好前程的Java又改进了甚么？这样一来"Android是否分裂了Java？"是对于问题的一箭中的还是只是长年来受到的刺激的反射式思考？Android计划中DalvikVM的出现不妨视之为软件开发演进中的必然，一方面Google从没宣称说这是Java，而现今也有其它程序语言能够开发在DalvikVM上运作的软件。如果Sun的Java做的够好Dalvik可能就只是Java的次世代技术。DalvikVM的问题点或许只是在于扯上了Java而不在于他是个VM，在不同的InstructionSet上用Java语言开发程序，在GCJ/.NetiKVM出现的同时就已经被证明了，如果这算分裂Java，那这件事一直因为人们的需求而发生。软件开发或许就如同电影侏罗纪公园中所说的"Lifewillfinditsway."，更不用说开发软件的是人，程序开发者总是期盼有更好的系统架构和方案。在兼容性的保护问题上，在网络上有人问过"为何没有人有勇气对Google询问他们对OpenJDK的质疑"，或许人们该想想Sun用了这么多的手段去控制Java的演进，却无法自己提出Dalvik，那么Google这么做除了保障平台的兼容性又何能控制全球的人们往更好的应用方向发展？另外许多软件厂商(Ex:Trolltech)说了"Google不过是制定了另一套Java"，这样的说法某些层面上是对的，但是对于由这些人说出的这些话，姑且以Android计划会妨碍他们的产品(Extopia/Jambi)的销售这样的想法而一笑置之。说了这么多，那Android到底是甚么?总结上述归纳几点:1.Android是个软件平台，让人们可以开发软件。这代拿AppleiPhone与之相比，不只是不对等，更凸显出iPhone的哗众取宠和Apple的短视无力(SDK原本是不打算开放的),拿iPhone与Android现有UI相较更是可笑的举动.2.和以往的Mobile平台不同的是，Android的设计让它在采用VM得到类似Javabytecode在不同硬件平台的兼容性的同时，VM对于底层硬件平台贴近的设计能够依然保有相当不错的效能。相较于WindowsMobile限定使用ARMCPU,其它MobileLinux平台则仅止制定了API层次的一致的作法，Android算是有突破性的作法。3.现在的Android是Linux平台，不过由于Android的核心在于上述的VM实作，这代表未来底层软件平台也或许是可以转换的(甚至是Desktop)。目前缺乏详细DalvikVM实作细节这项目纯属猜测。