移动应用程序开发的未来
|
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当前是可下载手机游戏的事实上的标准 ，特别是因为它具有游戏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 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已发布了一套准则，以减少为每部电话生成不同的可执行文件的做法 。 已经有一些解决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和操作系统之间建立接口 。 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落后于各种基准测试 。 尽管市场和应用程序需求在很大程度上决定了移动开发的平台，但由于开发人员面临对资源受限设备上应用程序的日益增长的需求，因此我们的评论为可用工具的资产和不足提供了一些具体的通用指导。 翻译自: 移动应用发展现状 （编辑：海南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
