AJAX將成為移動Web2.0時代首選開發平台

ajax|web|web2

一、 引言

最近,Opera宣布通過他們的瀏覽器把AJAX技術應用於行動裝置開發中。

考慮到Opera瀏覽器在目前瀏覽器市場(特別是在行動瀏覽器市場)的流行性,我們可以預計這一宣布對於整個瀏覽器市場必然會產生重要影響。從加入到行動服務開發市場幾年的經驗來看，我相信現在的AJAX很可能會替換Java ME和XHTML而成為開發行動裝置 App程式的首選平台。

在正式開始前，我想作一下說明-我相信，移動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的部分實現。

三、 行動裝置 App程式開發模型及其缺點

從上面的討論和有關參考文章來看，AJAX能夠明確地解決上面這兩種問題，也即是能夠提供一種優異的UI和一種標準化形式的資料檢索。其實，這兩個問題也可以應用到行動裝置，而且通過擴充，AJAX也能夠有效地解決這些問題。然而，我相信，其功能遠非這些！具體地說,它將會解決移動環境中的下列問題：

1. 市場份額問題

2. 移植問題（特定於下載應用程式，就象基於Java ME構建的那種）

3. 應用程式無障礙發布問題

另外,它還有大量的社區開發人員在背後支援它-這也是很重要的一個方面！

讓我們考慮現有行動裝置 App程式開發。行動裝置 App程式共有兩種主要種類：瀏覽性應用程式和下載性應用程式。當然，還有其它類型(就象訊息發送應用程式、SIM應用程式和嵌入式應用程式)，但是我們今天所見的大多數的應用程式應該屬於下載性或瀏覽性應用程式範圍。

瀏覽性應用程式：從概念上講，瀏覽性應用程式幾乎類似於瀏覽web的程式，但是又具有特定於移動性的限制（例如，小型裝置尺寸）。類似於web，服務可以通過一種微型瀏覽器加以存取-它使用一個URL來定位一個位於無線web伺服器上的服務。用戶端幾乎不具有任何處理能力。

與瀏覽性應用程式相比，下載性應用程式(智能用戶端應用程式)是這樣一類應用程式：首先要下載它們，然後安裝到用戶端裝置上。然後，這些應用程式在本地裝置上運行。不象瀏覽性應用程式,一個下載(或智能用戶端)應用程式在其運行時不需要串連到網路上。下載性應用程式也被稱作是"智能用戶端"應用程式，因為用戶端（也即，行動裝置）能夠進行一些處理和/或具有一定的持久性儲存能力（緩衝）。當前,大多數基於Java的遊戲都是下載性應用程式，也即它們被下載到用戶端，並要求在用戶端作一些處理並且不需要總是串連到網路上。企業行動裝置 App程式，例如銷售行業自動化，也是經常的智能用戶端應用程式的例子。

Java ME是開發下載性應用程式最常用的方式，而XHTML是開發瀏覽性應用程式最常用的方式。下面，讓我們詳細闡述前面所提到的問題，然後討論AJAX技術是怎樣解決這些問題的。

問題一：市場份額

行動裝置 App程式是主要的消費者應用程式。就象這一時期正在發展中的其它工業一樣，移動資料工業也是一個正在興起的行業，它僅佔有一定的市場份額。為了達到商業性運營目的（特別是考慮到網路效果的需要）,消費者應用程式需要有大批的使用者群體。

上面市場的運作可能基於單個的專利標準，例如來自於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所做的，就技術而言，其一直運行良好）是遠遠不夠的。該技術和基於之建立的應用程式必須保持同類和可互操作以支援網路效果並且獲得關鍵的客戶群體。一種平台存在越少的"瓶頸"，則對整個工業來說意味著這是更好的事情。

[1] [2]  下一頁