TWI437446B - 一種微博用戶端、微博消息之聚合方法以及即時通信用戶端 - Google Patents

Description

一種微博用戶端、微博消息之聚合方法以及即時通信用戶端

本發明關於電腦網路技術領域，尤指一種微博用戶端、微博消息之聚合方法以及即時通信用戶端。

即時通訊(IM)工具發展到今天，已經被大多數之網路使用者所接受，成為使用者必不可少之軟體工具。需要指出，網路IM工具不但於平時之休閒娛樂中，而且於用戶之工作中都有著廣泛之使用。用戶無論於生活還是工作中都大量使用IM軟體與朋友、同事以及同學等進行交流與溝通。故，使用者對IM工具(比如IM軟體)之易用性、穩定性、安全性等方面都會提出較高之要求。IM軟體主要實現之為一對一之好友單獨聊天模式，以及一對N之群或者討論群組之消息聊天模式。

隨著互聯網應用之不斷發展，出現了微型博客或者一句話博客，並且微博(比如twitter)作為一種擴展IM軟體之消息傳播機制之新產品、新應用，在不斷發展壯大。於微博中，用戶藉由140個字左右之一句話來表達自己，這種方式可以非常快速地傳播消息，實現使用者消息聊天模式從一對一、一對N到一對無窮之一種跨越。這種一對無窮之消息聊天模式亦意味著一個人可以對無窮多人進行消息之傳播，而一個人同時又可以得到來自數量級為萬級以上使用者之消息，這對大用戶量之應用提出了新的要求。

和其他網路溝通工具相比，習知之IM為對話式，其對話模式最原始亦最自然，但是效率較低，通常需要藉由很多對話才能表達出一個完整之意思。博客(blog)係文檔式，沒有明確之對話物件，博主(blogger)可以有個人風格或者定位，意思表示相對比較完整，但是寫blog之門檻較高。微博(micro-blogging)採用短消息之形式，亦沒有明確物件，但是意思相對完整。寫微博之門檻很低，可以為一句話，亦可以為一聲感歎。所以，相比於IM和blog而言，twitter等微博工具之資訊傳遞效率更高，而使用門檻更低。

在習知之微博用戶端中，微博消息係按時間順序一併呈現之，資訊呈現方式相對鬆散，缺少一定之分類聚合策略。對於整合於IM用戶端之微博模組而言，微博消息亦僅為於QQ主面板上按時間順序呈現。

進一步地，記憶體佔用量係衡量一個電腦應用工具性能之重要指標，特別為對於微博用戶端這種大批量消息展示之應用軟體，隨著使用者收到消息之增多，於介面上展示之資訊就越來越多，與此同時，該應用軟體之記憶體佔用勢必越來越大，如果沒有一個合理之記憶體使用策略，將產生非常嚴重之後果。

本發明提供了一種微博用戶端、微博消息之聚合方法以及即時通信用戶端。

在本發明提供之一種微博用戶端中，包括：消息拉取模組，用於根據地點資訊從外部之網路服務器拉取微博消息；消息池，用於儲存該消息拉取模組拉取到之微博消息；地理頁服務模組，用於生成一個或者多個地理頁，根據拉取到之微博消息對應之地點資訊於相應之地理頁上展示該微博消息。

該消息拉取模組用於：根據該微博用戶端之身份資訊獲得對應之本地地點資訊，並將該本地地點資訊轉換為對應之key值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。

該消息拉取模組用於：將該微博用戶端之用戶所選擇之歷史地點資訊或者該網路服務器提供之熱門地點資訊轉換為對應之key值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。

該地理頁服務模組包括：邏輯管理子模組，用於設置消息拉取策略；則該消息拉取模組進一步用於：根據該消息拉取策略和該地點資訊從該網路服務器拉取微博消息。

該消息拉取策略包括：單次拉取消息數和拉取消息總數；則該消息拉取模組用於：根據該單次拉取消息數一次性從該網路服務器拉取相應數量之微博消息，於檢測到地理頁之捲軸拉到底端時觸發下一次拉取，並於所拉取之消息數量達到該拉取消息總數時停止微博消息之拉取。

該消息池進一步用於：於所儲存之消息數量到達消息儲存門限時，根據消息淘汰策略釋放對應之微博消息。

該消息池用於：維護自身所儲存之一條或者多條微博消息之引用計數，並根據該引用計數確定消息淘汰策略。

該消息池用於：監視一個或者多個地理頁，當一個地理頁上顯示一條微博消息時，將該微博消息之引用計數加一，當一個地理頁被析構時，將該地理頁上原先所顯示之所有微博消息之引用計數減一。

該地理頁服務模組包括展示子模組，用於：在生成一個或者多個地理頁時，查找該微博用戶端中之容器池判斷是否存在可使用之控制項，如果存在則從該容器池獲取控制項，並將該微博消息填充到所獲取之控制項中；如果不存在則創建所需之控制項，並將該微博消息填充到所創建之控制項中。

該展示子模組進一步用於：將所生成之一個或者多個地理頁析構，並將該地理頁之控制項儲存到該容器池。

在本發明提供之一種微博消息之聚合方法中，包括：微博用戶端根據地點資訊從網路服務器拉取微博消息並儲存；該微博用戶端生成一個或者多個地理頁，根據拉取到之微博消息對應之地點資訊於相應之地理頁上展示該微博消息。

該微博用戶端根據地點資訊從網路服務器拉取微博消息包括：該微博用戶端根據其身份資訊獲得對應之本地地點資訊，並將該本地地點資訊轉換為對應之key值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。

該微博用戶端根據地點資訊從網路服務器拉取微博消息包括：該微博用戶端將其用戶所選擇之歷史地點資訊或者該網路服務器提供之熱門地點資訊轉換為對應之key值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。

該方法進一步包括：該微博用戶端根據預先設置之單次拉取消息數一次性從該網路服務器拉取相應數量之微博消息，於檢測到地理頁之捲軸拉到底端時觸發下一次拉取，並於所拉取之消息數量達到預先設置之拉取消息總數時停止微博消息之拉取。

該方法進一步包括：該微博用戶端監視一個或者多個地理頁，當一個地理頁上顯示一條微博消息時，將該微博消息之引用計數加一，當一個地理頁被析構時，將該地理頁上原先所顯示之所有微博消息之引用計數減一，根據該引用計數確定消息淘汰策略，以釋放自身所儲存之微博消息。

該方法進一步包括：於生成一個或者多個地理頁時，該微博用戶端判斷是否存在可使用之控制項，如果存在則將該微博消息填充到可使用之控制項中進行展示；如果不存在則創建所需之控制項，並將該微博消息填充到所創建之控制項中進行展示。

該身份資訊為IP位址。

於本發明提供之一種即時通信用戶端中，包括：基礎服務模組，用於儲存地點資訊和key值之轉換表；微博模組，用於根據該轉換表將作為聚合維度之地點資訊轉換為對應之key值，向外部之網路服務器發出攜帶該對應之key值之消息拉取請求，並生成一個或者多個地理頁，根據拉取到之微博消息對應之地點資訊在相應之地理頁上展示該微博消息。

該微博模組用於：根據該即時通信用戶端之身份資訊確定本地地點資訊，並根據該轉換表將所確定之本地地點資訊轉換為對應之key值。

該微博模組用於：根據該轉換表將該即時通信用戶端之用戶所選擇之歷史地點資訊或者該網路服務器提供之熱門地點資訊轉換為對應之key值。

藉由本發明提供之用戶端和方法，微博消息能夠按地點資訊聚合，給使用者獲取微博消息帶來便利。

為使本發明之目的、技術方案及優點更加清楚明白，以下參照附圖並舉實施例，對本發明進一步詳細說明。

在當前主流之微博用戶端之應用中，用戶十分希望能瞭解到其所在地點或其它熱門地點之微博消息(也可稱為廣播消息)。如果可以讓使用者藉由地區分類之形式直接查找相應地區之所有微博消息，則為於一定程度上實現了對資訊之分類聚合管理。具體實現時，可以為提供用戶當前所在地點之同城廣播，記錄使用者選擇過之城市資訊並提供該城市之微博消息，以及採用靈活之熱門地點推送策略方便使用者獲取微博消息等。

相應地，本發明提出了一種將微博消息按照地點資訊聚合之微博用戶端、微博消息聚合方法以及即時通信用戶端。本發明提供之用戶端採用鬆散耦合之結構，並且該用戶端對伺服器(server)施加盡可能少之負載量。為了實現鬆散耦合之結構，該用戶端採用分層模型之設計思路實現，將相關之邏輯功能封裝於同一個層次內，層與層之間採用介面以及抽象之資料結構表達和通信，以使各層模型之可複用性更好。在本發明一個實施例中，該用戶端之結構共分為3層：

(1)表現層，主要用於封裝以及與用戶之交互。

(2)業務邏輯層，主要用於功能性之邏輯處理、狀態儲存等。需要指出，業務邏輯層是用戶端之核心功能模組。

(3)資料層，用於資料之獲取(包括網路拉取等)與組織。

圖1為本發明一個具體實現中微博用戶端之結構示意圖，包括：消息拉取模組101、消息池102、地理頁服務模組103。進一步地，微博用戶端還包括：容器池104。

其中，消息拉取模組101，用於根據地點資訊從外部之網路服務器拉取微博消息。

消息池102，用於儲存消息拉取模組101拉取到之微博消息。

地理頁服務模組103，用於生成一個或者多個地理頁，根據拉取到之微博消息對應之地點資訊於相應之地理頁上展示所述微博消息。具體實現時，地理頁服務模組103可以用於將同城廣播地理頁展示給用戶，該地理頁上展示之微博消息都為由與該使用者同城之其它用戶發佈之。需要指出，每條微博消息都有其對應之地點資訊。

在一個具體實現中，地理頁服務模組103於展示消息之前，需要判斷消息池102中是否儲存有所需展示之微博消息。如果沒有，地理頁服務模組103將觸發消息拉取模組101進行微博消息之拉取。消息拉取模組101從外部之網路服務器拉取到微博消息後，將其儲存於消息池102中，同時提供給地理頁服務模組103進行展示。

具體地，消息拉取模組101可以根據該微博用戶端之身份資訊(比如IP位址)獲得對應之本地地點資訊，並將該本地地點資訊轉換為對應之key(關鍵)值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。

或者，消息拉取模組101將該微博用戶端之用戶所選擇之歷史地點資訊或者該網路服務器提供之熱門地點資訊轉換為對應之key值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。

為了用戶更加便利之使用，微博用戶端將記錄使用者之歷史地點資訊(比如最新一次查看之地點資訊)，保存於本地檔中，使得用戶於下次登錄時可以方便地查找到自己曾經關注過之地區。

另，為了採用更加靈活之熱門地點策略，可以將熱門地點資訊以設定檔之形式打包於微博用戶端之安裝包中，同時部署一份相同之內容在網路服務器。微博用戶端登錄成功後，該用戶端會攜帶相應之設定檔版本號詢問網路服務器，如果網路服務器發現該版本號及自身所儲存內容之版本號不符，比如用戶端提供之版本號相對較舊，則讓用戶端啟動下載之過程獲得伺服器上保存之設定檔。這樣，微博用戶端始終都能讀取到最新之設定檔，並根據當前之熱點城市及時改變自身熱門地點之配置，而無需改變微博用戶端之任何代碼邏輯，並可以做到對所有用戶端都能透明推送。

在實際應用中，用戶可以藉由點擊微博用戶端之單條消息頁中之地點，進入同城廣播地理頁。其中，同城廣播地理頁之標題(title)區域包括：

1、用戶當前所在地點，即該用戶之本地地點。點擊該地點後，當前地理頁之所有消息將會被刷新。

2、歷史地點，比如用戶所選擇之地點，包括最近一次曾經選擇過之地點或者當前選擇之地點等。

3、由伺服器推送之一個或者多個熱門地點。其中，熱門地點可以由伺服器運營，根據當前之熱門程度動態改變。

進一步地，地理頁服務模組103中設置有邏輯管理子模組105，其用於設置消息拉取策略，對多條微博消息按照地理之聚合進行邏輯管理。相應地，消息拉取模組101進一步用於：根據該消息拉取策略和該地點資訊從該網路服務器拉取微博消息。

具體地，該消息拉取策略包括：單次拉取消息數和拉取消息總數。相應地，該消息拉取模組101用於：根據該單次拉取消息數一次性從該網路服務器拉取相應數量之微博消息，於檢測到地理頁之捲軸拉到底端時觸發下一次拉取，並於所拉取之消息數量達到該拉取消息總數時停止微博消息之拉取。

實際應用中，由於同一城市之廣播消息數量十分巨大，如果一次性將所有廣播消息之轉播鏈條全部拉取下來，勢必給伺服器帶來巨大之負載量。為了於滿足服務品質之同時盡可能降低伺服器之負載量，於微博用戶端可以使用一定之消息拉取策略。藉由考慮用戶端之應用場景，於本發明之具體實現中引入批量多次之策略。比如，考慮到用戶端與伺服器一次網路交換之長度限制(比如最小位元組數)，以及單條廣播消息之平均長度，可以採用一次性拉取15條廣播消息之策略，這15條廣播消息是根據地點資訊聚合在一起，從而被一次性拉取到微博用戶端。也就是說，可以設置單次拉取消息數，避免每次拉取過多廣播消息。進一步地，當用戶看完本次拉取之15條消息並將捲軸拉到底端時將觸發下一次批量拉取之過程，直到總計拉取120條消息後，不再回應捲軸底端之觸發事件進行拉取，而是提示給用戶查看更多之字樣，讓用戶手動點擊“更多”按鈕跳轉到相應網頁。在實際應用中，單次拉取消息數和拉取消息總數可根據需要進行調整和修改。

需要指出，於微博用戶端設置之消息池可用於儲存所有之消息內容，並於消息數量到達預設之界限後採用一定之淘汰演算法釋放不再需要之消息。也就是說，消息池102也可以進一步用於：於所儲存之消息數量到達消息儲存門限時，根據消息淘汰策略釋放對應之微博消息。具體地，該消息池102用於：記錄並維護自身所儲存之一條或者多條微博消息之引用計數，並根據該引用計數確定消息淘汰策略。比如，某個頁面上顯示一條消息，則該條消息之引用計數加一，反之當該頁面析構之時候，對該條消息之引用計數減一。當某條消息之引用計數為1時，說明沒有控制項顯示該條消息，則可以釋放該條消息之記憶體資料。可以看出，該消息池102進一步用於：監視一個或者多個地理頁，當一個地理頁上顯示一條微博消息時，將該微博消息之引用計數加一，當一個地理頁被析構時，將該地理頁上原先所顯示之所有微博消息之引用計數減一。

具體實現時，每一條微博消息使用之控制項形式都是類似之，具有很大之複用性，該控制項可以包括控制項頁和控制項項(item)等。因此，地理頁服務模組103中設置有展示子模組106，用於：於生成一個或者多個地理頁時，查找容器池104判斷是否存在可使用之控制項，如果存在則從該容器池104獲取控制項，並將微博消息填充到所獲取之控制項中；如果不存在則創建所需之控制項，並將微博消息填充到所創建之控制項中。填充到控制項中之微博消息可能是消息池102中原先儲存之，亦可能為消息拉取模組101新從網路服務器拉取到之。進一步地，地理頁服務模組103中設置之展示子模組106用於：將所生成之一個或者多個地理頁析構，並將該地理頁之控制項儲存到該容器池104。

也就是說，當某一地理頁創建之時候，地理頁服務模組103會首先查找容器池104當前是否有可使用之資源，如果有，則用相應之消息內容填充對應之控制項，而不需再付出創建控制項頁及每個控制項項之消耗；如果沒有才執行控制項之創建。當使用者點擊回退按鈕時，表示當前之地理頁可以被析構，則首先對當前地理頁所顯示之所有消息於消息池102中減少相應之引用計數，另外將控制項頁及控制項項加入到容器池104中以備下次使用。

需要指出，地理頁服務模組103中之邏輯管理子模組105負責管理和維護展示子模組106之生命週期；而展示子模組106只負責介面顯示、使用者操作等與介面相關之處理。

並且，為了更有效之降低介面刷新帶來之螢幕閃動以及性能消耗，每個控制項項都採用自繪之方式實現，即自己計算控制項內部各個區域之大小及相應位置，從而於滿足使用者之使用要求之情況下，盡可能少之觸發介面控制項之重新排佈來達到更為理想之性能消耗。比如，於使用者拖動用戶端介面大小之時候，並不是在使用者拖動滑鼠之每一時刻都觸發介面之重新排佈，而只是在使用者放下滑鼠之瞬間才觸發一次介面重新排佈。

總之，記憶體之佔用量為衡量桌面應用程式性能之一個重要指標，隨著聚合到微博用戶端之微博消息之增多，其記憶體佔用之增長不可避免。於本發明之具體實現中，可藉由消息池102以及容器池104這兩個單元降低記憶體消耗。具體地，對於消息池102，採用消息淘汰策略；對於容器池104，採用控制項複用策略。

於本發明一個實施例中，微博用戶端採用VS2005之ATL工程作為開發環境實現。該微博用戶端可以為獨立之用戶端，亦可以是即時通信用戶端中之一個模組。相應地，該即時通信用戶端包括：基礎服務模組，用於儲存地點資訊和key(關鍵)值之轉換表；微博模組，用於根據該轉換表將作為聚合維度之地點資訊轉換為對應之key值，向外部之網路服務器發出攜帶該對應之key值之消息拉取請求，並生成一個或者多個地理頁，根據拉取到之微博消息對應之地點資訊於相應之地理頁上展示該微博消息。該即時通信用戶端還可以包括天氣模組，與該微博模組共用儲存於基礎服務模組中之轉換表。也就是說，為了更好之複用轉換表，本發明一個具體實現將相應之邏輯從天氣模組等外掛程式中抽離出來，放於基礎服務模組這一公共之APP層之中。

為了獲取使用者所在地點之資訊從而可以跳轉到使用者所在城市之頁面，於QQ登錄之過程中做了一次與伺服器之交互，整個過程如圖2所示。

步驟201：用戶端登錄。或者說，用戶通過用戶端登錄到伺服器。

步驟202：用戶端將自身之身份資訊(比如IP位址)上報伺服器。

步驟203：伺服器根據身份資訊查找對應之地點資訊，並確定該用戶端之key值。需要指出，key值可以作為聚合消息拉取之索引，所謂聚合消息為指按照一定維度(比如地點資訊)聚合之多條微博消息。

步驟204：用戶端將自身之身份資訊轉換為本地地點資訊向使用者顯示，並將自身之身份資訊轉換為key值，於發出消息拉取請求時攜帶該key值。

需要指出，於用戶端與伺服器通信之過程中傳輸key值，主要係為了有效地減小資料包之長度，用戶端、伺服器維護同一份轉換表，即可將相對較長之國家、省、市名稱轉換為位元組數更為精簡之key值，從而有效減少網路間資料通信之時間與負載量。於本發明一個具體實現中，轉換表可以為地點資訊與key值之對應表。

步驟205：伺服器將與該key值對應之微博消息聚合後發送給用戶端。

圖3為IM用戶端同城廣播地理頁之實現效果圖。其中，哈爾濱為用戶之本地地點。因此，使用者從單條消息頁跳轉到同城廣播地理頁時，首先展示之為哈爾濱之廣播消息。作為示例，海南為用戶所選擇之歷史地點，而北京、上海、深圳、廣州為4個熱門地點。用戶點擊北京，就會進入北京之地理頁，展示與北京對應之廣播消息。

採用本發明提供之技術方案，用戶可以很方便、快捷地查找到所在地點(比如城市、地區等)其它使用者發佈之微博消息或者廣播消息。進一步地，微博用戶端或者具有微博模組之即時通信用戶端還可以為使用該用戶端之用戶提供諸如歷史地點、熱門地點等資訊，使得使用者能夠獲得與歷史地點、熱門地點相關之微博消息，從而為使用者提供更有價值、更靈活之服務。

以上所述僅為本發明之較佳實施例而已，並非用以限定本發明之申請專利範圍；凡其它未脫離本發明所揭示之精神下所完成之等效改變或修飾，均應包含在下述之申請專利範圍內。

101．．．消息拉取模組

102．．．消息池

103．．．地理頁服務模組

104．．．容器池

105．．．邏輯管理子模組

106．．．展示子模組

S201~S205．．．根據地點資訊進行微博消息聚合之流程步驟

圖1為本發明一個具體實現中微博用戶端之結構示意圖；

圖2為本發明一個實施例中根據地點資訊進行微博消息聚合之方法流程圖；

圖3為IM用戶端同城廣播地理頁之實現效果圖。

101．．．消息拉取模組

102．．．消息池

103．．．地理頁服務模組

104．．．容器池

105．．．邏輯管理子模組

106．．．展示子模組

Claims (20)

1. 一種微博用戶端，其改良在於，該微博用戶端包括：消息拉取模組，用於根據地點資訊從外部之網路服務器拉取微博消息；消息池，用於儲存該消息拉取模組拉取到之微博消息；地理頁服務模組，用於生成一個或者多個地理頁，根據拉取到之微博消息對應之地點資訊於相應之地理頁上展示該微博消息。
2. 如申請專利範圍第1項所述之微博用戶端，其中，該消息拉取模組用於：根據該微博用戶端之身份資訊獲得對應之本地地點資訊，並將該本地地點資訊轉換為對應之key值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。
3. 如申請專利範圍第1項所述之微博用戶端，其中，該消息拉取模組用於：將該微博用戶端之用戶所選擇之歷史地點資訊或者該網路服務器提供之熱門地點資訊轉換為對應之key值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。
4. 如申請專利範圍第1-3項中任一項所述之微博用戶端，其中，該地理頁服務模組包括：邏輯管理子模組，用於設置消息拉取策略；則該消息拉取模組進一步用於：根據該消息拉取策略及該地點資訊從該網路服務器拉取微博消息。
5. 如申請專利範圍第4項所述之微博用戶端，其中，該消息拉取策略包括：單次拉取消息數和拉取消息總數；則該消息拉取模組用於：根據該單次拉取消息數一次性從該網路服務器拉取相應數量之微博消息，於檢測到地理頁之捲軸拉到底端時觸發下一次拉取，並於所拉取之消息數量達到該拉取消息總數時停止微博消息之拉取。
6. 如申請專利範圍第1-3項任一項所述之微博用戶端，其中，該消息池進一步用於：於所儲存之消息數量到達消息儲存門限時，根據消息淘汰策略釋放對應之微博消息。
7. 如申請專利範圍第6項所述之微博用戶端，其中，該消息池用於：維護自身所儲存之一條或者多條微博消息之引用計數，並根據該引用計數確定該消息淘汰策略。
8. 如申請專利範圍第7項所述之微博用戶端，其中，該述消息池用於：監視一個或者多個地理頁，當一個地理頁上顯示一條微博消息時，將該微博消息之引用計數加一，當一個地理頁被析構時，將該地理頁上原先所顯示之所有微博消息之引用計數減一。
9. 如申請專利範圍1-3項任一項所述之微博用戶端，其中，該地理頁服務模組包括展示子模組，用於：於生成一個或者多個地理頁時，查找該微博用戶端中之容器池判斷是否存在可使用之控制項，如果存在則從該容器池獲取控制項，並將該微博消息填充到所獲取之控制項中；如果不存在則創建所需之控制項，並將該微博消息填充到所創建之控制項中。
10. 如申請專利範圍第9項所述之微博用戶端，其中，該展示子模組進一步用於：將所生成之一個或者多個地理頁析構，並將該地理頁之控制項儲存到該容器池。
11. 一種微博消息之聚合方法，包括：微博用戶端根據地點資訊從網路服務器拉取微博消息並儲存；該微博用戶端生成一個或者多個地理頁，根據拉取到之微博消息對應之地點資訊於相應之地理頁上展示該微博消息。
12. 如申請專利範圍第11項所述之方法，其中，該微博用戶端根據地點資訊從網路服務器拉取微博消息包括：該微博用戶端根據其身份資訊獲得對應之本地地點資訊，並將該本地地點資訊轉換為對應之key值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。
13. 如申請專利範圍第11項所述之方法，其中，該微博用戶端根據地點資訊從網路服務器拉取微博消息包括：該微博用戶端將其用戶所選擇之歷史地點資訊或者該網路服務器提供之熱門地點資訊轉換為對應之key值，向該網路服務器發出攜帶該對應之key值之消息拉取請求，將該網路服務器中具有該對應之key值之微博消息拉取到該微博用戶端。
14. 如申請專利範圍第11-13項中任一項所述之方法，其中，進一步包括：該微博用戶端根據預先設置之單次拉取消息數一次性從該網路服務器拉取相應數量之微博消息，於檢測到地理頁之捲軸拉到底端時觸發下一次拉取，並於所拉取之消息數量達到預先設置之拉取消息總數時停止微博消息之拉取。
15. 如申請範圍專利第11-13項中任一項所述之方法，其中，進一步包括：該微博用戶端監視一個或者多個地理頁，當一個地理頁上顯示一條微博消息時，將該微博消息之引用計數加一，當一個地理頁被析構時，將該地理頁上原先所顯示之所有微博消息之引用計數減一，根據該引用計數確定消息淘汰策略，以釋放自身所儲存之微博消息。
16. 如申請專利範圍第11-13項中任一項所述之方法，其中，進一步包括：於生成一個或者多個地理頁時，該微博用戶端判斷是否存在可使用之控制項，如果存在則將該微博消息填充到可使用之控制項中進行展示；如果不存在則創建所需之控制項，並將該微博消息填充到所創建之控制項中進行展示。
17. 如申請專利範圍第12項所述之方法，其中，該身份資訊為IP位址。
18. 一種即時通信用戶端，其改良在於，該即時通信用戶端包括：基礎服務模組，用於儲存地點資訊和key值之轉換表；微博模組，用於根據該轉換表將作為聚合維度之地點資訊轉換為對應之key值，向外部之網路服務器發出攜帶該對應之key值之消息拉取請求，並生成一個或者多個地理頁，根據拉取到之微博消息對應之地點資訊於相應之地理頁上展示該微博消息。
19. 如申請專利範圍第18項所述之即時通信用戶端，其中，該微博模組用於：根據該即時通信用戶端之身份資訊確定本地地點資訊，並根據該轉換表將所確定之本地地點資訊轉換為對應之key值。
20. 如申請專利範圍第18項所述之即時通信用戶端，其中，該微博模組用於：根據該轉換表將該即時通信用戶端之用戶所選擇之歷史地點資訊或者該網路服務器提供之熱門地點資訊轉換為對應之key值。