使用 Adobe Flash 和 OpenGL ES 创建可

1、使用 Adobe Flash 和 OpenGL ES 创建可靠稳定且响应及时的嵌入式用户界面Andy GrycQNX 软件系统公司agryc摘要图形用户界面 (GUIs) 已成为工业控制、汽车和医疗市场中区分嵌入式产品的主要标志。客户不想再看到静态显示画面；他们现在渴望动感十足、引人入胜的显示效果，在多数情况下，他们希望获得可定制的图形用户界面。因此，嵌入式图形用户界面已变得异常复杂，经常要将多个图层或显示器与动态 2D/3D 应用程序进行融合。此外，嵌入式软件开发人员目前开始采用 Adobe Flash，原因很简单：它能使创建图形用户界面所需的时间缩短 30% - 50%。过去，软件开发团队

2、必须将图形用户界面的原型转换为 C、C+ 或 Java 代码，这一艰辛过程通常要持续数周甚至数月。如今，软件团队能使用高级 Flash 工具设计全部图形用户界面，并可直接在嵌入式 Flash 播放器上运行这些图形用户界面，无需编写图形代码。无论嵌入式图形用户界面变得多么复杂，它都必须保持可靠稳定、可扩展的特性，当然还必须保持较高的内存和 CPU 使用效率。本文将为您介绍，开发人员和系统设计师在采用如 OpenGL ES 和 Adobe Flash 标准的同时，是如何满足这些要求的。具体主题包括：实现对可用硬件最大程度的利用、减少内存占用、执行故障容错、确保迅速响应用户输入。简介Adobe 系统

3、公司的数据显示，目前有超过 5 亿的移动设备具有基于 Adobe Flash 的图形用户界面 (GUIs)到 2010 年，这一数字有望突破 10 亿。Flash 越来越受嵌入式系统开发人员欢迎的原因包括： 全球有 100 多万图形设计师使用 Flash 制作工具，从而为开发人员提供了赖以参考的庞大图形技术库。而且，开发人员还能 轻松集成数千种已针对台式机和手机市场研制的 Flash 组件。与桌面型 Flash 播放器相比，Adobe 公司推出的嵌入式 Flash 播放器（如 Flash Lite 3.1）占用内存更少，而且能以极少的 CPU 开销更快地进行渲染。目前，嵌入式设计采用的 CPU

4、 与图形芯片支持在 VGA 及大型显示器上获得最佳 Flash 体验所需的帧速率。例如，要获得每秒 10 帧的流畅动画，系统所需的 CPU 最少为 100 MIPS远远低于目前大多数嵌入式 CPU 可提供的常见的 300+ MIPS。大多数工业设计人员对 Flash 已十分熟悉，并利用它模拟所有最新的人机界面 (HMI) 设计。直接运行设计人员的模型，而非试图将其重新转换成传统的嵌入式语言或利用工具包以节省大量的时间和精力投入。 与通用编程语言及工具不同，Flash 为图形和多媒体提供了特定领域的应用环境，为创造用户体验提供了无限可能。因此，嵌入式系统开发人员能在少于传统所需的时间内制作动画和

5、特效。同时，Adobe Flash 播放器认证还能确保基于 Flash 的应用程序能以相同的方式在整个硬件平台上运行。因此，开发人员能一次创建图形用户界面组件，然后将其配置到定位于不同市场或价格点的各种系统中。但要满足嵌入式系统开发人员的要求，Flash 实现还须重视以下问题：具体包括： 您如何集成 Flash 内容和其他图形程序，如网页浏览器或 3D 导航程序？单独图形显示器能同时呈现基于 Flash 的图形和本机 2D/3D 图形（即使它们使用不同的绘制模式）吗？您怎样才能使基于 Flash 的用户界面在所有加载条件下运行一致？大多数嵌入式系统的图形用户界面都必须随时迅速地响应用户输入，因

6、此需要一定程度的优先级控制和实时性能。您如何才能使基于 Flash 的用户界面稳定可靠？您能确保系统监测故障并能自如地恢复吗？Flash 内容能与关键进程以可靠的方式共存吗？您如何控制 Flash 内容与操作系统 (OS) 服务的交互方式，如音频输出、触摸屏、时间关键型设备的驱动程序、文件系统和网络堆栈？ 让我们仔细斟酌如何应对这些挑战。集成 Flash 程序与其他图形应用程序按惯例，Flash 播放器是在网页浏览器内运行或从视窗系统中启动的。然而，通过彻底改变这种模式并使 Flash 成为启动所有图形程序（无论其是否基于 Flash）的主要应用环境，可大大简化图形用户界面的开发过程。Flas

7、h 可作为屏幕管理器，允许图形设计师密切控制菜单转换和音频效果；它还允许图形设计师和开发人员对图形组件进行任意定位、调整尺寸和配置，从而简化了定制过程。图 1 显示的是将 Flash 用作屏幕管理器的实例。左侧的程序是一个 Flash 播放器，其已直接将两种组件加载到程序空间内：一个 2D 图形库和一个控制图形硬件的图形驱动程序。以这种方式加载驱动程序可确保程序直接控制图形芯片从而提高运行性能。右侧的本机程序在 OpenGL ES（用于嵌入式系统的基于标准的 3D 应用程序接口）中绘制 3D 可视化效果。与 Flash 程序一样，它也能直接控制图形芯片从而提高运行性能。图 1集成 Flash

8、程序和其他图形应用程序。在此实例中，基于 Flash 的程序控制着基于 OpenGL ES 3D 应用程序接口的 3D 可视化程序。开发人员经常会将某些人机界面组件移至 OpenGL ES 中，具体原因如下： 代码已存在于 OpenGL ES 环境中。 代码需利用 OpenGL ES 提供的 3D 功能。 一种特殊的绘图功能需要的性能远远超过 Flash 能提供的范围。从基于 Flash 的主要人机界面中隔离选定的组件也能确保进程安全。例如，在图 2 中，仪表板使用针对底层背景图像的 Flash，但却渲染 OpenGL ES 中的指针以提供更能防止故障的安全关键型系统。Flash 运行时环境无

9、论因何种原因运行失败，指针都会继续运行。图 2在安全关键型应用中集成 Flash 程序和其他图形程序。在该实例中，一个进程渲染 OpenGL ES 中的指针，而分离进程执行基于 Adobe Flash 的人机界面。这种技术可确保次关键的导航与气象控件出现故障时，指针能继续运行。许多面向嵌入式系统的图形芯片现在都支持多层技术，从而允许基于 Flash 的程序与使用 OpenGL 的图形程序甚至与另外的图形框架进行无缝融合。例如，在图 1 中，Flash 播放器利用前景层并控制在背景层上绘制 3D 可视化效果。为使 3D 画布可见，开发人员在前景层上使用色度键技术。由于 Flash 渲染和 3D

10、渲染是在独立图层中进行的，因此图形控制器能刷新 3D 可视化效果而无需重绘 Flash 内容；这样能消除闪烁现象并减少 CPU 负载。开发人员还能利用透明混合处理和色度键技术使 Flash 组件呈半透明状态，然后将这些组件直接置于其他内容中。图 3 显示的是通过动画控制台显示的半透明警告信息，它进一步展示了该技术是如何将更多信息汇集到小屏幕上的。图 2利用透明混合处理技术在动画控制台上显示半透明警告信息的图形用户界面。由于警告信息和控制台是在不同图层上呈现的，因此图形驱动程序无需重绘警告信息即可重绘控制台。半透明组件允许更多信息汇集到小屏幕上。 最理想的是，底层操作系统或图形框架可提供高级应用

11、程序接口，允许开发人员以独立于硬件的方式部署多层显示器。这样，应用程序无需重新编码即可在支持不同图层的图形芯片上运行。应用程序接口还应允许开发人员确定每个程序是否管理自己的图层，或中心程序是否管理多个用户程序以动态方式共享图层的方式。确保可预测的响应时间嵌入式图形用户界面应随时能迅速响应用户命令，即使在系统处理各种 CPU 密集型任务时也一样。台式机响应时间缓慢或不一致的情况不应出现。当多个图形应用程序争夺 CPU 时间时，开发人员会面临更加严峻的挑战。一种解决方案是创建中央显示管理器，利用线程优先级决定每个图形程序何时控制 CPU。在这种技术中，需要加入图形应用环境的程序（如基于 Flash

12、 的 DVD 播放器）会向显示管理器发送请求。显示管理器会根据该程序是否具有足够的加入许可同意或拒绝其访问请求。当获准加入应用环境后，该程序可使用互斥锁（互斥体）。当程序希望在屏幕上绘制内容时，它会等待然后获取互斥体，接着直接在图像芯片上绘制内容，最后释放互斥体。每个图形程序会根据各自的优先级争夺该互斥体。由于具有最高优先级的图形程序总是首先获取互斥体，因此该技术可确保一定程度的实时性能和一致快速的用户体验。 但是，在 CPU 负载较重的条件下例如，当工业控制系统计算几千个数据点或汽车资讯娱乐系统计算路线时图形用户界面的性能会减退至令用户无法接受的程度。这种状况往往会导致系统故障。在可以控制用

13、例的封闭系统中，开发团队能防止出现此类性能故障。但是，在必须以动态方式支持新内容或应用程序的系统中，进行此类预防会变得更加困难。时间分区技术提供了解决这一问题的途径。利用该技术，系统设计人员可将软件组件置于单独分区中，并为每个分区定量分配 CPU 时间。例如，在汽车资讯娱乐系统中，系统设计人员可为图形用户界面分配 20% 的 CPU 时间，为 MP3 播放和免提远程信息处理分配 20% 和 30% 的 CPU 时间，等等。通过这种方式，图形用户界面能及时响应用户输入，无论其他分区中的进程会多么繁忙即使其他进程是以更高的优先级在运行。最终结果是用户满意度得以提高。通常，分区中的进程不会消耗分配至

14、该分区的所有 CPU 周期。某些分区计划程序会利用这种特性并以动态方式将未用的 CPU 周期分配到可从多余进程时间获益的分区中。这种方式可确保基于 Flash 的图形用户界面在有多余的 CPU 时间可用时，更快更平稳地运行。反之，它也能在图形用户界面未消耗其全部的 CPU 时间时，允许其他软件子系统更快地运行。许多商用操作系统目前都支持时间分区技术，使之成为一种实用可行的设计选择方案。针对目标机进行设计为确保嵌入式目标机发挥最佳性能，Flash 人机界面的设计人员必须摒弃看似引人入胜却消耗太多系统资源的技术。全屏透明混合处理、褪色、过滤及其他计算密集型技术在低功耗系统中很难发挥优势，因为图形内

15、容原本就是设计用于高功耗桌面环境的。为防止浪费精力并最大程度提高系统性能，人机界面设计人员应： 使用尽可能少的透明度（透明混合处理）多数 Flash 引擎都在软件中进行所有的透明混合处理。透明度运算需取得两个像素值，然后与透明混合系数及其逆函数相乘，再将所有值相加，该过程是针对透明区域的每个像素进行的。由于该过程较慢，因此设计人员应保持较小的透明区域，除非其确定透明混合处理会得到硬件加速的支持。同时，设计人员应将可见度属性设为不可见 (false)，而不是使用 alpha 值=0（100% 透明度）以隐藏对象。避免无故使用渐变色尽管渐变填充能产生夺人眼球的效果，但其需要进行补色计算，并使填充区

16、域以逐像素的方式输出。实体填充会显著加快系统的运行。使用可容许的最低帧速率Adobe Flash 使用帧速率确定电影播放的速度以及每秒会产生多少补间动画（或中间帧）。该数值越大，消耗的 CPU 就越多。当混合 SWF 文件时，应确定其是否具有不同的帧速率。产生的帧速率即为调用方使用的帧速率，因此，如一个可产生快速动画导入效果的 SWF 文件调用对话时，对话会不经意地消耗多于实际所需的 CPU。最简单的解决方案是：在整个项目过程中尽量使用一致的帧速率。 测试基于 Flash 的人机界面以下表格对测试基于 Flash 的人机界面的不同方法进行了对比。 环境实际的目标机硬件优势 最适用于预览实际性能

17、；有助于确保人机界面设计人员选择最能充分利用 CPU、内存和图形控制器的方法。有助于确保及时发现性能问题，防止不必要的重新设计。 警告 由于硬件与软件通常是同时设计的，因此并非随时可用；不如台式机进行日常测试那样方便。 测试与目标机硬件运行相似的设备CPU 参考平台 不如目标机硬件那样精确。 通常可先于定制硬件之前获得，但具有大致相同的性能特性。 如参考平台与最终的目标板（不同的图形控制器、更慢的内存总线等）之间会存在差异，开发团队必须评估影响并以人工方式消耗等量的 CPU 时间。如系统使用的操作系统支持 CPU 时间分区技术，就需要对分区预算进行简单修改。如操作系统不支持时间分区技术，开发人

18、员可编制简单的程序以通过“等待循环”消耗时间。电脑桌面环境 便捷：由于 Flash 两种环境之间存在显著的性能差距。要使虚拟设备平台与预期目标机SWF 文件本身就具有以类似的方式运行是很困难的。请参见以下“在电脑上测试”。多平台的特性，因此它会像在目标机上那样在电脑上运行。利用上述所有方法，系统未必能允许人机界面充分利用 CPU还有许多背景任务也在运行。如有可能，工程人员应对这些任务的处理要求进行评估，以准确控制人机界面在目标机、参考平台或电脑模拟器上可用的 CPU 时间。在电脑上测试某些电脑虚拟环境能限制虚拟设备的 CPU 使用，然后会像目标机一样运行。例如，当使用 2 GHz 单核桌面模拟

19、 200 MHz 目标机时，开发人员只需使用 CPU 的 10% 以接近目标机系统的性能。如电脑系统使用超线程、多核、更复杂的内存总线、丰富的内存和高速缓存或专用图形控制器，开发人员必须使用更少的 CPU 以准确模拟目标机的速度。相反，系统管理程序的作用会使 电脑运行减慢，并会使预期的 CPU 占用率略有增加。最好将 CPU 占用率设置较低并留有剩余，使预计百分比减半以体现电脑优于嵌入式系统的内在优势，这不失为一种明智的策略。在 Flash 环境中管理内存Adobe Flash 对动态分配内存的使用较多。习惯静态内存模式的嵌入式系统工程师需调整以适应这种方法。系统结构设计人员必须针对最坏的情形

20、做好预算，而不必预先大量固定内存的使用。ActionScript 作为 Adobe Flash 应用程序的脚本语言也是一种碎片收集语言，它通过进一步减少开发人员需承担的责任（内存管理）赋予人机界面设计人员更多的灵活性。碎片收集是在背景中自动进行的，它并非由编程操作而是由 Flash 引擎的启发式触发的。但并非所有功能都会丢失。嵌入式 Flash 运行环境应提供一种机制，以限制运行时环境使用的最大堆内存值。这种限制有助于保证本地 C/C+ 应用程序具有足够的内存以正常运行。为验证 Flash 使用的堆内存数量，开发人员可使用至 GetTotalPlayerMemory 或 GetFreePlay

21、erMemory 的 Flash fscommand2 命令接口。 开发人员还能使用其他技术节省内存： 将过时的参考指针明确地设为空值这种技术可确保碎片收集进程会尽快解除分配不再引用的对象。否则，碎片收集器不会回收对象，除非对象离开作用域，这一过程可能（或未必能）迅速完成，具体取决于对象的生命周期。在卸载内容前，使用 “removeListener” 明确地移除侦听程序如有对象引用文件，Flash 不会从 SWF 文件中回收内存。同时，“被遗忘的侦听程序”会无意将卸载的 SWF 中未用但已分配的内存区块留在随机存储器中。这种问题的确会发生，因为侦听程序会保留卸载 SWF 的参考。 管理字体使用

22、Adobe 可在 SWF 文件中使用嵌入的字体文件，这为设计人员提供了极大的便利。但无限制的使用这种功能，可能造成在内存中同时加载字体的多个副本。为避免出现这种问题，应使用设备字体而非嵌入字体。或者，将所有字体都置于单独的容器库中，并由需要这些字体的 SWF 重新使用；这种方法能确保只加载字体的一个副本。 管理故障状态为防止系统出现故障，许多嵌入式系统都需要某种程度的动态故障恢复功能。利用底层操作系统提供的故障通告机制，前面介绍过的显示管理器便能了解运行失败的图形应用程序的情况。如某个持有互斥体的基于 Flash 的程序或图形程序运行失败，显示管理器会释放互斥体并将其传给在优先级队列中等候的下

23、一个程序。显示管理器还能恢复运行失败程序所使用的任何资源并重启系统。我们已经介绍过时间分区技术怎样帮助图形用户界面迅速一致地响应用户输入。它还能确保及时执行故障通告和恢复功能，即使它们是以较低优先级运行的。这些功能越早响应，就越能阻止更多的软件故障，避免其导致严重的软件故障。某些 Flash 开发环境还提供了连接本机代码的方式，以创建 Flash 对象扩展。在这种情况下，本机代码中的漏洞会导致关闭 Flash 运行环境的系统故障，从而中断人机界面的运行。利用故障恢复机制，系统能及时发现这些故障，并重启 Flash 引擎。但系统应保留人机界面运行状态的记录，以便使 Flash 人机界面从中断的地

24、方恢复。为实现这一目标并以透明方式向用户呈现故障恢复过程，系统可使用能接收人机界面变更通告的独立状态管理器。OpenGL ES：可负担、能再用的 3D 图形此前，我们曾介绍过系统设计人员如何利用基于 OpenGL ES 的 3D 程序顺利地集成基于 Flash 的组件。完成此类集成的功能非常重要，因为 OpenGL ES 为开发汽车 3D 界面提供了基于标准且高效的应用程序接口 (API)。例如，车载导航系统可使用 OpenGL ES 呈现前方道路的三维“鸟瞰图”，或准确地显示当地的建筑和地标。自 2003 首次发布以来，OpenGL ES 在资源有限的嵌入式系统中为用户提供了实现 3D 和 2D 图形的应用程