專利名稱：一種基于im客戶端實(shí)現(xiàn)消息圖片管理的方法和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計(jì)算機(jī)技術(shù)領(lǐng)域，尤其涉及一種基于即時(shí)通訊(IM)客戶端實(shí)現(xiàn)消息圖片管理的方法和裝置。
背景技術(shù)：
網(wǎng)絡(luò)即時(shí)通訊(IM，Instant Messaging)工具發(fā)展至今，已經(jīng)被眾多的網(wǎng)民所接受，并已成為用戶必不可少的軟件工具，IM不但在平時(shí)的休閑娛樂(lè)中，而且在用戶的工作中得到廣泛的使用。因此，在實(shí)際應(yīng)用過(guò)程中，用戶對(duì)IM的易用性、穩(wěn)定性、安全性等方面提出了較高的要求。在IM軟件中，主要實(shí)現(xiàn)的是一對(duì)一的好友單獨(dú)聊天模式、以及一對(duì)多的群或者討論組的消息聊天模式。隨著互聯(lián)網(wǎng)應(yīng)用的不斷發(fā)展，類似推特(twitter)的微博應(yīng)用作為一種擴(kuò)展IM消息傳播機(jī)制的新工具也不斷發(fā)展壯大，這類微型博客使用戶通過(guò) 140個(gè)字左右的信息量來(lái)表達(dá)自己，這種方式可以非常快速的進(jìn)行傳播，實(shí)現(xiàn)用戶消息聊天模式從一對(duì)一、一對(duì)多到一對(duì)無(wú)窮的跨越；這種一對(duì)無(wú)窮的消息聊天模式也意味著一個(gè)用戶可以對(duì)無(wú)窮多個(gè)用戶進(jìn)行消息的傳播，同時(shí)一個(gè)用戶同時(shí)也可以收取萬(wàn)級(jí)以上的用戶消息，從而，這也就對(duì)大用戶量的應(yīng)用提出了新的要求。微博作為一種擴(kuò)展IM消息傳播機(jī)制的新應(yīng)用得到了快速的發(fā)展，但是原有IM工具中的好友數(shù)量(最多幾百個(gè))與微博的收聽(tīng)用戶量顯然不在同一個(gè)等級(jí)上(萬(wàn)級(jí)以上)； 由于微博收聽(tīng)的用戶量非常巨大，這就造成IM客戶端收到微博消息的消息量會(huì)非常大，然而，目前在IM客戶端中缺少一種能夠針對(duì)這種大消息量的圖片進(jìn)行上傳以及下載拉取管理的技術(shù)方案，從而無(wú)法快速有效的實(shí)現(xiàn)類似微博這種大消息量應(yīng)用中的圖片上傳和下載管理與展現(xiàn)。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種基于IM客戶端實(shí)現(xiàn)消息圖片管理的方法和裝置，以快速有效的實(shí)現(xiàn)類似微博這種大消息量應(yīng)用中的圖片上傳和下載管理與展現(xiàn)。為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的本發(fā)明提供了一種基于即時(shí)通訊(IM)客戶端實(shí)現(xiàn)消息圖片管理的方法，該方法包括當(dāng)IM的用戶需要下載圖片時(shí)，IM客戶端的下載組件根據(jù)所需下載圖片的統(tǒng)一資源定位符(URL)和類型查詢本地保存路徑中是否有所需下載圖片，如果有，則直接返回所需下載圖片在本地保存的路徑；如果沒(méi)有，則執(zhí)行相應(yīng)圖片的下載，并將下載的圖片保存到本地。所述當(dāng)IM的用戶需要下載圖片時(shí)，IM客戶端的下載組件根據(jù)所需下載圖片的URL 和類型查詢本地保存路徑中是否有所需下載圖片，具體為當(dāng)用戶觸發(fā)所需下載圖片的縮略圖或鏈接時(shí)，根據(jù)所述縮略圖或鏈接獲取所需下載圖片的URL和類型；將獲取到的URL和類型與所述IM客戶端本地保存路徑中的圖片的URL和類型進(jìn)行匹配，如果匹配到相同的URL和類型，則判斷所述本地保存路徑中有所需下載圖片；否則，判斷所述本地保存路徑中沒(méi)有所需下載圖片。該方法進(jìn)一步包括在下載成功時(shí)，將以URL和類型命名的圖片保存到IM客戶端本地。該方法進(jìn)一步包括在下載失敗時(shí)，判斷對(duì)應(yīng)圖片是否為第一次下載失敗，如果是第一次下載失敗，則將對(duì)應(yīng)圖片的狀態(tài)修改為第一次下載失敗并重新下載；否則，結(jié)束下載。該方法進(jìn)一步包括當(dāng)IM的用戶需要上傳圖片時(shí)，IM客戶端的上傳組件通過(guò)對(duì)批量上傳接口的調(diào)用， 將等待批量上傳的圖片加入等待上傳隊(duì)列中，并通過(guò)對(duì)等待上傳隊(duì)列的掃描，對(duì)所述等待上傳隊(duì)列中的圖片進(jìn)行上傳。在上傳完成后該方法進(jìn)一步包括解析生成的上傳結(jié)果文件，如果解析顯示上傳成功，則進(jìn)一步解析得到所上傳圖片的URL和類型；根據(jù)解析得到URL和類型命名圖片并保存到所述IM客戶端本地。該方法進(jìn)一步包括所述圖片的上傳還需調(diào)用底層組件，負(fù)責(zé)創(chuàng)建上傳的傳輸控制協(xié)議(TCP)通道， 并建立連接；所述IM客戶端采用底層組件的管理池，負(fù)責(zé)多個(gè)底層組件的提供以及管理多個(gè)底層組件的狀態(tài)。本發(fā)明還提供了一種基于IM客戶端實(shí)現(xiàn)消息圖片管理的裝置，該裝置包括下載組件，用于在IM的用戶需要下載圖片時(shí)，根據(jù)所需下載圖片的URL和類型查詢本地保存路徑中是否有所需下載圖片，如果有，則直接返回所需下載圖片在本地保存的路徑；如果沒(méi)有，則執(zhí)行相應(yīng)圖片的下載，并將下載的圖片保存到本地。所述下載組件進(jìn)一步用于，當(dāng)用戶觸發(fā)所需下載圖片的縮略圖或鏈接時(shí)，根據(jù)所述縮略圖或鏈接獲取所需下載圖片的URL和類型；將獲取到的URL和類型與所述IM客戶端本地保存路徑中的圖片的URL和類型進(jìn)行匹配，如果匹配到相同的URL和類型，則判斷所述本地保存路徑中有所需下載圖片；否則，判斷所述本地保存路徑中沒(méi)有所需下載圖片。所述下載組件進(jìn)一步用于，在下載成功時(shí)，將以URL和類型命名的圖片保存到IM 客戶端本地。所述下載組件進(jìn)一步用于，在下載失敗時(shí)，判斷對(duì)應(yīng)圖片是否為第一次下載失敗， 如果是第一次下載失敗，則將對(duì)應(yīng)圖片的狀態(tài)修改為第一次下載失敗并重新下載；否則，結(jié)束下載。該裝置還包括上傳組件，用于在IM的用戶需要上傳圖片時(shí)，通過(guò)對(duì)批量上傳接口的調(diào)用，將等待批量上傳的圖片加入等待上傳隊(duì)列中，并通過(guò)對(duì)等待上傳隊(duì)列的掃描，對(duì)所述等待上傳隊(duì)列中的圖片進(jìn)行上傳。所述上傳組件進(jìn)一步用于，在上傳完成后，解析生成的上傳結(jié)果文件，在解析顯示上傳成功時(shí)，進(jìn)一步解析得到所上傳圖片的URL和類型，并根據(jù)解析得到URL和類型命名圖片并保存到所述IM客戶端本地。該裝置還包括底層組件，用于負(fù)責(zé)創(chuàng)建上傳的TCP通道，并建立連接；底層組件的管理池，負(fù)責(zé)多個(gè)底層組件的提供以及管理多個(gè)底層組件的狀態(tài)。本發(fā)明所提供的一種基于IM客戶端實(shí)現(xiàn)消息圖片管理的方法和裝置，在微博應(yīng)用中由于消息傳播的特點(diǎn)以及泛關(guān)系鏈的用戶模型，可以非常方便的實(shí)現(xiàn)大消息量中圖片信息的上傳與下載拉取管理；另外，本發(fā)明通過(guò)URL和圖片的類型來(lái)唯一確認(rèn)圖片，并將已下載過(guò)的圖片用URL和類型命名后保存到IM客戶端本地，這可以有效避免重復(fù)下載。


圖1為本發(fā)明中微博消息圖片的上傳和下載組件的結(jié)構(gòu)示意圖；圖2為本發(fā)明實(shí)施例中基于IM客戶端實(shí)現(xiàn)微博消息圖片上傳的方法流程圖一；圖3為本發(fā)明實(shí)施例中基于IM客戶端實(shí)現(xiàn)微博消息圖片上傳的方法流程圖二 ；圖4為本發(fā)明實(shí)施例中基于IM客戶端實(shí)現(xiàn)微博消息圖片下載的方法流程圖。
具體實(shí)施例方式下面結(jié)合附圖和具體實(shí)施例對(duì)本發(fā)明的技術(shù)方案進(jìn)一步詳細(xì)闡述。本發(fā)明基于IM客戶端，為快速有效的實(shí)現(xiàn)類似微博這種大消息量應(yīng)用中的圖片上傳和下載管理與展現(xiàn)。在IM客戶端中，圖片上傳和下載作為一個(gè)全局服務(wù)Service)模型提供給上層調(diào)用，IM客戶端對(duì)外根據(jù)具體的應(yīng)用提供圖片上傳和下載功能，并封裝了上傳下載的細(xì)節(jié)。對(duì)于圖片上傳，根據(jù)類似微博這種大消息量應(yīng)用的具體應(yīng)用場(chǎng)景且考慮以后的擴(kuò)展性，IM客戶端對(duì)外提供了批量上傳的接口，即IM客戶端的外部可以調(diào)用一次該接口上傳多張圖片；IM客戶端的上傳下載組件將這一批要上傳的圖片作為一個(gè)任務(wù)去完成，并在上傳完畢后通知IM客戶端的應(yīng)用層已經(jīng)上傳完畢。對(duì)于圖片下載，IM客戶端對(duì)外提供根據(jù)統(tǒng)一資源定位符(URI^UniversalResource Locator)下載單張圖片的接口?？紤]到由于類似微博這種大消息量應(yīng)用的圖片的數(shù)量巨大，為了減少對(duì)下載的壓力和提高IM客戶端顯示圖片的性能，下載的圖片會(huì)保存到IM客戶端的本地；如果下次再有下載該圖片的請(qǐng)求時(shí)，則可以直接返回IM客戶端本地保存的圖片。如圖1所示，為IM客戶端的微博消息的上傳下載組件的結(jié)構(gòu)示意圖，IM客戶端的上傳下載組件對(duì)外提供接口 ITXWBloglmageMgr，該接口中提供批量上傳圖片 (UploadImageList)、取消上傳(CancelUploadImageList)、獲取圖片路徑(GetImagePath) 和取消下載(CancelDownloadImage)這四個(gè)模塊；其中，模塊UploadlmageList、 CancelUploadImageList用于實(shí)現(xiàn)微博消息的圖片上傳功能；模塊Getlmagel^ath、 CancelDownloadImage用于實(shí)現(xiàn)微博消息的圖片下載功能。該ITXWBlogImageMgr接口由 CWBlogImageMgr (CWBlogImageMgr 作為一個(gè)類)來(lái)實(shí)現(xiàn)，CWBlogImageMgr 的內(nèi)部包含了以下模塊UploadImageListλ CancelUploadImageList、GetlmagePath、QueryImagePath 禾口CancelDownloadImage,其中，QueryImagePath為查詢本地路徑的模塊。CffBlogImageMgr 的內(nèi)部聚合了 CffBlogImageUpload 對(duì)象禾口 CffBlogImageDownload對(duì)象，上傳功能由CWBloglmageUpload對(duì)象來(lái)實(shí)現(xiàn)，下載功能由 CWBloglmageDownload對(duì)象來(lái)實(shí)現(xiàn)。其中，CWBloglmageUpload對(duì)象中包含以下模塊 UploadImageList> CancelUpIoadImageList> OnUploadComplete、Up 1 oadffaitingQueue> InternelUploadlmage、GetlnfoFromResultFile 禾口 CheckNeedCallback,其中，模塊OnUploadComplete用于上傳完成的處理；模塊UploadWaitingQueue 用于選取等待隊(duì)列中的圖片上傳；模塊hternelUploadlmage用于上傳圖片；模塊 GethfoFromResultFile用于上傳完畢解析服務(wù)器返回的結(jié)果文件，該結(jié)果文件中包含所上傳圖片的URL;模塊CheckNeedCallback用于檢查一批圖片是否都上傳，上傳后需要告知用戶這批圖片已上傳完畢。CffBlogImageDownload 對(duì)象中包含以下模塊:DownloadImage> OnDown1oadComp1ete>DoDownload 禾口 CancelDownloadImage,其中，模塊Downloadlmage用于用戶調(diào)用該接口下載圖片，將任務(wù)加入到下載的等待隊(duì)列中；模塊OnDownloadComplete用于下載完成的處理；模塊DoDownload用于下載操作；模塊CancelDownloadlmage用于取消下載的操作。此外，WBlogImageHelper是圖片上傳下載的一個(gè)幫助類，WBlogImageHelper 中提供了圖片上傳下載相關(guān)的幫助模塊，主要包括KetlmageHash、GetImageSize, AddImagePostfiχ、GetFullUrl、GetUr1AndSiζe、GetFileNameFromUrl 禾口 Gtelmage&ivel^th。其中，模塊GetImageHash用于獲取圖片散列的操作；模塊 GetlmageSize用于獲取圖片大小的操作；模塊AddlmagePostfix用于添加圖片后綴的操作；模塊GetFulltol用于獲取URL的操作；模塊GettolAndSize用于獲取URL和圖片大小的操作；模塊GetFileNameFromUrl用于從URL獲取文件名的操作；模塊GteImageSavePath 用于獲取圖片保存路徑的操作。需要說(shuō)明的是，上述圖1所示的上傳下載組件對(duì)于類似微博這種大消息量的應(yīng)用，都是適用的。基于上述圖1所示IM客戶端的上傳下載組件，本發(fā)明所實(shí)現(xiàn)的消息圖片管理的方法，包括圖片的上傳和下載管理兩個(gè)方面，上傳管理部分由上傳組件來(lái)完成，下載管理部分由下載組件來(lái)完成；當(dāng)然，本發(fā)明中也可以將上傳組件和下載組件合設(shè)，組成上傳下載組件，實(shí)現(xiàn)上傳和下載管理。以微博消息的圖片管理為例，其中，微博消息圖片的上傳流程如圖2所示，主要包括以下步驟步驟201，IM客戶端調(diào)用批量上傳接口，即調(diào)用接口 ITXWBloglmageMgr中的 UploadImageList 模塊。當(dāng)IM的用戶需要利用IM客戶端上傳圖片至微博中時(shí)，通過(guò)手動(dòng)操作觸發(fā)IM客戶端調(diào)用批量上傳接口，即接口 ITXWBloglmageMgr中的UploadImageList模塊被調(diào)用。步驟202，IM客戶端向調(diào)用的批量上傳接口中加入任務(wù)隊(duì)列m_mapTaSk_C00kie_ Array0該任務(wù)即為圖片批量上傳的任務(wù)。步驟203，IM客戶端初始化該任務(wù)(即圖片批量上傳任務(wù))完成數(shù)量m_mapTaSk_ Cookie_CompleteNum。該 m_mapTask_Cookie_CompleteNum 用于限制圖片批量上傳的數(shù)量
7上限。步驟204，IM客戶端對(duì)待上傳的圖片進(jìn)行壓縮和格式轉(zhuǎn)換處理。步驟205，IM客戶端將需要批量上傳的每一個(gè)圖片加入等待上傳隊(duì)列m_ mapffaiting_Cookie_tagImage 中。步驟206，IM客戶端將回調(diào)指針m_SinkMgr_UploadImage加入等待上傳隊(duì)列中。 加入回調(diào)指針的目的是，當(dāng)批量上傳完成后，通過(guò)該回調(diào)指針通知應(yīng)用層，進(jìn)而讓用戶獲知批量上傳的操作完成。步驟207，觸發(fā)UploadWaitingQueue模塊開(kāi)始執(zhí)行圖片上傳的操作。UploadWaitingQueue模塊被觸發(fā)后，掃描等待上傳隊(duì)列，每次調(diào)用隊(duì)首的一個(gè)圖片進(jìn)行上傳。該UploadWaitingQueue模塊的調(diào)用時(shí)機(jī)可以是圖片加入等待上傳隊(duì)列后、調(diào)用一個(gè)圖片完成后或上傳一個(gè)圖片完成后。此外，圖片的上傳還需調(diào)用底層組件CTXHttpDownload，由底層組件 CTXHttpDownload 負(fù)責(zé)創(chuàng)建上傳的傳輸控制協(xié)議(TCP, Transmission ControlProtocol) 通道、建立連接、發(fā)送圖片等處理。進(jìn)一步的，為了保證上傳效率，本發(fā)明還可以采用一個(gè)CTXHttpDownload的管理池 CHttpUploadPool，負(fù)責(zé)提供 CTXHttpDownload 對(duì)象及管理 CTXHttpDownload 對(duì)象的狀態(tài)。較佳的，CTXHttpDownload的管理池最大管理5個(gè)CTXHttpDownload對(duì)象，以及可以支持5張圖片的同時(shí)上傳。在上傳完成后，上傳組件會(huì)返回一個(gè)JSON(JavaScript Object Notation)格式的文件(作為上傳結(jié)果文件)，文件中包含批量上傳的結(jié)果信息JSON是一種輕量級(jí)的數(shù)據(jù)交換格式。IM客戶端通過(guò)解析該結(jié)果信息，可以得到批量上傳成功或失敗的信息，如果上傳結(jié)果為成功，則會(huì)進(jìn)一步解析得到所上傳圖片的URL;也就是說(shuō)，上傳成功時(shí)，上述結(jié)果信息中還包含有所上傳圖片的URL。下面再結(jié)合圖3所示的具體實(shí)例，對(duì)微博消息圖片的上傳流程做進(jìn)一步的詳細(xì)闡述，如圖3所示，主要包括以下步驟步驟301，IM 客戶端從 ChttpUploadPool 中獲取 CTXHttpDownload 對(duì)象。步驟302，取等待上傳隊(duì)列m_mapWaiting_Cookie_tagImage中的第一個(gè)等待上傳項(xiàng)，該上傳項(xiàng)中即包含m_mapWaiting_Cookie_tagImage中第一個(gè)等待上傳的圖片。步驟303，按上傳圖片的超文本傳輸協(xié)議(HTTP, HyperText TransferProtocol) 組裝上傳數(shù)據(jù)。步驟304，調(diào)用CTXHttpDownload對(duì)象的接口 UploadFormData上傳圖片，調(diào)用失敗時(shí)執(zhí)行步驟309，調(diào)用成功時(shí)執(zhí)行步驟305。步驟305，該任務(wù)完成數(shù)量m_mapTask_Cookie_CompleteNum加1，在上傳成功時(shí)執(zhí)行步驟306，上傳錯(cuò)誤時(shí)執(zhí)行步驟309。步驟306，解析上傳結(jié)果文件，如果結(jié)果顯示為成功，則執(zhí)行步驟307 ；如果結(jié)果顯示為失敗，則執(zhí)行步驟309。步驟307，解析上傳結(jié)果文件得到所上傳圖片的URL和類型。步驟308，根據(jù)解析得到的URL和類型命名圖片并保存到IM客戶端本地。步驟309，檢查該批量任務(wù)是否已完成，如果完成，則通過(guò)回調(diào)指針!11_3^110%1~_
8UploadImage通知應(yīng)用層；如果未完成，則下載下一個(gè)UploadWaitingQueue，并返回步驟 301繼續(xù)執(zhí)行。在實(shí)際應(yīng)用中，微博的底層并沒(méi)有直接暴露下載接口給應(yīng)用層，而是提供 GetImageI^th接口，即查詢本地，如果圖片存在，則返回成功并帶上圖片的路徑；如果本地不存在，則返回失敗且啟動(dòng)下載，下載完成后通知應(yīng)用層。另外，圖片是根據(jù)其URL和圖片的類型來(lái)命名的，那么在根據(jù)URL和類型查詢圖片時(shí)，可以根據(jù)該URL和類型得到圖片的文件名，從而在本地的微博圖片保存路徑查詢?cè)搱D片是否存在，例如微博圖片的保存路徑為Util: :Dir: UserData: GteImageDir() +L "WBl og\\，，。基于此，本發(fā)明實(shí)施例所提供的微博消息圖片下載流程如圖4所示，主要包括以下步驟步驟401，IM客戶端調(diào)用GetImageI^ath模塊。步驟402，根據(jù)所需下載圖片的URL和類型查詢本地保存路徑中是否有該圖片，如果有，則向應(yīng)用層返回所查詢到的圖片在本地保存的路徑；如果沒(méi)有，則執(zhí)行步驟403。微博消息中的圖片通常是以縮略圖或鏈接的形式顯示的，用戶要下載對(duì)應(yīng)的圖片，需要觸發(fā)(如鼠標(biāo)點(diǎn)擊)該縮略圖或鏈接。當(dāng)用戶觸發(fā)所需下載圖片的縮略圖或鏈接時(shí)，GetImageI^th模塊根據(jù)所述縮略圖或鏈接獲取所需下載圖片的URL和類型；將獲取到的URL和類型與IM客戶端本地保存路徑中的圖片的URL和類型進(jìn)行匹配，如果匹配到相同的URL和類型，則判斷本地保存路徑中有所需下載圖片；否則，判斷本地保存路徑中沒(méi)有所需下載圖片。步驟403，調(diào)用 DownloadImage 模塊。步驟404，將下載任務(wù)的Downloadlmage模塊加入下載map中，并設(shè)置下載狀態(tài)為等待。其中，下載map是內(nèi)存中的一個(gè)數(shù)據(jù)結(jié)構(gòu)，其保存下載任務(wù)的相關(guān)信息。步驟405，觸發(fā)DoDownload模塊進(jìn)行下載。步驟406，在等待隊(duì)列中取一個(gè)等待的或第一次下載失敗的下載任務(wù)。步驟407，下載完成，如果下載成功，則執(zhí)行步驟408 ；如果下載失敗，則執(zhí)行步驟 411。步驟408，根據(jù)所下載圖片的URL和類型生成下載文件名。步驟409，拷貝下載文件到Image文件中，刪除原臨時(shí)下載文件。由于步驟407中下載成功的圖片是首先存儲(chǔ)到臨時(shí)下載文件目錄中的，因此，步驟409的操作即是將該臨時(shí)下載文件拷貝到步驟408中的下載文件名所對(duì)應(yīng)的Image文件夾中，而原臨時(shí)下載文件則需要相應(yīng)刪除。步驟410，拋下載完成事件，執(zhí)行完后轉(zhuǎn)到步驟412。下載完成后，DoDownload模塊將下載完成事件拋給應(yīng)用層，通知用戶該圖片的下載完成。步驟411，在下載失敗時(shí)，如果判斷是第一次下載失敗，則修改狀態(tài)后返回步驟 405 ；如果是第二次下載失敗，則執(zhí)行步驟412。在下載失敗時(shí)，如果判斷是第一次下載失敗，則將該圖片的下載狀態(tài)修改為第一次下載失敗，從而該圖片的狀態(tài)即從最開(kāi)始的等待狀態(tài)，到正在下載狀態(tài)，再到了現(xiàn)在的第一次下載狀態(tài)。步驟412，將該下載任務(wù)從下載map移出，如果還有其他的下載任務(wù)，則返回步驟 405繼續(xù)執(zhí)行；如果沒(méi)有下載任務(wù)，則結(jié)束整個(gè)流程。對(duì)應(yīng)上述基于IM客戶端實(shí)現(xiàn)微博消息圖片管理的方法，本發(fā)明還提供了一種基于IM客戶端實(shí)現(xiàn)微博消息圖片管理的裝置，適用于IM客戶端中，該裝置包括上傳組件和下載組件。其中，上傳組件用于在IM的用戶需要上傳圖片時(shí)，通過(guò)對(duì)批量上傳接口的調(diào)用， 將等待批量上傳的圖片加入等待上傳隊(duì)列中，并通過(guò)對(duì)等待上傳隊(duì)列的掃描，對(duì)等待上傳隊(duì)列中的圖片進(jìn)行上傳。下載組件，用于在IM的用戶需要下載圖片時(shí)，根據(jù)所需下載圖片的URL和類型查詢本地保存路徑中是否有所需下載圖片，如果有，則直接返回所需下載圖片在本地保存的路徑；如果沒(méi)有，則執(zhí)行相應(yīng)圖片的下載，并將下載的圖片保存到本地。具體的當(dāng)用戶觸發(fā)所需下載圖片的縮略圖或鏈接時(shí)，根據(jù)所述縮略圖或鏈接獲取所需下載圖片的URL和類型；將獲取到的URL和類型與IM客戶端本地保存路徑中的圖片的URL和類型進(jìn)行匹配，如果匹配到相同的URL和類型，則判斷本地保存路徑中有所需下載圖片；否則，判斷本地保存路徑中沒(méi)有所需下載圖片。進(jìn)一步的，上傳組件還用于在上傳完成后，解析生成的上傳結(jié)果文件，在解析顯示上傳成功時(shí)，進(jìn)一步解析得到所上傳圖片的URL和類型，并根據(jù)解析得到URL和類型命名圖片并保存到IM客戶端本地。進(jìn)一步的，該裝置還包括底層組件，用于負(fù)責(zé)創(chuàng)建上傳的TCP通道，并建立連接； 底層組件的管理池，負(fù)責(zé)多個(gè)底層組件的提供以及管理多個(gè)底層組件的狀態(tài)。進(jìn)一步的，下載組件還用于，在下載成功時(shí)，將以URL和類型命名的圖片保存到IM 客戶端本地。在下載失敗時(shí)，判斷對(duì)應(yīng)圖片是否為第一次下載失敗，如果是第一次下載失敗，則將對(duì)應(yīng)圖片的狀態(tài)修改為第一次下載失敗并重新下載；否則，結(jié)束下載。綜上所述，本發(fā)明一方面在微博應(yīng)用中由于消息傳播的特點(diǎn)以及泛關(guān)系鏈的用戶模型，可以非常方便的實(shí)現(xiàn)大消息量中圖片信息的上傳與下載拉取管理；而且，本發(fā)明通過(guò) URL和圖片的類型來(lái)唯一確認(rèn)圖片，并將已下載過(guò)的圖片用URL和類型命名后保存到IM客戶端本地，這可以有效避免重復(fù)下載。另一方面也可以非常方便的將這類模型復(fù)用在類似大消息量中圖片信息的管理產(chǎn)品中，實(shí)現(xiàn)消息圖片信息的有效管理和展現(xiàn)。本發(fā)明基于IM 客戶端實(shí)現(xiàn)的圖片管理方法和裝置，不僅限于在微博消息中的應(yīng)用，對(duì)于類似微博這種大消息量的應(yīng)用都是適用的。以上所述，僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種基于即時(shí)通訊(IM)客戶端實(shí)現(xiàn)消息圖片管理的方法，其特征在于，該方法包括當(dāng)IM的用戶需要下載圖片時(shí)，IM客戶端的下載組件根據(jù)所需下載圖片的統(tǒng)一資源定位符(URL)和類型查詢本地保存路徑中是否有所需下載圖片，如果有，則直接返回所需下載圖片在本地保存的路徑；如果沒(méi)有，則執(zhí)行相應(yīng)圖片的下載，并將下載的圖片保存到本地。
2.根據(jù)權(quán)利要求1所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的方法，其特征在于，所述當(dāng) IM的用戶需要下載圖片時(shí)，IM客戶端的下載組件根據(jù)所需下載圖片的URL和類型查詢本地保存路徑中是否有所需下載圖片，具體為當(dāng)用戶觸發(fā)所需下載圖片的縮略圖或鏈接時(shí)，根據(jù)所述縮略圖或鏈接獲取所需下載圖片的URL和類型；將獲取到的URL和類型與所述IM客戶端本地保存路徑中的圖片的URL和類型進(jìn)行匹配，如果匹配到相同的URL和類型，則判斷所述本地保存路徑中有所需下載圖片；否則，判斷所述本地保存路徑中沒(méi)有所需下載圖片。
3.根據(jù)權(quán)利要求1或2所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的方法，其特征在于，該方法進(jìn)一步包括在下載成功時(shí)，將以URL和類型命名的圖片保存到IM客戶端本地。
4.根據(jù)權(quán)利要求1或2所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的方法，其特征在于，該方法進(jìn)一步包括在下載失敗時(shí)，判斷對(duì)應(yīng)圖片是否為第一次下載失敗，如果是第一次下載失敗，則將對(duì)應(yīng)圖片的狀態(tài)修改為第一次下載失敗并重新下載；否則，結(jié)束下載。
5.根據(jù)權(quán)利要求1所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的方法，其特征在于，該方法進(jìn)一步包括當(dāng)IM的用戶需要上傳圖片時(shí)，IM客戶端的上傳組件通過(guò)對(duì)批量上傳接口的調(diào)用，將等待批量上傳的圖片加入等待上傳隊(duì)列中，并通過(guò)對(duì)等待上傳隊(duì)列的掃描，對(duì)所述等待上傳隊(duì)列中的圖片進(jìn)行上傳。
6.根據(jù)權(quán)利要求5所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的方法，其特征在于，在上傳完成后該方法進(jìn)一步包括解析生成的上傳結(jié)果文件，如果解析顯示上傳成功，則進(jìn)一步解析得到所上傳圖片的 URL和類型；根據(jù)解析得到URL和類型命名圖片并保存到所述IM客戶端本地。
7.根據(jù)權(quán)利要求5或6所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的方法，其特征在于，該方法進(jìn)一步包括所述圖片的上傳還需調(diào)用底層組件，負(fù)責(zé)創(chuàng)建上傳的傳輸控制協(xié)議(TCP)通道，并建立連接；所述IM客戶端采用底層組件的管理池，負(fù)責(zé)多個(gè)底層組件的提供以及管理多個(gè)底層組件的狀態(tài)。
8.一種基于IM客戶端實(shí)現(xiàn)消息圖片管理的裝置，其特征在于，該裝置包括下載組件， 用于在IM的用戶需要下載圖片時(shí)，根據(jù)所需下載圖片的URL和類型查詢本地保存路徑中是否有所需下載圖片，如果有，則直接返回所需下載圖片在本地保存的路徑；如果沒(méi)有，則執(zhí)行相應(yīng)圖片的下載，并將下載的圖片保存到本地。
9.根據(jù)權(quán)利要求8所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的裝置，其特征在于，所述下載組件進(jìn)一步用于，當(dāng)用戶觸發(fā)所需下載圖片的縮略圖或鏈接時(shí)，根據(jù)所述縮略圖或鏈接獲取所需下載圖片的URL和類型；將獲取到的URL和類型與所述IM客戶端本地保存路徑中的圖片的URL和類型進(jìn)行匹配，如果匹配到相同的URL和類型，則判斷所述本地保存路徑中有所需下載圖片；否則，判斷所述本地保存路徑中沒(méi)有所需下載圖片。
10.根據(jù)權(quán)利要求8或9所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的裝置，其特征在于，所述下載組件進(jìn)一步用于，在下載成功時(shí)，將以URL和類型命名的圖片保存到IM客戶端本地。
11.根據(jù)權(quán)利要求8或9所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的裝置，其特征在于，所述下載組件進(jìn)一步用于，在下載失敗時(shí)，判斷對(duì)應(yīng)圖片是否為第一次下載失敗，如果是第一次下載失敗，則將對(duì)應(yīng)圖片的狀態(tài)修改為第一次下載失敗并重新下載；否則，結(jié)束下載。
12.根據(jù)權(quán)利要求8所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的裝置，其特征在于，該裝置還包括上傳組件，用于在IM的用戶需要上傳圖片時(shí)，通過(guò)對(duì)批量上傳接口的調(diào)用，將等待批量上傳的圖片加入等待上傳隊(duì)列中，并通過(guò)對(duì)等待上傳隊(duì)列的掃描，對(duì)所述等待上傳隊(duì)列中的圖片進(jìn)行上傳。
13.根據(jù)權(quán)利要求12所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的裝置，其特征在于，所述上傳組件進(jìn)一步用于，在上傳完成后，解析生成的上傳結(jié)果文件，在解析顯示上傳成功時(shí)， 進(jìn)一步解析得到所上傳圖片的URL和類型，并根據(jù)解析得到URL和類型命名圖片并保存到所述IM客戶端本地。
14.根據(jù)權(quán)利要求12或13所述基于IM客戶端實(shí)現(xiàn)消息圖片管理的裝置，其特征在于， 該裝置還包括底層組件，用于負(fù)責(zé)創(chuàng)建上傳的TCP通道，并建立連接；底層組件的管理池，負(fù)責(zé)多個(gè)底層組件的提供以及管理多個(gè)底層組件的狀態(tài)。
全文摘要
本發(fā)明公開(kāi)了一種基于即時(shí)通訊(IM)客戶端實(shí)現(xiàn)消息圖片管理的方法和裝置，方法包括當(dāng)IM的用戶需要下載圖片時(shí)，IM客戶端的下載組件根據(jù)所需下載圖片的統(tǒng)一資源定位符(URL)和類型查詢本地保存路徑中是否有所需下載圖片，如果有，則直接返回所需下載圖片在本地保存的路徑；如果沒(méi)有，則執(zhí)行相應(yīng)圖片的下載，并將下載的圖片保存到本地。通過(guò)本發(fā)明，快速有效的實(shí)現(xiàn)類似微博這種大消息量應(yīng)用中的圖片上傳和下載管理與展現(xiàn)。
文檔編號(hào)H04L12/58GK102447642SQ20101050334
公開(kāi)日2012年5月9日 申請(qǐng)日期2010年9月30日 優(yōu)先權(quán)日2010年9月30日
發(fā)明者張麗 申請(qǐng)人:騰訊科技(深圳)有限公司