专利名称：基于泛关系链模型的系统中用户资料的管理方法及装置的制作方法
技术领域：
本发明涉及网络技术领域，具体涉及基于泛关系链模型的系统中用户资料的管理方法及装置。
背景技术：
随着网络技术的不断发展，出现了各种各样的网络通讯系统。其中，基于泛关系链模型的系统受到越来越多网络用户的青睐。在基于泛关系链模型的系统中，系统的用户之间可以不通过请求、验证的方式就能非常容易地建立关系。因此，该系统使得网络聊天模式从一对一、一对N跨越到一对无穷。这种一对无穷的聊天模式意味着一个用户可以向无穷多的其他用户传播消息，并同时可以接收万级以上用户的消息。这种系统中，听众以及讲者的数量非常大，用户发送一条消息可以被无数的其他用户收听。因此，这种系统具有海量的信息，比如具有海量的用户资料。目前，常用的基于泛关系链模型的系统可以以网页为载体也可以以客户端(如IM 客户端等)为载体，且系统的用户资料都是由系统服务器统一进行维护和管理的。在以客户端为载体的系统中，每当用户通过客户端登录系统时，需要由系统服务器把大量的用户资料通过客户端展现给该用户，且当该用户不断地切换关注对象时，系统服务器则需要通过客户端不断地为用户更新其所关注的用户资料。由此可见，每当用户想查询用户资料时， 都必须经由系统服务器才能得到，而不能在客户端本地查询用户资料，因此导致用户不能快速、方便地获知用户资料，即客户端不能快速地对用户资料进行展现。而且，客户端必须频繁不断地与系统服务器进行交互，从而导致系统服务器的通信压力过大，甚至导致系统服务器瘫痪。因此，急需对基于泛关系链模型的系统的用户资料进行更有效的管理。目前，应用最广泛的基于泛关系链模型的系统为微博系统。在微博系统中，用户通过140字左右的一句话来传播消息。这种通信方式简短、方便，可以快速地进行信息的传播和传递。微博采用的一对无穷的聊天模式使得微博系统具有海量的用户资料。在以客户端为载体的微博中，客户端必须频繁地与微博服务器交互以获取微博的用户资料，而微博的用户资料数量庞大，从而导致客户端不能快速地展现微博的用户资料，并且导致微博服务器通信压力过大，甚至导致微博服务器瘫痪。
发明内容
有鉴于此，本发明的主要目的是提供基于泛关系链模型的系统中用户资料的管理方法及装置，该方法及装置可以使客户端对海量的用户资料进行有效的管理。本发明实施例提供基于泛关系链模型的系统中用户资料的管理方法，该系统以客户端为载体且包括向系统用户提供服务的服务器。该方法包括位于所述客户端内部或与所述客户端相连的管理装置根据登录该客户端用户的需求从服务器拉取系统的用户资料，并将不同类型的用户资料采用不同的保存方式保存于客户端本地；管理装置根据预定的策略，对保存的用户资料进行管理。其中，用户资料至少包括登录该客户端用户的资料。本发明实施例还提供基于泛关系链模型的系统中用户资料的管理装置，该系统以客户端为载体且包括用于为系统用户提供服务的服务器，位于该系统的客户端侧。该装置包括拉取模块，用于根据登录该客户端用户的需求从系统的服务器拉取用户资料，其中，用户资料至少包括登录该客户端用户的资料；保存模块，用于将不同类型的用户资料采用不同的保存方式进行保存；管理模块，用于根据预定的策略，对保存模块保存的用户资料进行管理。客户端对本地的用户资料进行管理包括根据预定的策略，查询、更新和/或删除用户资料，和/或向用户通知用户资料事件。根据本发明实施例，由于不同类型的用户资料采用不同的保存方式，从而可以在客户端本地更加充分合理地利用存储空间。并且，由于用户资料拉取之后保存在客户端本地，则当用户再查询用户资料时，管理装置先在本地查询，而不是直接向微博服务器请求用户资料，因此可以更快速地调用用户资料，并能快速地展现用户资料。另外，在对本地的用户资料进行管理时也会根据不同的用户资料类型以及不同的场景选择不同的管理方式，进而可以更加合理地对用户资料进行管理。比如，在用户登录期间，在用户使用用户资料时 (比如用户查看他人的用户资料时)才更新一次，且此次登录期间已经更新过的用户资料不再更新，避免了重复拉取，减少了与微博服务器的交互次数，降低了微博服务器的通信压力。
在本发明的附图中，图1为根据本发明实施例的基于泛关系链模型的系统中用户资料的管理方法流程图；图2示出了根据本发明实施例中拉取和保存用户资料的具体流程图；图3为本发明实施例中微博系统中用户的文字资料的管理流程图；图4为本发明实施例中微博系统中用户的图片资料的管理流程图；图5为根据本发明实施例的基于泛关系链模型的系统中用户资料的管理装置的结构图；图6为根据本发明实施例的基于泛关系链模型的系统中用户资料的管理装置的一种逻辑结构图。
具体实施例方式下面结合附图和具体实施例对本发明进行详细说明。目前，在以客户端为载体的基于泛关系链的系统中，具有海量的用户资料，如何有效地管理海量的用户资料时亟待解决的问题。目前，系统的用户资料大都经由系统服务器管理和维护，而不是在客户端本地进行管理和维护，因而导致客户端不能快速地为用户提供用户资料的查询、展现等。并且，在对用户资料的管理中，没有考虑用户资料的类型以及不同的场景，管理缺乏灵活性。
为了克服上述问题，本发明实施例提供基于泛关系链模型的系统中用户资料的管理方法，该系统以客户端为载体且用户通过该客户端进入系统，该系统包括服务器，用于为系统用户提供服务。图1为根据本发明实施例的基于泛关系链模型的系统中用户资料的管理方法流程图。如图1所示，在步骤101中，管理装置根据登录该客户端的用户A的需求从系统的服务器拉取用户的资料，并根据不同的用户资料类型采用不同的保存方式在客户端本地保存拉取的用户资料；在步骤102中，管理装置根据预定的策略，对保存的用户资料进行管理。拉取的用户资料包括用户A的资料，还可以包括其他用户的资料。其中，管理装置为位于客户端内部用于实现管理方法的模块或与位于客户端外部且与其相连的用于实现管理方法的管理装置。在以下实施例中，以管理装置位于客户端内部为例进行说明。在本实施例中，客户端可以在用户A首次登录客户端时从系统服务器拉取用户A 自身的资料，和用户A指定的用户资料，并根据拉取的用户资料的类型采用不同的保存方式在客户端本地保存拉取的用户资料。用户A指定的用户资料可以是用户A感兴趣的或者频繁使用的用户资料，也可以是用户A当前关注的用户的资料。由于用户A感兴趣或频繁使用的用户资料在用户A登录后被保存在客户端本地，并由客户端根据预定的策略进行管理。因而，在后续使用这些用户资料时，客户端可以在本地调用用户资料，从而可以快速地展现用户资料。而且，由于客户端在展现用户资料时，可以在客户端本地调用用户资料，而不用每次都从服务器拉取用户资料，因此客户端与服务器的交互次数减少了，因而可以降低服务器的通信压力，保证服务器更快速、有效地提供服务。用户资料的类型至少包括文字资料和图片资料。其中文字资料一般用于描述用户的基本信息，比如用户标识码UIN或用户标识ID，用户名，职业，兴趣等。图片资料一般用于显示用户的形象，比如用户的头像，其包括图片文件的URL信息和/或图片文件。进一步地，客户端对保存的用户资料的管理可以包括用户资料的查询、更新和/ 或删除用户资料、和/或向用户A通知用户资料事件。目前应用较广泛的基于泛关系链模型的系统有微博系统，而以客户端为载体的微博系统中，客户端可以是微博专用客户端，也可以是现有的通讯客户端，如QQ，MSN, ICQ等即时通讯IM客户端或者其他类型的通讯客户端。在以下实施例中，将以IM客户端为载体的微博系统为例说明基于泛关系链模型的系统中用户资料的管理方法。在以IM客户端为载体的微博系统中，可以在IM客户端的界面添加一个微博Tab 页，用户只要点击微博Tab页即可进入微博系统。用户登录IM客户端，则可以通过微博Tab 页进入微博系统。在本发明实施例中，微博用户资料独立于IM资料，且其图片资料可以是微博用户的头像。头像可以是自定义头像或者客户端的默认头像。在以IM客户端为载体的微博系统中，微博用户资料与IM资料相互独立，使得海量的微博用户资料的管理更加方便。图2示出了根据本发明实施例的步骤101中拉取和保存用户资料的具体流程图。 如图2所示，步骤101包括步骤201 :IM客户端接收登录IM客户端的用户A的用户资料拉取指令，其中携带需要拉取的用户资料对应的用户标识码UIN或用户标识ID。在本步骤中，当用户A登录IM客户端则相当于向IM客户端发送了用户资料拉取指令，其中携带用户A的UIN或ID。当然，用户A在登录后可以选择自己感兴趣的或经常访问的用户并向IM客户端发送用户资料拉取指令，其中携带用户A感兴趣的用户的UIN或 ID。步骤202 :IM客户端向微博服务器发送用户资料拉取请求，该用户资料拉取请求携带与用户资料对应的用户标识码UIN或用户标识ID。步骤203 :IM客户端接收微博服务器根据该用户资料拉取请求中的UIN或ID向IM 客户端返回的响应，该响应中携带与UIN或ID对应的用户资料。在本步骤中，微博服务器返回响应时，根据不同类型的用户资料类型做不同的处理。对于文字资料，则直接携带在响应中返回IM给客户端；对于头像，则将头像文件的URL 信息携带在响应中返回给IM客户端，IM客户端根据收到的URL信息再从微博服务器或者设置于微博服务器外部的架构部下载头像文件。较佳地，IM客户端在下周头像文件之前判断本地存储的URL信息是否与收到的 URL信息相同，如果相同，再确认本地是否存储有与URL对应的头像文件，如果有，则不下载头像文件；如果URL信息不同，则下载头像文件。步骤204 =IM客户端将响应中携带的与UIN或ID对应的用户资料保存在本地。本步骤中，IM客户端将不同类型的用户资料采用不同的保存方式进行保存。具体地，对于用户资料中的文字资料，由于其占用的空间比较小，从微博服务器下载的速度也就比较快，因此IM客户端可以将文字资料保存在本地内存中。因此，IM客户端可以根据预定的策略管理本地内存中的文字资料，提高了文字资料的调用速度，进而提高了对用户资料的管理效率。当然，文字资料也可以保存在本地磁盘中。但是，文字资料相对图片资料来说， 下载速度比较快，每次用户A登录IM客户端时再从微博服务器下载文字资料对微博服务器的通信压力影响不大。因此，本发明实施例选用了将文字资料保存在本地内存的保存方式。另外，对于图片资料，则需要根据不同场景采取不同的保存方式。图片资料一般包括图片文件URL信息和图片文件本身，需要占用的空间较大，因此对图片资料的保存还需要考虑不同的场景。在本发明实施例中，关于图片资料的保存，至少可以考虑以下三种场景1)大批量显示和/或频繁使用图片文件的需求，如微博首页或@页中的消息发表者的头像，其中微博首页展示用户A收听的人发表的消息，@页中是用户A自己的页面，展示用户A发表的或提及用户A的消息；2)单个查看图片文件的需求，如进入微博客人页查看客人头像的需求； 3)登录期间可能只需显示一次的大批量图片文件的显示需求，比如其他用户的偶像或粉丝列表。对于第1)种场景，则IM客户端在本地磁盘保存图片文件的URL信息以及图片文件。对于第2、种场景，则IM客户端在查看图片文件之后在本地磁盘保存图片文件的URL 信息以及图片文件。对于第3)种场景，则IM客户端将图片文件的URL信息保存在本地内存，并将图片文件临时保存在本地磁盘，并在用户A退出IM客户端后清除临时保存的图片文件。由此可见，在本发明实施例中，不同场景下对图片资料的保存方式不同，从而可以在IM客户端本地灵活方便地对图片资料进行管理。对于第1)种场景中的图片资料，由于大批量显示的图片文件占用带宽多，从微博服务器下载的速度就比较慢，且会占用大量内存，因此采用保存在本地磁盘的保存方式，从而可以在IM客户端快速地调用和展现大批量的图片文文件。另外，对于频繁使用的图片文件，如果每次使用都从微博服务器下载，则需要频繁地与微博服务器交互，从而增加了与微博服务器的交互次数，进而增加微博服务器的通信压力。并且，图片文件的下载速度较慢， IM客户端对图片文件的展现速度也会受影响。因此频繁使用的图片文件也采用保存在本地磁盘的保存方式。由于图片文件在本地保存，则可以方便IM客户端根据预定的策略对用户资料进行管理，比如可以快速、方便地进行查询和展现。对于第2)种场景，由于用户A需要单个查看的图片文件一般是用户感兴趣的或频繁使用的，因此在查看图片文件之后在本地磁盘保存图片文件的URL信息以及图片文件， 由IM客户端管理本地保存的用户资料，以便后续用户A查看时更加便捷，即可以由IM客户端在本地保存的用户资料中调用该图片文件并展现给用户A，因而展现速度更快。在第1)和第2、种场景中，IM客户端可以将图片资料保存在本地磁盘的特定目录下。对于第3)种场景，由于登录期间可能只需显示一次，则可以临时保存或在内存保存；而由于是大批量的图片，需要占用较大空间，保存在内存会增加内存压力，因此较佳的保存方式为临时保存在本地磁盘，比如保存在临时目录下。较佳地，第3)中场景中的图片文件的URL信息可以保存在内存中，而图片文件保存在本地磁盘的临时目录下。另外，在IM客户端拉取图片文件失败且本地也没有自定义图片文件的情况下，IM 客户端使用默认图片文件作为微博用户的图片文件(如微博用户的头像)。从以上可以看出，通过对不同类型的用户资料采用不同的保存方式进行保存，可以更充分、合理地利用本地内存以及磁盘空间，并可以方便IM客户端在本地对用户资料进行管理，从而可以给用户A带来更好的体验，并减轻微博服务器的通信压力。以下将结合附图及具体实施例说明本发明步骤102中对用户资料的管理过程。根据本发明实施例，步骤102中预定的策略会根据用户资料的类型不同而不同。在以下实施例中，将分别说明文字资料和图片资料这两种类型的用户资料的具体管理过程，包括用户资料的查询、更新和/或删除、和/或向用户A通知用户资料事件。图3为本发明实施例中微博系统中用户的文字资料的管理流程图。如图3所示， IM客户端根据预定的策略，对保存的文字资料进行管理包括步骤301 :IM客户端接收用户A的用户资料查询请求。该用户资料查询请求至少携带待查询用户资料所对应用户的用户标识码UIN或用户标识ID，且用户资料类型为文字资料。步骤302 :IM客户端查找文字资料。具体地，IM客户端判断待查询的用户资料类型为文字资料时，在本地内存中查找文字资料。步骤303 当找到文字资料时，向用户A返回本地的文字资料；当没找到文字资料时，向用户A返回查询失败消息。在本步骤中，当没找到文字资料时，也可以不返回查询失败消息，而是执行步骤 305和306以拉取本地没有保存的文字资料，并在IM客户端拉取用户A查询的文字资料后保存在内存中，并向用户A返回拉取的文字资料。或者，IM客户端向用户A返回查询失败消息后，如果收到用户A的针对该UIN或 ID的用户资料拉取指令，再执行步骤305和306以向用户A返回拉取的文字资料。步骤304 当用户A使用文字资料时，则IM客户端触发该文字资料的更新。
本步骤中，用户A使用文字资料一般指查看某用户的页面。这样在用户A查看的某用户页面时，IM客户端触发更新，从而可以保证用户A查看最新的用户资料，避免不必要的更新。在本步骤中，也可以是用户A手动更新文字资料。不过，如果用户A过于频繁地手动更新文字资料，则会增加微博服务器的通信压力。因此，可以在此设置一个手动更新的频率限制，一周一次或两周一次等。步骤305 =IM客户端向微博服务器发送用户资料拉取请求。本步骤中，IM客户端判断待更新的文字资料在用户A此次登录IM客户端期间是否已经更新过；如果已经更新过，则不发送用户资料拉取请求，如果尚未更新过，则发送用户资料拉取请求以拉取该文字资料。具体地，可以为更新过的文字资料打上标签，从而可以根据标签判断哪些文字资料更新过哪些还没有更新。步骤306 微博服务器向IM客户端返回响应，其中携带请求的文字资料。步骤307 :IM客户端进行更新处理。具体，判断本地保存的文字资料与拉取的文字资料是否一致，如果一致，则不保存拉取的文字资料；否则用拉取的文字资料替换本地的文字资料，并执行步骤308。步骤308 :IM客户端向用户A通知文字资料更新事件。具体地，将文字资料更新事件通知到界面，通过界面向用户A展现更新后的文字资料。在上述步骤301-308中，可以只执行查询过程(步骤301-30 ，而不执行更新过程 (步骤304-307)。步骤308的通知过程也可以不执行，而是在用户A查询时再把更新后的文字资料返回给用户A。上述管理过程还可以包括删除本地内存中的文字资料。在用户A退出IM客户端后，则删除内存保存的用户资料。由以上的管理过程可以看出，按照预定的策略管理本地保存的用户资料，比如当用户A查询其他用户的用户资料时，IM客户端先在本地内存查询，而不是直接向微博服务器请求用户资料，因此可以更快速地调用用户A所需要的用户资料，并能快速地展现用户资料。另外，按照预定的策略管理本地保存的用户资料，比如控制更新次数，即在用户A — 次登录期间，用户A使用用户资料时才进行更新一次，且此次登录期间已经更新过的用户资料不再更新，可以避免重复拉取用户资料，减少了与微博服务器的交互次数，降低了微博服务器的通信压力。图4为本发明实施例中微博系统中用户的图片资料的管理流程图。如图4所示， IM客户端根据预定的策略，对保存的图片资料进行管理包括步骤401 :IM客户端接收用户A的用户资料查询请求。该用户资料查询请求至少携带待查询用户资料所对应用户的用户标识码UIN或用户标识ID，且用户资料类型为图片资料。步骤402 :IM客户端查找图片资料。具体地，IM客户端判断待查询的用户资料类型为图片资料时，在本地磁盘中查找图片资料。具体地，由于图片资料根据不同的场景采用不同的保存方式进行保存，即针对场景1)和幻中的图片资料，一般保存在本地磁盘的特定目录下而针对场景幻中的图片资
12料，则一般保存图片文件在本地临时目录下而保存图片文件的URL信息在本地内存。因此， IM客户端可以根据不同的场景在选择查询范围，从而可以节省查询时间。步骤403 当找到图片资料时，IM客户端向用户A返回本地的图片资料；当没找到图片资料时，向用户A返回查询失败消息。在返回图片资料时，可以通过IM客户端向用户 A展现图片资料中的图片文件，比如微博用户的头像。与步骤303类似，当没找到图片资料时，也可以不返回查询失败消息，而是执行步骤406和407以拉取本地没有保存的图片资料，并在IM客户端拉取用户A查询的图片字资料后根据不同的场景进行保存，并向用户A返回拉取的图片资料。或者，IM客户端向用户A返回查询失败消息后，如果收到用户A的针对该UIN或 ID的用户资料拉取指令，再执行步骤406和407以向用户A返回拉取的图片资料。又或者，IM客户端在返回查询失败消息的同时展现默认的图片文件。步骤404 进行更新触发。本步骤中，用户A可以手动进行更新触发；也可以由IM客户端根据预定的更新条件进行更新触发。本发明实施例以用IM客户端根据预定的更新条件进行更新触发为例来说明。步骤405 :IM客户端根据更新条件的场景，判断是否需要拉取图片文件的URL信息。如果需要，则执行步骤406 ；否则结束本更新过程。在本步骤中，更新请求的场景可以是上述的三种场景，即1)对于大批量显示和/ 或频繁使用图片文件的更新；幻对单个查看图片文件的更新；幻对登录期间可能只需显示一次的大批量图片文件的更新。根据本发明实施例，不同的场景下采用不同的更新逻辑。具体地，第1)种场景下， 用户A每登录一次IM客户端更新一次图片资料；第2)场景下，只要用户查看某个图片文件，则更新该图片文件，即采用强制更新图片资料的逻辑；在第3)种场景下，则拉取一批的图片资料(如一批微博用户的头像)。因此在本步骤中，IM客户端首先需要判断待更新的图片资料属于哪种场景的更新条件。如果属于第1)种场景，由于此场景下用户A每登录一次IM客户端更新一次图片资料的方式，因此IM客户端首先判断图片资料在用户A此次登录期间是否已经更新过。如果已经更新过一次，则确定不需要拉取图片文件的URL信息；否则，确定需要拉取图片文件的 URL信息。如果属于第2)和3)种场景，则确定需要拉取图片文件的URL信息。 步骤406 IM客户端向微博服务器发送用户资料拉取请求用于拉取图片资料。步骤407 微博服务器收到用户资料拉取请求且确定拉取的用户资料包括图片资料，则向IM客户端返回响应，其中携带图片文件的URL信息。408 =IM客户端比较微博服务器返回的URL信息和本地保存的URL信息。如果微博服务器返回的URL信息与本地保存的URL信息不一致，则执行步骤409 ；否则，不修改本地URL信息，结束本管理过程。步骤409 =IM客户端将本地URL信息修改为微博服务器返回的URL信息，并根据返回的URL信息向图像架构部请求下载图片文件。在本实施例中，图片资料为微博用户的头像，而头像又分为自定义头像、系统头像和默认头像。当IM客户端拉取头像失败且没有本地的自定义头像时，IM客户端显示默认头像。头像的URL格式为http://Domain/key。其中，Domain为域名，key为图片标识。 对于自定义头像还包含了用户标识码UIN和时间戳等信息，而对于系统头像，比如小秘书头像等，则不含UIN信息。在服务器端，不同用户的自定义头像的key是不同的，而不同用户的相同的小秘书或系统头像的key相同。IM客户端在比较微博服务器返回的URL信息和本地保存的URL信息时，主要判断其中的key是否改变。如果改变，则准备向图像架构部请求下载头像文件。但是，在下载头像文件之前，IM客户端判断本地是否已经保存有与该URL信息对应的头像(此时的判断与 UIN没有关系)；如果没有保存，则下载该头像文件，否则不再下载。对于不同UIN的URL信息，如果key是相同的且本地有该头像文件，则不再下载该头像。对于相同UIN的URL信息中，如果key没变且本地该URL信息对应的头像文件存在，则不下载头像文件；而如果key 没变但本地头像文件损坏或丢失，则下载头像文件。客户端中常用的头像尺寸为40*40和2(^20，所以下载时会在URL后面加上这两种尺寸下载这两种头像，即 http://Domain/key/20 和 http //Domain/key/40。在下载头像时，可以采用HttpP2PDownload组件。步骤410 图像架构部向IM客户端返回新的图片文件。步骤411 :IM客户端根据不同的场景对返回的URL信息和新的图片文件进行保存。本步骤可以根据前文描述的保存方式来保存图片资料，即图片文件的URL信息和图片文件。比如对于第1)种场景，则IM客户端在本地磁盘保存图片文件的URL信息以及图片文件。对于第幻种场景，则IM客户端在查看图片文件之后在本地磁盘保存图片文件的URL信息以及图片文件。对于第3)种场景，则IM客户端将URL信息保存于内存，并临时保存图片文件，并在用户A退出IM客户端后清除临时保存的图片文件。不同场景下对图片资料的保存方式不同，可以在IM客户端本地灵活方便地对图片资料进行管理，从而提高用户资料管理的效率。步骤412 IM客户端向用户A通知图片资料更新事件。具体地，对于第1)和2)种场景，在图片资料有变化后，通知图片文件变化事件；对于第3)种场景，则通知图片下载完成事件。进一步地，该管理过程还可以包括删除本地保存的图片资料。比如删除第幻中场景下的图片资料，或者根据用户A的指令删除某个或某些图片资料。从而可以更合理地利用存储空间，进而提高客户端对图片资料的管理速度。由以上的管理过程可以看出，当用户A查询其他用户的用户资料时，IM客户端先在本地磁盘查询，而不是直接向微博服务器请求用户资料，因此可以更快速地调用用户A 所需要的用户资料，并能快速地展现用户资料。尤其是对于占用空间较大的图片资料，根据本实施例可以大大提高展现速度快。另外，根据预定的策略对用户资料进行管理，尤其是对图片资料进行管理时，不同的场景使用不同的策略，比如根据不同场景选择更新和保存方式，分而治之，充分、合理地利用了客户端的保存资源，提高了用户资料管理的灵活性。并且，利用预定的策略控制图片资料更新的次数，减少了客户端与服务器的交互次数，减低了服务器的通信压力。虽然图3和图4的管理过程中分别描述了文字资料和图片资料这两种类型的用户资料的管理过程，但是在实际管理过程中，用户A可以在一条用户资料查询请求中同时查询文字资料和图片，这种情况下，IM客户端的处理也和图3和图4类似，只是微博服务器在向IM客户端返回的响应中要同时携带两种类型的用户资料。本发明实施例还提供了基于泛关系链模型的系统中用户资料的管理装置，该系统以客户端为载体，用户通过客户端进入该系统，且包括服务器，用于为系统用户提供服务。 该管理装置可以位于客户端内部，也可以是与客户端相连接的一个独立的管理装置，并与系统服务器相连用于对系统的用户资料进行管理。图5为根据本发明实施例的基于泛关系链模型的系统中用户资料的管理装置的结构图。如图5所述，所述管理装置位于系统的客户端侧，包括拉取模块501，用于根据登录该客户端用户A的需求从系统的服务器拉取用户资料；保存模块502，用于将不同类型的用户资料采用不同的保存方式进行保存；管理模块503，用于根据预定的策略，对保存模块502保存的用户资料进行管理。用户资料可以是用户A的用户资料，还可以包括用户A感兴趣或者经常关注的用户的资料。本实施中，以IM客户端为载体的微博系统为例说明基于泛关系链模型的系统中用户资料的管理装置。根据本发明实施例，用户资料的类型至少包括文字资料和图片资料， 在微博系统中，图片资料可以是用户的头像。具体地，保存模块502可以对文字资料和图片资料采用不同的保存方式进行保存，而管理模块503对保存的用户资料的管理可以包括用户资料的查询、更新和/或删除用户资料、和/或向用户A通知用户资料事件。根据本发明实施例，拉取模块501根据用户A的需求从系统的服务器拉取用户资料与上述步骤201-203类似，在此不再赘述。根据本发明实施例，保存模块502包括类型判断子模块，用于判断用户资料的类型；和保存子模块，用于根据类型判断子模块判断的用户资料的类型，选择对应的保存方式来保存拉取模块501拉取的用户资料。具体地，当类型判断子模块判断用户资料的类型为文字资料时，则保存子模块选择保存于本地内存的保存方式，并根据选择的保存方式保存文字资料；当类型判断子模块判断拉取的用户资料的类型为图片资料时，则保存子模块根据不同场景选择不同的保存方式，并根据选择的保存方式保存拉取的图片资料。其中， 根据不同场景选择不同的保存方式与上述步骤204类似，在此不再赘述。根据本发明实施例，由于文字资料和图片资料的存储需求存在差异，采用两个保存子模块可以减少两类用户资料的耦合性，因此保存子模块还可以包括文字资料保存子模块和图片资料保存子模块。同理，根据本发明实施例，基本资料和图片资料的管理也存在差异，为了减少两类用户资料的耦合性，管理模块503中的预定的策略分为基于文字资料的策略和基于图片资料的策略，可以包括文字资料管理子模块，用于对用户资料中的文字资料根据预定的策略进行管理； 和图片资料管理子模块，用于对用户资料中的图片资料根据预定的策略进行管理。
进一步地，管理模块503还包括判断子模块，判断来自用户A或服务器的信息中， 用户资料包括文字资料还是图片资料，并将涉及文字资料的信息发给文字资料管理子模块进行管理，将涉及图片资料的信息发给图片资料管理子模块进行管理。根据本发明实施例，文字资料管理子模块包括文字资料查询子模块，用于接收判断子模块的关于文字资料的用户资料查询请求，在客户端本地内存中查找待查询用户资料中的文字资料；当找到所述文字资料时，在客户端向用户A返回所述文字资料；当没找到所述文字资料时，客户端向用户A返回查询失败消息。根据本发明实施例，所述图片资料管理子模块包括图片资料查询子模块，用于接收判断子模块的关于图片资料的用户资料查询请求，在本地磁盘中查找所述图片资料；当找到所述图片资料后，客户端向用户A展现所述图片资料；当没找到所述图片资料时，客户端向用户A返回查询失败消息。根据本发明实施例，文字资料管理子模块还包括文字资料更新子模块，用于每当文字查询子模块收到关于文字资料的用户资料查询请求时，更新一次文字资料。图片资料管理子模块还包括图片资料更新子模块，用于根据不同的场景更新图片资料。根据本发明实施例，管理模块503还包括拉取触发子模块，用于当用户A使用文字资料时，触发拉取模块501从服务器拉取文字资料，并将拉取的文字资料发给文字资料更新子模块。其中，文字资料更新子模块还用于判断客户端本地保存的文字资料是否与新拉取的文字资料一致；如果一致，则不保存新拉取的文字资料；否则，则通知保存模块502 用新拉取的文字资料替换本地保存的文字资料。所述图片资料更新子模块包括场景判断子模块，用于判断待更新的图片资料属于哪种场景；第一更新子模块，用于当待更新的图片资料属于大批量显示和/或频繁使用的场景时，则每当用户A登录客户端时更新一次所述图片资料；第二更新子模块，用于当待更新的图片资料属于用户A单个查看的图片资料时， 则用户A查看一次所述单个图片资料更新一次所述图片资料；第三更新子模块，用于当待更新的图片资料属于登录期间只需显示一次的大批量图片资料时，通知所述拉取触发子模块触发所述拉取模块从服务器拉取所述只需显示一次的图片资料的URL信息并根据拉取的URL信息下载对应的图片文件。根据本发明实施例，拉取触发子模块还用于根据第一更新子模块和/或第二更新子模块的请求，触发拉取模块向服务器请求待更新的图片资料的URL信息以及从服务器接收所请求的URL信息，并由拉取模块将请求的URL信息发送给第一更新子模块和/或第二更新子模块；第一更新子模块和/或第二更新子模块还用于判断所请求的URL信息与客户端本地保存的URL信息是否相同；如果不同，则根据所请求的URL信息下载新的图片文件，并通知保存模块502保存请求的URL信息和新的图片文件。根据本发明实施例，第三更新子模块还用于将下载完的图片文件临时保存并将对于的URL信息保存内存，在用户退出客户端后清除临时保存的图片文件。根据本发明实施例，管理模块503还包括通知子模块，用于当本地的文字资料变化时，通知文字资料更新事件；当本地的图片资料变化时，通知图片资料更新事件；当下载完只需显示一次的图片文件时，通知下载完成事件。
根据本发明实施例，管理模块503还包括删除子模块，用于根据用户的请求，删除本地保存的用户资料。进一步地，管理装置还包括编解码器，位于服务器和拉取模块501之间，用于对来自服务器的文字资料和图片资料进行编码解码，对拉取模块501发送给服务器的数据进行编码解码。通过以上的管理装置，当用户A查询其他用户的用户资料时，管理装置可以先在 IM客户端本地查询，而不是直接向微博服务器请求用户资料，因此可以更快速地调用用户 A所需要的用户资料，并能快速地展现用户资料。尤其是对于占用空间较大的图片资料，图片资料的展现速度得到很大的提高。另外，由于利用预定的策略对用户资料进行管理，比如不同的场景下的图片资料使用不同的更新和保存方式，分而治之，充分、合理地利用了客户端的保存资源，突出了用户资料管理的灵活性。并且，可以控制更新次数，从而避免重复拉取，减少与微博服务器的交互次数，进而降低了微博服务器的通信压力。图6为图5中管理装置的逻辑结构示意图。如图6所示，该管理装置主要包括文字资料管理器和头像资料管理器。具体地，在实现过程中，文字资料管理器可以定义为CTXWBlogContactlnfoMgr， 其实现文字资料管理器对外接口 ITXWBlogContactInfoMgr，对文字资料进行管理，包括文字资料的拉取Fetchl iStWBlogInfo ()、更新UpdateListffBLogInfo O、供用户查询 QueryffBLogInfo ()，以及文字资料更新时通知用户。较佳地，管理装置还包括资料更新事件接口 ITXWBlogContactlnfoEvtExt，当 CTXWBlogContactlnfoMgr内部的文字资料更新时调用该接口通知用户，而用户可以通过该接口来注册文字资料更新事件。较佳地，管理装置还包括文字资料更新事件实现类CTXWBlogContactlnfoEvtExt， 用于实现文字资料更新事件接口 ITXWBlogContac nfoEvtExt。在实现过程中，头像管理器可以定义为CWBlogCustomerHeadMgr， 其实现头像管理器对外接口 ITXWBlogCustomHeadMgr，对头像进行管理，包括头像的拉取FetchlistWBlogCustomHeadO、更新(包括头像信息更新 UpdateffBlogCustomHeadInfo O、头像列表更新 UpdateListWBlogCustomHead O、头像强制更新 ForceUpdateWBlogCustomHead O )、供用户查询 QueryCustomHead O，下载头像文件 DownloadUserHeadImage ()，以及头像更新时通知用户。较佳地，管理装置还包括头像更新事件接口 ITXWBlogCustomHeadEvtExt，在头像管理器CWBlogCustomerHeadMgr内部头像更新时调用该接口通知用户，而用户可以通过该接口来注册头像更新事件。较佳地，管理装置还包括头像更新事件实现类CTXWBlogCustomHeadEvtExt，实现头像更新事件接口 ITXWBlogCustomHeadEvtExt。较佳地，管理装置还包括编解码器CCSWBlogContac nfoCodec，用于与微博服务器交互数据时的编码和解码。具体地，当CTXWBlogContactlnfoMgr和 CWBlogCustomerHeadMgr向微博服务器发送数据时，调用CCSWBlogContacWnfoCodec中的编码器将发送的数据按微博服务器的要求进行编码，当收到微博服务器返回的数据时，调用CCSWBlogContac nfoCodec中的解码器进行数据解析。 以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
权利要求
1.基于泛关系链模型的系统中用户资料的管理方法，其特征在于，所述系统以客户端为载体且包括用于向系统用户提供服务的服务器，所述方法包括以下步骤位于所述客户端内部或与所述客户端相连的管理装置根据登录所述客户端的用户的需求从服务器拉取系统的用户资料，并将不同类型的用户资料采用不同的保存方式保存于客户端本地，其中所述用户资料至少包括所述用户的资料；所述管理装置根据预定的策略，对保存的用户资料进行管理。
2.如权利要求1所述的方法，其特征在于，所述用户资料还包括其他用户的资料；所述用户资料至少包括文字资料和图片资料两种类型；其中文字资料至少包括用户标识码UIN 或用户标识ID，所述图片资料包括图片文件的URL信息以及图片文件。
3.如权利要求2所述的方法，其特征在于，所述管理装置根据登录该客户端用户的需求从系统的服务器拉取系统的用户资料包括管理装置收到所述用户的用户资料拉取指令后，向服务器发送用户资料拉取请求，该用户资料拉取请求携带与用户资料对应的UIN或ID ；管理装置接收服务器根据该用户资料拉取请求中的UIN或ID向管理装置返回的响应， 该响应中携带与所述UIN或ID对应的用户资料。
4.如权利要求3所述的方法，其特征在于，还包括当响应中携带的用户资料类型为文字资料时，所述管理装置从所述响应中直接提取文字资料；当响应中携带的用户资料包括图片文件的统一资源定位URL信息时，管理装置根据所述URL信息从服务器或图像架构部下载图片文件。
5.如权利要求2所述的方法，其特征在于，所述管理装置对本地的用户资料进行管理包括根据预定的策略，查询、更新和/或删除所述用户资料，和/或向所述用户通知用户资料事件。
6.如权利要求5所述的方法，其特征在于，所述将拉取的用户资料保存于客户端本地包括管理装置将文字资料保存在客户端本地内存中；和/或根据不同的场景保存所述图片资料。
7.如权利要求6所述的方法，其特征在于，所述管理装置根据预定的策略查询本地的用户资料包括管理装置接收用户的用户资料查询请求，该用户资料查询请求至少携带待查询用户资料所对应用户的用户标识码UIN或用户标识ID ；管理装置判断所述待查询的用户资料是否包括文字资料和/或图片资料；当所述用户资料只包括文字资料时，则管理装置在客户端本地内存中查找所述文字资料；当找到所述文字资料后，向用户返回所述文字资料；当没找到所述文字资料时，向用户返回查询失败消息；当所述用户资料只包括图片资料时，则管理装置根据所述图片资料在不同场景下的保存方式查找所述图片资料；当找到所述图片资料后，向用户返回所述图片资料；当没找到所述图片资料时，向用户返回查询失败消息；当所述用户资料包括文字资料和图片资料时，则管理装置在客户端本地内存中查找所述文字资料并根据所述图片资料在不同场景下的保存方式查找所述图片资料；当找到所述文字资料和图片资料时，则向用户返回所述文字资料和图片资料；当没找到所述文字资料和图片资料时，则向用户返回查询失败消息。
8.如权利要求7所述的方法，其特征在于，还包括当管理装置返回查询失败消息后，管理装置根据所述用户的用户资料拉取指令从服务器拉取待查询的用户资料；如果所述用户资料为图片资料，在管理装置返回查询失败消息后，判断客户端本地是否有所述图片资料，如果没有，则向用户展现客户端的默认图片文件。
9.如权利要求6所述的方法，其特征在于，所述根据预定的策略更新所述用户资料包括当所述用户资料包括文字资料时，则每当所述用户使用所述文字资料时，更新一次所述文字资料，并保存更新的文字资料；当所述用户资料包括图片资料时，则根据不同的场景更新所述图片资料。
10.如权利要求9所述的方法，其特征在于，所述每当用户查询所述文字资料时更新一次所述文字资料包括管理装置从服务器拉取与所述UIN或ID对应的用户的文字资料，并判断本地内存保存的文字资料是否与从服务器拉取的文字资料一致；如果不一致，则用拉取的文字资料替换本地保存的文字资料。
11.如权利要求9所述的方法，其特征在于，所述根据不同的场景更新所述图片资料包括对于大批量显示和/或频繁使用的图片资料，每当所述用户登录客户端则更新一次图片资料；对于用户当前单个查看的图片资料，则每当所述用户查看一次图片资料更新一次所述图片资料；对于所述用户登录客户端期间只需显示一次的大批量图片资料，则用户请求所述图片资料时从服务器拉取所述图片资料的URL信息并根据拉取的URL信息下载图片文件。
12.如权利要求11所述的方法，其特征在于，所述对于大批量显示和/或频繁使用的图片资料，每当用户登录客户端则更新一次图片资料包括管理装置判断用户此次登录后所述大批量显示和/或频繁使用的图片资料是否更新过，如果更新过一次，则不再更新；否则，更新此次登录后未更新过的图片资料。
13.如权利要求11或12所述的方法，其特征在于，所述更新一次所述图片资料包括 管理装置向服务器请求待更新的图片资料的URL信息，并从服务器接收请求的URL信息；管理装置判断请求的URL信息与本地保存的URL信息是否相同； 如果不相同，则根据所请求的URL信息下载新的图片文件，并保存请求的URL信息和新的图片文件。
14.如权利要求13所述的方法，其特征在于，所述URL信息包括域名domain和图片标识 key ；所述管理装置判断请求的URL信息与本地保存的URL信息是否相同包括 判断请求的URL信息的key与本地保存的URL信息的key是否相同，如果相同，则这两个URL信息相同，否则这两个URL信息不同。
15.如权利要求6或9所述的方法，其特征在于，所述根据不同的场景保存所述图片资料包括对于大批量显示和/或频繁使用的图片资料，将URL信息和图片文件保存在本地磁盘的特定目录下；对于用户当前单个查看的图片资料，则将URL信息和图片文件保存在本地磁盘的特定目录下；对于只需显示一次的图片资料，将URL信息保存在内存中，并在根据URL信息下载完图片文件后将下载的图片文件保存在本地磁盘的临时目录下，并在用户退出客户端后清除保存的图片文件。
16.如权利要求11所述的方法，其特征在于，所述通知所述用户资料包括当所述文字资料有变化时，管理装置通知文字资料更新事件；当所述图片资料有变化时，管理装置通知图片资料更新事件；当下载完只需显示一次的图片文件后，管理装置通知下载完成事件。
17.如权利要求5所述的方法，其特征在于，所述删除所述用户资料包括根据用户的请求，删除保存的用户资料。
18.如权利要求1-5中任一项所述的方法，其特征在于，所述基于泛关系链模型的系统为微博系统，所述客户端为即时通讯IM客户端。
19.基于泛关系链模型的系统中用户资料的管理装置，其特征在于，该系统以客户端为载体且包括用于为系统用户提供服务的服务器，该管理装置位于该系统的客户端侧，包括拉取模块，用于根据登录该客户端用户的需求从系统的服务器拉取用户资料；保存模块，用于将不同类型的用户资料采用不同的保存方式进行保存；管理模块，用于根据预定的策略，对保存模块保存的用户资料进行管理。
20.如权利要求19所述的装置，其特征在于，所述管理模块包括文字资料管理子模块，用于对用户资料中的文字资料根据预定的策略进行管理；和图片资料管理子模块，用于对用户资料中的图片资料根据预定的策略进行管理。
21.如权利要求20所述的装置，其特征在于，所述管理模块还包括判断子模块，用于判断来自用户或服务器的信息中，所述用户资料包括文字资料还是图片资料，并将涉及文字资料的信息发给文字资料管理子模块进行管理，将涉及图片资料的信息发给图片资料管理子模块进行管理。
22.如权利要求21所述的装置，其特征在于，所述文字资料管理子模块包括文字资料查询子模块，用于接收来自所述判断子模块的关于文字资料的用户资料查询请求，在客户端本地内存中查找待查询用户资料中的文字资料；当找到所述文字资料时，向用户返回所述文字资料；当没找到所述文字资料时，向用户返回查询失败消息；所述图片资料管理子模块包括图片资料查询子模块，用于接收来自所述判断子模块的关于图片资料的用户资料查询请求，用于根据图片资料在不同场景下的保存方式查找所述图片资料；当找到所述图片资料后，向用户返回所述图片资料；当没找到所述图片资料时，向用户返回查询失败消息。
23.如权利要求22所述的装置，其特征在于，所述文字资料管理子模块包括文字资料更新子模块，用于当用户使用文字资料时，更新一次所述文字资料；所述图片资料管理子模块包括图片资料更新子模块，用于根据不同的场景更新所述图片资料。
24.如权利要求23所述的装置，其特征在于，所述管理模块还包括拉取触发子模块， 用于每当用户使用所述文字资料时，触发所述拉取模块从服务器拉取所述文字资料，并将拉取的文字资料发给所述文字资料更新子模块；其中，所述文字资料更新子模块还用于判断客户端本地保存的文字资料是否与新拉取的文字资料一致；如果不一致，则通知所述保存模块用新拉取的文字资料替换本地保存的文字资料。
25.如权利要求23所述的装置，其特征在于，所述图片资料更新子模块包括场景判断子模块，用于判断待更新的图片资料属于哪种场景；第一更新子模块，用于当待更新的图片资料属于大批量显示和/或频繁使用的场景时，则每当用户登录客户端时更新一次所述图片资料；第二更新子模块，用于当待更新的图片资料属于用户单个查看的图片资料时，则用户查看的一次所述图片资料更新一次所述图片资料；第三更新子模块，用于当待更新的图片资料属于用户登录客户端期间只需显示一次的大批量图片资料时，在用户请求所述图片资料时，触发所述拉取模块从服务器拉取所述只需显示一次的图片资料的URL信息并根据拉取的URL信息下载对应的图片文件。
26.如权利要求25所述的装置，其特征在于，所述拉取触发子模块还用于根据第一更新子模块和/或第二更新子模块的请求，触发所述拉取模块向服务器请求待更新的图片资料的URL信息以及从服务器接收所请求的URL信息，并由所述拉取模块将请求的URL信息发送给第一更新子模块和/或第二更新子模块；所述第一更新子模块和/或第二更新子模块还用于判断所请求的URL信息与客户端本地保存的URL信息是否相同；如果不同，则根据所请求的URL信息下载新的图片文件，并通知保存模块502保存请求的URL信息和新的图片文件；第三更新子模块还用于将下载完的图片文件临时保存，并在用户退出客户端后清除临时保存的图片文件。
27.如权利要求沈所述的装置，其特征在于，所述保存模块根据所述第一更新子模块和/或第二更新子模块的通知，将请求的URL信息和新的图片文件保存到本地磁盘的特定目录中。
28.如权利要求19所述的装置，其特征在于，所述保存模块包括类型判断子模块，用于判断拉取的用户资料的类型为文字资料还是图片资料；保存子模块，用于当类型判断子模块确定用户资料包括文字资料时，选择将文字资料保存于本地内存中；当类型判断子模块确定用户资料包括图片资料时，选择根据不同场景采用不同保存方式保存图片资料。
29.如权利要求观所述的方法，其特征在于，所述保存子模块还用于当待保存的图片资料属于大批量显示和/或频繁使用的场景或属于用户单个查看的图片资料时，将所述图片资料保存在本地磁盘的特定目录下；当待更新的图片资料属于用户登录客户端期间只需显示一次的大批量图片资料时，保存URL信息于本地内存中，并将图片文件保存于本地磁盘临时文件夹中。
30.如权利要求25所述的装置，还包括通知子模块，用于当所述文字资料变化时，通知文字资料更新事件；当所述图片资料变化时，通知图片资料更新事件；当下载完所述只需显示一次的图片文件时，通知下载完成事件。
全文摘要
本发明实施例提供了基于泛关系链模型的系统中用户资料的管理方法和装置。该系统以客户端为载体且包括用于向系统用户提供服务的服务器。该管理方法包括以下步骤位于客户端内部或与客户端相连的管理装置根据登录客户端的用户的需求从服务器拉取系统的用户资料，并将不同类型的用户资料采用不同的保存方式保存于客户端本地；管理装置根据预定的策略，对保存的用户资料进行管理。拉取的用户资料包括登录该客户端的用户的资料，还可以包括其他用户的资料。通过本发明实施例，可以实现用户资料的有效管理和快速展现。
文档编号H04L12/24GK102387026SQ20101027612
公开日2012年3月21日 申请日期2010年9月1日 优先权日2010年9月1日
发明者张丽 申请人:腾讯科技(深圳)有限公司