CN102447642A - 一种基于im客户端实现消息图片管理的方法和装置 - Google Patents

Abstract

本发明公开了一种基于即时通讯(IM)客户端实现消息图片管理的方法和装置，方法包括：当IM的用户需要下载图片时，IM客户端的下载组件根据所需下载图片的统一资源定位符(URL)和类型查询本地保存路径中是否有所需下载图片，如果有，则直接返回所需下载图片在本地保存的路径；如果没有，则执行相应图片的下载，并将下载的图片保存到本地。通过本发明，快速有效的实现类似微博这种大消息量应用中的图片上传和下载管理与展现。

Description

一种基于IM客户端实现消息图片管理的方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于即时通讯(IM)客户端实现消息图片管理的方法和装置。

背景技术

网络即时通讯(IM，Instant Messaging)工具发展至今，已经被众多的网民所接受，并已成为用户必不可少的软件工具，IM不但在平时的休闲娱乐中，而且在用户的工作中得到广泛的使用。因此，在实际应用过程中，用户对IM的易用性、稳定性、安全性等方面提出了较高的要求。在IM软件中，主要实现的是一对一的好友单独聊天模式、以及一对多的群或者讨论组的消息聊天模式。随着互联网应用的不断发展，类似推特(twitter)的微博应用作为一种扩展IM消息传播机制的新工具也不断发展壮大，这类微型博客使用户通过140个字左右的信息量来表达自己，这种方式可以非常快速的进行传播，实现用户消息聊天模式从一对一、一对多到一对无穷的跨越；这种一对无穷的消息聊天模式也意味着一个用户可以对无穷多个用户进行消息的传播，同时一个用户同时也可以收取万级以上的用户消息，从而，这也就对大用户量的应用提出了新的要求。

微博作为一种扩展IM消息传播机制的新应用得到了快速的发展，但是原有IM工具中的好友数量(最多几百个)与微博的收听用户量显然不在同一个等级上(万级以上)；由于微博收听的用户量非常巨大，这就造成IM客户端收到微博消息的消息量会非常大，然而，目前在IM客户端中缺少一种能够针对这种大消息量的图片进行上传以及下载拉取管理的技术方案，从而无法快速有效的实现类似微博这种大消息量应用中的图片上传和下载管理与展现。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于IM客户端实现消息图片管理的方法和装置，以快速有效的实现类似微博这种大消息量应用中的图片上传和下载管理与展现。

为达到上述目的，本发明的技术方案是这样实现的：

本发明提供了一种基于即时通讯(IM)客户端实现消息图片管理的方法，该方法包括：

当IM的用户需要下载图片时，IM客户端的下载组件根据所需下载图片的统一资源定位符(URL)和类型查询本地保存路径中是否有所需下载图片，如果有，则直接返回所需下载图片在本地保存的路径；如果没有，则执行相应图片的下载，并将下载的图片保存到本地。

所述当IM的用户需要下载图片时，IM客户端的下载组件根据所需下载图片的URL和类型查询本地保存路径中是否有所需下载图片，具体为：

当用户触发所需下载图片的缩略图或链接时，根据所述缩略图或链接获取所需下载图片的URL和类型；

将获取到的URL和类型与所述IM客户端本地保存路径中的图片的URL和类型进行匹配，如果匹配到相同的URL和类型，则判断所述本地保存路径中有所需下载图片；否则，判断所述本地保存路径中没有所需下载图片。

该方法进一步包括：

在下载成功时，将以URL和类型命名的图片保存到IM客户端本地。

该方法进一步包括：

在下载失败时，判断对应图片是否为第一次下载失败，如果是第一次下载失败，则将对应图片的状态修改为第一次下载失败并重新下载；否则，结束下载。

该方法进一步包括：

当IM的用户需要上传图片时，IM客户端的上传组件通过对批量上传接口的调用，将等待批量上传的图片加入等待上传队列中，并通过对等待上传队列的扫描，对所述等待上传队列中的图片进行上传。

在上传完成后该方法进一步包括：

解析生成的上传结果文件，如果解析显示上传成功，则进一步解析得到所上传图片的URL和类型；

根据解析得到URL和类型命名图片并保存到所述IM客户端本地。

该方法进一步包括：

所述图片的上传还需调用底层组件，负责创建上传的传输控制协议(TCP)通道，并建立连接；

所述IM客户端采用底层组件的管理池，负责多个底层组件的提供以及管理多个底层组件的状态。

本发明还提供了一种基于IM客户端实现消息图片管理的装置，该装置包括：下载组件，用于在IM的用户需要下载图片时，根据所需下载图片的URL和类型查询本地保存路径中是否有所需下载图片，如果有，则直接返回所需下载图片在本地保存的路径；如果没有，则执行相应图片的下载，并将下载的图片保存到本地。

所述下载组件进一步用于，当用户触发所需下载图片的缩略图或链接时，根据所述缩略图或链接获取所需下载图片的URL和类型；将获取到的URL和类型与所述IM客户端本地保存路径中的图片的URL和类型进行匹配，如果匹配到相同的URL和类型，则判断所述本地保存路径中有所需下载图片；否则，判断所述本地保存路径中没有所需下载图片。

所述下载组件进一步用于，在下载成功时，将以URL和类型命名的图片保存到IM客户端本地。

所述下载组件进一步用于，在下载失败时，判断对应图片是否为第一次下载失败，如果是第一次下载失败，则将对应图片的状态修改为第一次下载失败并重新下载；否则，结束下载。

该装置还包括：上传组件，用于在IM的用户需要上传图片时，通过对批量上传接口的调用，将等待批量上传的图片加入等待上传队列中，并通过对等待上传队列的扫描，对所述等待上传队列中的图片进行上传。

所述上传组件进一步用于，在上传完成后，解析生成的上传结果文件，在解析显示上传成功时，进一步解析得到所上传图片的URL和类型，并根据解析得到URL和类型命名图片并保存到所述IM客户端本地。

该装置还包括底层组件，用于负责创建上传的TCP通道，并建立连接；

底层组件的管理池，负责多个底层组件的提供以及管理多个底层组件的状态。

本发明所提供的一种基于IM客户端实现消息图片管理的方法和装置，在微博应用中由于消息传播的特点以及泛关系链的用户模型，可以非常方便的实现大消息量中图片信息的上传与下载拉取管理；另外，本发明通过URL和图片的类型来唯一确认图片，并将已下载过的图片用URL和类型命名后保存到IM客户端本地，这可以有效避免重复下载。

附图说明

图1为本发明中微博消息图片的上传和下载组件的结构示意图；

图2为本发明实施例中基于IM客户端实现微博消息图片上传的方法流程图一；

图3为本发明实施例中基于IM客户端实现微博消息图片上传的方法流程图二；

图4为本发明实施例中基于IM客户端实现微博消息图片下载的方法流程图。

具体实施方式

下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。

本发明基于IM客户端，为快速有效的实现类似微博这种大消息量应用中的图片上传和下载管理与展现。在IM客户端中，图片上传和下载作为一个全局服务(Service)模型提供给上层调用，IM客户端对外根据具体的应用提供图片上传和下载功能，并封装了上传下载的细节。

对于图片上传，根据类似微博这种大消息量应用的具体应用场景且考虑以后的扩展性，IM客户端对外提供了批量上传的接口，即IM客户端的外部可以调用一次该接口上传多张图片；IM客户端的上传下载组件将这一批要上传的图片作为一个任务去完成，并在上传完毕后通知IM客户端的应用层已经上传完毕。

对于图片下载，IM客户端对外提供根据统一资源定位符(URL，UniversalResource Locator)下载单张图片的接口。考虑到由于类似微博这种大消息量应用的图片的数量巨大，为了减少对下载的压力和提高IM客户端显示图片的性能，下载的图片会保存到IM客户端的本地；如果下次再有下载该图片的请求时，则可以直接返回IM客户端本地保存的图片。

如图1所示，为IM客户端的微博消息的上传下载组件的结构示意图，IM客户端的上传下载组件对外提供接口ITXWBlogImageMgr，该接口中提供批量上传图片(UploadImageList)、取消上传(CancelUploadImageList)、获取图片路径(GetImagePath)和取消下载(CancelDownloadImage)这四个模块；其中，模块UploadImageList、CancelUploadImageList用于实现微博消息的图片上传功能；模块GetImagePath、CancelDownloadImage用于实现微博消息的图片下载功能。该ITXWBlogImageMgr接口由CWBlogImageMgr(CWBlogImageMgr作为一个类)来实现，CWBlogImageMgr的内部包含了以下模块：

UploadImageList、CancelUploadImageList、GetImagePath、QueryImagePath和CancelDownloadImage，

其中，QueryImagePath为查询本地路径的模块。

CWBlogImageMgr的内部聚合了CWBlogImageUpload对象和CWBlogImageDownload对象，上传功能由CWBlogImageUpload对象来实现，下载功能由CWBlogImageDownload对象来实现。其中，CWBlogImageUpload对象中包含以下模块：UploadImageList、CancelUploadImageList、OnUploadComplete、UploadWaitingQueue、InternelUploadImage、GetInfoFromResultFile和CheckNeedCallback，

其中，模块OnUploadComplete用于上传完成的处理；模块UploadWaitingQueue用于选取等待队列中的图片上传；模块InternelUploadImage用于上传图片；模块GetInfoFromResultFile用于上传完毕解析服务器返回的结果文件，该结果文件中包含所上传图片的URL；模块CheckNeedCallback用于检查一批图片是否都上传，上传后需要告知用户这批图片已上传完毕。

CWBlogImageDownload对象中包含以下模块：DownloadImage、OnDownloadComplete、DoDownload和CancelDownloadImage，

其中，模块DownloadImage用于用户调用该接口下载图片，将任务加入到下载的等待队列中；模块OnDownloadComplete用于下载完成的处理；模块DoDownload用于下载操作；模块CancelDownloadImage用于取消下载的操作。

此外，WBlogImageHelper是图片上传下载的一个帮助类，WBlogImageHelper中提供了图片上传下载相关的帮助模块，主要包括：GetImageHash、GetImageSize、AddImagePostfix、GetFullUrl、GetUrlAndSize、GetFileNameFromUrl和GteImageSavePath。其中，模块GetImageHash用于获取图片散列的操作；模块GetImageSize用于获取图片大小的操作；模块AddImagePostfix用于添加图片后缀的操作；模块GetFullUrl用于获取URL的操作；模块GetUrlAndSize用于获取URL和图片大小的操作；模块GetFileNameFromUrl用于从URL获取文件名的操作；模块GteImageSavePath用于获取图片保存路径的操作。

需要说明的是，上述图1所示的上传下载组件对于类似微博这种大消息量的应用，都是适用的。基于上述图1所示IM客户端的上传下载组件，本发明所实现的消息图片管理的方法，包括图片的上传和下载管理两个方面，上传管理部分由上传组件来完成，下载管理部分由下载组件来完成；当然，本发明中也可以将上传组件和下载组件合设，组成上传下载组件，实现上传和下载管理。以微博消息的图片管理为例，其中，微博消息图片的上传流程如图2所示，主要包括以下步骤：

步骤201，IM客户端调用批量上传接口，即调用接口ITXWBlogImageMgr中的UploadImageList模块。

当IM的用户需要利用IM客户端上传图片至微博中时，通过手动操作触发IM客户端调用批量上传接口，即接口ITXWBlogImageMgr中的UploadImageList模块被调用。

步骤202，IM客户端向调用的批量上传接口中加入任务队列m_mapTask_Cookie_Array。该任务即为图片批量上传的任务。

步骤203，IM客户端初始化该任务(即图片批量上传任务)完成数量m_mapTask_Cookie_CompleteNum。该m_mapTask_Cookie_CompleteNum用于限制图片批量上传的数量上限。

步骤204，IM客户端对待上传的图片进行压缩和格式转换处理。

步骤205，IM客户端将需要批量上传的每一个图片加入等待上传队列m_mapWaiting_Cookie_tagImage中。

步骤206，IM客户端将回调指针m_SinkMgr_UploadImage加入等待上传队列中。加入回调指针的目的是，当批量上传完成后，通过该回调指针通知应用层，进而让用户获知批量上传的操作完成。

步骤207，触发UploadWaitingQueue模块开始执行图片上传的操作。

UploadWaitingQueue模块被触发后，扫描等待上传队列，每次调用队首的一个图片进行上传。该UploadWaitingQueue模块的调用时机可以是图片加入等待上传队列后、调用一个图片完成后或上传一个图片完成后。

此外，图片的上传还需调用底层组件CTXHttpDownload，由底层组件CTXHttpDownload负责创建上传的传输控制协议(TCP，Transmission ControlProtocol)通道、建立连接、发送图片等处理。

进一步的，为了保证上传效率，本发明还可以采用一个CTXHttpDownload的管理池CHttpUploadPool，负责提供CTXHttpDownload对象及管理CTXHttpDownload对象的状态。较佳的，CTXHttpDownload的管理池最大管理5个CTXHttpDownload对象，以及可以支持5张图片的同时上传。

在上传完成后，上传组件会返回一个JSON(JavaScript Object Notation)格式的文件(作为上传结果文件)，文件中包含批量上传的结果信息；JSON是一种轻量级的数据交换格式。IM客户端通过解析该结果信息，可以得到批量上传成功或失败的信息，如果上传结果为成功，则会进一步解析得到所上传图片的URL；也就是说，上传成功时，上述结果信息中还包含有所上传图片的URL。

下面再结合图3所示的具体实例，对微博消息图片的上传流程做进一步的详细阐述，如图3所示，主要包括以下步骤：

步骤301，IM客户端从ChttpUploadPool中获取CTXHttpDownload对象。

步骤302，取等待上传队列m_mapWaiting_Cookie_tagImage中的第一个等待上传项，该上传项中即包含m_mapWaiting_Cookie_tagImage中第一个等待上传的图片。

步骤303，按上传图片的超文本传输协议(HTTP，HyperText TransferProtocol)组装上传数据。

步骤304，调用CTXHttpDownload对象的接口UploadFormData上传图片，调用失败时执行步骤309，调用成功时执行步骤305。

步骤305，该任务完成数量m_mapTask_Cookie_CompleteNum加1，在上传成功时执行步骤306，上传错误时执行步骤309。

步骤306，解析上传结果文件，如果结果显示为成功，则执行步骤307；如果结果显示为失败，则执行步骤309。

步骤307，解析上传结果文件得到所上传图片的URL和类型。

步骤308，根据解析得到的URL和类型命名图片并保存到IM客户端本地。

步骤309，检查该批量任务是否已完成，如果完成，则通过回调指针m_SinkMgr_UploadImage通知应用层；如果未完成，则下载下一个UploadWaitingQueue，并返回步骤301继续执行。

在实际应用中，微博的底层并没有直接暴露下载接口给应用层，而是提供GetImagePath接口，即查询本地，如果图片存在，则返回成功并带上图片的路径；如果本地不存在，则返回失败且启动下载，下载完成后通知应用层。

另外，图片是根据其URL和图片的类型来命名的，那么在根据URL和类型查询图片时，可以根据该URL和类型得到图片的文件名，从而在本地的微博图片保存路径查询该图片是否存在，例如：微博图片的保存路径为Util::Dir::UserData::GteImageDir()+L“WBlog\\”。

基于此，本发明实施例所提供的微博消息图片下载流程如图4所示，主要包括以下步骤：

步骤401，IM客户端调用GetImagePath模块。

步骤402，根据所需下载图片的URL和类型查询本地保存路径中是否有该图片，如果有，则向应用层返回所查询到的图片在本地保存的路径；如果没有，则执行步骤403。

微博消息中的图片通常是以缩略图或链接的形式显示的，用户要下载对应的图片，需要触发(如鼠标点击)该缩略图或链接。

当用户触发所需下载图片的缩略图或链接时，GetImagePath模块根据所述缩略图或链接获取所需下载图片的URL和类型；将获取到的URL和类型与IM客户端本地保存路径中的图片的URL和类型进行匹配，如果匹配到相同的URL和类型，则判断本地保存路径中有所需下载图片；否则，判断本地保存路径中没有所需下载图片。

步骤403，调用DownloadImage模块。

步骤404，将下载任务的DownloadImage模块加入下载map中，并设置下载状态为等待。

其中，下载map是内存中的一个数据结构，其保存下载任务的相关信息。

步骤405，触发DoDownload模块进行下载。

步骤406，在等待队列中取一个等待的或第一次下载失败的下载任务。

步骤407，下载完成，如果下载成功，则执行步骤408；如果下载失败，则执行步骤411。

步骤408，根据所下载图片的URL和类型生成下载文件名。

步骤409，拷贝下载文件到Image文件中，删除原临时下载文件。

由于步骤407中下载成功的图片是首先存储到临时下载文件目录中的，因此，步骤409的操作即是将该临时下载文件拷贝到步骤408中的下载文件名所对应的Image文件夹中，而原临时下载文件则需要相应删除。

步骤410，抛下载完成事件，执行完后转到步骤412。

下载完成后，DoDownload模块将下载完成事件抛给应用层，通知用户该图片的下载完成。

步骤411，在下载失败时，如果判断是第一次下载失败，则修改状态后返回步骤405；如果是第二次下载失败，则执行步骤412。

在下载失败时，如果判断是第一次下载失败，则将该图片的下载状态修改为第一次下载失败，从而该图片的状态即从最开始的等待状态，到正在下载状态，再到了现在的第一次下载状态。

步骤412，将该下载任务从下载map移出，如果还有其他的下载任务，则返回步骤405继续执行；如果没有下载任务，则结束整个流程。

对应上述基于IM客户端实现微博消息图片管理的方法，本发明还提供了一种基于IM客户端实现微博消息图片管理的装置，适用于IM客户端中，该装置包括：上传组件和下载组件。

其中，上传组件用于在IM的用户需要上传图片时，通过对批量上传接口的调用，将等待批量上传的图片加入等待上传队列中，并通过对等待上传队列的扫描，对等待上传队列中的图片进行上传。

下载组件，用于在IM的用户需要下载图片时，根据所需下载图片的URL和类型查询本地保存路径中是否有所需下载图片，如果有，则直接返回所需下载图片在本地保存的路径；如果没有，则执行相应图片的下载，并将下载的图片保存到本地。具体的：当用户触发所需下载图片的缩略图或链接时，根据所述缩略图或链接获取所需下载图片的URL和类型；将获取到的URL和类型与IM客户端本地保存路径中的图片的URL和类型进行匹配，如果匹配到相同的URL和类型，则判断本地保存路径中有所需下载图片；否则，判断本地保存路径中没有所需下载图片。

进一步的，上传组件还用于在上传完成后，解析生成的上传结果文件，在解析显示上传成功时，进一步解析得到所上传图片的URL和类型，并根据解析得到URL和类型命名图片并保存到IM客户端本地。

进一步的，该装置还包括底层组件，用于负责创建上传的TCP通道，并建立连接；底层组件的管理池，负责多个底层组件的提供以及管理多个底层组件的状态。

进一步的，下载组件还用于，在下载成功时，将以URL和类型命名的图片保存到IM客户端本地。在下载失败时，判断对应图片是否为第一次下载失败，如果是第一次下载失败，则将对应图片的状态修改为第一次下载失败并重新下载；否则，结束下载。

综上所述，本发明一方面在微博应用中由于消息传播的特点以及泛关系链的用户模型，可以非常方便的实现大消息量中图片信息的上传与下载拉取管理；而且，本发明通过URL和图片的类型来唯一确认图片，并将已下载过的图片用URL和类型命名后保存到IM客户端本地，这可以有效避免重复下载。另一方面也可以非常方便的将这类模型复用在类似大消息量中图片信息的管理产品中，实现消息图片信息的有效管理和展现。本发明基于IM客户端实现的图片管理方法和装置，不仅限于在微博消息中的应用，对于类似微博这种大消息量的应用都是适用的。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (14)

1.一种基于即时通讯(IM)客户端实现消息图片管理的方法，其特征在于，该方法包括：

当IM的用户需要下载图片时，IM客户端的下载组件根据所需下载图片的统一资源定位符(URL)和类型查询本地保存路径中是否有所需下载图片，如果有，则直接返回所需下载图片在本地保存的路径；如果没有，则执行相应图片的下载，并将下载的图片保存到本地。

2.根据权利要求1所述基于IM客户端实现消息图片管理的方法，其特征在于，所述当IM的用户需要下载图片时，IM客户端的下载组件根据所需下载图片的URL和类型查询本地保存路径中是否有所需下载图片，具体为：

当用户触发所需下载图片的缩略图或链接时，根据所述缩略图或链接获取所需下载图片的URL和类型；

将获取到的URL和类型与所述IM客户端本地保存路径中的图片的URL和类型进行匹配，如果匹配到相同的URL和类型，则判断所述本地保存路径中有所需下载图片；否则，判断所述本地保存路径中没有所需下载图片。

3.根据权利要求1或2所述基于IM客户端实现消息图片管理的方法，其特征在于，该方法进一步包括：

在下载成功时，将以URL和类型命名的图片保存到IM客户端本地。

4.根据权利要求1或2所述基于IM客户端实现消息图片管理的方法，其特征在于，该方法进一步包括：

在下载失败时，判断对应图片是否为第一次下载失败，如果是第一次下载失败，则将对应图片的状态修改为第一次下载失败并重新下载；否则，结束下载。

5.根据权利要求1所述基于IM客户端实现消息图片管理的方法，其特征在于，该方法进一步包括：

当IM的用户需要上传图片时，IM客户端的上传组件通过对批量上传接口的调用，将等待批量上传的图片加入等待上传队列中，并通过对等待上传队列的扫描，对所述等待上传队列中的图片进行上传。

6.根据权利要求5所述基于IM客户端实现消息图片管理的方法，其特征在于，在上传完成后该方法进一步包括：

解析生成的上传结果文件，如果解析显示上传成功，则进一步解析得到所上传图片的URL和类型；

根据解析得到URL和类型命名图片并保存到所述IM客户端本地。

7.根据权利要求5或6所述基于IM客户端实现消息图片管理的方法，其特征在于，该方法进一步包括：

所述图片的上传还需调用底层组件，负责创建上传的传输控制协议(TCP)通道，并建立连接；

所述IM客户端采用底层组件的管理池，负责多个底层组件的提供以及管理多个底层组件的状态。

8.一种基于IM客户端实现消息图片管理的装置，其特征在于，该装置包括：下载组件，用于在IM的用户需要下载图片时，根据所需下载图片的URL和类型查询本地保存路径中是否有所需下载图片，如果有，则直接返回所需下载图片在本地保存的路径；如果没有，则执行相应图片的下载，并将下载的图片保存到本地。

9.根据权利要求8所述基于IM客户端实现消息图片管理的装置，其特征在于，所述下载组件进一步用于，当用户触发所需下载图片的缩略图或链接时，根据所述缩略图或链接获取所需下载图片的URL和类型；将获取到的URL和类型与所述IM客户端本地保存路径中的图片的URL和类型进行匹配，如果匹配到相同的URL和类型，则判断所述本地保存路径中有所需下载图片；否则，判断所述本地保存路径中没有所需下载图片。

10.根据权利要求8或9所述基于IM客户端实现消息图片管理的装置，其特征在于，所述下载组件进一步用于，在下载成功时，将以URL和类型命名的图片保存到IM客户端本地。

11.根据权利要求8或9所述基于IM客户端实现消息图片管理的装置，其特征在于，所述下载组件进一步用于，在下载失败时，判断对应图片是否为第一次下载失败，如果是第一次下载失败，则将对应图片的状态修改为第一次下载失败并重新下载；否则，结束下载。

12.根据权利要求8所述基于IM客户端实现消息图片管理的装置，其特征在于，该装置还包括：上传组件，用于在IM的用户需要上传图片时，通过对批量上传接口的调用，将等待批量上传的图片加入等待上传队列中，并通过对等待上传队列的扫描，对所述等待上传队列中的图片进行上传。

13.根据权利要求12所述基于IM客户端实现消息图片管理的装置，其特征在于，所述上传组件进一步用于，在上传完成后，解析生成的上传结果文件，在解析显示上传成功时，进一步解析得到所上传图片的URL和类型，并根据解析得到URL和类型命名图片并保存到所述IM客户端本地。

14.根据权利要求12或13所述基于IM客户端实现消息图片管理的装置，其特征在于，该装置还包括底层组件，用于负责创建上传的TCP通道，并建立连接；

底层组件的管理池，负责多个底层组件的提供以及管理多个底层组件的状态。

Images