【正文】 然了，仍然有一些有待改進的地方，但這是一個好的開始。OK，電子表格就是一個富客戶端程序了嗎？當(dāng)然不是。在電子表格或者類似的桌面應(yīng)用中，業(yè)務(wù)邏輯和數(shù)據(jù)模型是在一個封閉的環(huán)境中運行的。在這個環(huán)境中，它們彼此清晰地了解對方，并且可以互相訪問，而環(huán)境之外的東西，對于它們來說是未知的（圖12）。那么客戶端又 是什么呢？它是與另一個獨立的進程相互通信的程序，后者通常運行在服務(wù)器上。一般來說，服務(wù)器總是要比客戶端大一些，能力強一些，配置更好一些，因為在服 務(wù)器上通常要存儲浩如煙海的信息?？蛻舳顺绦蚴沟米罱K用戶可以查看和修改這些信息，當(dāng)多個客戶端連接在同一個服務(wù)器上的時候，可以在它們之間共享這些信 息。圖13展示了一個簡單的客戶/服務(wù)器架構(gòu)在現(xiàn)代的n層架構(gòu)中，服務(wù)器往往要和更遠的后端服務(wù)器（例如數(shù)據(jù)庫）通信，因此被稱作“中間件”的層同時扮演著客戶端和服務(wù)器的角色。我們的Ajax應(yīng)用位于這個鏈的一端，它僅僅是作為客戶端，因此為討論方便，我們可以把整個n層系統(tǒng)看作是一個標(biāo)記為“服務(wù)器”的黑盒。我的電子表格應(yīng)用只需要管理它自己保存在內(nèi)存或本地文件系統(tǒng)中的少量數(shù)據(jù)。如果架構(gòu)設(shè)計良好的話，數(shù)據(jù)和它的表現(xiàn)形式的耦合可以非常松散，但是我不能通過網(wǎng)絡(luò)來分割或者通過網(wǎng)絡(luò)來共享它們。從這個意義上來說，電子表格應(yīng)用不是一個客戶端。與之相對應(yīng)的Web瀏覽器就是一個典型的客戶端，它與Web服務(wù)器通信，請求需要的頁面。瀏覽器有豐富的功能，用來管理用戶的瀏覽行為，常見功能有回退按鈕、歷史列表和分頁瀏覽多個文檔等等。但是當(dāng)我們把特定網(wǎng)站的Web頁面看作是一個應(yīng)用時，這些通用的瀏覽功能實際上和應(yīng)用關(guān)系不大，充其量也就如電子表格和Windows的開始按鈕或者窗口列表之間的關(guān)系。我們來考察一下現(xiàn)代的Web應(yīng)用。為了簡單起見，我們選擇了“地球人都知道”（圖14）。在瀏覽器中打開Amazon網(wǎng)站，因為在此之前我訪問過，它會給我顯示一個友好的問候、一些推薦書目，還有我的購買歷史信息。點擊推薦書目中的任何一條，就會轉(zhuǎn)到另外一個頁面（此時，頁面要刷新一下，在這幾秒鐘內(nèi)我什么也看不到）。新頁面是該書的相關(guān)信息：書評、二手書報價、同一作者的其他著作，以及以前我瀏覽過的其他書籍簡 而言之，呈現(xiàn)在我面前的是非常豐富的、關(guān)聯(lián)度很高的信息。但是對我而言，交互的方式就是點擊那些超鏈接，然后填寫一些表格。假設(shè)我在鍵盤前面不小心睡著 了，第二天才醒來，如果不刷新頁面，我就沒法知道《哈里波特》系列的新書已經(jīng)出版了，也不能將我的列表從一個頁面帶到另一個頁面，我要是想同時看到更多 一些東西也不行，因為我無法改變頁面上局部內(nèi)容區(qū)域的大小。我似乎是在批評Amazon的界面，其實并非如此，我只是拿它來做個例子。事實上，在傳統(tǒng)Web開發(fā)方式的桎梏下，他們已經(jīng)做得非常棒了。但是比起電子表格來說，它所用的交互模型毫無疑問是太有限了。為何現(xiàn)代的Web應(yīng)用仍然有這么多的局限呢？造成目前的狀況有一些合理的技術(shù)原因，我們現(xiàn)在就來考察一下。 網(wǎng)絡(luò)延遲因特網(wǎng)的宏偉藍圖是將這個世界上所有的計算機都連接起來，形成一個無比巨大的計算資源。如果能把本地調(diào)用和遠程調(diào)用等同起來，那么無論是分析蛋白質(zhì)的成分還是破解外太空的信號，使用者都無需考慮機器的物理位置，剩下來的只有愉快地計算。但是非常不幸，本地調(diào)用和遠程調(diào)用是完全不同的東西。在現(xiàn)有的技術(shù)水平之下，網(wǎng)絡(luò)通信仍然是一件代價高昂的事情（也就是說，通常很慢，而且并不可靠）。在沒有網(wǎng)絡(luò)調(diào)用的情況中，不同的方法和函數(shù)以及它們所操作的數(shù)據(jù)都位于相同的本地內(nèi)存中（圖16），向方法內(nèi)傳遞數(shù)據(jù)并且獲得方法的返回結(jié)果是非常直接的。而在有遠程調(diào)用的情況下，位于網(wǎng)絡(luò)兩端的通信雙方為了發(fā)送和接收數(shù)據(jù)在底層需要進行大量計算（圖17）。比起數(shù)據(jù)在線路上的往返，這些計算需要消耗更多的時間。傳輸一段二進制的數(shù)據(jù)，中間要經(jīng)過很多環(huán)節(jié)的編碼和解碼、錯誤校驗、失敗重發(fā)、數(shù)據(jù)包拆分和重組，數(shù)據(jù)最終轉(zhuǎn)化為0和1表示的二進制信號，通過線路（或者無線連接）到達另外一方。在本地，調(diào)用函數(shù)的調(diào)用請求被編碼為一個對象，然后將這個對象序列化為一系列字節(jié)，最后使用應(yīng)用層協(xié)議（通常是HTTP）通過物理傳輸介質(zhì)（例如銅纜、光纖或者無線電波）將其發(fā)送出去。在 遠程機器上，對應(yīng)用層協(xié)議解碼，將獲得的數(shù)據(jù)字節(jié)反序列化，創(chuàng)建一個請求對象的副本。然后對數(shù)據(jù)模型應(yīng)用這個對象并生成一個響應(yīng)對象。為了將響應(yīng)對象傳遞 給本地的調(diào)用函數(shù)，所有的序列化、反序列化以及傳輸層的操作都要反向再來一次。最后，響應(yīng)對象被傳遞給本地的調(diào)用函數(shù)。這個交互過程很復(fù)雜吧，幸好，它是可以自動完成的。盡管如此，執(zhí)行遠程調(diào)用時，上述所有這些操作仍然會在內(nèi)部執(zhí)行。如果我們到處使用遠程調(diào)用，性能勢必會大受影響。這也就是說，遠程調(diào)用是不可能和本地調(diào)用一樣有效率的。更糟糕的是，網(wǎng)絡(luò)的不穩(wěn)定更讓這種效率損失捉摸不定，難以預(yù)計。相比之下，運行在本地內(nèi)存之中的本地調(diào)用，在這一點上無疑要有優(yōu)勢得多。等等，說了半天的遠程調(diào)用，這和軟件的可用性有關(guān)系嗎？答案是，大有關(guān)系。一個成功的計算機用戶界面要能以最起碼的水平模擬我們在真實世界中的體驗。交互的基本規(guī)則之一就是，當(dāng)我們推一下、刺一下或者捅一下某個東西的時候，它立刻就會響應(yīng)。響應(yīng)的時間只要稍微拖長一點點，就會使人困惑，分散其注意力，把關(guān)注點從手頭的任務(wù)轉(zhuǎn)移到用戶界面上。遠程調(diào)用橫穿整個網(wǎng)絡(luò)，需要執(zhí)行大量的額外操作，它們往往會把系統(tǒng)拖慢，使用戶察覺到延遲。在桌面應(yīng)用中，只有當(dāng)可用性設(shè)計做得非常糟糕的時候，才會出現(xiàn)這種令用戶感覺充滿bug、反應(yīng)遲鈍的用戶界面，但在網(wǎng)絡(luò)應(yīng)用中，什么都不做就能得到大量這樣的界面。因為網(wǎng)絡(luò)延遲不可預(yù)測，這類界面問題往往都神出鬼沒，對應(yīng)用響應(yīng)的測試也難以開展。換句話說，網(wǎng)絡(luò)延遲是導(dǎo)致實際應(yīng)用的交互性糟糕的一個普遍原因。 異步交互用戶界面的開發(fā)者對于網(wǎng)絡(luò)延遲只能做最壞的假設(shè)。簡單地說，就是要盡可能讓用戶界面與網(wǎng)絡(luò)活動無關(guān)。天才的程序員們早已發(fā)明了一種確實有效而且久經(jīng)考驗的方案，來專門解決這一問題。先賣個關(guān)子，讓我們到現(xiàn)實世界中走一趟。在我每天早上必做的事中，很重要的一項是叫醒我的孩子去上學(xué)。我可以站在床邊把他們折騰醒，催著他們起床穿衣，但這是一種很耗費時間的方法，總要耗費我很多寶貴的早間時光我要叫醒孩子，看看窗外，往往會忽略了喂貓。孩子們起來之后會問我要早餐。就像服務(wù)器端的進程一樣，孩子們起床總是慢吞吞的。如果我遵循同步交互模式，就要等他們老半天。不過，只要他們嘟囔一句“我醒了”，我就可以先去干其他的事，需要時再回來看看他們。按 照計算機的術(shù)語，我需要做的就是為每個孩子在一個單獨的線程中建立一個異步進程。開始之后，孩子們會在他們的線程里自己起床，我這個父線程沒有必要同步傻 等，他們完事后會通知我（往往還會問我要吃的）。在他們醒來的過程中，我并不需要和他們交互，就當(dāng)他們已經(jīng)起來并自己穿好衣服了，因為我有理由相信他們很 快會這么做的（圖19）。對于任何用戶界面來說，這是一種沿用已久的實踐，即創(chuàng)建異步的線程，讓它在后臺處理那些需要計算很久的任務(wù)，這樣用戶可以繼續(xù)做其他的事情。當(dāng)啟動這個線程的時候，有必要阻塞用戶的操作[4]，但是在可接受的很短時間之后，阻塞就會解除。因為存在網(wǎng)絡(luò)延遲，使用異步方式來處理任何耗時的遠程調(diào)用是一種很好的實踐。實際上，網(wǎng)絡(luò)延遲問題和相關(guān)的解決方案由來已久。在老的客戶/服 務(wù)器模式中，當(dāng)設(shè)計不佳的客戶端程序碰上了高負載的服務(wù)器時，用戶界面就會出現(xiàn)讓人難以忍受的延遲。即便是在如今的因特網(wǎng)時代，當(dāng)切換頁面時，如果瀏覽器 半天出不來東西，那么這種糟糕的情況很可能就是因為網(wǎng)絡(luò)延遲造成的。在現(xiàn)有技術(shù)條件下，我們暫時還沒有辦法消除網(wǎng)絡(luò)延遲，但是至少有一個對策，那就是采用 異步方式處理遠程調(diào)用，不是嗎？糟糕的是，對于Web開發(fā)人員而言這樣做存在一個難點：HTTP協(xié) 議是一個“請求—響應(yīng)”模式的協(xié)議。也就是說，客戶端請求一個文檔，服務(wù)器要么返回這個文檔，要么告訴客戶端找不著文檔或者讓客戶端去另外一個地方找，還 可以告訴客戶端可以使用它的本地緩存，諸如此類?？偠灾?，“請求—響應(yīng)”模式的協(xié)議是一種單向的通信協(xié)議?？蛻舳丝梢韵蚍?wù)器發(fā)起連接，但是服務(wù)器不可 以向客戶端發(fā)起連接。甚至，當(dāng)客戶端下次發(fā)起通信請求時，健忘的服務(wù)器都記不起來這個客戶端是誰了（HTTP是無連接的）。多數(shù)Web開發(fā)者使用現(xiàn)代的編程語言，例如，Java、他們熟悉用戶會話（user session）的概念，這其實是應(yīng)用服務(wù)器對于不能保持連接狀態(tài)的HTTP協(xié)議的一種補救措施。HTTP就其最初的設(shè)計目的來說表現(xiàn)得非常好，采用一些巧妙的處理，它能夠適應(yīng)設(shè)計之初沒有考慮的場合。但是我們的這個異步回調(diào)方案中的關(guān)鍵特征是，客戶端會收到兩次通知，一次是在線程創(chuàng)建的時候，另一次是在線程結(jié)束的時候。標(biāo)準(zhǔn)的HTTP和傳統(tǒng)Web應(yīng)用模型可不會提供這些。像Amazon那樣的傳統(tǒng)Web應(yīng)用，是建造在頁面概念之上的。給用戶顯示一個文檔，上面包括各種鏈接和表單，用戶可進一步訪問更多的文檔。這種交互模式可以在很大的規(guī)模上支持復(fù)雜的數(shù)據(jù)集（就像Amazon和其他網(wǎng)站已經(jīng)證明的那樣），它所提供的用戶體驗也足以滿足開展業(yè)務(wù)的需要。十年來，這種交互模式在我們對因特網(wǎng)商業(yè)應(yīng)用的看法上打下了深深的烙印。界面友好的所見即所得（WYSIWYG）Web制作工具使得站點更容易被理解為一堆頁面。服務(wù)器端的Web框架使用狀態(tài)圖來對頁面的轉(zhuǎn)換建模。沒有引入，傳統(tǒng)的Web應(yīng)用就這么一直牢牢地束縛在頁面刷新操作之上，就好像這種刷新是理所當(dāng)然而且無可避免的，從沒有嘗試過任何異步的處理方案。當(dāng)然，毫無疑問，傳統(tǒng)的Web應(yīng)用肯定不是一無是處的。畢竟Amazon在這種交互模式上創(chuàng)造了成功的商業(yè)應(yīng)用。但是這種適用于Amazon的方式并不一定適用于所有的人。為什么這么說呢？要理解這一點，我們需要考察用戶的使用模式（usage pattern）。 獨占或瞬態(tài)的使用模式泛泛地討論自行車和SUV（運 動型轎車）孰優(yōu)孰劣毫無意義。因為它們各自都有優(yōu)點和缺點——舒適度、速度、油耗或者個人身份的象征等等。只有在特定的使用模式下討論，這樣的比較才有意 義。例如，是要在上下班高峰時段穿越市中心，還是要帶上一家老小去度假，或者只是要找個躲雨的地方。在類似這樣的具體情況下，我們才能有的放矢地比較。對 于用戶界面，亦復(fù)如是。軟件可用性專家Alan Cooper寫了很多有關(guān)使用模式的好文章，他定義了兩種主要的使用方式：瞬態(tài)的（transient）和獨占的（sovereign）[5]。瞬態(tài)應(yīng)用可能每天都會偶爾使用一下，但是總是作為次要的活動，突發(fā)性地用上一會兒。與之形成鮮明對比的是獨占應(yīng)用，獨占應(yīng)用需要應(yīng)付用戶每天幾個小時的持續(xù)使用。很 多應(yīng)用天生就具備獨占或者瞬態(tài)的性質(zhì)。例如，寫作用的字處理軟件就是一個獨占應(yīng)用，可能還會用到幾個瞬態(tài)的應(yīng)用，比如文件管理（文件的開啟和關(guān)閉窗口中常 常會嵌入這個功能）、字典或者拼寫檢查工具（很多字處理程序也嵌入這些功能），還有與同事聯(lián)絡(luò)的電子郵件和聊天工具。而對于軟件開發(fā)者，文本編輯器、調(diào)試 器或者IDE（集成開發(fā)環(huán)境）則是獨占的。獨占應(yīng)用常常使用得更頻繁。要知道，一個良好的用戶界面應(yīng)該是不可見的。衡量使用頻繁程度的一個好的標(biāo)尺，是當(dāng)這個用戶界面發(fā)生明顯的停頓時，它對于用戶流程的影響。例如，從一個目錄向另一個目錄移動文件要發(fā)生2秒鐘的停頓，我能愉快地接受；可是如果這兩秒是發(fā)生在我正飽含激情地用繪畫軟件創(chuàng)作一幅作品時，或者是我正努力地調(diào)試一段很難對付的代碼時，這肯定會讓我感覺十分不爽。Amazon是一個瞬態(tài)應(yīng)用，eBay、Google以及大多數(shù)大型的公眾Web應(yīng)用都是瞬態(tài)應(yīng)用。自因特網(wǎng)誕生之日起，專家們就曾經(jīng)預(yù)測傳統(tǒng)的桌面應(yīng)用面臨Web應(yīng)用的沖擊。十年過去了，這些都還沒有發(fā)生，為什么呢？基于Web頁面的方案對于瞬態(tài)應(yīng)用是足夠了，但是對于獨占應(yīng)用卻還遠遠不夠。 忘掉Web現(xiàn)代Web瀏覽器和它最原始的出發(fā)點（從遠程服務(wù)器上獲得一個文檔）相比已經(jīng)完全不是一碼事了，它們之間就像是瑞士軍刀和新石器時代的狩獵工具一樣，可謂是天壤之別。各種交互組件、腳本語言和插件，這些年來無法抑制地瘋狂發(fā)展，近乎強制地一次又一次地創(chuàng)造著新的瀏覽體驗。[。1993年的時候，Netscape創(chuàng)立之前的Marc Andreessen（Netscape的創(chuàng)始人）還在游說Tim BernersLee（Web的創(chuàng)始人，W3C的領(lǐng)導(dǎo)者）等人，列舉為HTML引入一個圖片標(biāo)簽的好處]。幾年以前，一些先行者就已經(jīng)開始把JavaScript當(dāng)作一種嚴肅的編程語言來對待。但就整體而言，更多的人仍然把它和那些假模假樣的警告框以及“點擊猴子贏大獎”的廣告一類的小把戲聯(lián)系在一起。瀏覽器大戰(zhàn)導(dǎo)致JavaScript成了個被誤解的、病態(tài)的孩子，Ajax可以看作是他的康復(fù)中心[6]。只要適當(dāng)引導(dǎo)，然后給它配上合適的框架，JavaScript就很有可能變成因特網(wǎng)的模范公民。它能真正增強Web應(yīng)用的實用性，而且不強迫用戶安裝額外的軟件，或者逼迫用戶拋棄自己心愛的瀏覽器。得到廣泛理解的成熟的工具可以幫助我們達成這一目標(biāo)。本書后面會大量提到的設(shè)計模式就是這樣一類工具。推 廣和普及一項新技術(shù)，既是技術(shù)事務(wù)，也是社會行為。一旦技術(shù)已經(jīng)成熟，人們還需要領(lǐng)會應(yīng)該如何去使用它。這一步驟常常是通過用它來做我們很熟悉的事情開始 的。比如，早年的自行車叫做“木馬輪”或者“蹬行馬”，靠腳使勁蹬地的反作用力來前進。隨著這一技術(shù)漸漸為大眾所接受，后來的發(fā)明者們會發(fā)明出這一技術(shù)新 的使用方式，給它加上踏板、剎車、鏈條齒輪以及充氣輪胎。每一次的發(fā)明創(chuàng)造，都使得自行車中馬的影子越來越淡，以至于徹底消失（圖110）。相同的過程也發(fā)生在如今的Web開發(fā)領(lǐng)域。Ajax背后的技術(shù)有能力將Web頁面轉(zhuǎn)換成某種完全不同的新東西。早期Ajax的使用嘗試使得Web頁面開始變得像“木馬輪”一樣不倫不類。要領(lǐng)悟Ajax的精髓，我們就要忘掉Web的頁面概念，也就是說，我們要打破這些年來所形成的經(jīng)驗。就在Ajax正式命名后的這幾個月，這樣的事已經(jīng)發(fā)生了不少。