【IT168 技术文档】 一、关注点

    这篇文章阐述了一些我从前表达的观点，同时也在文中增加了一些新的观点。本文主要关注Ajax在移动开发中的影响力(我们并不在这里大肆讨论Ajax)。

    讨论议题：

    1.什么限制了移动设备上的浏览器模式的发展，如何战胜它?

    2.Ajax在移动开发中的影响力。

    3.Ajax/浏览器模式的潜力将使应用定位在更加广泛的消费群体。

    二、对草地保龄球和长尾(long tails)的思考

    请想象一下如下情景：

    正如大多数体育爱好者一样，你正热切地关注在墨尔本召开的联邦运动会。但是，和别人不同的是你喜欢的运动是“草地保龄球”。

    “草地保龄球是什么?”人们经常会这样问你。因为很少有人(除了那些关注联邦运动会的)听说过这项运动(呵呵，这项运动将作为北京2008奥运会的表演项目)。于是你很兴奋于至少墨尔本正在进行这项比赛。但从宽泛的观点来看，像游泳、拳击这样“有魅力”的比赛才能获得所有的声誉。“草地保龄球”的确太冷门了。

而正当你将这个状况和Geek(技术迷)朋友聊起时，他会把一个称为“长尾”(long tails)的概念作为给你的解释。很明显，你就是“长尾”中的一员。

    多数情况下，80%的收入来自于20%的产品或者服务(下图中的红色部分)。剩余80%的产品具有低需求和低销量的特征。它们组成了“长尾”(就象草地保龄球一样)。“长尾”原理所说明的是:那些低数量、低销售量的产品构成了市场的主力，它们与少数畅销产品相持平甚至超出后者，前者提供了广泛的分配渠道和价格低廉的产品。

    现在假使我们为联邦运动会设计一个移动应用，并已经进行了几个月的准备。但是设计者可能不重视“草地保龄球”这一部分。

    但作为草地保龄球的铁杆球迷，你期待着全部的应用:blog、投票、图片、个人档案等等。

    移动Web2.0，Ajax和部件设计对这个场景有所帮助吗?下文便见分晓。文章主要按以下范围讨论：

    1.所有的移动应用都能采用浏览器技术实现吗?

    2.采用移动Ajax的可能性。

    3.移动Ajax技术的进化和Opera声明的意义。

    4.“围墙花园”与“开放花园”。

    5.来自JAVA ME的回应。

    6.谈谈移动游戏。

    7.为什么Ajax将代替J2me和HTML成为移动应用开发中的首选平台?

    三、所有的移动应用都能采用浏览器技术实现吗?

    在我们开始讨论移动应用和Ajax前，让我们思考一个这样的问题:所有移动应用都能采用浏览器技术实现吗?在PC/Internet的世界中，浏览器飞速成为了一个通用的客户端。但在PC世界和浏览器世界之间存在着天壤之别。

    在PC世界，我们需要一种程序来执行一个特殊类型的应用(就像word用来读写word文档、excel用来读写表格一样)。而相对的，我们使用浏览器查看任何一种应用。这使应用开发被大幅度地优化，它受到运行在客户端的软件的影响更小。

    让我们看一下浏览器和移动领域应用。假设移动设备具有更高的性能、更快速的带宽。那么在这个假设的前提下，所有的移动应用能以浏览器技术去实现吗?毕竟，工作在PC上的浏览器作为一个通用的客户端——为什么不能在移动设备上成行那?对这个问题的推断可能是:在移动设备上的浏览与在pc上使用的web浏览具有许多根本上的不同。

    为了更好的了解这些不同，我们来考虑如下的因素：

    1.间断的网络连接

    不像在pc上使用的web那样，无线网络相对不稳定，常收到信号覆盖的影响(如果进入隧道的话，你将失去连接)。

    2.带宽限制

    即使3G覆盖提前实现，实际的带宽也不足以满足需要。

    3.在客户端的数据存储

    如果设备没有本地存储，所有的数据将不得不被重复下载。而连接的间断性和昂贵的带宽又把这种存储方式逼入了绝地。

    4.最后，也是最重要的——本地应用程序提供了丰富的用户体验，特别是对像游戏之类的应用而言。

    这里还有诸如用户输入能力、屏幕尺寸之类的限制。上面因素中的一些会随着设备和技术的进步而得以改善。但是整体的用户体验仍然是重要的因素之一。

    因此，我们这个假设问题的答案是——不能，我们不能仅使用浏览器开发所有的移动应用。但浏览式应用的框架正在改变，在浏览式和下载式应用之间的界限已经不如从前那样明显了。

    在另一方面，本机和本地(native)应用提供了一项优势——更好的用户接口。但它们遭受了一些显著的缺陷——在应用中不得不覆盖多种不同的设备、操作系统、屏幕尺寸、用户接口、多个软件发布版本等问题。这也导致了移动领域的“割据”局面。