当前页面: 开发资料首页 → J2EE 专题 → 拥抱移动Web2.0{Ajax在移动开发领域的影响}
拥抱移动Web2.0{Ajax在移动开发领域的影响}
摘要: 这篇文章阐述了一些我从前表达的观点，同时也在文中增加了一些新的观点。本文主要关注在Ajax在移动开发中的影响力（我们并不在这里大肆讨论Ajax）。讨论议题：什么限制了移动设备上的浏览器模式的发展，如何战胜它？Ajax在移动开发中的影响力；Ajax/浏览器模式的潜力将使应用定位在更加广泛的消费群体。。。
——分析Ajax在移动开发领域的影响
作者：cleverpig
一、关注点：
这篇文章阐述了一些我从前表达的观点，同时也在文中增加了一些新的观点。本文主要关注在Ajax在移动开发中的影响力（我们并不在这里大肆讨论Ajax）。
讨论议题：
1．什么限制了移动设备上的浏览器模式的发展，如何战胜它？
2．Ajax在移动开发中的影响力。
3．Ajax/浏览器模式的潜力将使应用定位在更加广泛的消费群体。
二、对草地保龄球和长尾（long tails）的思考：
图-1 年轻的“思考者”
请想象一下如下情景：
正如大多数体育爱好者一样，你正热切地关注在墨尔本召开的联邦运动会。但是，和别人不同的是你喜欢的运动是“草地保龄球”。
“草地保龄球是什么？”人们经常会这样问你。因为很少有人（除了那些关注联邦运动会的）听说过这项运动（呵呵，这项运动将作为北京2008奥运会的表演项目）。于是你很兴奋于至少墨尔本正在进行这项比赛。但从宽泛的观点来看，像游泳、拳击这样“有魅力”的比赛才能获得所有的声誉。“草地保龄球”的确太冷门了。
而正当你将这个状况和Geek（技术迷）朋友聊起时，他会把一个称为“长尾”（long tails）的概念作为给你的解释。很明显，你就是“长尾”中的一员。
多数情况下，80%的收入来自于20%的产品或者服务（下图中的红色部分）。剩余80%的产品具有低需求和低销量的特征。它们组成了“长尾”（就象草地保龄球一样）。“长尾”原理所说明的是：那些低数量、低销售量的产品构成了市场的主力，它们与少数畅销产品相持平甚至超出后者，前者提供了广泛的分配渠道和价格低廉的产品。
图-2 “长尾”示意图
现在假使我们为联邦运动会设计一个移动应用，并已经进行了几个月的准备。但是设计者可能不重视“草地保龄球”这一部分。
但作为草地保龄球的铁杆球迷，你期待着全部的应用：blog、投票、图片、个人档案等等。
移动Web2.0，Ajax和部件设计对这个场景有所帮助吗？下文便见分晓。文章主要按以下范围讨论：
1．所有的移动应用都能采用浏览器技术实现吗？
2．采用移动Ajax的可能性。
3．移动Ajax技术的进化和Opera声明的意义。
4．“围墙花园”与“开放花园”。
5．来自JAVA ME的回应。
6．谈谈移动游戏。
7．为什么Ajax将代替J2me和HTML成为移动应用开发中的首选平台？
三、所有的移动应用都能采用浏览器技术实现吗？
图-3 这是真的吗？
在我们开始讨论移动应用和Ajax前，让我们思考一个这样的问题：所有移动应用都能采用浏览器技术实现吗？在PC/Internet的世界中，浏览器飞速成为了一个通用的客户端。但在PC世界和浏览器世界之间存在着天壤之别。
在PC世界，我们需要一种程序来执行一个特殊类型的应用（就像word用来读写word文档、excel用来读写表格一样）。而相对的，我们使用浏览器查看任何一种应用。这使应用开发被大幅度地优化，它受到运行在客户端的软件的影响更小。
让我们看一下浏览器和移动领域应用。假设移动设备具有更高的性能、更快速的带宽。那么在这个假设的前提下，所有的移动应用能以浏览器技术去实现吗？毕竟，工作在PC上的浏览器作为一个通用的客户端——为什么不能在移动设备上成行那？对这个问题的推断可能是：在移动设备上的浏览与在pc上使用的web浏览具有许多根本上的不同。
为了更好的了解这些不同，我们来考虑如下的因素：
1．间断的网络连接：
不像在pc上使用的web那样，无线网络相对不稳定，常收到信号覆盖的影响（如果进入隧道的话，你将失去连接）。
2．带宽限制：
即使3G覆盖提前实现，实际的带宽也不足以满足需要。
3．在客户端的数据存储：
如果设备没有本地存储，所有的数据将不得不被重复下载。而连接的间断性和昂贵的带宽又把这种存储方式逼入了绝地。
4．最后，也是最重要的——本地应用程序提供了丰富的用户体验，特别是对像游戏之类的应用而言。
这里还有诸如用户输入能力、屏幕尺寸之类的限制。上面因素中的一些会随着设备和技术的进步而得以改善。但是整体的用户体验仍然是重要的因素之一。
因此，我们这个假设问题的答案是——不能，我们不能仅使用浏览器开发所有的移动应用。但浏览式应用的框架正在改变，在浏览式和下载式应用之间的界限已经不如从前那样明显了。
在另一方面，本机和本地（native）应用提供了一项优势——更好的用户接口。但它们遭受了一些显著的缺陷——在应用中不得不覆盖多种不同的设备、操作系统、屏幕尺寸、用户接口、多个软件发布版本等问题。这也导致了移动领域的“割据”局面。
四、采用移动Ajax的可能性：
抛离上面的说法，我相信Ajax将导致浏览式应用的复苏，它将克服我们现在所面对的一些问题，理由如下：
1．到浏览器的抽象转移：
基于浏览器的应用相对易于升级、并能用在跨运营商的领域。这将吸引一个较大的目标用户群。开发者能访问消费者中核心群体来促进应用开发更有价值。正因为浏览器提供了一种通用客户端，所以它也减少了应用的分离（fragmentation）。
2．Ajax提供了更佳的浏览器体验核数据管理能力。
3．来自Internet上的开发者对Ajax的支持。
重量级的产业力量正在转移他们的支持到Ajax上来（IBM对Open Ajax的支持就是个好例子）。
4．部件设计的概念并非新鲜事物。
本文中，部件指的是一种可下载的交互软件对象，它提供了单一的服务（如地图、新闻feed等）。Ajax提供了在浏览器上实现部件的机制。
5．Ajax为部件写作市场（widget authoring market）提供了温床，就象Apple widgets 和 Opera widgets那样。
我相信Ajax通过提供丰富的体验、更大的用户群体、数据管理能力、部件写作工具而使浏览式应用的复苏更进一步。
另外，开发者的支持（包括在web领域和移动领域的）将引领Ajax形成一个我们难以想象的强大系统。
五、移动Ajax技术的进化和Opera声明的意义
图-4 人的进化？
Opera平台由以下主要特性组成：
1．全屏模式的Opera web浏览器；
2．一个运行多个部件/应用的Ajax框架；
3．通过抽象层访问设备本地功能（native functionality）。
仅在2005年，Opera就已经在17000万移动浏览器上支持Ajax。这意味着凭借现有的Opera浏览器你可以使用桌面Ajax服务：例如Gmail、Google Maps等。
但是，其意义远远不止支持Ajax这一点：
1．Opera平台是首创的移动Ajax框架。
它也是一个名副其实的浏览器框架。但，和其它框架比如Zimbra (zimlets) 和 Backbase不同，它完全是为移动设备而设计的。它在浏览器和移动设备的设计上采用了相同的代码库。通过微小的改变，桌面浏览器部件也能运行在移动设备上。从开发者的角度看，这是一个再好不过的使部件（桌面、移动设备、浏览器）最大化获利的方法。Opera声明对移动应用开发意义深远的一点是它把一个庞大的代码库与获利紧密结合在一起。
2．部件调用其它部件。
复杂的应用可以由简单的、基于浏览器的组件开发而成。
3．Opera平台允许访问底层设备API。
为了说明这个概念，我们首先考虑一下浏览器模式在建筑学上的不足。
浏览器模式是基于标记（mark-up）语言、以文档为核心的。而相对的，那些被下载的或是本地的应用则以应用为中心，因为它们是基于某种编程语言的。
为了达到实用需要，任何移动应用开发模式必须具有访问那些和设备紧密耦合的数据成员。它们包括电话API、电话簿、短消息、消息API、呼叫记录、SIM卡、日历、蓝牙堆栈、媒体播放器、文件系统等。
运行在手机上的应用能够通过API访问这些服务。而在大多数情况中，运行在浏览器的应用却不能访问这些功能（除了一些厂商私有的解决方案）。
Opera平台是一个基于浏览器的编程环境，它通过一套javascript API将本地设备API进行了抽象，这样来提供给开发者从浏览器访问设备底层功能。它使建立的更加丰富的浏览器应用成为了可能。
让我们回到“草地保龄球”的话题，对Ajax、部件进行一些说明：Ajax的能力在于建立桌面极的部件。通过Opera平台的方式，同一个部件能被重用在移动设备上。这些部件便具有了从“长尾”获得收入的能力。在联邦运动会这个场景中，它应有可能为草地保龄球迷们提供低成本的部件。这些部件无论运行在桌面浏览器或是在移动浏览器上都运行良好。这就是Ajax方式的重大意义。
有人会站出来争辩：这个方式不是纯正基于浏览器的方式（因为客户端需要以某些软件的形式在本地执行）。另外，请注意平台方式和使用插件是不同的，因为插件是可以被下载。而平台却作为设备的一部分被生产厂商安装在设备中。
我同意称这种方式不够“纯正”的说法。但是以这种方式，开发者将处理很少的平台，而不是他们不得不去与之斗争的数以百计的变化体。
这种方式不是开发的。在一个平台开发的应用只能运行在此平台。并且此方式并没有获得开放移动联盟（这里简称为OMA）的认可。整个问题对于移动运营商来讲还太早，因为它还需要经过由浏览器厂商到设备生产商再到运营商的过程。但W3C mobile web initiative也可以作为与OMA协作的一个标准体。
最后，这种方式对于一些应用类型（例如游戏）来讲还不够“丰富”。
但无论如何，这也是在前进路上迈出的一大步，因为我们具有一个更统一、跨运营商的“运动场”。
从历史上看，流行技术常常依赖于产业支持。比如粗糙陈旧的SQL，软件厂商们（例如Sybase、Informix等）都各自发布一个SQL的程序版本（例如Oracle的PLSQL）。SQL和PLSQL在某些方面是矛盾的，因为SQL是基于集合的，而PLSQL是程序式的。
但是“程序式”的SQL由于产业需要而存在了下来。我们在Ajax身上印证了同样的现象。
六、“围墙花园”与“开放花园”
图-5 哈哈，围墙花园的门打开了！
“围墙花园”本意指采用围墙的花园，它把围墙作为掩体把无法适应本地气候的花卉苗圃保护起来，使其避免气候的“折磨”；“开放花园”与“围墙花园”相反，它没有围墙，使花草生长在风霜雨雪的自然环境里。
这里存在着两种“围墙花园”：
首先是一个偏激的例子，就像3这个网站，它阻塞来自于本网站之外的访问。这种情况很类似没有评论功能的新闻列表，用户只能读取。
另一种则是像Vodafone网站一样的。Vodafone live虽然是一个“围墙花园”，但它自己没有对来自浏览器的访问进行任何限制。
正由于目前一些应用迁移到了浏览器端（因此能跨运营商），所以基于Ajax的方式将解决“围墙花园”的问题。实际上，当前的浏览器技术也能跨越运营商。但基于Ajax的方式为我们提供了建造出色的应用并可在浏览器模式中访问设备API的机会。所以它扩大了应用的目标用户群。
如果浏览器体验被提升，我们可以编写基于浏览器的应用给大多数运营商，从而获得巨大的用户市场。
七、来自JAVA ME的回应
Ajax平台拉进了在基于浏览器的应用与下载式的应用之间的鸿沟。瘦客户端仍会采用在那些需要保持连接的移动环境。而抛开这些应用，随着用户接口的提高、访问设备能力进一步实现，潜在的用户群体将增加而开发花费则会减少。
Ajax具有比较优越的开发模式，并不断地从开源世界汲取养分。Java（MIDP）目前具有较好的文档说明和完备的部署。Symbian、WinMobile提供了更多的电话集成功能，但它们是不可移植的、完全厂商私有的。Adobe Flash是另一个有趣的东东，但没有已经对Ajax的支持。因此它只是一个增强器，而不并非Ajax的竞争者。
八、移动游戏
图-6 完美的“移动”Game
举个例子：移植游戏的成本在300至600之间（但大多数情况是在500至600之间）。我们拥有近80个支持250种手机、不同语言的版本。但仅采用了单一的技术（很典型的是Java）进行开发，所以这里不包含Brew版本。支出的重要因素是对MIDP1.0的支持，于是需要增加从100%~150%不等的开发费用作为移植花销。而且还有可能改变一些游戏内容的类型（比如2D/3D）。
这样，多数移动应用被迫减少对游戏/娱乐方面的投入，但这一点都不值得可怜。应用和游戏在开发、市场上具有天壤之别吗？我并不是唯一认为游戏当前的事态呈现颓势的人。像前面所讲的，移动游戏开发非常消耗人力，一个游戏需要为不同的手机进行数百次的潜在优化。这些设备实现不同的MIDP，具有不同的屏幕尺寸、键盘布局和用户接口。这些潜在的花费和时间是巨大的。
而一种兴旺的产业不可否认的存在于游戏移植领域。如果WORA（Write once run anywhere）成为事实的话，花费在使游戏跨越设备和运营商上的投入应该相对的便宜些。——但这个假设目前不成立。事实上，像babel media这样的公司，其主要的收入来源于游戏移植，即使移动游戏适应发行商和运营商制定的标准。
最终，这种产业模式成为了一种获利不斐的商业模式，没有它移动游戏产业将无法生存、更不可能发生任何变革。于是，不少小型开发团队加入分配渠道，并可能获得了很“大方”的回报。
这些因素比美丽的一面更加重要。浏览器模式有能力冲破这些当前折磨着游戏产业的问题。目前，我们付出了昂贵的代价来获得一个“华丽”的接口。我相信开发一款成功的移动游戏并不必需具备一个华丽的接口。事实上，成功的游戏可以采用非常简单的技术：比如SMS。另外休闲游戏也正在日趋盛行。
由于移动游戏与PC游戏不同，所以把从PC游戏中获得的经验和概念应用到移动游戏上的确是一个错误。而通过浏览器模式，相对轻易地可获得更多的收入和更多的社区（用户群）。
九、为什么移动Ajax将代替J2ME和XHTML成为移动应用开发的首选平台？
图-7 你打算搭乘哪班列车？
请在脑海中呈现这句话：“Ajax代替J2ME和XHTML成为移动应用开发的首选平台”和“Ajax将代替J2ME和XHTML成为移动应用开发的首选平台”是不同的，并请注意这里的用词：“首选平台”。
让我们以实例详细阐述：假如你的第一个工作是软件开发，在大学你学习过“C”语言和Unix。你的项目团队经常在一起吃饭，谈论的话题总是相同的：Team Leader（一个经历多年软件开发的老手）常常开始挑起这个话题，他着迷于“AS400是VAX的杀手？还是， VAX是AS400的杀手”（换言之就是那种平台更好）。你经常着迷于这个技术讨论。
当你问起“Unix怎么样？”时，有人会轻视地回答：“哦，那些是PC系统”。然后他们继续AS400 vs VAX的话题。
在数年后，事情发生了戏剧性的变化。VAX和AS400都仍然存在，但应用首选平台却不是它们中的一员。如果你要开发新的应用，那么你未必将它们作为你的首选而考虑。但请注意，它们并没有被新的应用所代替。这是由经济而不是技术所决定的。
现在，你应该清楚了我的意思：浏览器/Ajax将成为开发的首选模式，但不只有此一种开发模式。
十、相关资源：
拥抱移动web2.0时代{AJAX for 移动设备}
拥抱移动Web2.0：{信步在无线荫蔽下的“移动花园”}
Opera Platform SDK快速教学 For Matrixer
最后祝大家万圣节快乐！
↑返回目录
前一篇: 《实战POJOs》：开发企业级Java应用程序
后一篇: 拥抱移动Web2.0：{信步在无线荫蔽下的“移动花园”}