声明：原文出自大牛——ScreenShot作者A ntony  P ranata 。本人英语很烂，之所以瞎译出来一是为了以后参考方便一些，二是在翻译的过程中自己能更仔细的看～。强烈建议大家对照英文原版来看哈。另外有些地方没有翻译，大家意会哈。

原文地址：

http://www.antonypranata.com/articles/new-symbian-os-9-executable-file-format-e32image

前言：

Symbian OS 9已经发布，与之前的版本相比，OS 9增加了许多新特性并有了一些改变，其中之一就是新的可执行文件格式（E32Image）。本文主要讨论了这个新的文件格式，如果你想了解OS 9之前的可执行文件格式，可以阅读一下我之前关于此话题的文章。

在开始之前，请注意我们仅仅讨论的是真机环境下的可执行文件格式（ARM）。为什么不讨论模拟器环境呢？因为运行在模拟器的可执行文件使用了一种不同的文件格式（Cxt注：模拟器下的可执行文件应该是windows的PE格式），如果你之前不了解任何一个平台的可执行文件格式，下面的介绍会更好的帮助你理解E32文件格式。

这篇文章是在Symbian网站或者其他拥有Symbian OS licensees的厂商（例如Nokia）提供的公开信息（文档）之上完成的。虽然我目前在一家手机厂商工作，但这篇文章涉及内容的正确性并未经过公司的核对。尽管我已经紧握最大的努力确保这篇文章内容的正确，但我仍然无法100％保证（Cxt音：看看，大牛总是很谦虚的，我们要做一个谦虚的人哈）。

EABI介绍（ Introduction to EABI ）：

ABI（应用程序二进制接口，Application Binary Interface）是由ARM及其合作伙伴们制定的一个标准，它定义了如何编译、链接，以及其他工具怎样生成obj文件和可执行文件。这个标准可以让不同编译器生成的obj文件互通，例如可以把不同编译器生成的obj文件组合在一起。EABI（嵌入式应用程序二进制接口， Embedded Application Binary Interface ）也是这样的标准，它就是嵌入式平台的ABI。

写这篇文章的时候，有两种编译器可以用于Symbian OS 9——RVCT（ RealView Compilation Tools ）和GCCE。RVCT是ARM公司开发的编译器，license费用可达数千美元；与此不同，GCCE是一个由 CodeSourcery 开发的免费编译器；顾名思义，GCCE基于GNU编译器。

    EABI编译器生成的格式为ELF（ Executable and Linking Format ），它不同于Symbian OS 9之前的PE格式。然而Symbian OS并不使用ELF格式，因为Symbian OS通常在大小受限的ROM上，而标准ELF文件的尺寸通常又很大。所以Symbian把标准的ELF转换为Symbian特有的E32Image格式。如果你有安装Symbian SDK，可以在epoc32\tools目录下找到用于把ELF转换为E32Image的工具，它叫elf2e32.exe。

下图展示了Symbian OS 9的新工具链。如你所见，最后生成的是由elf2e32.exe转换完的Symbian特有格式——E32Image。Symbian网站和SDK中有更多关于这方面的介绍。（Cxt注：SDK help：   »   Symbian OS v9.1   »   Symbian OS Tools And Utilities   »   Build tools guide   »  The native build targets 目录下有全面详细的文档介绍）。通常你不会看到下图所示的流程，因为Symbian OS使用一些脚本工具（例如bldmake、abld等）自动完成。

如果你不熟悉.dso文件也没关系，它其实与Symbian OS 9以及其他平台的.lib文件是一样的。（Cxt注：.dos提供导出的函数的名称和位置，DLL包含实际的函数和数据。）

我在前面说过，ELF文件通常都很大，不适合用于手机。减少ELF尺寸的方法之一是把函数名字替换为序号。例如可以把MyFunction()替换为1，正如你期望的，这种方法可以极大的减小ELF的尺寸，特别是当函数名称很长时（例如 ThisIsVeryLongFunction ()）这种效果更加明显。额等等！如此一来，如何找到序号和函数名称之间的对应关系呢？别急，我们有一个.def文件，它提供了序号与函数名之间的对应关系。（Cxt：呼 …… ）

E32Image概述（ Overview of E32Image ）：

现在让我们来看看E32Image吧。与其他标准的可执行文件类似，它也包含头（Header）、代码段（Code Section）、数据段（Data Section）、导入段（Import Section）等等。

上图展示了E32文件格式，与其他可执行文件格式一样，最开始的部分是header。下面我会着重介绍E32 header里面都有些什么东东。在Header之下还有一些其它section（Cxt：这部分大家意会哈^_^）：

·  Code section, contains all the object files (.o) of your source code as well as export address table that lists all the exported functions.

·  BSS section, contains un-initialized data.

·  Data section, contains initialized data.

·  Import section, contains the information about all imported functions used by your program.

· Relocation section, contains relocation table needed by Symbian OS loader to load your program.

E32Image头（ Header of E32Image ）：

头信息也许是最有趣的部分，因为它包含了可执行文件的很多信息。E32ImageHeader的声明可以在SDK的\epoc32\include\f32image.h中找到。看看class  E32ImageHeaderV 的声明，这可是E32Image文件格式完整的头信息。如果你仔细看了class  E32ImageHeaderV ，你会发现它继承了E32HeaderComp（E32HeaderComp继承了E32ImageHeader）。下图对它们的关系做了更好的说明：

下面的代码片段展示了 EImageHeader ， EImageHeaderComp 和 E32ImageHeaderV 的声明，请注意我删减了部分函数以及注释以便于更清晰的查看：

class  E32ImageHeader

{

public :

  TUint32 iUid1;

  TUint32 iUid2;

  TUint32 iUid3;

  TUint32 iUidChecksum;

  TUint iSignature;  // ’EPOC’

  TUint32 iHeaderCrc;  // CRC-32 of entire header

  TUint32 iModuleVersion;  // Version number for this executable (used in link resolution)

  TUint32 iCompressionType;  // Type of compression used (UID or 0 for none)

  TVersion iToolsVersion;  // Version of PETRAN/ELFTRAN which generated this file

  TUint32 iTimeLo;

  TUint32 iTimeHi;

  TUint iFlags;  // 0 = exe, 1 = dll, 2 = fixed address exe

  TInt iCodeSize;  // size of code, import address table, constant data and export dir

  TInt iDataSize;  // size of initialised data

  TInt iHeapSizeMin;

  TInt iHeapSizeMax;

  TInt iStackSize;

  TInt iBssSize;

  TUint iEntryPoint;  // offset into code of entry point

  TUint iCodeBase;  // where the code is linked for 

  TUint iDataBase;  // where the data is linked for

  TInt iDllRefTableCount;  // filling this in enables E32ROM to leave space for it

  TUint iExportDirOffset;  // offset into the file of the export address table

  TInt iExportDirCount;

  TInt iTextSize;  // size of just the text section, also doubles as the offset for the

  // iat w.r.t. the code section

  TUint iCodeOffset;  // file offset to code section, also doubles as header size

  TUint iDataOffset;  // file offset to data section

  TUint iImportOffset;  // file offset to import section

  TUint iCodeRelocOffset;  // relocations for code and const

  TUint iDataRelocOffset;  // relocations for data

  TUint16 iProcessPriority;  // executables priority

  TUint16 iCpuIdentifier;  // 0×1000 = X86, 0×2000 = ARM

};

class  E32ImageHeaderComp :  public  E32ImageHeader

{

public :

  TUint32 iUncompressedSize;  // Uncompressed size of file

  // For J format this is file size - sizeof(E32ImageHeader)

  // and this is included as part of the compressed data :-(

  // For other formats this is file size - total header size

};

class  E32ImageHeaderV :  public  E32ImageHeaderComp

{

public :

  SSecurityInfo iS;

  // Use iSpare1 as offset to Exception Descriptor

  TUint32 iExceptionDescriptor;  // Offset in bytes from start of code section to Exception Descriptor,

  // bit 0 set if valid

  TUint32 iSpare2;

  TUint16 iExportDescSize;  // size of bitmap section

  TUint8 iExportDescType;  // type of description of holes in export table

  TUint8 iExportDesc[1];  // description of holes in export table - extend

};

     我将逐一解释上面这些字段。从下面的列表中，左端的16进制数表示这个字段在文件中的偏移量，例如iUid2的位置是从文件头部开始0×04的位置。换句话说，如果你把可执行文件用二进制编辑器打开，然后找到偏移量0×04的位置你就可以找到iUid2。注意E32Image使用小端格式（little-endian order）。

E32ImageHeader ：

0×00:   iUid1 ，可执行文件的第一个UID。这个UID可被看作是一个系统级别的标识符，例如Dlls是 0×1000 0079 ，可执行程序是 0×1000 007A 。如果你想更多的了解Symbian OS UID相关信息，可以 访问这里 。

0×04: iUid2 ，可执行文件的第二个UID。当两个对象拥有同一个UID1的时候，就需要用这个UID来区分它们，例如 0×1000 39CE 表示多态接口Dll（ polymorphic interface DLLs ），  0×1000 008d 表示静态接口（ static interface (shared library) ）。

0×08: iUid3 ，可执行文件的第三个UID。   每个程序的UID3都不同。下面这段不翻译了，贴个图看图识字吧^_^。

It is unique for each application. Developers have to request this UID from Symbian Signed service. Symbian OS 9 applications usually have UIDs in the range of 0×200 0000 and 0x2FFF FFFF. Examples from Symbian OS SDKs, like S60 SDK or UIQ SDK, have the UIDs in the range of 0xA000 0000 and 0xAFFF FFFF. There are also some UID available for testing, which can be chosen from the range 0×0100 0000 to 0x0FFF FFFF.

0x0C: iUidChecksum ，校验前面提到的3个UID。Symbian SDK中提供了一个uidcrc.exe工具完成该功能；下面的例子展示了如何生成这三个UID： 0×1000 007A ， 0×1000 39CE  和 0xA000 017F 的校验码：

C:\>uidcrc 0x1000007A 0x100039CE 0xA000017F

0x1000007a 0x100039ce 0xa000017f 0x1e7cca07

0×10: iSignature ，E32文件唯一签名（ unique signature ）。值统一为“EPOC”。图示如下：

0×14: iHeaderCrc ，整个头信息的完整校验，使用 CCITT CRC-32 算法。

0×18: iModuleVersion ，可执行版本号。该信息用于链接过程（linking process）。在S60 3 rd  ， iModuleVersion  值为10（ 0×0000 000A ）（Cxt注：大牛这里可能笔误了，iModuleVersion是T u int32，占4个字节，这个值应该是0x000A 0000）。

0x1C: iCompressionType ，一个UID，表示使用哪种压缩算法压缩了可执行文件。如果值为0就说明未压缩。就我目前所看到的，只使用了一种压缩算法：由RFC 1951定义的 Deflate/Huffman 算法。它的UID是 KUidCompressionDeflate （ 0x101F 7AFC ）。需要注意的是，未来也许会使用其他压缩算法。

0×20: iToolsVersion ，生成这个可执行文件的 ELFTRAN 工具版本。

0×24: iTimeLo ，时间戳。 the lowest word of the timestamp when the file is created.

0×28: iTimeHi ，时间戳。 the lowest word of the timestamp when the file is created.

0x2C: iFlags ，可执行文件的一个标记，比如 KImageDll  ， KImageNoCallEntryPoint  等。这些标记定义在f32image.h中。f32image.h中有一些函数定义用来解释这些标记的意思。例如：如果flag值为 0×1200 002A ，我们可以把它看作： 0×1000 0000 + 0×0200 0000 + 0×0000 00020 + 0×0000 0008 + 0×0000 00002 ，结合f32image.h中的常量声明，我们可以发现：

·  0×10000000 = KImageImpFmt_PE ，可执行文件使用ELF-derived入口。

·  0×02000000 = KImageHdrFmt_V ，header的版本支持。

·  0×00000020 = KImageEpt_Eka2 ，EKA2可执行文件。

·  0×00000008 = KImageABI_EABI ，可执行文件为EABI image file。

·  0×00000002 = KimageNoCallEntryPoint ，no call to entry point。

0×30: iCodeSize ， is the size of code section, import address table, constant data and export dir.

0×34: iDataSize , size of initialised data.

0×38: iHeapSizeMin , the minimum size of the heap.

0x3C: iHeapSizeMax , the maximum size of the heap.

0×40: iStackSize , the size of the stack.

0×44: iBssSize , the size of the un-initialized data section.

0×48: iEntryPoint , offset into code of entry point.

0x4C: iCodeBase , where the code is linked for.

0×50: iDataBase , where the data is linked for.

0×54: iDllRefTableCount , the number of DLLs imported by this program.

0×58: iExportDirOffset , offset into the file of the export address table.

0x5C: iExportDirCount , the offset of the export address table.

0×60: iTextSize , size of just the text section, also doubles as the offset for the iat w.r.t. the code section.

0×64: iCodeOffset , file offset to code section, also doubles as header size.

0×68: iDataOffset , file offset to data section.

0x6C: iImportOffset , file offset to import section.

0×70: iCodeRelocOffset , relocations for code and const.

0×74: iDataRelocOffset , relocations for data.

0×78: iProcessPriority , executables priority.

0x7A: iCpuIdentifier , the identifier of CPU. Look at the following constant for all possible values:

enum TCpu

{

  ECpuUnknown=0, 

  ECpuX86=0×1000, 

  ECpuArmV4=0×2000, 

  ECpuArmV5=0×2001, 

  ECpuArmV6=0×2002, 

  ECpuMCore=0×4000

};                 

E32ImageHeaderComp ：

    开始之前，我们需要知道2个结构：定义在e32cmn.h的 ScapabilitySet 和 SSSecurityInfo 。Symbian OS 9可以看到它们，它们保存了平台安全相关信息，比如能力（capability）、安全标识符（secure identifier）和厂商标识符（vendor identifier）。

struct SCapabilitySet

{

enum {ENCapW=2};

TUint32 iCaps[ENCapW];

};

struct SSecurityInfo

{

TUint32 iSecureId;

TUint32 iVendorId;

SCapabilitySet iCaps; // Capabilities re. platform security

};

好了，让我们回到 E32ImageHeaderV ：

0×80: iS.iSecureId ，可执行文件的安全ID（secure ID）。就是可执行文件的UID3。

0×84: iS.iVendorId ，可执行文件的厂商ID（vendor ID）。对于第三方应用程序，值为0。

0×88: iS.iCaps.iCaps ，运行可执行文件需要的能力。Symbian OS所有的能力定义可以在 e32capability.h 文件中找到。

enum TCapability

{

  ECapabilityTCB = 0,

  ECapabilityCommDD = 1,

  ECapabilityPowerMgmt = 2,

  ECapabilityMultimediaDD = 3,

  ECapabilityReadDeviceData = 4,

  ECapabilityWriteDeviceData = 5,

  ECapabilityDRM = 6,

  ECapabilityTrustedUI = 7,

  ECapabilityProtServ = 8,

  ECapabilityDiskAdmin = 9,

  ECapabilityNetworkControl = 10,

  ECapabilityAllFiles = 11,

  ECapabilitySwEvent = 12,

  ECapabilityNetworkServices = 13,

  ECapabilityLocalServices = 14,

  ECapabilityReadUserData = 15,

  ECapabilityWriteUserData = 16,

  ECapabilityLocation = 17,

  ECapabilitySurroundingsDD = 18,

  ECapabilityUserEnvironment = 19,

};

    能力以bit的形式表示，例如 ECapabilityTCB 意味着最低有效位（LSB），如果设置了最低有效位，可执行文件就具有TCB能力。

0×90: iExceptionDescriptor ， is offset in bytes from start of code section to Exception Descriptor, bit 0 set if valid

0×94: iSpare2 , reserved.

0×98: iExportDescSize , size of bitmap section.

0x9A: iExportDescType[1] , type of description of holes in export table.

0x9B: iExportDesc[1] , is description of holes in export table.

Example：

    下面我们来看一个例子，来帮助你更好的理解上面说的那些字段。我们将使用标准的Symbian OS build command来编译3.0 SDK提供的Helloworld Basic例子。

C:\Symbian\9.1\S60_3rd\S60Ex\helloworldbasic>bldmake bldfiles

C:\Symbian\9.1\S60_3rd\S60Ex\helloworldbasic>abld build gcce urel

现在切换到 \epoc32 \r elease\gcce\urel 目录，使用 Elf2E32 工具读取E32 image头信息。做法如下：

C:\Symbian\9.1\S60_3rd\S60Ex\helloworldbasic>elf2e32 –e32input=helloworldbasic.exe

然后你将会看到 helloworldbasic.exe 的头信息；输出的过程可能会很长，所以一个比较好的方法是将他转储到文件，便于我们进一步分析：

C:\Symbian\9.1\S60_3rd\S60Ex\helloworldbasic>elf2e32 –e32input=helloworldbasic.exe > helloworldbasic.txt

打开 helloworldbasic.txt ，你将会看到头信息（我已经用绿色的注释标明了 E32ImageHeaderV 的字段）：

  E32ImageFile ’helloworldbasic.exe’

  V2.00(505) Time Stamp: 00e0eb0a,d2525b80  // iTimeStampHi, iTimeStampLo

  EPOC Exe for ARMV5 CPU  // iCpuIdentifier = 0×20001 (ARMv5)

  Flags: 1200002a  // iFlags

  Priority Foreground

  Entry points are not called

  Image header is format 2

  Image is compressed using the DEFLATE algorithm  // iCompressionType

  Uncompressed size 0000b788

  Image FPU support : Soft VFP

  Secure ID: a000017f  // iSecureId

  Vendor ID: 00000000  // iVendorId

  Capabilities: 00000000 00000000  // iSs.iCaps.iCaps

  Exception Descriptor Offset: 00002561  // iExceptionDescriptor

  Exception Index Table Base: 00012dfc

  Exception Index Table Limit: 000130bc

  RO Segment Base: 00008001

  RO Segment Limit: 0000a77c

  Export Description: Size=000, Type=01  // iExportDescSize = 000 iExportDescType = 01

  Export description consistent

  Module Version: 10.0  // iModuleVersion

  Imports are ELF-style

  ARM EABI

  Built against EKA2

  Uids: 1000007a 100039ce a000017f (1e7cca07)

  // iUid1 = 1000007a, iUid2 = 100039ce, iUid3 = a000017f, iUidChecksum = 1e7cca07

  Header CRC: 023aca0d  // iHeaderCrc

  File Size: 0000b788  // iUncompressedSize

  Code Size: 0000b0bc  // iCodeSize

  Data Size: 00000000  // iDataSize

  Compression: 101f7afc  // iCompressionType

  Min Heap Size: 00001000  // iHeapSizeMin

  Max Heap Size: 00100000  // iHeapSieMax

  Stack Size: 00005000  // iStackSize

  Code link addr: 00008000  // iCodeBase

  Data link addr: 00400000  // iDataBase

  Code reloc offset: 0000b650  // iCodeRelocOffset

  Data reloc offset: 00000000  // iDataRelocOffset

  Dll ref table count: 10  // iDllRefTableCount

  Offset Size Relocs #Relocs

  Code 00009c 00b0bc 00b650 00007d +002504 (entry pnt)

  // iCodeOffset = 00009c iCodeSize = 00b0bc iCodeRelocOffset = 00b650

  Data 000000 000000

  // iDataOffset iDataSize

  Bss 000000  // iBssSize

  Import 00b158  // iImportOffset

    全都在这了！！希望你能够喜欢这篇文章！

本文将用老谋深算的Symbian平台、历史悠久的Windows Mobile平台、玲珑剔透的Mac OS X平台、前景光明的Android平台四个章节对目前市面上主流手机操作系统的优势和特色做一个详细的介绍。

       老谋深算的Symbian平台

       随着科技和信息技术的发展，人们对手机功能的要求也越来越高。现在，很多人对手机已不仅仅满足于打电话和发短信等基本功能，而是要求它能够播放音乐、上网聊天、安排日程甚至进行GPS导航。因此，很多人已经逐步抛弃传统固化软件的手机，改投智能手机的怀抱。目前，在智能手机市场上，销量最大的平台有三种，分别是Symbian、Windows Mobile和Mac OS X，其中前两种都有一种以上的手机品牌在使用，而Mac OS X仅为苹果iPhone和iPhone 3G独占使用。现在，基于Google Android平台的新一代智能手机T-Mobile G1马上就要上市，它几乎无可非议的会受到人们的追捧。这样一来，市场上便形成了四大智能手机操作平台鼎立的局面。

       Symbian（塞班）

       首先要提到的当然是Symbian（塞班）系统。使用在智能手机上的Symbian系统分为S60和UIQ两种用户界面，其中前者现已发展到v3版本。得益于世界手机老大诺基亚的大力支持，安装了Symbian S60系统的手机已经广为人们使用。而UIQ的主推者是索尼爱立信，虽然UIQ的界面更加华丽，但由于索尼爱立信自身和手机市场的原因，Symbian UIQ一直没有能够得到很好的发展。

       由于Symbian由多家传统手机厂商联合研发，因此无论在运行速度还是易用性上跟其它的系统相比都有很大的优势，而且对移动通信协议，如GSM、GPRS、WCDMA和蓝牙等的支持要优于其它系统。由于发布时间较早，其第三方软件经过几年的发展数量已经非常之多，可以实现人们的大多数需求。

       但遗憾的是，由于系统的先天限制，Symbian系统的多媒体性能并不突出。刷固件较为困难、内存紧张等问题是一直是人们所诟病的几大缺憾。S60 v3发布后诺基亚开始推行的签名策略也浇灭了很多人开发第三方软件的热情。而且，Symbian系统实现触摸操作相当困难，好在诺基亚拥有强大的研发实力。相信继5800 XpressMusic之后，诺基亚还会继续推出触摸屏机型。不过尽管如此，Symbian平台凭着强大的电话功能和较强的易用性，仍然博得了很多人的青睐。

       历史悠久的Windows Mobile平台

       Windows Mobile

       作为微软下了血本研发的一个操作平台，Windows Mobile系统自然丝毫不能被轻视。Windows Mobile的前身是Windows CE，一个微软专为PDA和掌上电脑开发的嵌入式系统。后来随着智能手机的出现，Windows CE演变成了Windows Pocket PC。2003年，微软又开发了Pocket Phone Edition和Windows Powered Smart Phone操作系统，而这两者的融合，才是严格意义上的Windows Mobile。

       目前，Windows Mobile最高版本为6.1。它最大的优势在于其PDA（个人数字助理）功能非常强大，并可通过ActiveSync或Windows Mobile Center和计算机中Outlook等程序保持同步，商务人士可使用该系统随时处理文件、邮件或进行日程安排。由于这个系统的历史非常悠久，和桌面版Windows系统也有异曲同工之处，其第三方软件的数量已经多到了一个令人难以想象的地步。通过各种第三方软件，安装了Windows Mobile系统的手机可以发挥几乎无限的用途。对于软件开发者来说，由于Windows Mobile系统的软件开发较为简单，再加上新版系统中增加了对.Net Framework的支持，使软件的开发相当便利。而对于最终用户来说，Windows Mobile系统的操作方式跟桌面版Windows非常类似，都有开始菜单等人们所熟悉的组件，熟悉计算机的人可以很快上手使用。

       但Windows Mobile系统的缺陷也是显而易见的。按照通常的说法，它有着三大缺陷。其一是系统运行速度太慢。或许是微软往小小的系统中塞了很多东西，Windows Mobile也延续了Windows系统庞大臃肿的毛病，几乎可以算得上是反应最慢的智能手机操作系统。其二是支持的颜色数仅为65000色。关于这个问题很多年前人们就开始抱怨，到现在还是如此。不知道微软为什么不听听群众们的呼声。其三是系统操作过于复杂。它的很多设置都隐藏在层层菜单和选项下，有时甚至还需动用注册表修改器，仍然继承了桌面版Windows的传统。虽然这可能正好满足了少数人的“变态”控制欲。

       但是总的来说，Windows Mobile以其强大的功能、便捷的信息管理以及第三方软件众多等优势，一直以来都为世人所喜爱。当然，更重要的是它还有微软这样一个重量级的后盾。可以说，只要微软不倒，Windows Mobile也将一直生存下去。

       玲珑剔透的Mac OS X平台

       Mac OS X

       苹果的iPhone手机自从公布的那天起便一直受到人们的关注，现在的iPhone 3G也是如此。iPhone使用的操作系统为精简过的Mac OS X，最高版本为2.1，其很多特性与完整版的Mac OS X相类似。该系统使用的内核基于BSD Unix，具有抢占式多任务处理（pre-emptive multitasking）的特性。其内存管理功能非常优秀，具有强烈的Unix风格，允许同时运行很多软件，并从实质上消除了一个程序崩溃导致其它程序崩溃的可能性。

       iPhone的Mac OS X系统更多的优势来自于与iTunes服务的紧密紧密。iTunes原先仅是一个媒体播放软件，后来当iPod和iPhone发布后，iTunes逐渐演变为苹果在Mac和Windows系统上的一个无穷无尽的媒体源。人们可以通过iTunes登录到苹果的在线商店，购买各种音乐、视频或程序。这也成为苹果的一个新的盈利增长点。

       虽然iPhone和iPhone 3G的Mac OS X系统已被大大精简，但在苹果计算机的Mac OS X系统中广为人们熟知的Dock和Aqua等关键元素仍然存在。更重要的是，人们可以在安装特定程序后进入Unix命令行进行各种操作，并对系统底层进行控制。此时iPhone已不再是一台手机，它更像是台超便携的苹果电脑，能够处理很多普通人所意想不到的事情。

       不久以前，苹果为iPhone和iPod Touch开放了App Store应用程序商店。手机用户可通过信用卡在商店中购买自己喜欢的程序，而开发者也能通过App Store发布自己编写的程序，其收益与苹果七三分成。苹果的这个创新构思马上得到了人们的响应，短短几个月的时间App Store中的程序便达到了惊人的数量。

       前景光明的Android平台

       Android

       文章最后要提到的当然是本专题的主角——Google Android平台。Android 是一个真正意义上的开放性移动设备平台。它包括操作系统、用户界面和应用程序等移动电话工作所需的全部组件，而且不存在任何以往阻碍移动产业创新的专有权障碍。

       说到Android，便不能不提OHA（Open Handset Alliance）开放手机联盟。去年，Google与包括中国移动、英特尔、摩托罗拉、高通在内的33家业内巨头成立了该组织，这个联盟将共同推动Google手机平台Android的发展。Android作为Google企业战略的重要组成部分，将进一步推进“随时随地为每个人提供信息”这一企业目标的实现。

       跟iPhone相比，Android平台同样也拥有自己的在线应用程序商店，名为Android Market。这个在线商店仅需进行简单的注册后便可以自由上传程序。虽然这可能导致一些安全问题，但总的来说这种开放式的平台非常有利于第三方软件的发展。而Google在对这些软件进行幕后审查的同时，也采取了多项措施，最大限度的保证了软件开发者的利益。

       Android与前面三种系统相比最大的特点在于其开放性。这里所指的开放性包括两个方面，其一是Android以开源Linux系统为基础，对于开源爱好者而言，他们会觉得Android平台更能满足自己的使用需求。其二是Android对第三方软件的开放程度。Google不会对Android系统的第三方应用程序像苹果那样严格把关，而仅是在用户自行发布之后进行审查。这样一来必将极大的促进该系统第三方软件的发展。

       而就基于Android的第一款手机T-Mobile G1来说，其最不能令人忍受的缺陷恐怕就是没有3.5mm耳机插孔了。另外，由于T-Mobile背后使下的“阴招”，用户在用完1GB流量后带宽便会自动下降为50Kbps，这将大大影响人们的购买欲望。而且，Android系统目前还没有桌面同步软件，也不支持Exchange同步。虽然Google的很多在线服务都可以满足人们的需要，但总有上不了网的时候。况且，很多信息保存在计算机中要安全得多。

       四款主流或将要成为主流的智能手机操作平台到这里就介绍完了。俗话说的好，尺有所短，寸有所长，每个平台都有其各自的优点和不足。大家在选择智能手机的时候，需要关注的重点是各种平台的侧重点，这样在今后的使用中才会得心应手。至于该如何选择，相信大家心中都已经有数了吧。