EEPW论坛

Java与嵌入式系统 gulf 于 2002/06/20 09:59 加贴在 嵌入式系统论坛 设为精华 删除 如果有人问Java是否可以成为理想的嵌入式设备程序设计语言，正确的答案 应该是:具体情况具体分析。对此，本文将提供有益的参考。 Java程序设计语言最初是针对机顶盒应用而设计的，它可使家庭与WWW连为一 体。而今，开发商们又希望把Java作为一种针对嵌入式系统的程序设计语言 , 令其以新的方式进入家庭。 然而, 与最初针对机顶盒的应用开发相比, 针对嵌入式系统的家庭应用开发 要复杂得多。人们不得不面对许多新的设备与新的技术，同时也遇到种种限 制，例如运行速度、内存配置、外形尺寸以及与时间相关的技术问题。Java 具有面向对象的特性、内在的Internet集成并因此而获得了大批拥有雄厚技 术实力的开发商，可以帮助人们顺利完成嵌入式系统的开发。 例如， Java 2 Micro Edition(J2ME)——Java API的一个子集，只包含了J ava的关键特性，是专门针对那些对内存具有苛刻要求的嵌入式设备而设计的 。J2ME粗略地将应用对象划分为两大范畴：内存在128K～512K之间的设备和 内存为512K以上的设备，根据设备所处的类别提供不同的用户接口和不同的 软件包。 然而, 具有讽刺意味的是, 某些使Java成为Internet和桌面设备理想编程语 言的良好特性, 在嵌入式系统中却引发了一些十分棘手的问题。缺乏指针寻 址以及运行于Java虚拟机(JVM)模式中的安全特性都使Java很难对硬件进行直 接控制。 自动垃圾收集功能可使程序设计变得更加容易, 但却使应用失去了实时决策 能力。另外, Java的运行速度偏慢, 而且程序量也偏大。然而, 令程序设计 人员感到鼓舞的是, 目前所有这些问题大多数已能够解决, 许多可行的方案 正在陆续推出。因此, 如果有人问Java是否可以成为理想的嵌入式设备程序 设计语言, 那么正确的答案应该是：具体情况具体分析。 什么情况下Java是理想的选择? 为“火星探路者”引导方向的微处理器对中断功能具有很强的依赖性, 此时 Java可能不是最佳的选择。如果你希望设计那些小型化、高功效、可执行关 键任务的实时应用, 例如火箭控制、传感器通信或报告宇宙飞行器的方位等 , 最好采用C语言或汇编程序。 然而, 对于其他一些应用, 例如使用手持设备追踪货物的发运情况, Java将 是一种最理想的选择。那些需要相互对话或与Internet进行沟通的设备, 可 以充分利用这一语言的内在通信特性。如果已经用Java编写了服务器端软件 ，那么与此协同运作的客户端应用也很适合使用这种语言。 关于运行速度的考虑 Java之所以能够得以流行, 一个重要原因是具有WORA(Write once run anyw here, 编写一次即可到处运行)的特性。同样的Java代码可以运行在Mac、PC 甚至是大型机上, 因为Java是一种解释性语言。面向具体平台的JVM可解释在 每一*作系统平台上运行的字节代码。然而, 这一解释需要花费额外的时间 。值得庆幸的是, 目前JVM解释代码所花费的时间已大大减少, 这要归功于即 时(Just-in-time)编译程序的推出。预先(AOT，ahead-of-time)编译程序也 可解决这一问题, 因为它能够预先解释Java代码, 把Java代码转换成经过优 化且面向具体平台的二进制代码。 Cygnus Solutions公司声称, AOT编译程序能够把代码的运行速度提高8倍。 NewMonics也开发了一个名为QuickPERC的编译程序。该公司宣称, 与通常的 解释模式相比，这一编译程序可把代码的执行速度提高20倍。 尽管使用AOT令开发人员失去了可以在中心控制点对所编译的代码进行版本管 理和维护的能力, 但对于比较稳定的代码库(例如嵌入式系统)环境这算不上 是很大的损失。 程序规模遇到了“天花板” 在一个服务器中拥有几个Gb的内存十分平常，但一个可运行Java的电器设备 充其量只有不足512K的内存。因此, 当运行带有1Mb核心类库的Java时, 即使 你只编写了一行代码, 也无法将其装进嵌入式系统。AOT编译程序可以解决这 一问题，因为它可以帮助你去除所有不使用的代码、方法和类。许多供应商 已经编写了体积更小、效率更高、面向具体平台的专用核心Java类, 而且仍 可继续使用已公布的Java API。与汇编或C等语言相比, 通常情况下, 面向对 象的语言需要使用更多的内存。在台式机上这早已算不上是一个问题，然而 在嵌入式系统中却是一个很大的问题。 选择正确的集成开发环境（IDE） 人们已经认识到, C程序中80%的故障是指针引起的, 因此Java中去掉了指针 。Java的安全模式放弃了系统内存直接寻址和指向实际硬件的指针寻址。然 而, 这些指针的存在本来是很方便的, 特别是当你希望快速和直接寻址内存 时。 用Java编写的嵌入式系统必须使用本地接口去执行那些面向具体硬件的功能 。然而, 这将意味着你正在管理以多种语言编写、具有多种类型的代码。对 于开发人员来说，就必须懂得更多的技术, 否则只好组织一个更庞大的开发 人员班子。如何把所有代码连接成一个模块？当出现某些故障时如何对代码 进行调试? 所有这些都是必须解决的问题。 推出功能丰富、支持多平台代码的IDE(集成开发环境)，这是朝正确方向迈出 的一大步。当前可用的IDE有Metrowerks CodeWarrior(它可使程序设计人员 在同一IDE中使用多种语言编写代码) 和IBM的VisualAge for J2ME。由于这 些IDE是用于解决复杂问题的，所以人们也需付出较大的努力才能掌握它们。 垃圾处理刻不容缓 许多人不愿在嵌入式系统中使用Java的一个重要原因是Java不能保证应用的 实时决策需求，即这种语言不能以可预知、可重复的时间长度来处理一个具 体的代码部分。Java使用自动垃圾收集功能回收那些不再使用的内存，开发 人员几乎不能控制垃圾收集的具体时间。实际上, 当Java进行垃圾收集时暂 停了整个应用的执行。为了解决这一问题, 供应商们陆续推出一些不同的垃 圾收集方法与算法。 有些产品, 例如NewMonic的Real Time Executive和WindRiver的FastJ，可以 确保绝对时间决策应用的开发。Sun拥有一个不同的方案，但它也开始转向对 实时决策功能的支持。各种编码技术（例如对象的重用）, 也可减缓垃圾收 集所产生的不良影响。 可重用性不可忽视 尽管使用AOT编译程序会牺牲掉在任何平台上运行同一编译后Java代码的能力 , 但可移植的Java源代码仍将是一大优势。 当供应商推出其硬件新版本时, 只要接口保持不变, 那么与接口对话的代码 就不必改变, 这就是面向对象设计的实质所在。事实上，大多数高级应用逻 辑在台式机上就可以进行调试，而不必在嵌入系统的目标设备上摸索。 内存与处理器的成本 有的时候, 人们之所以愿意使用Java, 是因为Java具有良好的性能价格比。 众所周知, 目前内存和处理器的价格是相当便宜的, 而且越来越便宜。尽管 花费几百美元, 甚至是几千美元为服务器购买内存是合乎情理的，但对于价 格本来就十分低廉的蜂窝电话来说, 过多的内存开销显然是不能接受的。如 果因为使用了较小的内存让每部电话节省1美元, 那么2000万部将节省2000万 美元。因此内存和处理器速度的开销应与设备成本相适应。实际上，对于有 些应用场合来说，内存和处理器速度并不是刻意追求的因素，这就给降低产 品成本找到了一条出路。 如何吸纳Java？ 如果你正在考虑把Java用于你的下一个嵌入式系统, 那么重要的不是技术问 题，而是你的公司文化。如果你拥有一批习惯于牺牲机器资源换取自己方便 的Web设计人员, 并让他们充当嵌入式系统的Java程序员，尽管同样是使用J ava，但从Web设计到嵌入式系统程序设计将是一个不大容易的转变。对Java 的使用要循序渐进，而不是立即使用Java编写所有的应用。必须让Java程序 员与那些有经验的嵌入式系统设计人员进行对话沟通，互相学习对方的技能 。 在JVM上运行的J2ME目标代码偏离通常环境越远，应用管理就越复杂。其中的 经验是, 尽可能采用标准的J2ME。只有遇到特殊问题时，才采用特殊的方案 。 如果某些针对嵌入式系统的技术(例如AOT编译程序和半自动垃圾收集)反过来 被应用到台式机和服务器环境，这并不令人感到惊奇。Java良好的内在特性 , 无论对于家庭应用还是工业应用, 都将是嵌入式系统首先需要认真考虑的 一种程序设计语言。