AJAX将成为移动Web2.0时代首选开发平台

<iframe align="center" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog336280.html" frameborder="0" width="336" scrolling="no" height="280"></iframe>

从加入到移动服务开发市场几年的经验来看，我相信现在的AJAX很可能会替换Java ME和XHTML而成为开发移动应用程序的首选平台。

一、 引言

　　最近,Opera宣布通过他们的浏览器把AJAX技术应用于移动设备开发中。考虑到Opera浏览器在目前浏览器市场(特别是在移动浏览器市场)的流行性,我们可以预计这一宣布对于整个浏览器市场必然会产生重要影响。从加入到移动服务开发市场几年的经验来看，我相信现在的AJAX很可能会替换Java ME和XHTML而成为开发移动应用程序的首选平台。

　　在正式开始前，我想作一下说明-我相信，移动Web 2.0远远不止"移动AJAX"这一层应用。移动Web 2.0应该包含把Web 2.0的所有七个原则都将应用于移动市场。在本文中，我想只讨论一下AJAX，也就是只讨论Web 2.0的一个方面。

　　二、 什么是AJAX?

　　AJAX是Web 2.0的一种可选的增强技术，而不仅仅指一种技术。而是,它把许多现有技术结合到一起，也就是：

　　· XHTML和CSS-用于基于标准的描述

　　· 文档对象模型-用于动态显示和交互

　　· XML和XSLT-用于数据交换和操作

　　· XMLHttpRequest-异步数据检索

　　· JavaScript-用于把前面这些技术"捆绑"到一起

　　在AJAX出现之前，实现"复制"本机应用程序所具有的丰富的和可交互的设计相当困难。AJAX在解决这些问题方面与其前应用的一些技术存在明显不同，因为它基于已经为众多开发人员所熟悉的现有的、非专利性标准。

　　在传统型web应用程序中,大多数用户行为都会触发一个HTTP请求。然后，由服务器进行一些处理并且把结果返回到用户。在服务器处理过程中，用户只能等待！从技术的角度来看，web应用程序的这种"开始-停止-开始"特征并没有什么不好的地方，但是这并没有从用户交互的角度来解决问题（因为几乎所有的用户交互都要导致到服务器的处理，而在服务器进行这一处理时，用户只能等待！）。

　　通过使用AJAX引擎，AJAX解决了这个问题。在会话的开始,AJAX应用程序加载AJAX引擎。AJAX引擎以JavaScript开发（作为一个JavaScript库）并处于一个隐藏帧中。用户与AJAX引擎进行交互而代替原来的与web服务器交互。如果用户交互并要求到服务器的处理，那么，该AJAX引擎自己来处理当前交互。当用户交互需要一些来自服务器的数据时,AJAX引擎将进行异步地调用(经由XML/XMLHttpRequest API)而不会打断的用户的"思路"。

　　AJAX是"异步的"，其含义是指，AJAX引擎与服务器的通讯以及与用户交互是异步的。因此,用户能够得到一种"无缝的"体验(也就是说，用户不必等待)。

　　当前，AJAX背后存在一种"动力"-开发人员已经熟悉对于这种技术支持的背景，并且所有组成AJAX的技术都已经成熟并稳定起来。AJAX成为web上许多新型应用程序的基础，例如Google suggest,Google Maps,还有Flickr和Amazon的A9.com的部分实现。

　　三、 移动应用程序开发模型及其缺点

　　从上面的讨论和有关参考文章来看，AJAX能够明确地解决上面这两种问题，也即是能够提供一种优异的UI和一种标准化形式的数据检索。其实，这两个问题也可以应用到移动设备，而且通过扩展，AJAX也能够有效地解决这些问题。然而，我相信，其功能远非这些！具体地说,它将会解决移动环境中的下列问题：

　　1. 市场份额问题

　　2. 移植问题（特定于下载应用程序，就象基于Java ME构建的那种）

　　3. 应用程序无障碍发布问题

　　另外,它还有大量的社区开发人员在背后支持它-这也是很重要的一个方面！

　　让我们考虑现有移动应用程序开发。移动应用程序共有两种主要种类：浏览性应用程序和下载性应用程序。当然，还有其它类型(就象消息发送应用程序、SIM应用程序和嵌入式应用程序)，但是我们今天所见的大多数的应用程序应该属于下载性或浏览性应用程序范围。

　　浏览性应用程序：从概念上讲，浏览性应用程序几乎类似于浏览web的程序，但是又具有特定于移动性的限制（例如，小型设备尺寸）。类似于web，服务可以通过一种微型浏览器加以存取-它使用一个URL来定位一个位于无线web服务器上的服务。客户端几乎不具有任何处理能力。

　　与浏览性应用程序相比，下载性应用程序(智能客户端应用程序)是这样一类应用程序：首先要下载它们，然后安装到客户端设备上。然后，这些应用程序在本地设备上运行。不象浏览性应用程序,一个下载(或智能客户端)应用程序在其运行时不需要连接到网络上。下载性应用程序也被称作是"智能客户端"应用程序，因为客户端（也即，移动设备）能够进行一些处理和/或具有一定的持续性存储能力（缓冲）。当前,大多数基于Java的游戏都是下载性应用程序，也即它们被下载到客户端，并要求在客户端作一些处理并且不需要总是连接到网络上。企业移动应用程序，例如销售行业自动化，也是经常的智能客户端应用程序的例子。

　　Java ME是开发下载性应用程序最常用的方式，而XHTML是开发浏览性应用程序最常用的方式。下面，让我们详细阐述前面所提到的问题，然后讨论AJAX技术是怎样解决这些问题的。

问题一：市场份额

　　移动应用程序是主要的消费者应用程序。就象这一时期正在发展中的其它工业一样，移动数据工业也是一个正在兴起的行业，它仅占有一定的市场份额。为了达到商业性运营目的（特别是考虑到网络效果的需要）,消费者应用程序需要有大批的用户群体。

　　上面市场的运作可能基于单个的专利标准，例如来自于Qualcomm的BREW（这显然有它的不利之处）或者通过不受任何企业实体控制的具有很少工业障碍的开放标准。

　　为了说明市场份额怎样影响一种新的服务的商业生存能力，我经常推荐使用下列途径（其中，大多数的数据都能够容易地从网上获取）。其思想是，使用"同心圆"理论试图估计出你的应用程序的目标用户群。

　　下面是我使用的一个示例步骤：

　　1. 准备发行你的应用程序的国家有多少人口？

　　2. 在上面的人口中，人均手持设备占有率是多少？

　　3. 在这样的人口中，你想雇用什么样的操作员？（大多数国家都有多种类型的移动操作员）

　　4. 在这样的人口中，你的目标手持设备是什么？（并非所有的操作员支持所有的手持设备）

　　5. 使用什么样的发布技术，是Java,SMS,还是WAP？

　　6. 应用程序是否有任何特殊技术需要，例如基于位置的服务？有多少人拥有支持这种技术的手持设备？

　　7. 你的市场分割分析提示了什么规律？(最简单的分割是男性/女性，预付/后付，等等)

　　8. 你的市场渠道有哪些？

　　9. 我们期望达到什么样的市场份额，并且基于我们的市场预算把它们转化为多少顾客数？（也即，转化率-典型情况下大约为2%）

　　这将为你提供你的目标用户群数,并且这个目标用户群数乘以每月潜在的下载数应该为你计算出你每月的收入。而且，这还能够直接联系到你的费用底值-包括你的开发费,移植费等等-以达到一种更为客观的在这种新型服务上投资所存在的成功/失败率的认识。

　　上面的方法揭示了一个市场份额问题，并且它暗示，今天很少的移动服务能够赢利。因而,我们可以创建一种增殖服务-'广播内容应用程序'，例如ringtones和图像软件；但是，在大众市场上具有极少的相应的工具应用程序。

　　问题二：移植问题

　　这个问题特定于所下载的应用程序（在Java ME中更为普遍）。在Java ME环境下，"书写一次到处运行"只是个玩笑而已！请不妨考虑一下典型地使用Java ME开发的移动游戏（一种可载的应用程序）的情况。

　　首先，好的方面在于：

　　· 据报导，有些运营商，例如Sprint，目前其移动游戏和其它数据服务占居他们每年收入的大约百分之十；

　　· 工业咨询公司Ovum注意到，现在，全球市场上存在超过四亿五千万支持Java技术的手持设备,还有三千八百万和一千五百万支持BREW和Symbian的手持设备；

　　· 移动游戏出版商在2004年在全球的销售达到１２亿美元，并且在2005年有望达到一种更强的销售势头，因为越来越多的消费者发现其实这种微型游戏控制台实际上早已存在于他们的手机上。

　　但是，接下来让我们看一下不利的因素：

　　· 游戏移植通常需要开发人员适合于不同的屏幕分辨率，处理器速度,内存量限制和音频能力,所有这些都因设备不同而存在很大差异。

　　· 对于出版商来说,这会使他们错过在一个高度竞争性的工业中关键的市场机会。

　　· 作为一个示例，设想你是一个中等规模的游戏出版商，总共有30部游戏。为了实现你的游戏能够在全世界范围内以五种语言并且仅在50种设备上可用,你需要创建7,500种不同的发布版本。以每一种发布版本需要花费$2,500计算,你需要一项接近于一千九百万美元的移植处理预算。

　　这严重地限制了业务规模，并因此使得极少的移动游戏能够赢利。

　　问题三：应用程序"无壁垒"发布

　　前面使用Java ME技术进行移动开发的每一个示例所存在的困境说明，仅仅创建一种社区（正如Sun所做的，就技术而言，其一直运行良好）是远远不够的。该技术和基于之创建的应用程序必须保持同类和可互操作以支持网络效果并且获得关键的客户群体。一种平台存在越少的"瓶颈"，则对整个工业来说意味着这是更好的事情。

四、 为什么AJAX能够替换JavaME和XHTML而成为更受欢迎的移动开发平台？

　　AJAX能否解决上面提出的问题呢？我的观点是，可以。AJAX被通过浏览器加以存取。顾客能够使用两种方式得到浏览器-或由制造商把浏览器预安装到手机中，或把浏览器作为一种独立的应用程序进行安装。

　　任何人都可以下载一种智能手机浏览器，正如这里的Opera链接所显示的60种系统的手机的情况一样。这意味着，所有的顾客能够潜在地安装他们自己的浏览器，并且如果有足够人这样做,那么我们就有了关键的用户群体问题-凭借着极少的"瓶颈"。

　　而且,AJAX提供了一种优异的用户体验并且已经得到开发人员社区对它的支持。解决了关键的用户群体问题可能性（由于更少的瓶颈）意味着更多的应用程序赢利机会-导致一种更好的应用程序的良性循环。

　　今天的Java ME已经表现出存在严重的缺陷(并不是这一技术本身而是业务模型),而XHTML也将成为"过时"，因为AJAX将提供一种优异的用户体验。因此,我相信，AJAX将会成为移动应用程序的更具优势的开发平台，从而严重影响Java ME和XHTML的市场。

　　五、 备注

　　· 我已经说过"首选"而不是"替代"，也就是说，我也并不盼望AJAX取代任何技术

　　· AJAX不可能解决所有的问题。你仍然需要创建一种对移动顾客有用的服务

　　· AJAX并非是创建一个更好的接口的唯一尝试。也存在其它一些技术尝试，但是仅有非常有限的成功，而且不是"跨工业性"的(或是专利性的)。例如来自于bitflash的移动SVG,superscape的用于3D游戏的转向技术（其实，它是JSR 184-针对Java ME的移动3D图形API的一种实现)，还有Macromedia(现在的Adobe)的移动技术，等。

　　· 并不是有大量的人在实际浏览移动互联网。尽管WAP的使用显示出一种增长势头,但是，这些数据（包括把WAP作为一种传输机制使用）典型地仅用于下载内容。换句话说,你每次都要下载一个ringtone,而且你还要隐式地创建一个WAP页面。总之，我怀疑实际浏览移动互联网的消费者数字可能很低

　　· 极少的移动操作员曾经尝试过加入到社区开发人员中。实际上，我能够想到的唯一例子只是source o2

　　· 一部分开发人员可能会从我与一个北朝鲜供应商的讨论（当时我是在汉城的imobicon进行这一谈话的）中得到一些启示。这位供应商最终设法把他的游戏显示到一家UK portal上。然而，这是因为一个北朝鲜聚合器设法与一个UK聚合器通讯的结果。因此,他现在拥有两个聚合器和一个雇佣操作员！而他自己却留下很少。这真是一件极其令人难过的事情。肯定存在某种方法来全球性创建和发布应用程序，也就是说，你要进行浏览器编程并且使用浏览器的任何人都能够下载和运行你的应用程序

　　· 移动操作员经常在处理收费和位置服务，等等问题上进行争论。这是不错的-但是让我们还是首先关心一下数字的问题吧。另外,收费都要付出一定的代价并且可能网上存在更好的收费机制。

　　六、 小结

　　总之，移动应用程序首先是消费者集中的。他们需要关键的用户群体问题。当前,该市场还相当不成熟，而且当前的商业模型也支离破碎。AJAX提供了一种潜在的更好的解决方案-比较于Java ME和XHTML来说，因为它的良好的发布机制而且组合了更少的潜在的瓶颈。所以，当前的经济模型并不积极支持Java ME，而AJAX提供了一种比XHTML更为优异的用户体验。它得到社区开发人员的大力支持。

　　最后,请注意，我已经说过AJAX将成为"首选"模型而不是"唯一"模型，我也并不盼望AJAX取代任何技术-Java ME或XHTML。

文章转自:天极开发http://dev.yesky.com/5/2457005.shtml