新CPU移植过程.doc

Android是一个基于Linux内核的多任务操作系统，其框架结构可分为底层的硬件平台，到上一层的Linux核心层，上面是硬件抽象层和系统运行库层，再上面是应用程序框架层，最上面的是应用程序层。 移植Android到新的嵌入式CPU上，通常需要做以下工作：交叉编译GCC工具链；移植Android内核，使之支持新的指令和硬件设备；添加相关硬件抽象层的代码；对Dalvik VM/bionic进行移植和优化；移植文件系统。 典型的Android系统移植的流程如下。 将Android移植到采用新指令集的CPU上，需要做大量的移植工作，包括所有与硬件设备有关的驱动程序(BSP)、运行库。 由于大部分Android应用软件都是运行在Java虚拟机上，因此这部分软件可以直接运行在新的硬件平台上，不需要移植，这要归功于Java的硬件无关性。但也不是所有的Java程序都可以直接运行，由于Java有标准版本、企业版本和用于移动应用的微版本，Android的Java库更接近于Java标准版本。最主要的区别是Java用户界面类库（AWT和Swing）被摒弃了，取而代之的是Android特定的用户界面类库。Android还在标准Java类库上增添了不少新属性，能够支持绝大多数的Java标准属性。 编写Java源文件，用Java编译器将其编译为Java字节代码。但在这之后，还得再一次使用的Dalvik编译器重新编译成为Dalvik字节码。正是这些Dalvik字节代码，在Dalvik虚拟机上运行。Eclipse和Ant 较难移植的是游戏软件。Java虚拟机为了追求兼容性，会牺牲掉一些效率。游戏软件为了保证用户体验，通常会调用一些与硬件平台有关的函数库，进行硬件加速。在移植到新指令集的硬件平台上后，需要对用到这些函数库的源代码进行重新编译，这个过程会增加一些工作量。但这个工作量其实是很小的，例如愤怒的小鸟移植到MIPS架构上时，重新编译的时间只有8分钟。真正的难点是，目前开发移动应用的厂商为数众多，这些厂商的硬件平台全部是基于ARM处理器，要推动移动应用的开发企业针对新的硬件平台进行移植，而且是使用量较小的硬件平台，应用的开发企业获得的收益很小。移植的工作量虽然不大，但是还有版本管理、文档管理、客户服务等很多后继的工作，都需要企业增加投入。 此外，由于Java虚拟机的效率决定了Java程序的效率，因此操作系统厂商对CPU的支持程度会极大影响应用软件的执行效率。目前几乎所有的移动应用都是在ARM平台上开发的，Googel对ARM的支持力度也最大，有数百人的工程团队在做支持ARM指令集的Java虚拟机的优化，对其他指令集的支持力度则要小得多。缺少Google的强力支持，支持其他指令集的Java虚拟机在效率上要打一定的折扣，应用软件的执行效率和使用体验会有程度不同的损失。