一、 引言
最近，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所做的，就技术而言，其一直运行良好）是远远不够的。该技术和基于之创建的应用程序必须保持同类和可互操作以支持网络效果并且获得关键的客户群体。一种平台存在越少的"瓶颈"，则对整个工业来说意味着这是更好的事情。
