CN108111390A - 联系人管理方法、设备及存储介质 - Google Patents

Abstract

本申请公开了联系人管理方法、设备及存储介质，其中方法包括：获取用户的社交软件中的联系人与用户的互动记录；根据互动记录，确定联系人与用户的联系状况；根据联系状况确定联系人在至少两个预设类别中对应的预设类别，每个预设类别设置有对应的优先级；根据联系人对应的预设类别，进行与联系人有关的处理。应用本申请所述方案，能够减少社交超载的问题等。

Description

联系人管理方法、设备及存储介质

【技术领域】

本申请涉及计算机应用技术，特别涉及联系人管理方法、设备及存储介质。

【背景技术】

随着各种社交软件的普及，越来越多的用户开始通过社交软件来进行交流互动，相应地，社交软件中的联系人数也日趋增多。

为适应这一需求，各种社交软件都在不断地上调其联系人容量，比如，最新版本的微信支持单个用户的最大联系人数为5000。

但这样也会导致一些问题，比如，由于联系人数过多，可能造成社交超载等问题。

【发明内容】

本申请中提供了联系人管理方法、设备及存储介质。

根据本申请的一些实施例的一种联系人管理方法，包括：获取用户的社交软件中的联系人与所述用户的互动记录；根据所述互动记录，确定所述联系人与所述用户的联系状况；根据所述联系状况确定所述联系人在至少两个预设类别中对应的预设类别，每个预设类别设置有对应的优先级；根据所述联系人对应的预设类别，进行与所述联系人有关的处理。

根据本申请的一些实施例的一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现如以上所述的方法。

根据本申请的一些实施例的一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如以上所述的方法。

基于上述介绍可以看出，采用本申请所述方案，可根据与用户的联系状况来对社交软件中的联系人进行分类，并可为每个预设类别分别设置对应的优先级，进而可根据联系人对应的预设类别等，进行与联系人有关的处理，如可仅对特定类别或优先级的联系人进行某种处理或按照优先级进行联系人的排序等，从而实现了对于联系人的针对性筛选及有效管理等，进而减少了社交超载等问题。

【附图说明】

图1为根据本申请一些实施例的联系人管理方法的流程图。

图2为本申请所述的获取用户的社交软件中的联系人与用户的互动记录，根据互动记录确定出联系人与用户的联系状况，并根据联系状况确定出联系人与用户的联系热度的方法的第一实施例的流程图。

图3为本申请所述获取用户的社交软件中的联系人与用户的互动记录，根据互动记录确定出联系人与用户的联系状况，并根据联系状况确定出联系人与用户的联系热度的方法的第二实施例的流程图。

图4为本申请所述的根据联系热度确定联系人在至少两个预设类别中对应的预设类别的方法的第一实施例的流程图。

图5为本申请所述的根据联系热度确定联系人在至少两个预设类别中对应的预设类别的方法的第二实施例的流程图。

图6示出了适于用来实现本申请实施方式的示例性计算机***/服务器12的框图。

【具体实施方式】

本申请中提出一种联系人管理方案，可根据与用户的联系状况来对社交软件中的联系人进行分类，并可为每个预设类别分别设置对应的优先级，进而可根据联系人对应的预设类别等，进行与联系人有关的处理，如可仅对特定类别或优先级的联系人进行某种处理或按照优先级进行联系人的排序等，从而实现了对于联系人的针对性筛选及有效管理等，进而减少了社交超载等问题。

为了使本申请的技术方案更加清楚、明白，以下参照附图并举实施例，对本申请所述方案进行进一步说明。

显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

图1为根据本申请一些实施例的联系人管理方法的流程图。如图1所示，包括以下具体实现方式。

在101中，获取用户的社交软件中的联系人与用户的互动记录。

在102中，根据互动记录，确定联系人与用户的联系状况。

在103中，根据联系状况确定联系人在至少两个预设类别中对应的预设类别，每个预设类别设置有对应的优先级。

在104中，根据联系人对应的预设类别，进行与联系人有关的处理。

用户的社交软件中通常会包括多个联系人，那么可针对其中的部分或全部联系人中的每个联系人，分别确定出联系人与用户的联系状况。较佳地，可针对全部联系人中的每个联系人，分别确定出联系人与用户的联系状况。

联系人与用户的联系状况可根据联系人与用户的互动记录来确定。联系人与用户的互动记录包括所记录的联系人与用户的交互信息。在一些实施例中，联系人与用户的互动信息可包括：联系人与用户的聊天日志、朋友圈互动日志以及红包发放日志等；其中，联系人与用户的聊天日志可包括私聊日志以及群聊日志等，朋友圈互动日志可包括点赞和评论等。在一些实施例中，可获取最近预定时长内联系人与用户的互动记录，所述预定时长的具体取值可根据实际需要而定。

联系人与用户的联系状况可指示该联系人与用户之间的联系的情况。在一些实施例，联系状况可包括联系频率、联系强度、联系间隔等之中的至少一种。

其中，联系频率可以指示预定时长内联系人与用户的联系次数，联系强度可以指示联系人与用户之间的联系的信息量大小，联系间隔可以指示联系人与用户的相邻两次联系之间所间隔的时长等。在一些实施例中，若联系人与用户之间存在多次联系，所述联系强度可以指示联系人与用户的多次联系的总信息量大小或平均信息量大小，所述联系间隔可以指示联系人与用户的相邻两次联系之间所间隔的平均时长等；在一些实施例中，所述多次联系为联系人与用户之间在最近一段预定时长内的多次联系。

在根据互动记录确定出联系人与用户的联系状况后，可根据联系状况确定出联系人在至少两个预设类别中对应的预设类别，比如，可根据联系状况映射到相应的预设类别。

比如，可针对不同的预设类别，预先分别设置对应的取值区间，当获取到联系人与用户的联系频率后，可确定联系人与用户的联系频率所属的取值区间，进而可将所属的取值区间对应的预设类别作为联系人对应的预设类别。

同样地，当获取到联系人与用户的联系强度后，可确定联系人与用户的联系强度所属的取值区间，进而可将所属的取值区间对应的预设类别作为联系人对应的预设类别。当获取到联系人与用户的联系间隔后，可确定联系人与用户的联系间隔所属的取值区间，进而可将所属的取值区间对应的预设类别作为联系人对应的预设类别。

或者，在根据互动记录确定出联系人与用户的联系状况，如联系频率、联系强度或联系间隔后，可将联系人的联系状况与社交软件中的至少部分其他联系人的联系状况进行聚类运算，从而获得聚类结果，进而可根据聚类结果，确定出联系人以及至少部分其他联系人分别对应的预设类别。

另外，在根据互动记录确定出联系人与用户的联系状况后，还可首先根据联系状况确定出联系人与用户的联系热度，进而根据联系热度确定出联系人在至少两个预设类别中对应的预设类别。该联系热度可采用可量化的值或等级来指示联系人与用户之间与联系有关的热度。

具体实现可包括以下方式。

一)方式一

图2为本申请所述的获取用户的社交软件中的联系人与用户的互动记录，根据互动记录确定出联系人与用户的联系状况，并根据联系状况确定出联系人与用户的联系热度的方法的第一实施例的流程图。本实施例中，联系状况包括联系频率。如图2所示，本实施例包括以下具体实现方式。

在201中，获取联系人与用户的互动记录。

可获取最近预定时长内联系人与用户的互动记录，所述预定时长的具体取值可根据实际需要而定。

联系人与用户的互动记录可包括：联系人与用户的聊天日志、朋友圈互动日志以及红包发放日志等，其中，联系人与用户的聊天日志可包括私聊日志以及群聊日志等，朋友圈互动日志可包括点赞和评论等。

在202中，根据互动记录确定出联系人与用户的联系频率。

可通过对获取到的互动记录进行统计分析等，确定出联系人与用户的联系频率。

联系频率可以指示预定时长内联系人与用户的联系次数等。

比如，用户发到朋友圈一条信息，联系人对该信息执行了点赞或评论操作，那么则可认为联系人与用户进行了一次联系；再比如，联系人向用户发了一个红包或用户向联系人发了一个红包，那么则可认为联系人与用户进行了一次联系；再比如，联系人与用户进行聊天，若超过预定时长未产生新的聊天信息，那么则可认为本次聊天结束，将本次聊天作为联系人与用户进行的一次联系。

可按照上述方式，统计预定时长内联系人与用户进行联系的次数，从而基于统计结果确定联系人与用户的联系频率。

以上仅为举例说明，并不用于限制本申请的技术方案，比如，假设最近预定时长为最近30天，可统计这些天中联系人与用户进行了联系的天数，将统计结果作为所需的联系频率。

在203中，根据联系频率确定出联系人与用户的联系热度，联系频率越高，联系热度越高。

在获取到联系频率之后，可按照联系频率越高联系热度越高的原则，确定出联系人与用户的联系热度。

比如，可将联系次数进行预定处理如归一化处理后作为联系热度。

二)方式二

图3为本申请所述获取用户的社交软件中的联系人与用户的互动记录，根据互动记录确定出联系人与用户的联系状况，并根据联系状况确定出联系人与用户的联系热度的方法的第二实施例的流程图。本实施例的联系状况包括联系频率和联系强度。如图3所示，本实施例包括以下具体实现方式。

在301中，获取联系人与用户的互动记录。

可获取最近预定时长内联系人与用户的互动记录，所述预定时长的具体取值可根据实际需要而定。

联系人与用户的互动记录可包括：联系人与用户的聊天日志、朋友圈互动日志以及红包发放日志等，其中，联系人与用户的聊天日志可包括私聊日志以及群聊日志等，朋友圈互动日志可包括点赞和评论等。

在302中，根据互动记录确定出联系人与用户的联系频率以及联系强度。

可通过对获取到的互动记录进行统计分析等，确定出联系人与用户的联系频率和联系强度。

联系频率可以表示预定时长内联系人与用户的联系次数等。

联系强度可以指示联系人与用户之间的联系的信息量大小；在一些实施例中，所述联系强度可以指示联系人与用户的多次联系的总信息量大小或平均信息量大小；在一些实施例中，所述多次联系为联系人与用户之间在最近一段预定时长内的多次联系。比如，可针对不同的联系方式，分别设置对应的评估准则，并按照对应的评估准则确定出每次联系的信息量评估值，进而将最近预定时长内联系人与用户的各次联系的信息量评估值的均值作为所需的联系强度。

比如，联系人与用户的联系方式为聊天，那么可统计聊天字数，并根据聊天字数的多少来确定出本次联系的信息量评估值，聊天字数越多，信息量评估值越大。再比如，联系人与用户的联系方式为对用户发到朋友圈中的一条信息进行点赞或评论，那么可根据所执行的操作类型(点赞、评论)以及评论字数等确定出本次联系的信息量评估值。再比如，联系人与用户的联系方式为发红包，那么可根据红包金额来确定出本次联系的信息量评估值等。

在303中，根据联系频率以及联系强度确定出联系人与用户的联系热度，联系频率越高，联系热度越高，联系强度越大，联系热度越高。

在获取到联系频率和联系强度之后，可按照以下原则：联系频率越高，联系热度越高，联系强度越大，联系热度越高，根据联系频率以及联系强度确定出联系人与用户的联系热度。

比如，可分别将联系频率以及联系强度与对应的加权系数相乘，并将两个乘积相加，将相加之和作为联系热度。再比如，可计算联系频率与联系强度的乘积，将计算出的乘积作为联系热度。

图2和图3所示确定联系人与用户的联系热度的方式仅为举例说明，并不用于限制本申请的技术方案，除这两种方式外，还可以采用其它任意可行的实现方式。

比如，可获取联系人与用户的互动记录，根据互动记录确定出联系人与用户的联系间隔，联系间隔可以是指最近预定时长内联系人与用户每相邻两次联系时所间隔的平均时长，进而可根据联系间隔确定出联系人与用户的联系热度，如可将联系间隔进行预定处理如归一化处理后作为联系热度，联系间隔越短，联系热度越大。又比如，可获取联系人与用户的互动记录，根据互动记录确定出联系人与用户之间的联系频率、联系强度、联系间隔中的至少一者，进而根据联系频率、联系强度、联系间隔中的至少一者确定出联系人与用户的联系热度。

在确定出联系人与用户的联系热度之后，可进一步根据联系热度确定出联系人在至少两个预设类别中对应的预设类别，且每个预设类别分别设置有对应的优先级。

比如，预设类别可包括：经常联系、正常联系、偶尔联系、几乎不联系等。其中，按照优先级由高到低的顺序依次为：经常联系、正常联系、偶尔联系、几乎不联系。上述预设类别的分类仅用于举例，而非表示限制。本领域技术人员可根据需要来设置预设类别的分类。

如何根据联系热度确定出联系人在至少两个预设类别中对应的预设类别同样可根据实际需要而定，比如，可采用以下两种方式。

一)方式一

图4为本申请所述的根据联系热度确定联系人在至少两个预设类别中对应的预设类别的方法的第一实施例的流程图。如图4所示，包括以下具体实现方式。

在401中，确定出联系人的联系热度所属的取值区间。

可预先为每个预设类别分别设置对应的取值区间。

比如，联系热度的取值为0～1之间，预设类别数为4，分别为预设类别1～预设类别4，那么作为一种可能的实现方式，预设类别1对应的取值区间可为[0，0.25)，预设类别2对应的取值区间可为[0.25，0.5)，预设类别3对应的取值区间可为[0.5，0.75)，预设类别4对应的取值区间可为[0.75，1]。

在402中，将所属的取值区间对应的预设类别作为联系人对应的预设类别。

比如，联系人的联系热度为0.4，位于[0.25，0.5)的取值区间内，那么则可确定联系人对应的预设类别为预设类别2。

二)方式二

图5为本申请所述的根据联系热度确定联系人在至少两个预设类别中对应的预设类别的方法的第二实施例的流程图。如图5所示，包括以下具体实现方式。

在501中，将联系人的联系热度与社交软件中的至少部分其他联系人的联系热度进行聚类运算，获得聚类结果。

可将步骤101中得到的联系人的联系热度与社交软件中的至少部分其他联系人的联系热度进行聚类运算，从而获得聚类结果。

前述步骤101中用于确定联系人的联系热度的实施例可用于确定社交软件中的至少部分其他联系人的联系热度，在此不再赘述。

在502中，根据聚类结果，确定出联系人以及至少部分其他联系人分别对应的预设类别。

比如，参与聚类运算的联系热度共有100个，每个联系热度分别对应一个联系人，将这100个联系热度进行聚类运算，共得到4个聚类结果，每个聚类结果分别对应一个预设类别，每个聚类结果中包含的联系人分别对应同一预设类别。

上述两种根据联系热度确定联系人在至少两个预设类别中对应的预设类别的方式用于举例，而非表示限制。

无论通过上述哪种方式，在确定出联系人对应的预设类别之后，后续当符合更新条件时，均可重新确定出联系人对应的预设类别，即对分类结果进行更新。

在一些实施例中，更新条件可以包括但不限于：到达预定的更新周期，或者，互动记录的累计增加数量达到预定数量等。

比如，每经过预定时长，则重新确定各联系人对应的预设类别，或者，每累积增加了M条互动记录，M为大于一的正整数，则重新确定各联系人对应的预设类别，所述预定时长和M的具体取值均可根据实际需要而定。

上述各实施例的执行主体可为用户端，也可为云端的社交服务器。

另外，还可根据联系人对应的预设类别等，进行与联系人有关的处理。在一些实施例中，几种典型的应用场景介绍如下。

一)场景一

现有技术中，由于用户的社交软件的通讯录中的联系人数可能非常多，那么当用户需要查找某一联系人时，比如，当用户需要从通讯录中选择消息接收人时，则可能需要进行多次翻屏操作才能找到目标联系人。

而本申请所述方案中，可按照对应的预设类别的优先级越高排序越靠前的原则，对用户的社交软件的通讯录中的联系人进行排序，之后，当满足呈现通讯录中的联系人的条件时，可根据排序呈现通讯录中的联系人。也即，基于联系人的优先级，确定联系人在社交软件的通讯录中的排序。

比如，通讯录中共包括500个联系人，其中的50个联系人对应的预设类别为经常联系，150个联系人对应的预设类别为正常联系，200个联系人对应的预设类别为偶尔联系，100个联系人对应的预设类别为几乎不联系，那么可按照经常联系的联系人、正常联系的联系人、偶尔联系的联系人以及几乎不联系的联系人的顺序，对这500个联系人进行排序。其中，对于对应同一预设类别的各联系人，可按照字母顺序进行排序，或者，可按照联系热度由高到低的顺序进行排序，具体实现方式不限。

这样处理之后，与用户联系较多的联系人就会被排到前面，从而当用户需要与这些联系人进行联系时，可以迅速地找到所需的联系人。

二)场景二

该场景中，可获取用户分享至其分享空间的分享信息，之后，当联系人浏览用户的分享空间时，可根据联系人对应的预设类别，向联系人呈现分享空间中的分享信息。

用户的分享信息可以是指用户发布到朋友圈中的信息等。

比如，如果联系人对应的预设类别为经常联系或正常联系，那么则可向联系人呈现用户的分享空间中的分享信息，如果联系人对应的预设类别为偶尔联系或几乎不联系，那么则可向联系人屏蔽用户的分享空间中的分享信息，即联系人将不能看到用户的分享空间中的分享信息，从而实现了分享信息的针对性展现。

三)场景三

该场景中，可按照对应的联系人对应的预设类别的优先级越高排序越靠前的原则，对聊天记录列表中的各聊天记录进行排序。

比如，排在最前面的是经常联系的联系人对应的聊天记录，其次是正常联系的联系人对应的聊天记录，再之后是偶尔联系的联系人对应的聊天记录，最后是几乎不联系的联系人对应的聊天记录。

现有技术中，聊天记录列表中的聊天记录通常按照最后一次聊天的时间降序排列，这样，当用户需要查看某一经常联系的联系人对应的聊天记录时，如果聊天记录列表中包含的聊天记录数比较多，而所要查看的聊天记录又比较靠后的话，查找起来就会比较费时费力，而采用本申请所述方案后，可方便快捷地查找到所要查看的聊天记录。

上述三种场景主要用于举例，而非表示限制。

图6示出了适于用来实现本申请实施方式的示例性计算机***/服务器12的框图。图6显示的计算机***/服务器12仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图6所示，计算机***/服务器12以通用计算设备的形式表现。计算机***/服务器12的组件可以包括但不限于：一个或者多个处理器(处理单元)16，存储器28，连接不同***组件(包括存储器28和处理器16)的总线18。

总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，***总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及***组件互连(PCI)总线。

计算机***/服务器12典型地包括多种计算机***可读介质。这些介质可以是任何能够被计算机***/服务器12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

存储器28可以包括易失性存储器形式的计算机***可读介质，例如随机存取存储器(RAM)30和/或高速缓存存储器32。计算机***/服务器12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机***存储介质。仅作为举例，存储***34可以用于读写不可移动的、非易失性磁介质(图6未显示，通常称为“硬盘驱动器”)。尽管图6中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本申请各实施例的功能。

具有一组(至少一个)程序模块42的程序/实用工具40，可以存储在例如存储器28中，这样的程序模块42包括——但不限于——操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本申请所描述的实施例中的功能和/或方法。

计算机***/服务器12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该计算机***/服务器12交互的设备通信，和/或与使得该计算机***/服务器12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口22进行。并且，计算机***/服务器12还可以通过网络适配器20与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图6所示，网络适配器20通过总线18与计算机***/服务器12的其它模块通信。应当明白，尽管图中未示出，可以结合计算机***/服务器12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

处理器16通过运行存储在存储器28中的程序，从而执行各种功能应用以及数据处理，例如实现图1、2、3、4或5所示实施例中的方法。

本申请同时公开了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时将实现如图1、2、3、4或5所示实施例中的方法。

可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法等，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (12)

1.一种联系人管理方法，其特征在于，包括：

获取用户的社交软件中的联系人与所述用户的互动记录；

根据所述互动记录，确定所述联系人与所述用户的联系状况；

根据所述联系状况确定所述联系人在至少两个预设类别中对应的预设类别，每个预设类别设置有对应的优先级；

根据所述联系人对应的预设类别，进行与所述联系人有关的处理。

2.根据权利要求1所述的方法，其特征在于，所述联系状况包括联系频率、联系强度、联系间隔中的至少一种。

3.根据权利要求1所述的方法，其特征在于，根据所述联系状况确定所述联系人在至少两个预设类别中对应的预设类别，包括：

根据所述联系状况确定所述联系人与所述用户的联系热度；

根据所述联系热度确定所述联系人在至少两个预设类别中对应的预设类别。

4.根据权利要求3所述的方法，其特征在于，每个预设类别分别具有对应的取值区间，所述根据所述联系热度确定所述联系人在至少两个预设类别中对应的预设类别，包括：

确定所述联系人的联系热度所属的取值区间，将所属的取值区间对应的预设类别作为所述联系人对应的预设类别。

5.根据权利要求1所述的方法，其特征在于，所述根据所述联系状况确定所述联系人在至少两个预设类别中对应的预设类别，包括：

将所述联系人的联系状况与所述社交软件中的至少部分其他联系人的联系状况进行聚类运算，获得聚类结果；

根据所述聚类结果，确定所述联系人以及所述至少部分其他联系人分别对应的预设类别。

6.根据权利要求1所述的方法，其特征在于，所述预设类别包括：经常联系、正常联系、偶尔联系、几乎不联系。

7.根据权利要求1所述的方法，其特征在于，该方法进一步包括：

当符合更新条件时，重新确定所述联系人对应的预设类别。

8.根据权利要求1所述的方法，其特征在于，所述根据所述联系人对应的预设类别进行与所述联系人有关的处理，包括：

按照对应的预设类别的优先级越高排序越靠前的原则，对所述社交软件的通讯录中的联系人进行排序；

当满足呈现所述通讯录中的联系人的条件时，根据所述排序呈现所述通讯录中的联系人。

9.根据权利要求1所述的方法，其特征在于，该方法进一步包括：

获取所述用户分享至其分享空间的分享信息；

所述根据所述联系人对应的预设类别进行与所述联系人有关的处理，包括：

当所述联系人浏览所述用户的分享空间时，根据所述联系人对应的预设类别，向所述联系人呈现所述分享空间中的分享信息。

10.根据权利要求1所述的方法，其特征在于，所述根据所述联系人对应的预设类别进行与所述联系人有关的处理，包括：

按照对应的联系人对应的预设类别的优先级越高排序越靠前的原则，对聊天记录列表中的各聊天记录进行排序。

11.一种计算机设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1～10中任一项所述的方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1～10中任一项所述的方法。