Ajax無重新整理分頁，已經是一個大家比較熟悉的事物了，大概就是web前端頁面上有一個js的方法，通過Ajax去請求伺服器端的分頁資料介面，拿到資料後再在頁面上建立html結構，展現給使用者，類似於下面這樣：
view sourceprint?
01 |
<script type=”text/javascript”> |
02 |
function getPage(pageIndex){ |
04 |
url:"RemoteInterface.cgi", |
06 |
data:{pageIndex:pageIndex}, |
10 |
function callback(datalist){ |
11 |
//todo:根據返回的datalist資料建立html結構展現給使用者。 |
程式碼片段1
其中，RemoteInterface.cgi是一個伺服器端的介面。我們這裡限於篇幅，涉及的執行個體代碼可能都不是完整的，只為了把意思表達明白。
UI上，可能會有各種款式的分頁控制項，大家也都比較熟悉，比如：
但無非都是使用者點擊控制項觸發這裡的getPage(pageIndex)方法，這個getPage方法可能不是那麼簡單。
如果按照程式碼片段1的寫法，我們可以想象，使用者每次點擊翻頁的時候，都會請求一次RemoteInterface.cgi，在忽略資料可能有更新的情況下，除了第一次，後面每次getPage(1) 、getPage(2)、getPage(3)等等所觸發的遠程介面請求以及在網路上往返的資料流量，其實都是重複的、不必要的。每頁第一次請求的時候都可以把這些資料以某種形式緩衝在頁面上，使用者如果有興趣回頭來看之前翻過的頁，getPage方法應該先檢查本機快取當中是否包含該頁資料，如果有，則直接重新展現給使用者，而不是去調用遠程介面。按照這個想法，我們可以把程式碼片段1修改一下，如下：
view sourceprint?
01 |
<script type=”text/javascript”> |
03 |
function getPage(pageIndex){ |
04 |
if(pageDatalist[pageIndex]){ //如果本地的資料列表中包含當前請求頁碼的資料 |
05 |
showPage(pageDatalist[pageIndex])//直接展現當前資料 |
10 |
url:" RemoteInterface.cgi, |
12 |
data:{pageIndex:pageIndex}, |
17 |
function callback(pageIndex,datalist){ |
18 |
pageDatalist[pageIndex]= datalist; //快取資料 |
19 |
showPage(datalist);//展現資料 |
21 |
function showPage(datalist){ |
22 |
//todo:根據返回的datalist資料建立html結構展現給使用者。 |
程式碼片段2
這樣做一來節約網路請求往返的時間，更重要的是節約寶貴的網路流量和減輕介面伺服器的負擔。在低網速環境下或者介面伺服器運行壓力已經比較大的情況下，這種必要的改進更能顯現明顯的最佳化效果。大名鼎鼎的yahoo 34條，第一條就是盡量減少HTTP請求次數。Ajax的非同步請求，毫無疑問也是在http請求的範疇內。訪問量小的web應用或許感覺沒有必要，但是想象一下，如果有一個這樣的頁面：每天訪問量1000萬次，使用者平均翻5頁，其中有一頁為重複查看。那麼這樣一個頁面，按照程式碼片段1的寫法，平均每天將觸發5000萬次的資料請求，而按照程式碼片段2的寫法，則平均每天至少可減少1000萬次請求。如果每次請求的資料量是20kb，則可以節約1000萬*20kb=200,000,000kb 約合190G的網路流量。這樣看節約的資源是相當可觀的。
如果要繼續深究的話，程式碼片段2當中資料緩衝方法還值得討論一下。我們前面假定可以忽略分頁資料的時效性，但實際應用裡面時效性卻是個不能迴避的問題。緩衝毫無疑問會導致時效性的降低，真正的緩衝方案應該還要依賴對應用時效性要求的分析和取捨。
對於一般不是特彆強調時效性的內容，頁面上的緩衝應該還是可以接受的，一來使用者不會一直停留在一個頁面上，頁面之間有跳轉造成重新載入時，可以獲得更新後的資料。另外如果使用者有重新整理頁面的習慣的話，當他特別想看列表是否有資料更新的時候，可以選擇重新整理頁面。如果追求完美的話，還可以考慮設定一個時間範圍，比如5分鐘。如果使用者一直停留在當前頁面超過5分鐘，那麼5分鐘內他的翻頁都是先讀取頁面上的緩衝，5分鐘以後的翻頁才再次請求伺服器的資料。
有些情況，如果我們可以預知資料的更新頻率，比如多少天才可能會有一次資料更新，甚至可以考慮使用本機存放區，隔一定時間才觸發一次對伺服器資料的請求，這樣對請求數和流量的節約就更加徹底了。當然最終什麼樣的緩衝方法適用，歸根結底還取決於產品對時效性的要求，但原則還是能節約的請求和流量，盡量節約，對於訪問量超大的頁面尤其如此。
對於時效性要求高的一類資料，緩衝就完全不適用麼?當然不是的，只不過整體的思路還得再變一變。一般所謂變化，可能主要是列表當中的資料有增、減或者改動，但是絕大多數的資料還是保持不變的。大多數情況下，前面講的設定在一段時間範圍內做緩衝還是適用的。
如果有接近於要求即時更新資料的需求，大家可能很容易想到使用定時器的方法，比如每20秒執行一次getPage(pageIndex)方法並重繪列表。但大家只要聯想到前面1000萬次頁面訪問的假設，就會發現這無疑是一件超級恐怖的事情，按照這種訪問量和重試的頻率，伺服器壓力山大呀。關於這種情況怎麼處理，我想請大家去看一看Gmail、163郵箱和新浪郵箱等對郵件清單頁的處理方式。它們幾乎同時滿足了我們之前的假設：超級大的日訪問量，對資料要求即時更新等。用網路抓包工具分析一下不難發現，它們在使用者重複請求同一個頁碼的資料時，都不會向伺服器發出請求。為了保證有訊息更新時能夠及時通知使用者並且更新郵件列表，可以使用一個定時、重複進行的非同步請求，但是這個請求只是做一個狀態查詢，而不是重新整理列表。只有擷取到有訊息更新的狀態時才會發起請求去擷取更新的資料，或者狀態查詢的介面在發現有更新時會直接把更新的資料返回。事實上，163郵箱這個定時的狀態查詢，間隔時間都是設的比較長的，大概兩分鐘一次，新浪郵箱這個時間間隔更長一些，大概5分鐘一次，可以瞭解它們都在儘力減少請求數量。但是這種處理方式，可能就不是僅前端單方面就能做的，實現方案需要和後台介面整體考慮才行。
現在我們再回過頭來看一下程式碼片段2當中的資料緩衝方法。現在不再討論請求數量和流量的節約，我們來看一下前端的實現上還有沒有什麼值得深究一下的。按照程式碼片段2示意的處理方式，未經處理資料被儲存起來，當再次被調用時，showPage(datalist)需要再次根據資料去重建html結構展現給使用者，但是之前這個建立結構的過程我們是有做過的，是不是可以考慮在第一次建立結構的時候，直接把這個結構存起來呢?這樣可以減少js重複的計算，特別當結構比較複雜時更值得考慮。再想一下，這個結構之前在頁面上建立過了，翻頁的時候銷毀並再次建立新的結構，也是耗費資源的，能不能第一次建立好了之後，翻頁的時候不銷毀，只是通過控制CSS樣式給它隱藏起來，重複翻頁的時候也只是在這些建立好的結構之間控制彼此顯示或者隱藏?
最後，這裡討論的方法，不一定適用所有情景，但或者會有些許啟發，可以在適當的時候嘗試其中一二。同時思想如果發散開來，或者還不僅僅可以運用在無重新整理分頁。這裡拋磚引玉，大家一起探討。
來源：TID-財付通設計中心
