即时通信群组的管理方法和装置与流程

本申请涉及通信技术领域，尤其涉及一种即时通信群组的管理方法和装置。

背景技术：

随着互联网技术的广泛发展，即时通信技术给人们的工作与生活带来了各种便利。从早期的icq以及oicq(今日广泛使用的qq)到如今更新一代的微信以及钉钉等，即时通信技术正在不断地向着更加便利用户的方向演进。

很多即时通信都支持群聊技术，群聊技术可以允许在现实生活中处于同一集体的用户聚集在一起进行信息的交互与分享，比如：同学群、公司群等。在目前的群聊应用中，经常会出现一些简易性的多人会话，比如：临时将几个同事拉到一个群中说一下关键问题。然而，这类群后续再被使用的概率很低，导致服务端要维护很多这样的“僵尸群”，增加了群管理的复杂度，并且容易出错。

技术实现要素：

有鉴于此，本申请提供一种即时通信群组的管理方法和装置。

具体地，本申请是通过如下技术方案实现的：

一种即时通信群组的管理方法，所述方法包括：

确定群组会话消息中的必读消息；

根据所述必读消息的阅读情况，确定是否满足群组解散条件；

若满足群组解散条件，则基于预设的策略解散该群组。

一种即时通信群组的管理装置，所述装置包括：

必读确定单元，确定群组会话消息中的必读消息；

条件判断单元，根据所述必读消息的阅读情况，确定是否满足群组解散条件；

群组解散单元，若满足群组解散条件，则基于预设的策略解散该群组。

由以上描述可以看出，本申请可以根据群组中必读消息的阅读情况确定是否满足群组解散条件，并在满足该群组解散条件时，基于预设的策略解散该群组，从而解散大量的“僵尸群”，降低群组管理的复杂度，同时还可以释放服务端的存储、处理等各项资源。

附图说明

图1是本申请一示例性实施例示出的一种即时通信群组的管理方法的流程示意图。

图2是本申请一示例性实施例示出的一种群组会话界面示意图。

图3是本申请一示例性实施例示出的一种基于预设的策略解散群组的流程示意图。

图4是本申请一示例性实施例示出的一种用于即时通信群组的管理装置的一结构图。

图5是本申请一示例性实施例示出的一种即时通信群组的管理装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1是本申请一示例性实施例示出的一种即时通信群组的管理方法的流程示意图。

请参考图1，所述即时通信群组的管理方法可以应用在即时通信服务端，包括有以下步骤：

步骤101，确定群组会话消息中的必读消息。

在本实施例中，由于“公司群”、“同学群”等很多群组是长期存在的群组，并没有解散的必要，所以本申请可以仅针对临时群组执行必读消息的确定以及后续的解散流程。具体地，群创建者可以在创建群组的时候选择群组的类型，比如：创建“固定群组”还是创建“临时群组”；此外，针对已创建的固定群组，群主或者管理员也可以通过设置选项将固定群组的类型修改为临时群组；当然，针对已创建的临时群组，也可以通过设置选项将其类型修改为固定群组。

在本实施例中，所述必读消息通常由群主、管理员等有权限的群组成员标记。请参考图2的示例，群主在通过客户端发布一条群组会话消息后，可以通过点击、双击、长按等操作触发对必读消息的标记，比如：群主可以将希望所有群组成员都阅读的消息标记为必读消息。群主将某条消息标记为必读消息后，群主客户端可以将该标记事件发送给服务端，比如：可发送携带群组会话消息标识的标记事件给服务端，由服务端可以根据接收到的标记事件将对应的群组会话消息确定为必读消息。

当然，在实际的应用中，也可以采用其他的方式进行必读消息的标记，比如：在编辑好某条群组会话消息后，可以在消息编辑框中先将其标记为必读消息，然后再发送。采用这样的方式，客户端可以将必读消息的标记和该群组会话消息一同发送给服务端，无需在后续再次发送标记事件，本申请对此不作特殊限制。

步骤102，根据所述必读消息的阅读情况，确定是否满足群组解散条件。

在本实施例中，服务端可以统计所述必读消息的阅读情况，该阅读情况通常包括：已读或者未读。具体地，服务端可以检测每个群组成员对所述必读消息的阅读情况，然后根据所述必读消息在群组成员中的阅读情况群架是否满足群组解散条件。其中，所述阅读情况的检测可以采用相关技术中的实现方案来实现，本申请在此不再一一赘述。

在本实施例中，所述群组解散条件可以为默认的缺省条件，也可以由群主或者管理员根据需要进行个性化设置。

步骤103，若满足群组解散条件，则基于预设的策略解散该群组。

由以上描述可以看出，本申请可以根据群组中必读消息的阅读情况确定是否满足群组解散条件，并在满足该群组解散条件时，基于预设的策略解散该群组，从而解散大量的“僵尸群”，降低群组管理的复杂度，同时还可以释放服务端的存储、处理等各项资源。

下面以临时群组为例对本申请的实现过程进行详细描述。

在本实施例中，群主或管理员等有权限的群组成员可以根据需要设置必读消息的上限数量。举例来说，假设小白建立某临时群组的目的是向群组成员发布一条重要消息，那么小白可以将必读消息的上限数量设置为1，并在发送该条重要消息后，将这条重要消息标记为必读消息。值得注意的是，本申请中的必读消息上限数量不是固定不变的，在该临时群组解散之前，小白可以根据实际需要对该必读消息上限数量进行修改，本申请对此不作特殊限制。

在本实施例中，服务端基于小白的标记事件，可以检测各个群组成员对该必读消息的阅读情况。

在一个例子中，当服务端确定所述必读消息已经被所有群组成员阅读时，可以确定该临时群组满足群组解散条件，进而可以基于预设的策略解散该临时群组。

在另一个例子中，当服务端确定所述必读消息已被所有群组成员阅读，且所述必读消息的发布时长已到达第一时长时，可以确定该临时群组满足群组解散条件，进而可以基于预设的策略解散该临时群组。其中，所述第一时长可以由小白预先进行定义，也可以是默认的缺省值，比如：1天、3天等。以1天为例，当服务端确定所述必读消息已被所有群组成员阅读，且该必读消息的发布时长已到达24小时，可以基于预设的策略解散该临时群组。在这样的实现方式中，在所述必读消息的发布时长到达第一时长之前，群组成员还可以在该临时群组中进行相关讨论，小白也可以根据需要重新设置必读消息上限数量，实现更为灵活，用户体验更好。

在另一个例子中，当服务端确定所述必读消息未被所有群组成员阅读，但所述必读消息的发布时长已到达第二时长时，可以确定该临时群组满足群组解散条件，进而可以基于预设的策略解散该临时群组。其中，所述第二时长可以由小白预先进行定义，也可以是默认的缺省值，比如：15天、30天等，该第二时长通常大于前述第一时长。以15天为例，当服务端确定所述必读消息一直未被所有群组成员阅读，且该必读消息的发布时长已到达15天，则可以基于预设的策略解散该临时群组。换言之，当该必读消息的发布时长已到达15天时，即便还有群组成员没有阅读该必读消息，那么也可以基于预设的策略解散该临时群组。采用这样的实现方式，可以有效避免个别群组成员未阅读该必读消息，导致该临时群组一直不能被解散的问题。

在另一个例子中，当服务端确定已阅读所述必读消息的群组成员数量到达预设的比例时，可以确定该临时群组满足群组解散条件，进而可以基于预设的策略解散该临时群组。其中，所述预设的比例也可以由小白进行设置，比如：80％、90％等。举例来说，假设该临时群组共有10个群组成员，当服务端确定8个成员已阅读所述必读消息后，就可以基于预设的策略解散该临时群组。在实际应用中，也可以将这样的实现方式与前述第一时长、第二时长相结合，以作为群组解散条件的判定基准。

在另一个例子中，若小白设置的必读消息上限数量是大于1的数值，那么服务端可以在确定该临时群组中必读消息的数量已到达所述必读消息上限数量时，再根据所有必读消息的阅读情况，确定是否满足群组解散条件。

举例来说，假设小白将该临时群组的必读消息上限数量设置为3，则服务端可以在确定该临时群组中必读消息的数量到达3条时，进行群组解散条件的判定，比如：若这3条必读消息均已被所有群组成员阅读，可以确定该临时群组满足群组解散条件；若这3条必读消息均已被所有群组成员阅读，且发布时间最晚的必读消息的发布时长已到达24小时，可以确定该临时群组满足群组解散条件；若这3条必读消息中至少有1条必读消息未被所有群组成员阅读，且发布时间最晚的必读消息的发布时长已到达15天，可以确定该临时群组满足群组解散条件等，本申请在此不再一一赘述。

在本实施例中，当确定上述临时群组满足群组解散条件时，可基于预设的策略解散该群组。其中，所述预设的策略可以由开发人员进行设置。

在一个例子中，服务端可以立刻解散该临时群组，具体地，可以删除已保存的和该临时群组相关的所有信息，比如：群组标识、群组成员信息、群组会话消息等。

在另一个例子中，在解散该临时群组之前，可以给用户留一段缓冲时间。请参考图3，基于预设的策略解散该群组可以包括以下步骤：

步骤301，发送隐藏通知给客户端，以使客户端在群组列表中隐藏该群组。

在本实施例中，服务端在确定上述临时群组满足群组解散条件时，可先发送隐藏通知给客户端，客户端在接收到该隐藏通知后，可以在群组列表中隐藏该临时群组。这样，对于该临时群组的群组成员而言，已无法在群组列表中看见该临时群组，避免了已不使用的临时群组对用户的干扰。

步骤302，当该群组的隐藏时长到达第三时长时，解散该群组。

在本实施例中，服务端可以在确定该临时群组的隐藏到达第三时长时，解散该临时群组。其中，所述第三时长可以由开发人员进行设置，比如：20天、30天等。

举例来说，假设服务端在2017年3月1日18时确定上述临时群组满足群组解散条件，则服务端可以先发送隐藏通知给该临时群组的各个群组成员的客户端，客户端进而可以在群组列表中隐藏该临时群组。以上述第三时长是20天为例，服务端可以在2017年3月21日18时解散该临时群组。

进一步地，在该临时群组的隐藏时长到达第三时长之前，若接收到小白的查询指令，则可以通知小白的客户端显示该临时群组，若确定该临时群组出现新的必读消息，则取消对该临时群组的解散。

仍以上述举例为例，在2017年3月21日18时之前，若小白还想向该临时群组中的群组成员发布必读消息，则可以通过查询指令进行该临时群组的查询，比如：小白可以输入该临时群组的群组名称进行查询。服务端通知小白的客户端显示该临时群组。基于查找到的该临时群组，小白可以再次发送必读消息，还可以修改必读消息上限数量。在一个例子中，若服务端确定该临时群组出现新的必读消息，可以取消对该临时群组的解散，后续等该临时群组的必读消息数量再次到达必读消息上限数量时，根据所有必读消息的阅读情况，确定该临时群组是否满足群组解散条件，本申请在此不再一一赘述。

本申请在解散满足群组解散条件的群组之前，给用户一定的缓冲时间，灵活性更高。

与前述即时通信群组的管理方法的实施例相对应，本申请还提供了即时通信群组的管理装置的实施例。

本申请即时通信群组的管理装置的实施例可以应用在服务提供商部署的服务器或者服务器集群上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务器的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请即时通信群组的管理装置所在服务器的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的服务器为通常根据该服务器的实际功能，还可以包括其他硬件，对此不再赘述。

图5是本申请一示例性实施例示出的一种即时通信群组的管理装置的框图。

请参考图5，所述即时通信群组的管理装置400可以应用在前述图4所示的服务器中，包括有：必读确定单元401、条件判断单元402以及群组解散单元403。

其中，必读确定单元401，确定群组会话消息中的必读消息；

条件判断单元402，根据所述必读消息的阅读情况，确定是否满足群组解散条件；

群组解散单元403，若满足群组解散条件，则基于预设的策略解散该群组。

可选的，所述条件判断单元402，当所述必读消息已被所有群组成员阅读时，确定满足所述群组解散条件。

可选的，所述条件判断单元402，当所述必读消息已被所有群组成员阅读，且所述必读消息的发布时长已到达第一时长时，确定满足所述群组解散条件。

可选的，所述条件判断单元402，当所述必读消息未被所有群组成员阅读，但所述必读消息的发布时长已到达第二时长时，确定满足所述群组解散条件。

可选的，所述条件判断单元402，当已阅读所述必读消息的群组成员数量到达预设的比例时，确定满足所述群组解散条件。

可选的，所述条件判断单元402，还获取预定义的必读消息上限数量，并在所述群组会话消息中的必读消息数量已到达所述必读消息上限数量时，根据所有必读消息的阅读情况，确定是否满足群组解散条件。

可选的，所述必读消息上限数量由群主或管理员设定。

可选的，所述群组解散单元403，发送隐藏通知给客户端，以使客户端在群组列表中隐藏该群组；当该群组的隐藏时长到达第三时长时，解散该群组。

可选的，所述群组解散单元403，还在该群组的隐藏时长到达第三时长之前，若接收到来自群主或管理员的查询指令，则通知客户端显示该群组；并在确定该群组出现新的必读消息时，取消对该群组的解散。

可选的，所述群组为临时群组。

可选的，所述必读消息由群主或管理员标记。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

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