移动应用发展现状
本文首次出现在IEEE Software杂志上，由InfoQ和IEEE Computer Society提供。
移动设备已稳步获得多媒体平台的认可。 当前的工具为应用程序开发人员提供了使用各种技术（例如Java，Open C，Python，Flash Lite，XHTML / CSS，JavaScript和Mobile Ajax）的选项，以实现功能强大的移动应用程序。 内容开发人员可以使用音频，视频，多媒体消息传递和Flash来创建丰富而引人注目的移动内容。 尽管开发平台的选择主要取决于市场，但它也取决于可用平台的特性和特定应用程序的要求。 为了阐明当前开发平台的状态和趋势，我们针对各种定量和定性标准重新审视并比较了四种流行的移动应用程序运行时环境。 我们根据早期研究[1]的数据 ，技术规格，白皮书以及对32位移动应用程序开发人员进行了非正式调查的结果，进行了比较，这些经验涉及我们使用平台审查过的平台。 最重要的是，我们开发了一个简单的游戏应用程序，并在所有四个平台上实现了该应用程序，以突出四个平台的主要特征以及相对优缺点的案例研究。 我们描述了这种比较的一般结果以及游戏应用程序开发的细节。 我们将所有来源的结果汇总在表格中，并以评估不同平台对于关键应用程序-开发需求的适当程度作为结论。
四个移动应用平台
可用于手持设备的开发平台很多，包括诸如Symbian，OpenC，iPhone和Palm操作系统之类的本地环境。 Web运行时，例如小部件； 以及运行时环境（例如Python，Lazarus，Brew）以及我们在此处介绍的四个环境（Java Mobile Edition（ME）、. NET Compact Framework（CF），Flash Lite和Android），它们目前拥有最大的开发人员和部署基础。 图1总结了这四个平台的软件堆栈。
图1.用于已审查的移动应用程序开发平台的软件堆栈。 操作系统，运行时，应用程序框架和开发语言的比较。
Java ME
Java平台的此子集提供了经过认证的Java API集合，用于为资源受限的设备（例如手机，PDA和机顶盒）开发软件。
特征
Java ME在基于内核的虚拟机（KVM）之上运行，该虚拟机允许合理但不是完整的访问底层设备的功能。 Java ME通过配置和配置文件支持跨平台开发：
- 配置定义了水平设备系列（即具有类似处理和内存限制，用户界面要求和连接功能的设备）的最低Java VM功能和库集。
- 配置文件包括专门针对特定设备类的独特特征的库。
当前，所有支持Java ME的移动设备都支持以下配置和配置文件规范：
- Connected Limited Device Configuration （CLDC），一种针对资源受限设备的Java ME应用程序框架。 CLDC包含移动应用程序开发所需的Java类库的严格子集。
- 移动信息设备配置文件 （MIDP），一种在嵌入式设备（例如手机和PDA）上使用Java的规范。 MIDP是Java ME平台的一部分，位于CLDC之上。
通过CLDC / MIDP开发的Java应用程序称为MIDlet，通常打包在Java归档（JAR）文件中。
Java ME被设计为跨平台的，因此规范和实现是两个独立的过程。 Java社区过程（JCP）是指一种规范的规范过程，它使感兴趣的各方可以参与定义Java平台版本。 JCP使用Java规范请求（JSR）来记录对Java平台提出的新增建议。 移动解决方案提供商委员会将新的Java ME标准API指定为最终的JSR，其中包括该技术的参考实现的源代码。 然后，供应商可以自由开发自己的实现。
评论
就其安装和开发人员而言，Java ME是主要的移动软件平台。 但是，Java语言的“编写一次，随处运行”公理不适用于Java ME [2] 。 开发人员必须提供略有不同的应用程序版本，以解决跨各种设备功能以及配置文件，配置和API的选择的JSR集和实现中的变化。 对于给定的标题，此要求通常会导致数十个可执行文件-这种现象称为设备碎片 ，这在产品的整个生命周期中会大大增加运营成本。 碎片限制了Java ME应用程序可以访问的设备，并表明它更适合于以具有类似功能和Java API支持的设备为目标的垂直应用程序。
但是，通过针对各个操作系统，使用Java ME的开发人员可以访问大量定义良好且成熟的JSR。 例如，面向Symbian平台的Java应用程序可以覆盖全球约70％的智能手机。 80多个JSR为MIDlet开发人员提供了一系列丰富的附加技术，尽管MIDlet编程并不简单，并且需要认真的Java开发技能。
在Symbian平台上扩展MIDP 2.0的常用JSR包括蓝牙API（JSR 82），无线消息API（JSR 205）和移动3D图形API（JSR 184）。
.NET CF
.NET CF是为Windows Mobile上的应用程序设计的，是Microsoft完整.NET平台的子集[3] 。.NET CF在设备的内存中预加载了公共语言运行时（CLR）引擎，以方便移动应用程序的部署。 CLR提供了与基础设备操作系统的互操作性，从而允许将本机组件集成到移动应用程序中。
特征
原则上，.NET CF运行时类似于Java虚拟机（JVM）。 .NET开发人员无需编写用于底层操作系统的本机代码，而是编写针对托管执行环境的托管代码。 Microsoft最初设计和开发了支持多种语言和操作系统的.NET平台，旨在扩大开发人员基础并重用现有库。 但是，.NET CF开发工具Visual Studio（VS.NET）当前仅支持两种主要的.NET语言：C＃和Visual Basic（VB.NET）。 此外，它将操作系统支持限制为Windows平台，而Windows平台仅代表当今移动设备产品的一小部分。
核心组件是整个.NET框架的子集-大约占其类和功能的30％。 .NET和.NET CF中都存在一些类，但是.NET CF版本不一定支持所有完整版本的类成员（属性，方法或事件）。 许多类根本没有实现，而其他类仅部分实现。 独特的.NET CF类解决特定于设备的扩展和第三方扩展。
.NET CF用户界面设计基于.NET Windows窗体的丰富子集。
评论
.NET CF在提供托管运行时环境，丰富的库和可重用的组件（高级用户界面组件，网络连接，数据管理，XML Web服务等）以及完整的熟悉的API方面可与Java ME媲美。 .NET框架，例如Windows窗体控件。 这些功能简化了桌面开发人员向移动应用程序的过渡。
将运行时系统用于中间（托管）代码意味着相对较低的执行性能。 但是，与Java ME不同，.NET CF与语言无关，并且仅指定通用中间语言（CIL）指令。 .NET支持的语言可编译为同一CIL，因此.NET CF运行时可以执行它们。
.NET CF展示了与整个.NET平台的API级别的一致性和兼容性。 这种设计方法具有不可预见的内存占用成本，但是.NET CF仍然代表了由强大的供应商推动的快速实现。 开发人员知道要编程的硬件规格，并可以假定某些本地软件（例如Windows Media Player）的可用性。 因此，它与特定于设备的功能（电话，短消息服务，用户身份模块卡访问，蓝牙等）提供了令人满意的集成，并且没有Java ME的碎片问题。 另一方面，.NET CF的目标是一组有限的Windows终端设备，而VS.NET开发工具包括许可证费用。
Adobe Flash Lite
Flash Lite是一项专有技术，广泛用作多媒体和游戏编程平台。 Adobe专门创建了它，以帮助供应商快速将丰富的内容和交互式界面部署到移动设备。
特征
Flash Lite应用程序以基于矢量的SWF图形和动画格式存储其内容和GUI描述。 它在ActionScript中实现其应用程序和表示逻辑。
Flash Lite的原始设备制造商（OEM），运营商和开发者采用的数量正在Swift增加。 Flash Lite 1.1支持Flash 4和ActionScript 1.0。 Flash Lite 2.0和3.1（分别基于Flash Player 7和9）支持ActionScript 2.0。 尚不支持基于ActionScript 3.0的与Flash Player 9兼容的内容。
所有版本都支持万维网联盟（W3C）Tiny标准[4] ，这是W3C可缩放矢量图形（SVG）建议的移动配置文件。
评论
Flash Lite平台是图形密集型电话和PDA应用程序的合理选择。 由于采用了Flash的桌面应用程序开发人员可以轻松地将Flash Lite转换为移动应用程序，因此行业采用率有所提高。 快速开发是Flash Lite的主要优势。 它易于学习且易于迁移Flash应用程序，并且它包含一组丰富的设计器/开发人员工具。 此外，它提供了丰富的媒体支持（图像，视频，声音和动画），相对广泛的运行时安装基础以及基于矢量图形的小型部署文件。 从Flash Lite 2.x开始，它支持压缩的SWF，并且Flash Lite 3.0添加了对流行的本机Flash视频（FLV）的支持。
当前，Flash Lite最适合用于创建动画，休闲游戏，基于移动Web的Flash应用程序，前端界面以及特定于设备的内容（墙纸，屏幕保护程序等）。 但是，它不适合开发成熟的独立应用程序，主要是因为它缺少Java ME平台强大的面向移动设备的API。 Flash Lite的图形性能相对较差，部分原因是矢量图形需要复杂的处理。 它附带了广泛的工具集（Adobe CS5，Adobe Device Central），但是该工具集需要收取许可费用。 尽管Flash Lite的低级设备集成似乎是一个限制，但是第三方提供了支持创新应用程序开发的低级设备API。 例如，KuneriLite工具包扩展了Symbian平台中的Flash Lite功能。 当然，由于碎片问题和内存占用，成本会更高。
安卓系统
Google于2007年推出了Android ，以推进移动设备的开放标准。 Android是一个Apache免费软件平台，具有基于Linux的移动设备的开源许可证。 其用于移动设备的软件堆栈包括操作系统，中间件和关键应用程序。
特征
Android应用程序主要用Java编写，然后编译为Dalvik可执行文件（DEX）格式（自定义字节码）。 每个应用程序都使用自己的Dalvik虚拟机实例在其自己的进程上执行。 Dalvik运行DEX文件，这些文件在编译时会从标准类和JAR文件进行转换。 DEX文件比类文件更紧凑，更高效。 开发人员可以完全访问核心应用程序使用的所有框架和API，以及Google开发的软件库。 Android的软件架构旨在简化组件重用。 任何应用程序都可以发布其功能，然后其他任何应用程序都可以使用这些功能，但要遵守框架所实施的安全性约束。 Android软件开发套件（SDK）支持创作具有丰富功能的应用程序。 像iPhone一样，它可以处理触摸屏，加速度计，3D图形和GPS，以及电子邮件，消息传递，日历，社交网络和基于位置的服务等应用程序之间的协作。
评论
Android支持Java标准版（SE）5.0库的较大子集，这意味着从Java桌面应用程序迁移的成本降低了。 它还支持几个第三方库。 与Java ME相似，应用程序开发由流行的Java集成开发环境（IDE）（例如NetBeans和Eclipse）提供支持。 Android为面向服务的模块化应用程序和应用程序间通信提供了固有的支持。 Java ME的MIDP 3.0同样支持MIDlet间的通信。 新平台发行版引入了许多新的用户和开发人员功能-例如，帐户同步，改进的媒体播放性能以及数据库和地理位置API支持-但也引起了碎片问题。 运行Android 1.0、1.5、1.6和2.0作为应用程序的手机可能无法在所有操作系统版本上顺利运行。 目标设备堆栈中平台的开放性加剧了碎片化问题。
手机游戏案例研究
我们实现了一个玩具应用程序的四个相同版本，一个名为Snake的游戏（参见图2）。
图2.与在（a）Java ME，（b）.NET CF，（c）Flash Lite和（d）Android中开发的Snake游戏实现相关的屏幕截图。 有关游戏实现的比较数据，请参见表1。
这些实现使我们可以将平台在开发工作量和时间以及几个技术问题方面进行比较，例如声音再现，静止图像显示，菜单和应用程序界面设计，关键事件处理，内存使用，部署文件大小以及可重用性。为等效的桌面应用程序编写的代码（请参见表1）。
表1：与Snake游戏实现相关的技术问题
技术问题 | Java ME | .NET CF | Flash Lite | 安卓系统 |
开发工作（从桌面到移动端口） | 从Swing到液晶显示器用户界面（LCDUI）类的端口GUI； 将基类的main（）方法转换为MIDlet的startApp（）； 将基于Java数据库连接（JDBC）的持久性存储转换为记录管理系统（RMS） | 调整GUI以使用Windows窗体控件，并将数据库切换到SQL Server Mobile Edition | 使GUI适应屏幕尺寸 | 更改实现的接口并扩展父类； 将数据库切换到SQL Lite； 使用DroidDraw GUI设计器在XML文件中指定GUI |
代码行 | 约1100 | 约800 | 〜600 | 〜900 |
修改代码行以移植桌面应用程序 | 〜400 | 〜150 | 〜50 | 〜200 |
部署应用程序大小 | 29 KB | 63 KB | 12.6 KB | 23 KB |
为了确保公平的比较，我们专注于评估移动应用程序开发的特殊性，而不是不同的编程语言特性。 为此，我们首先实现了桌面游戏应用程序，然后将其迁移到移动平台，并尽可能重用了源代码-也就是说，我们将Java SE代码移植到Java ME和Android，将C＃.NET代码移植到.NET CF，和Flash（ActionScript）代码添加到Flash Lite。 该游戏使用相对简单的图形来响应按键事件来传达蛇的身体动作。 该实现包括一个简短的声音文件，当蛇吃东西时播放。 它还提供了暂停，恢复和更改功能，以适应蛇的速度，并且在设备的持久存储中保持了高分和游戏状态。
蛇的动作的流畅性和表现力在很大程度上取决于设备的特性（屏幕分辨率，屏幕帧频和处理器频率）。 我们无法在可用的平台仿真器上定量评估这些特征。
移动游戏一直是移动应用市场的主要推动力。 Java ME当前是可下载手机游戏的事实上的标准[5] ，特别是因为它具有游戏API。 此外，Java ME是唯一提供低级3D图形API的框架。 Flash Lite是一种流行的游戏平台，主要是因为其开发速度快且适合图形密集型应用程序。 Flash Lite 3.0更加注重视频和多媒体支持，而不是游戏开发。 但是，Flash Lite是将游戏集成到网页中的理想选择-类似于为台式机开发Flash电影。 .NET CF和Android在游戏开发方面尚未获得重要的市场份额。
在Java ME中，从桌面到移动应用程序的移植更加麻烦。 诸如JDiet（Java SE 1.4到Java ME CLDC转换器）之类的工具可能有用，但不支持GUI转换。 我们使用Java ME Polish工具集合设计了MIDlet的菜单模板，该工具集合包括用于为多个设备和语言环境创建应用程序捆绑包的构建工具。 设备数据库，可帮助调整适用于不同手机的应用程序； 使用简单CSS文本文件设计GUI的工具； 和实用程序类。 我们必须将基于JDBC的存储（例如，存储游戏状态或得分）移植到RMS，RMS不是成熟的数据库系统，但类似于Flash Lite中采用的共享对象方法。 但是，Java ME Game API的TiledLayer和GameCanvas类对于绘制游戏的风景和传达蛇的动作非常有用。
.NET CF和Android应用程序更易于开发，因为它们分别与完整的.NET和Java SE框架具有更好的兼容性。 在这两个平台中SQL数据库的使用也很简单。 我们为.NET CF修改了一些C＃方法调用，因为它不支持相应的库。 Android不需要进行此类修改。 此外，.NET CF中的声音支持很差，仅处理未压缩的声音播放，这增加了应用程序的大小。 从Flash到Flash Lite的迁移相对容易，因为在两种情况下我们都使用相同的ActionScript代码。
我们必须将桌面应用程序按键事件转换为所有平台中相应手机的键盘事件。 使用可用的Visual GUI构建器，GUI设计相对容易。 对于Android，我们必须通过第三方Droid-Draw构建器获取此工具。 值得注意的是，事实证明，将程序逻辑与GUI设计分离对所有平台都是有用的，这使我们可以为台式机和移动应用程序使用相同的游戏逻辑类。
平台比较
表2在五个定性和定量领域评估了审查平台：软件体系结构和技术问题，应用程序开发，功能和约束，开发人员社区和市场成功以及开发工具。
表2：五个领域中编程平台的比较
问题说明 | Java ME | .NET CF | Flash Lite | 安卓系统 |
软件架构和技术问题 | | | | |
脚印 | 〜128 KB用于存储基于内核的虚拟机和关联的库 | 在基于Windows Mobile的Pocket PC 2000/2002上为1.55 MB； 用于Pocket PC 2003或Windows CE .NET设备的Windows Mobile上为1.35 MB | Flash Lite 2.1的核心库为450 KB； Flash Lite 3.1的374 KB | 3兆字节 |
运行时内存要求 | <0.5 MB | 约0.5 MB | 2-4 MB | 最小32 MB的RAM |
内存管理 | 传统垃圾收集器提供的自动内存管理功能，可以重新分配程序不再使用的对象占用的内存 | 公共语言运行时（CLR）提供的自动内存管理； CLR垃圾收集器管理应用程序的内存分配和释放 | 每分钟或每当应用程序的内存使用量增加20％或更多时，垃圾收集就会自动执行 | 由Dalvik的垃圾收集器处理的自动内存管理； 垃圾收集可能会明显降低性能 |
设备支持 | 所有设备都支持连接的受限设备配置（CLDC），移动信息舞蹈配置文件（MIDP）（实际上，仅不支持基于Windows Mobile的Pocket PC） | 所有设备都支持连接的受限设备配置（CLDC），移动信息舞蹈配置文件（MIDP）（实际上，仅不支持基于Windows Mobile的Pocket PC） | Pocket PC 2000，Pocket PC 2002，基于Windows Mobile 2003的Pocket PC和智能手机，运行Windows CE .NET 4.1及更高版本的嵌入式系统 | 富士通，日立，LG，三菱，摩托罗拉，诺基亚，松下，三星，三洋，夏普和索尼爱立信等主要制造商的手机和PDA |
用户界面（UI）组件 | 高级LCDUI组件，例如Form或List； 用于控制每个UI像素的低级LCDUI； 支持SVG（在JSR 287中定义）； J2ME Polish允许设计以及在类似CSS的外部文件中指定的动画和效果 | Windows Forms控件（适用于Pocket PC和智能手机） | 诺基亚Flash Lite Feather框架（FL 2.x），索尼爱立信Adobe XD UI组件（FL 1.1 / 2.x） | View和ViewGroup对象； DroidDraw工具用于快速UI设计； J2ME Polish支持将Java ME MIDlet的UI转换为与Android兼容的UI |
开发语言 | Java（CLDC / MIDP） | C＃，Visual Basic .NET | ActionScript 1.0，ActionScript 2.0 | Java（Android SDK） |
打包 | Java应用程序描述（JAD）和Java归档（JAR）文件 | 内阁（CAB）文件安装程序 | SWF文件 | Android包（APK）文件 |
部署方式 | 无线（OTA），蓝牙/红外，无线应用协议（WAP）推送 | OTA，蓝牙 | 蓝牙，物理电缆，OTA | OTA，蓝牙 |
服务器端技术* | Java Servlet，JavaServer Pages（JSP） | ASP.NET移动控件 | Flash Media Server（将ActionScript 1用于服务器端逻辑 | Java Servlet，JSP |
永久存储和数据库支持 | 来自mObject的RMS和Perst Lite | 对SQL Server Mobile Edition的本地数据库支持； 在服务器端，对SQL Server的支持 | 通过共享对象持久存储； 在服务器端，支持与PHP脚本交互以及使用MySQL数据库 | Android API包含对SQLite数据库的支持 |
声音处理和支持的格式 | MP3和设备支持的任何格式的未压缩脉冲 | 仅代码调制（PCM）文件； 支持好 | 第三方提供的已知格式（WAV，MP3等）（例如.NET CF的Resco Audio）嵌入SWF文件中的声音文件； 支持MP3，AIFF，AU，WAV等； 不支持同时播放多种声音 | 3GP，MP3，MP4 |
2D / 3D图形处理和支持的格式 | 所有MIDP版本均支持显示栅格化图像（仅PNG格式）； MIDP增加了对SVG（JSR 226）的支持； MIDP 3.0增加了对GIF图像的支持； 在移动3D图形（M3G）格式上支持移动3D图形：M3G 1.0（JSR 184）或M3G 2.0（JSR 297） | 支持BMP，JPG，GIF和PNG格式； 不支持SVG； 适用于Windows Mobile 5.0的Direct3D移动应用程序 | 基于矢量的图形包括对位图的支持； 不提供低级3D图形API，但可以使用从3D工具导出的一系列图像 | 支持PNG，JPG和GIF； 不支持SVG； 通过OpenGL API支持3D图形 |
应用开发 | | | | |
学习曲线* | 中等（开发人员需要熟悉Java SE平台不包含的几个API） | 平均值（与.NET平台API的大量重叠） | 陡峭（重复使用相同的ActionScript代码） | 平均（与Java SE平台API明显重叠） |
开发者社区基础* | 大型社区 | 相对较大的社区 | 相对较大的社区 | 规模庞大且发展Swift的社区 |
调试器可用性 | 优秀的 | 优秀的 | 好 | 集成在Eclipse中； 还提供独立调试监视器 |
跨平台部署 | 在支持CLDC / MIDP的任何设备上执行，但是各个供应商之间的实现不一致，因此需要单独的构建 | Windows Mobile，基于Symbian的设备（通过第三方工具） | 优秀（由排名前五的移动制造商支持；最佳的Web兼容性） | 仅限于Android，因为Dalvik VM |
部署速度（打包，安装，测试）* | 慢（碎片问题） | 比较快 | 比较快 | 比较快 |
能力和约束 | | | | |
功能性 | 手机会有所不同，具体取决于可用的JSR； 没有高分辨率图片，没有单元格ID，文件访问受限 | 有限的音频支持 | 不支持访问本机组件 | 触摸屏，加速度计，GPS，小区ID，应用间通信 |
事件模型 | 基于命令对象的事件处理机制 | 通过多播委托绑定到方法的GUI事件 | 使用功能强大的ActionScript的事件模型（影片剪辑和对象事件） | 继承Java事件模型； 使用特殊的类（意图）使应用程序对外部事件（例如电话）做出响应 |
手机数据访问 | 根据手机的不同，具体取决于可用的JSR 75，PDA可选包装 | 充分 | 没有 | 充分 |
运行速度 | 平均（由于Java字节码） | 平均值（由于CLR托管代码） | 低于平均水平（口译语言） | 由于Java字节码的平均值 |
开发者社区和市场成功 | | | | |
开发者社区和支持* | 广泛 | MSDN | 广泛 | 最近，成长中 |
市场渗透* | 广泛（也是Danger Sidekick平台的基础） | 平均 | 平均 | 在34家主要软件，硬件和电信公司的支持下，有可能获得广泛认可 |
发行和许可 | 无（Java签名） | 无（第三方可以提供许可） | 没有 | 没有 |
开发工具 | | | | |
集成开发环境（IDE）的可用性 | Eclipse，NetBeans | Visual Studio .NET 2008、2010年 | Adobe Flash CS4，Adobe Device Central | Eclipse，NetBeans（带有Android插件） |
仿真器可用性 | 免费模拟器，Sun Java Wireless Toolkit | 与IDE捆绑在一起 | 与IDE捆绑在一起 | 免费模拟器 |
开发工具成本 | 自由 | 免费（但仅基本工具） | 变化：免费，但受Motion-Twin ActionScript 2 Compiler IDE的限制 | 自由 |
*信息主要来自在线调查报告的汇编。
数据反映了我们在实施Snake游戏之前和之后的产品评论和开发经验。 这也是我们对32个移动应用程序开发商进行的非正式在线调查得出的普遍结论的因素。 这些问题在问题描述中以星号表示。
对于每个平台，至少有7个开发人员参与了调查，其中包括16个有关他们在该平台上的经验的问题。 该调查可在此处获得 。 该链接提供了一些来自调查汇编的定量信息，此处未进行讨论。
平台状态和趋势
在当前的实践中，设备沿许多轴变化，以至于几乎不可能编写一个移动应用程序的单一版本以在各种设备上运行。 碎片化几乎增加了整个软件生命周期中的生产工作量–从而提高了成本，延长了上市时间并缩小了目标市场。 更好的标准化（例如，更少的可选API和更详细的规范）和更严格的标准执行（例如，使用API验证计划和技术兼容性套件）可以在这方面有所帮助。 移动应用程序行业中的主要参与者（例如平台供应商，设备制造商和运营商）可以在对抗碎片化的战争中发挥关键作用。
毫无疑问，Java ME是具有最广泛的部署基础的平台，并且仍然保持着最大的市场份额，但它是受碎片影响最大的平台，因此可能会被替代平台所取代。 Sun Microsystems已发布了一套准则，以减少为每部电话生成不同的可执行文件的做法[6] 。 已经有一些解决Java ME设备碎片的工具（例如，用于CLDC的NetBeans Mobility Pack 5.5），但是还有很长的路要走。
同样，移动服务体系结构（MSA）已成为一种行业标准，以减少碎片并为开发人员提供一致的Java ME平台。 除了指定兼容设备必须包含的JSR组件之外，MSA还阐明了行为要求，以提高JSR的可预测性和互操作性。 MSA定义了两个堆栈：包含16个JSR（JSR 249）的完整堆栈，以及八个JSR的子集（JSR 248）。 JSR 248被推到JSR 249之前，以帮助开发人员更早地开始开发符合MSA的应用程序。 JCP最近批准了JSR 248，但OEM对其采用的情况尚待观察。
Java ME在针对大量图形应用程序的平台（如Flash Lite）方面的竞争力也将取决于能够在移动设备上实现表达丰富，功能丰富的内容的技术。 为此，Sun Microsystems最近发布了JavaFX Mobile ，它是一种具有富互联网应用程序（RIA）友好功能的新平台和语言，包括用于GUI开发的JavaFX Script语言的声明性语法。 JavaFX Mobile使开发人员可以在重新使用现有后端Java代码的同时构建表达性接口。 它还使没有编程经验的开发团队成员（例如设计师和图形艺术家）可以为移动应用程序创建图形密集型前端。 但是，OEM厂商将通过JavaFX Mobile所提供的支持来决定JavaFX Mobile的成功，例如，通过在手机上集成其二进制文件和运行时。
只要Windows掌上电脑仍然存在，.NET CF就会维持其开发人员基础。 它是一个功能强大的平台，可用于编程和访问与Windows兼容的PDA和智能手机的本机组件。 但是，由于将其移植到流行的电话操作系统上很麻烦，因此其市场份额不太可能增加。 具体来说，它需要实现平台适配引擎以在CLR和操作系统之间建立接口[7] 。
Flash Lite的发行历史表明，Adobe不仅致力于为开发具有丰富功能的应用程序定义强大的API，还更加致力于支持多媒体。 尽管已努力将Flash Lite建立为游戏平台，但它缺少专门针对游戏开发的API或类。 例如，Flash Lite 3.0不支持Flash 8的一部分的BitmapData对象，该对象对游戏开发很有用。 它还需要改善其声音处理。 此外，比较研究表明，与Java ME相比，Flash Lite表现出较低的性能和帧速率，同时消耗更多的内存。 另一方面，Flash Lite似乎是设计用户界面和图形丰富的应用程序的自然选择。 从这个意义上讲，它使设计师可以进入移动开发领域。 Flash Lite的有希望的发展之路似乎在于它与不同应用程序平台的协同作用，从而汇集了最佳世界。 最近， Capuchin项目将Java ME API定义为Java ME和Flash Lite之间的桥梁。 它支持将后者用作应用程序的前端，将前者用作应用程序的后端，从而使开发人员可以使用Flash工具进行GUI设计，同时仍可以访问Java ME可用的所有电话服务。
最初，Android得到了制造商和开发商的热烈欢迎，但是一些手机制造商花费的时间比预期的要长。 因此，它的市场份额没有以预期的速度增长。 尽管如此，Android开发者社区似乎仍在增长-主要是与Java ME相比。 它的未来将在很大程度上取决于提供简化多媒体丰富应用程序设计的技术。 Sun Microsystems宣布JavaFX Mobile将在Android OS上可用。 最重要的是Android处理碎片问题的能力。 鉴于Android的安装基础相对狭窄，现在回答这个问题为时尚早。
由于Android是一个相对较年轻的软件平台，因此它在为数不多的可用应用程序中苦苦挣扎。 在第一款Android手机发布之前，Google已进行投资以吸引开发人员并准备大量应用程序。 运行大量现有的Java ME应用程序也可以为Android增加价值。 因此，一些供应商正在提供移植服务，以将现有的Java ME标题转换为Android平台。 示例包括Tira Wireless和J2ME Polish。
评估
根据我们的审查，我们已经针对四个关键应用程序开发要求评估了每个平台的适用性：
可移植性
当今手持设备中所代表的各种硬件和软件不可避免地使便携性成为移动应用程序开发人员的难题。 可移植性主要取决于运行时支持以及跨平台实现相同的外观和功能的可行性。 在运行时支持方面，Java ME无疑是赢家，其次是Flash Lite。 Android可能会扩展其部署基础，.NET CF可能仍将是仅Windows平台。
另一方面，Java ME在跨平台应用程序开发中表现出碎片化。 在这方面，Flash Lite是一个更好的选择，因为Adobe对其运行时环境进行了严格的控制。 鉴于Android的采用速度缓慢以及其替代业务模型是开放源代码，但受到Google的严格控制，Android的碎片化处理仍不清楚。 由于.NET CF的支持设备范围很窄，因此碎片不是问题。
功能性
Java ME通过OEM通过利用手机功能来实现的众多API（JSR）来最好地实现实现诸如游戏之类的多媒体丰富的成熟应用程序的目的。 .NET CF和Android应用程序还使用功能强大的API。 Flash Lite最适合图形-繁重的应用程序。
发展速度
快速上市时间是移动应用程序的关键要求。 充分利用开发人员在桌面应用程序上的编程经验，是减轻学习难度并缩短开发时间的最安全方法。 例如，Java开发人员将自然而然地适合Java ME和Android，Flash开发人员将具有Flash Lite，等等。 不熟悉任何平台基础语言的开发人员使用Flash Lite的ActionScript将感到更加舒适和高效。 尽管如此，由于文档和开发人员社区基础广泛，加速了Java ME和.NET CF等传统平台的开发过程。
性能
随着移动应用程序的计算强度越来越大，并且需要更快的运行速度和存储I / O，性能也成为一个关键问题。 处理开销，内存消耗，帧速率和部署文件大小等指标均取决于特定的开发平台工具集。 例如，它是否支持SVG Tiny，图形缓冲，压缩的声音文件等？ Java ME，.NET CF和Android达到了可比的性能，而Flash Lite落后于各种基准测试[8] 。
尽管市场和应用程序需求在很大程度上决定了移动开发的平台，但由于开发人员面临对资源受限设备上应用程序的日益增长的需求，因此我们的评论为可用工具的资产和不足提供了一些具体的通用指导。
翻译自: https://www.infoq.com/articles/ieee-mobile-platforms/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1
移动应用发展现状
