CN112748980B - 消息推送方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本申请提供了一种消息推送方法、装置、设备及计算机可读存储介质，应用于人工智能领域，所述方法包括：响应于推送事件，获取至少两个任务对象中每一任务对象的状态消息；状态消息用于表征任务对象的任务状态；在会话界面中呈现目标会话消息；其中，目标会话消息包括每一任务对象的状态消息；会话界面用于为至少一个真实用户呈现虚拟用户发出的目标会话消息；虚拟用户用于通过预设接口执行每一任务对象。通过本申请提供的消息推送方法，能够提升状态消息的可读性。

Description

消息推送方法、装置、设备及计算机可读存储介质

技术领域

本申请涉及消息推送技术，尤其涉及一种消息推送方法、装置、设备及计算机可读存储介质。

背景技术

随着计算机技术的不断发展和应用功能的多样化发展，人们可以通过社交软件接收到各式各样的消息，社交软件提供的会话界面中，用户可以该会话界面接收多个真实用户发出的消息，也可以通过该会话界面接收关注的虚拟用户发出的消息。

相关技术中，由于虚拟用户只能机械的将系统生成的消息发送到当前会话界面中，在系统生成的消息较多的情况下，会存在虚拟用户“刷屏”的情况，导致用户无法快速获取到有用信息，消息可读性较差。

发明内容

本申请实施例提供一种消息推送方法、装置、设备及计算机可读存储介质，能够消息推送。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种消息推送方法，包括：响应于推送事件，获取至少两个任务对象中每一任务对象的状态消息；状态消息用于表征任务对象的任务状态；在会话界面中呈现目标会话消息；其中，目标会话消息包括每一任务对象的状态消息；会话界面用于为至少一个真实用户呈现虚拟用户发出的目标会话消息；虚拟用户用于通过预设接口执行每一任务对象。

在本申请的一些实施例中，所述在会话界面中呈现目标会话消息，包括：在会话界面中呈现基于展示模板和每一任务对象的状态消息生成的目标会话消息；展示模板是根据会话界面的界面类型信息和每一任务对象的类型信息得到的。

在本申请的一些实施例中，在任务对象为可操作任务对象的情况下，所述可操作任务对象的状态消息包括至少一个操作选项；操作选项用于响应于触发事件执行对应的预设操作。

在本申请的一些实施例中，在会话界面的界面类型信息为单人会话界面的情况下，展示模板用于根据每一任务对象的业务类型对每一任务对象的状态消息进行划分，确定至少一个第一组别，并在目标会话消息中分别呈现每一第一组别的第一组别消息；第一组别消息包括第一组别的第一组别信息和第一组别内的状态消息。

在本申请的一些实施例中，在会话界面的界面类型信息为群组会话界面的情况下，展示模板用于根据每一任务对象的第一类型对每一任务对象的状态消息进行划分，确定至少一个第二组别；根据每一任务对象的第二类型对每一第二组别内的任务对象进行划分，确定每一第二组别对应的至少一个第三组别；并在目标会话消息中分别呈现每一第二组别的第二组别消息；第二组别消息包括第二组别信息和第二组别内的每一第三组别的第三组别消息；第三组别消息包括第三组别的第三组别信息和第三组别内的状态消息；其中，第一类型为业务类型且第二类型为用户类型，或，第一类型为用户类型且第二类型为业务类型。

在本申请的一些实施例中，所述获取至少两个任务对象中每一任务对象的状态消息，包括：确定会话界面对应的至少一个真实用户；在至少一个真实用户对应的消息缓存中获取每一任务对象的状态消息；

在本申请的一些实施例中，所述在至少一个真实用户对应的消息缓存中获取每一任务对象的状态消息，包括：确定推送事件对应的第一用户；在第一用户的消息缓存中获取至少一个第一任务对象的第一状态消息；基于至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息。

在本申请的一些实施例中，在会话界面为单人会话界面的情况下，所述基于至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息，包括：将至少一个第一任务对象的第一状态消息，确定为至少一个任务对象的状态消息。

在本申请的一些实施例中，在会话界面为群组会话界面的情况下，所述基于至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息，包括：获取预设的第一等待时间；在第一等待时间内未接收到第二用户对应的推送事件的情况下，将至少一个第一任务对象的第一状态消息，确定为至少一个任务对象的状态消息；第二用户为群组会话界面中除第一用户之外的其他真实用户；在第一等待时间内接收到至少一个第三用户对应的推送事件的情况下，在每一第三用户对应的消息缓存中获取每一第三用户对应的至少一个第三任务对象的第三状态消息；将至少一个第一任务对象的第一状态消息和每一第三用户对应的至少一个第三任务对象的第三状态消息，确定为至少一个任务对象的状态消息。

在本申请的一些实施例中，所述方法还包括：基于每一任务对象的状态消息，生成目标会话消息。

在本申请的一些实施例中，所述基于每一任务对象的状态消息，生成目标会话消息，包括：根据会话界面的界面类型信息和每一任务对象的类型信息选择展示模板；基于每一任务对象的状态消息和展示模板，生成目标会话消息。

在本申请的一些实施例中，在所述根据会话界面的界面类型信息和每一任务对象的类型信息选择展示模板之前，方法还包括：基于每一状态消息的有效期，去除过期的状态消息。

在本申请的一些实施例中，所述在推送事件为后台触发事件的情况下，所述方法还包括：响应于后台生成的状态变更事件，获取状态变更事件中的第四任务对象和第四状态消息；利用第四任务对象和第四状态消息更新状态变更事件对应的第四用户的消息缓存；在第四状态消息的消息类别为推送类别的情况下，生成后台触发事件。

在本申请的一些实施例中，所述利用第四任务对象和第四状态消息更新状态变更事件对应的第四用户的消息缓存，包括：在第四用户的消息缓存中不存在第四任务对象的情况下，在第四用户的消息缓存中创建第四任务对象，并将第四状态消息确定为第四任务对象对应的状态消息；在第四用户的消息缓存中存在第四任务对象的情况下，利用第四状态消息替换第四用户的消息缓存中第四任务对象对应的历史状态消息。

在本申请的一些实施例中，所述在第四状态消息的消息类别为推送类别的情况下，生成后台触发事件，包括：在第四状态消息的消息类别为推送类别的情况下，获取第四用户的消息推送状态；在消息推送状态表征第四用户不存在需要推送的状态消息的情况下，生成后台触发事件；后台触发事件用于推送第四状态消息。

在本申请的一些实施例中，所述在消息推送状态表征第四用户没有任何消息需要推送的情况下，生成后台触发事件，包括：在消息推送状态表征第四用户不存在需要推送的状态消息的情况下，获取第四状态消息的紧急参数；确定紧急参数对应的第二等待时间；在第二等待时间之后，生成后台触发事件。

在本申请的一些实施例中，在推送事件为用户触发事件的情况下，所述方法还包括：接收第一用户发出的状态更新请求；基于状态更新请求，生成用户触发事件。

在本申请的一些实施例中，所述接收第一用户发出的状态更新请求，包括以下至少之一：接收第一用户针对会话界面中的状态更新选项的触发操作，基于触发操作生成状态更新请求；接收第一用户在会话界面输入的会话信息，提取会话信息中的关键字，在关键字用于查询任务对象的状态消息的情况下，生成状态更新请求；接收第一用户对虚拟标识的选择操作，虚拟标识用于确定虚拟对象。

本申请实施例提供一种消息推送装置，所述装置包括：

获取模块，用于响应于推送事件，获取至少两个任务对象中每一任务对象的状态消息；状态消息用于表征任务对象的任务状态；

呈现模块，用于在会话界面中呈现目标会话消息；其中，目标会话消息包括每一任务对象的状态消息；会话界面用于为至少一个真实用户呈现虚拟用户发出的目标会话消息；虚拟用户用于通过预设接口执行每一任务对象。

本申请实施例提供一种消息推送设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的消息推送方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的消息推送方法。

本申请实施例具有以下有益效果：

本申请实施例响应于推送事件，获取至少两个任务对象中每一任务对象的状态消息；状态消息用于表征任务对象的任务状态；在会话界面中呈现目标会话消息；其中，目标会话消息包括每一任务对象的状态消息；会话界面用于为至少一个真实用户呈现虚拟用户发出的目标会话消息；虚拟用户用于通过预设接口执行每一任务对象。其中，通过判断状态消息的消息类别，仅仅获取推送类别的状态消息，可以避免在目标会话消息中显示过多的冗余消息，可以使目标会话消息中重要消息直观的呈现给至少一个真实用户。同时，通过在获取第一用户关注的至少一个任务对象的状态信息的同时，获取其他的至少一个第二用户关注的至少一个任务对象的状态信息，可以使生成的目标会话消息不仅可以为第一用户展示其关注的任务状态，也可以为各第二用户展示各第二用户关注的任务状态；同时，还可以避免一个时间段内虚拟用户连续发出大量会话消息，而造成真实用户发出的重要信息被大量会话消息淹没的问题。

附图说明

图1是本申请实施例提供的消息推送系统的一个可选的架构示意图；

图2是本申请实施例提供的消息推送设备的结构示意图；

图3A是本申请实施例提供的消息推送方法的一个可选的流程示意图；

图3B是本申请实施例提供的会话界面的一个可选的界面示意图；

图3C是本申请实施例提供的会话界面的一个可选的界面示意图；

图4A是本申请实施例提供的消息推送方法的一个可选的流程示意图；

图4B是本申请实施例提供的目标会话消息的一个可选的显示示意图；

图4C是本申请实施例提供的目标会话消息的一个可选的显示示意图；

图5是本申请实施例提供的消息推送方法的一个可选的流程示意图；

图6是本申请实施例提供的消息推送方法的一个可选的流程示意图；

图7是本申请实施例提供的消息推送方法的一个可选的流程示意图；

图8是本申请实施例提供的消息推送方法的一个可选的流程示意图；

图9是本申请实施例提供的消息推送方法的一个可选的流程示意图；

图10是本申请实施例提供的一种机器人任务会话消息的管理方法示意图；

图11是本申请实施例提供的消息推送系统的一个可选的系统架构图；

图12是本申请实施例提供的消息推送方法的一个可选的流程示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使在本实施例中描述的本申请实施例能够以除了在本实施例中图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

本申请实施例提供的方案涉及人工智能技术，具体通过如下实施例进行说明：

人工智能(AI，Artificial Intelligence)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。换句话说，人工智能是计算机科学的一个综合技术，该技术企图了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器。人工智能也就是研究各种智能机器的设计原理与实现方法，使机器具有感知、推理与决策的功能。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

(1)AIOPS(Artificial Intelligence for IT Operations，智能运维)：由Gartner定义的新类别，源自ITOA(IT Operations and Analytics)基于算法的IT运维，把数据科学和算法用于自动化传统的IT运维任务和流程。算法被集成到工具里，帮助企业进一步简化运维工作，把人从耗时又容易出错的流程中解放出来。

(2)信息流机器人：在问答机器人的基础上，引入用户信息，对用户做出判断和推荐，实现更具针对性的回答。

(3)机器人任务：通过人机交互的方式，用户通过输入执行任务的唤醒词，机器人直接调用接口进行任务执行。

(4)任务追踪：机器人任务创建后，自动追踪任务的状态，通过人机交互的方式，返回表征任务状态的状态消息给用户，帮助用户实时关注任务进度。

(5)消息合并/聚合：多个机器人任务并发执行时，通过消息管理机制进行任务的消息的合并/聚合，方便用户同时管理多个机器人任务。

参见图1，图1是本申请实施例提供的消息推送系统100的一个可选的架构示意图，为实现支撑一个消息推送应用，终端(示例性示出了终端400-1和终端400-2)通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。图1还示出了服务器200可以为服务器集群，该服务器集群包括服务器200-1至200-3，同样地，服务器200-1至200-3可以是实体机器，也可以是利用虚拟化技术(如容器技术及虚拟机技术等)构建的虚拟机器，本申请实施例对此不做限定，当然，在本实施例中也可使用单个服务器来进行服务的提供。

在本申请的一些实施例中，终端可以接收用户的状态消息查询请求，并将该状态消息查询请求发送至服务器200，以获取至少两个任务对象中每一任务对象的状态消息，之后，终端可以通过交互式界面(示例性示出了界面410-1和界面410-2)中的会话界面呈现目标会话消息；其中，目标会话消息包括每一任务对象的状态消息；会话界面用于为至少一个真实用户呈现虚拟用户发出的目标会话消息；虚拟用户用于通过预设接口执行每一任务对象。

在本申请的一些实施例中，服务器200可以响应于后台触发事件，向终端发送至少两个任务对象中每一任务对象的状态消息，之后，终端可以通过交互式界面(示例性示出了界面410-1和界面410-2)中的会话界面呈现目标会话消息。

参见图2，图2是本申请实施例提供的消息推送设备500的结构示意图，图2所示的消息推送设备500包括：至少一个处理器510、存储器550、至少一个网络接口520和用户接口530。消息推送设备500中的各个组件通过总线系统540耦合在一起。可理解，总线系统540用于实现这些组件之间的连接通信。总线系统540除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统540。

处理器510可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口530包括使得能够呈现媒体内容的一个或多个输出装置531，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口530还包括一个或多个输入装置532，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器550包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memory)。本申请实施例描述的存储器550旨在包括任意适合类型的存储器。存储器550可选地包括在物理位置上远离处理器510的一个或多个存储设备。

在本申请的一些实施例中，存储器550能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统551，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块552，用于经由一个或多个(有线或无线)网络接口520到达其他计算设备，示例性的网络接口520包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

显示模块553，用于经由一个或多个与用户接口530相关联的输出装置531(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；

输入处理模块554，用于对一个或多个来自一个或多个输入装置532之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在本申请的一些实施例中，本申请实施例提供的消息推送装置可以采用软硬件结合的方式实现，作为示例，本申请实施例提供的消息推送装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的消息推送方法。

在本申请的一些实施例中，本申请实施例提供的消息推送装置可以采用软件方式实现，图2示出了存储在存储器550中的消息推送装置555，其可以是程序和插件等形式的软件，包括以下软件模块：获取模块5551和呈现模块5552，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。

将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的消息推送方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，ComplexProgrammable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable GateArray)或其他电子元件。

将结合本申请实施例提供的终端的示例性应用和实施，在本申请实施例中，将以终端为执行主体说明本申请实施例提供的消息推送方法。

参见图3A，图3A是本申请实施例提供的消息推送方法的一个可选的流程示意图，将结合图3A示出的步骤进行说明。

在步骤301中，响应于推送事件，获取至少两个任务对象中每一任务对象的状态消息；状态消息用于表征任务对象的任务状态。

在本申请的一些实施例中，所述推送事件可以包括以下至少之一：后台触发事件和用户触发事件。其中，该用户触发事件是基于真实用户的操作生成的触发事件，例如该用户触发事件是响应于真实用户在会话界面对目标选项的选择操作而生成的触发事件，也可以是响应于真实用户输入的会话消息而生成的触发事件；该后台触发事件是后台基于预设机制自动产生的触发事件，例如，该后台触发事件可以为基于定时触发机制而产生的触发事件，也可以是由于任务对象的任务状态发生变更后生成的触发事件。

在本申请的一些实施例中，在步骤301之前，每一任务对象已经被创建并执行，因此，每一任务对象均对应一个最新的状态消息，该状态消息用于表征该任务对象的任务状态。其中，该任务状态可以包括以下至少之一：任务标识，即该任务对象的名称；任务进度，即该任务对象的完成程度，可以通过时间、任务量和任务步骤等维度表征该任务对象的完成程度；运行状态，即该任务对象的当前状态，可以包括正在运行、暂停运行和定时运行等状态。

其中，该推送事件用于获取两个任务对象中至少一个任务对象的状态消息，也就是说，该推送事件可以是用于获取该至少两个任务对象中全部任务对象的状态消息，也可以是用于获取该至少两个任务对象中的部分任务对象的状态消息。也就是说，该推送事件需要显示的状态消息。

在步骤302中，在会话界面中呈现目标会话消息；其中，目标会话消息包括每一任务对象的状态消息；会话界面用于为至少一个真实用户呈现虚拟用户发出的目标会话消息；虚拟用户用于通过预设接口执行每一任务对象。

在本申请的一些实施例中，该会话界面是为至少一个真实用户和至少一个虚拟用户提供会话消息的显示界面。在该会话界面为单人会话界面的情况下，该会话界面可以同时对应一个真实用户和一个虚拟用户；在该会话界面为群组会话界面的情况下，该会话界面可以同时对应至少两个真实用户和至少一个虚拟用户。其中，该虚拟用户可以为信息流机器人，该任务对象可以是该信息流机器人调用预设接口执行的机器人任务。

在本申请的一些实施例中，响应于步骤301中的推送事件，可以通过上述会话界面呈现包括每一任务对象的状态消息的目标会话消息。其中，该目标会话消息是虚拟用户发出的一条会话消息，并通过该会话界面呈现给当前属于该会话界面的至少一个真实用户，以向该至少一个真实用户展现每一任务对象的状态消息。

需要说明的是，该目标会话消息是对每一任务对象的状态消息进行聚合处理后得到的。

在本申请的一些实施例中，该目标会话消息的格式可以为以下至少之一：文字、音频、图片和视频等。其中，以该目标会话消息同时包括文字和图片为例，任务对象的状态消息可以由文字和图片组成，基于上述任务状态消息得到的目标会话消息也是由文字和图片组成的。以该目标会话消息仅包括音频为例，该目标会话消息对应的音频包括每一任务对象对应的音频片段，每一任务对象对应的音频片段均用于表征该任务对象的任务状态。

请参阅图3B所示的会话界面的一个可选的界面示意图，在该会话界面30中，可以包括至少一个真实用户31(示例性的示出了真实用户“张三”)和一个虚拟用户32(示例性的示出了虚拟用户“机器人”)，可以看到，在该推送事件为响应于真实用户“张三”输入的会话消息而生成的触发事件的情况下，虚拟用户“机器人”在该会话界面30中呈现了目标会话消息33，该目标会话消息33包括了每一任务状态的状态消息，例如，“A任务”的状态消息331和“B任务”的状态消息332。其中，真实用户“张三”输入的会话消息可以为文字消息311“@机器人：查询我的任务进度！”，也可以为语音消息312，该语音消息312包含上述文字消息311的语义信息。

在本申请的一些实施例中，在任务对象为可操作任务对象的情况下，可操作任务对象的状态消息包括至少一个操作选项；操作选项用于响应于触发事件执行对应的预设操作。

其中，该至少一个任务对象中还可能存在可操作任务对象，该可操作任务对象的状态消息相比于其他任务对象的状态消息，还包括至少一个操作选项，该操作选项用于在被真实用户触发的情况下，执行该操作选项对应的预设操作。该操作选项可以包括以下至少之一“步骤状态”、“暂停/开始”、“任务链接”和“取消关注”等。

请参阅图3C所示的会话界面的一个可选的界面示意图，在该会话界面30中呈现了虚拟用户“机器人”发出的目标会话消息311，该目标会话消息33包括了“B任务”的状态消息332。其中，该“B任务”为可操作任务对象，在该状态消息332中，还显示了该“B任务”对应的至少一个操作选项3321。其中，图3C示例性的显示了步骤状态”、“暂停/开始”和“任务链接”共3个操作选项，在操作选项被真实用户触发之后，会执行该操作选项对应的预设操作。例如，在“暂停/开始”选项被真实用户触发之后，该“B任务”会由暂停状态转换至“开始状态”。

需要说明的是，本申请各实施例中的虚线框只是便于区分界面/消息中各个组成部分，在实际应用中并非必须显示的图形。

通过本申请实施例对于图3A的上述示例性实施可知，本申请实施例通过会话界面呈现虚拟用户发出的目标会话消息，可以使会话界面对应的至少一个真实用户及时获知关注的任务对象的任务状态，省去了访问服务端口查询状态的步骤，降低了状态查询时的运行成本；其次，由于本申请将多个任务对象的状态信息放在当前会话界面中的一个目标会话消息中进行呈现，相比于传统技术中发送大量的通知消息的方案，可以避免会话界面中重要的消息被大量通知消息淹没的情况，不仅提升了任务对象的状态消息的可读性，还可以降低其他重要消息被忽略的风险。

参见图4A，图4A是本申请实施例提供的消息推送方法的一个可选的流程示意图，基于图3A，图3A示出的步骤302可更新为步骤401，将结合图4A示出的步骤进行说明。

在步骤401中，在会话界面中呈现基于展示模板和每一任务对象的状态消息生成的目标会话消息；展示模板是根据会话界面的界面类型信息和每一任务对象的类型信息得到的；目标会话消息包括每一任务对象的状态消息；会话界面用于为至少一个真实用户呈现虚拟用户发出的目标会话消息；虚拟用户用于通过预设接口执行每一任务对象。

在本申请的一些实施例中，在会话界面的界面类型信息为单人会话界面的情况下，展示模板用于根据每一任务对象的业务类型对每一任务对象的状态消息进行划分，确定至少一个第一组别，并在目标会话消息中分别呈现每一第一组别的第一组别消息；第一组别消息包括第一组别的第一组别信息和第一组别内的状态消息。

其中，该单人会话界面用于显示一个真实用户与一个虚拟用户之间的会话消息。此时，该目标会话消息只需呈现该真实用户关注的各任务对象的状态消息。

在本申请的一些实施例中，每一任务对象的类型信息可以包括用于表征该任务对象所属的业务类型，通过统计每一任务对象所属的业务类型，可以得到该目标会话消息中需要显示的业务类型的类型数量。在步骤401中，可以通过单人会话界面和业务类型的类型数量确定一种展示模板，通过该展示模板可以对需要显示的所有状态消息进行分组显示，提高状态消息的可读性。

例如，在至少两个任务对象的状态消息包括A任务、B任务和C任务共三个任务对象对应的任务消息的情况下，且A任务、B任务属于第一业务，C任务属于第二业务。此时，可以得到如图4B所示的目标会话消息，参阅图4B所示的目标会话消息的一个可选的显示示意图，在该目标会话消息40中，需要显示的全部任务对象已经按照业务类型分成了两个第一组别消息，包括第一业务对应的第一组别消息41和第二业务对应的第一组别消息42，其中，第一组别消息41包括第一业务对应的第一组别信息411和第一组别内的状态消息412。

在本申请的一些实施例中，在会话界面的界面类型信息为群组会话界面的情况下，展示模板用于根据每一任务对象的第一类型对每一任务对象的状态消息进行划分，确定至少一个第二组别；根据每一任务对象的第二类型对每一第二组别内的任务对象进行划分，确定每一第二组别对应的至少一个第三组别；并在目标会话消息中分别呈现每一第二组别的第二组别消息；第二组别消息包括第二组别信息和第二组别内的每一第三组别的第三组别消息；第三组别消息包括第三组别的第三组别信息和第三组别内的状态消息；其中，第一类型为业务类型且第二类型为用户类型，或，第一类型为用户类型且第二类型为业务类型。

在本申请的一些实施例中，每一任务对象的类型信息可以包括用于表征该任务对象所属的业务类型和用于表征该任务对象所属真实用户的用户类型，通过统计每一任务对象所属的业务类型，可以得到该目标会话消息中需要显示的业务类型的类型数量，通过统计每一任务对象所属的用户类型，可以得到该目标会话消息中需要显示的用户类型的类型数量。

在步骤401中，可以通过群组会话界面、业务类型的类型数量和用户类型的类型数量确定一种展示模板，通过该展示模板可以对需要显示的所有状态消息进行分组显示，提高状态消息的可读性。

需要说明的是，可以以第一类型为业务类型且第二类型为用户类型对需要显示的任务对象的状态消息进行显示，通过当前的显示方式，可以便于至少一个真实用户对每一业务类型的任务对象的执行情况进行整体把控，提升业务类型下整体状态消息的可读性；还可以以第一类型为用户类型且第二类型为业务类型对需要显示的任务对象的状态消息进行显示，通过当前的显示方式，可以便于至少一个真实用户对每一用户类型的任务对象的执行情况进行整体把控，提升每一真实用户对各自关注的状态消息的可读性。

例如，在至少两个任务对象的状态消息包括A任务、B任务、C任务和D任务共四个任务对象对应的任务消息的情况下，且A任务、B任务和D任务属于第一业务，C任务属于第二业务；且A任务、B任务和C任务属于真实用户“张三”，D任务属于真实用户“李四”。

以第一类型为业务类型且第二类型为用户类型对需要显示的任务对象的状态消息进行显示，可以得到如图4C所示的目标会话消息，参阅图4C所示的目标会话消息的一个可选的显示示意图，在该目标会话消息40中，需要显示的全部任务对象已经按照业务类型分成了两个第二组别消息，包括“张三”对应的第二组别消息43和“李四”对应的第二组别消息44。其中，第二组别消息43包括“张三”对应的第二组别信息431、第一业务对应的第三组别消息432和第二业务对应的第三组别消息433；第三组别消息432包括第一业务对应的第三组别信息“第一业务：共2个机器人任务”和第一业务对应的第三组别内的状态消息“A任务和B任务”；第三组别消息433包括第二业务对应的第三组别信息“第二业务：共1个机器人任务”和第二业务对应的第三组别内的状态消息“C任务”。第二组别消息44包括“李四”对应的第二组别信息441、第一业务对应的第三组别消息442，其中，第三组别消息442包括第一业务对应的第三组别信息“第一业务：共1个机器人任务”和第一业务对应的第三组别内的状态消息“D任务”。

通过本申请实施例对于图4A的上述示例性实施可知，本申请实施例利用预设的展示模板对需要显示的至少两个任务对象的状态消息进行重构，在目标会话消息中显示重构后的状态消息，不仅实现了多个状态消息的同时显示，而且提升了消息重构的效率。另外，本申请通过任务对象的业务类别对各状态消息进行分组显示，可以使用户直观的获取各个业务接口的任务执行情况，以便用户对业务接口的整体运行情况进行把控；另外，本申请还可以通过任务对象的用户类型对各状态消息进行分组，可以在群组会话界面中的至少两个真实用户可以直观的获取自身关注的任务对象的任务状态。

参见图5，图5是本申请实施例提供的消息推送方法的一个可选的流程示意图，基于图3A，图3A示出的步骤301可更新为步骤501至步骤502，将结合图5示出的步骤进行说明。

在步骤501中，响应于推送事件，确定会话界面对应的至少一个真实用户。

在本申请的一些实施例中，该会话界面对应的至少一个真实用户为参与该会话界面对应会话组的至少一个真实用户。可以基于该会话界面的界面标识或对应会话组的组标识，确定处于该会话界面的至少一个真实用户，或确定参与该会话组的至少一个真实用户。

在步骤502中，在至少一个真实用户对应的消息缓存中获取每一任务对象的状态消息。

在本申请的一些实施例中，每一真实用户均对应一个消息缓存，该消息缓存用于存储该真实用户关注的所有任务对象及每一任务对象的状态消息。其中，对于一个真实用户关于的目标任务对象，该目标任务对象可以对应一个状态消息，该状态消息用于表征该目标任务对象的最新任务状态；该目标任务对象还可以对应多个状态消息，每一状态消息均对应一个时间点和目标任务对象在每一时间点下的任务状态。

在本申请的一些实施例中，任务对象的状态消息包括推送类别的状态消息和静默类别的状态消息。一个真实用户关注的多个任务对象的状态消息可以同时包括推送类别的状态消息和静默类别的状态消息，也可以仅仅包括推送类别的状态消息，还可以仅仅包括静默类别的状态消息。步骤502中获取的任务对象的状态消息仅为推送类别的状态消息。

需要说明的是，在真实用户对应的所有任务对象的状态消息均为静默类别的状态消息的情况下，不会从该真实用户对应的消息缓存中获取状态消息。因此，在会话界面对应N个真实用户的情况下，可能只会在M个真实用户对应的消息缓存中获取每一任务对象的状态消息，M小于或等于N。

通过本申请实施例对于图5的上述示例性实施可知，本申请实施例通过消息缓存保存生成的状态消息，在需要推送的时候在统一从消息缓存中获取待推送的消息，实现了消息生成和消息推送的分离，相比于传统技术中生成消息后直接推送的方案，本申请将消息通知系统的状态与后台内部状态解耦，编程者想发通知消息就可以生成消息并调用接口，仅需考虑用户是否马上需要被通知即可，无需在编写后台逻辑时考虑消息管理，实现异步状态刷新。这种方式对于未做消息合并系统的现存旧模块的兼容性也较好。

参见图6，图6是本申请实施例提供的消息推送方法的一个可选的流程示意图，基于图5，图5示出的步骤502可以包括步骤601至步骤603，将结合图6示出的步骤进行说明。

在步骤601中，确定推送事件对应的第一用户。

在本申请的一些实施例中，在该推送事件为后台触发事件的情况下，可以通过以下方式确定该推送事件对应的第一用户：获取该后台触发事件对应的任务对象，将该任务对象对应的真实用户确定为所述第一用户。例如，在该后台触发事件为任务对象的任务状态发生变更后产生了推送类别的状态消息的情况下，可以将该任务对象对应的真实用户确定为第一用户。该后台触发事件还可以为定时推送事件。

在步骤602中，在第一用户的消息缓存中获取至少一个第一任务对象的第一状态消息。

在本申请的一些实施例中，可以在该第一用户的消息缓存中获取该第一用户关注的所有任务对象和每一任务对象的状态消息，根据状态消息的消息类型进行筛选，将消息类型为推送类型的状态消息作为该第一状态消息，进而可以确定至少一个第一任务对象的第一状态消息。

在步骤603中，基于至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息。

在本申请的一些实施例中，可以通过步骤6031或步骤6032实现上述基于至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息。

在步骤6031中，在会话界面为单人会话界面的情况下，将至少一个第一任务对象的第一状态消息，确定为至少一个任务对象的状态消息。

在步骤6032中，在会话界面为群组会话界面的情况下，获取预设的第一等待时间；在第一等待时间内未接收到第二用户对应的推送事件的情况下，将至少一个第一任务对象的第一状态消息，确定为至少一个任务对象的状态消息；第二用户为群组会话界面中除第一用户之外的其他真实用户；在第一等待时间内接收到至少一个第三用户对应的推送事件的情况下，在每一第三用户对应的消息缓存中获取每一第三用户对应的至少一个第三任务对象的第三状态消息；将至少一个第一任务对象的第一状态消息和每一第三用户对应的至少一个第三任务对象的第三状态消息，确定为至少一个任务对象的状态消息。

在本申请的一些实施例中，在会话界面为群组会话的情况下，虽然当前的推送事件只需要获取第一用户关注的至少一个任务对象的状态消息，但是，为了在一个时间段内不断地显示每一真实用户各自关注的至少一个任务对象的状态消息，本申请实施例通过在推送第一用户关注的状态消息的同时，获取至少一个第二用户关注的状态消息，以完成第一用户关注的状态消息与至少一个第二用户关注的状态消息之间的聚合。

通过本申请实施例对于图6的上述示例性实施可知，本申请实施例通过判断状态消息的消息类别，仅仅获取推送类别的状态消息，可以避免在目标会话消息中显示过多的冗余消息，可以使目标会话消息中重要消息直观的呈现给至少一个真实用户。同时，通过在获取第一用户关注的至少一个任务对象的状态信息的同时，获取其他的至少一个第二用户关注的至少一个任务对象的状态信息，可以使生成的目标会话消息不仅可以为第一用户展示其关注的任务状态，也可以为各第二用户展示各第二用户关注的任务状态；同时，还可以避免一个时间段内虚拟用户连续发出大量会话消息，而造成真实用户发出的重要信息被大量会话消息淹没的问题。

参见图7，图7是本申请实施例提供的消息推送方法的一个可选的流程示意图，基于图5，在步骤502之后，所述方法还包括步骤701，将结合图7示出的步骤进行说明。

在步骤701中，基于每一任务对象的状态消息，生成目标会话消息。

在本申请的一些实施例中，可以通过步骤7011至步骤7012实现上述基于每一任务对象的状态消息，生成目标会话消息。

在步骤7011中，根据会话界面的界面类型信息和每一任务对象的类型信息选择展示模板。

在步骤7012中，基于每一任务对象的状态消息和展示模板，生成目标会话消息。

在本申请的一些实施例中，在根据会话界面的界面类型信息和每一任务对象的类型信息选择展示模板之前，所述方法还包括：基于每一状态消息的有效期，去除过期的状态消息。

其中，本实施例中的展示模板具体可参阅图4实施例中对展示模板的描述。

通过本申请实施例对于图7的上述示例性实施可知，本申请实施例利用预设的展示模板对需要显示的至少两个任务对象的状态消息进行重构，在目标会话消息中显示重构后的状态消息，不仅实现了多个状态消息的同时显示，而且提升了消息重构的效率。另外，本申请通过任务对象的业务类别对各状态消息进行分组显示，可以使用户直观的获取各个业务接口的任务执行情况，以便用户对业务接口的整体运行情况进行把控；另外，本申请还可以通过任务对象的用户类型对各状态消息进行分组，可以在群组会话界面中的至少两个真实用户可以直观的获取自身关注的任务对象的任务状态。

参见图8，图8是本申请实施例提供的消息推送方法的一个可选的流程示意图，基于图5，所述方法还包括步骤801至步骤803，步骤501可以更新为步骤804，将结合图8示出的步骤进行说明。

在步骤801中，响应于后台生成的状态变更事件，获取状态变更事件中的第四任务对象和第四状态消息。

在步骤802中，利用第四任务对象和第四状态消息更新状态变更事件对应的第四用户的消息缓存。

在本申请的一些实施例中，可以通过步骤8021或步骤8022实现上述利用第四任务对象和第四状态消息更新状态变更事件对应的第四用户的消息缓存。

在步骤8021中，在第四用户的消息缓存中不存在第四任务对象的情况下，在第四用户的消息缓存中创建第四任务对象，并将第四状态消息确定为第四任务对象对应的状态消息。

在步骤8022中，在第四用户的消息缓存中存在第四任务对象的情况下，利用第四状态消息替换第四用户的消息缓存中第四任务对象对应的历史状态消息。

在步骤803中，在第四状态消息的消息类别为推送类别的情况下，生成后台触发事件。

在本申请的一些实施例中，可以通过步骤8031至步骤8032实现上述在第四状态消息的消息类别为推送类别的情况下，生成后台触发事件。

在步骤8031中，在第四状态消息的消息类别为推送类别的情况下，获取第四用户的消息推送状态。

在步骤8032中，在消息推送状态表征第四用户不存在需要推送的状态消息的情况下，生成后台触发事件；后台触发事件用于推送第四状态消息。

其中，对于每一个用户，可以为其维护一个消息推送锁，该消息推送锁可使用任意分布式锁方案实现。在步骤8031之后，尝试获取该锁，如果获取成功，则消息推送状态表征第四用户不存在需要推送的状态消息，即可以生成后台触发事件。如果获取失败，则消息推送状态表征第四用户存在需要推送的状态消息，因为当前占有锁的状态消息占有了发送权，会帮助捎带发送该第四状态消息。

在本申请的一些实施例中，可以通过以下方式实现上述步骤8032：在消息推送状态表征第四用户不存在需要推送的状态消息的情况下，获取第四状态消息的紧急参数；确定紧急参数对应的第二等待时间；在第二等待时间之后，生成后台触发事件。

其中，可以通过紧急参数与第二等待时间的对应关系，确定当前第四状态消息对应的第二等待时间。例如，存储的对应关系可以为E1对应T1，E2对应T2和E3对应T3，在当前第四状态消息对应的紧急参数为E1的情况下，可以得到对应的第二等待时间为T1。其中，随着紧急参数表征消息的紧急程度越高，对应的第二等待时间越少，在紧急程度最高时，对应的第二等待时间为零。

在步骤804中，响应于后台触发事件，确定会话界面对应的至少一个真实用户。

通过本申请实施例对于图8的上述示例性实施可知，本申请实施例通过获取用户的消息推送状态，避免了在一段时间中多次推送同一用户对应的状态消息，提升了相同用户下状态消息的聚合度。

参见图9，图9是本申请实施例提供的消息推送方法的一个可选的流程示意图，基于图5，所述方法还包括步骤901至步骤902，步骤501可以更新为步骤903，将结合图9示出的步骤进行说明。

在步骤901中，接收第一用户发出的状态更新请求。

在本申请的一些实施例中，可以通过以下至少之一的方式实现上述接收第一用户发出的状态更新请求：接收第一用户针对会话界面中的状态更新选项的触发操作，基于触发操作生成状态更新请求；接收第一用户在会话界面输入的会话信息，提取会话信息中的关键字，在关键字用于查询任务对象的状态消息的情况下，生成状态更新请求；接收第一用户对虚拟标识的选择操作，虚拟标识用于确定虚拟对象。

其中，该虚拟标识可以为虚拟用户的头像，该选择操作可以为双击，长按等。上述选择操作还可以是对虚拟对象的身份标识的选择操作，在用户会话信息中同时存在该身份标识与选择字符的情况下，生成所述状态更新请求。例如，对于用户标识“张三”，可以在用户会话信息中同时存在该身份标识“张三”与选择字符“@”的情况下，即“@张三”，生成所述状态更新请求。

在步骤902中，基于状态更新请求，生成用户触发事件。

在步骤903中，响应于用户触发事件，确定会话界面对应的至少一个真实用户。

通过本申请实施例对于图9的上述示例性实施可知，本申请实施例通过获取用户触发的状态更新请求，生成对应的用户触发事件，提升了用户对于状态消息查询的便捷度。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

由于AIOPS兴起，任务型机器人也得到了很大程度的重视，在日常业务运营的过程中，经常需要需求发起者发起一个需求任务，并通过即时通信工具将该需求任务发送至需求处理人员，需求处理人员通过其他平台完成该需求任务后，将处理结果反馈至需求发起者。

机器人任务的出现使得需求任务可以在对话中产生，然后在对话中通过机器人直接完成并告知需求发起者，这在一定程度上提供高需求任务的流转效率，节省了用户的时间。然而，需求发起者的需求往往会出现多个，此时，在需求发起者的会话消息管理上就出现了问题，多个需求任务对应的任务会话消息在对话框中难以管理，需求发起者不知道每个任务的执行进度。

基于上述问题，本申请通过后台自动跟踪任务状态，当新的机器人任务产生时，如果检测到有未完成的任务，会自动将新任务的会话消息与未完成的任务进行消息合并通知，方便用户能同时管理多个任务，如图10所示，图10提供了一种机器人任务会话消息的管理方法示意图。

在步骤1001中，创建机器任务。

其中，以单一用户同时创建至少两个任务为例，该用户可以创建任务1，相应的，会存在该任务1对应的会话消息1；该用户还可以创建任务2，相应地，会存在该任务2对应的会话消息2。

在步骤1002中，对运行的机器任务进行状态跟踪。

在步骤1003中，将会话消息进行合并。

其中，以上述单一用户同时创建至少两个任务为例，步骤1003会将任务1对应的会话消息1和任务2对应的会话消息2进行合并。并将合并后的会话消息显示于会话界面中。

在本申请的一些实施例中，本申请使用如下技术方案实现状态通知消息聚合功能：

第一方面，本申请将生成的消息划分为推送消息和静默消息。其中，该推送消息和静默消息相当于上述实施例中的推送类别的状态消息和静默类别的状态消息。

其中，消息聚合可以在减少消息发送频率的同时，保证消息内容的及时性，满足用户预期。在实施时，消息聚合可以是将消息生成和消息推送分离。任务状态类消息通常描述了一个后台任务的最新状态，状态发生变更时，用户不一定立即需要获取消息；然而当某个事件触发消息推送或用户主动获取消息时，用户又需要看到最新的消息内容。

对于状态同步消息，每条消息都有一个描述对象(相当于上述实施例中的任务对象)，该消息描述对象的最新状态。对于相同的描述对象，一条新的状态描述消息生成时，旧的状态描述消息的内容就过时了，因为新的消息反映了最新的状态。这种消息的新颖程度与及时程度称为时效性。对于描述对象相同的多条消息，较新的一条总是比旧的一条时效性更好。在描述同一对象的所有消息的集合中，就时效性的二元关系而言，显然该集合中所有元素之间的关系满足反对称性与传递性，且集合中任意两条消息都可以比较时序性，也就是说该二元关系是一个全序关系。对于该时效性的全序关系，本申请定义时间上靠前的一条消息为靠后的一条消息的祖先，靠后的一条消息为靠前的一条消息的后代。由于用户在查看某对象当前状态时，总是希望看到时效性最好的消息，故祖先消息总是可以被后代消息顶替。由于该关系为全序关系且满足传递性，一条消息的后代的后代依然是这条消息的后代，因此顶替行为可以持续进行。

本申请将推送行为与后台消息生成分离，将所有调用接口发送的消息分为推送消息与静默消息。推送是指将消息从消息管理模块发送给用户。推送消息是指后台生成后需要触发推送行为的消息。后台仅在关键事件发生时发送推送消息。静默消息是指后台生成后不需要触发推送行为的消息。静默消息仅顶替自己的祖先消息在消息缓存中的状态。

通过第一方面的技术方案，将状态通知维护与刷新封装至消息接口一侧，比起在后台(非消息推送模块)内部维护用户查询状态要更加清晰。这种方式也便于将消息通知系统的状态与后台内部状态解耦，编程者想发通知消息就可以生成消息并调用接口，仅需考虑用户是否马上需要被通知即可，无需在编写后台逻辑时考虑消息管理，实现异步状态刷新。通过第一方面的技术方案对于未做消息合并系统的现存旧模块的兼容性也较好。

第二方面，通过消息捎带与消息缓发机制实现聚合。

其中，消息捎带是指当一条推送消息请求生成时，该用户所述的其他消息也会按格式合并到文本中一起发送。这些其他的消息可能当前未被发起推送，但由于其他的消息总是最新的一条静默消息，因此也可以反映其内容的最新情况。

消息缓发是指当一条推送消息请求生成时，后台等待一定时间后再做发送，这可以提升消息的聚合度。当目前有正在等待推送的推送消息时，其他的推送消息会自动转换为静默消息并被合并。等待时间通常是十几秒，该时间长度的制定需要在被推送消息的及时性和短期内消息的聚合度之间选择一个平衡点。

第三方面，采用“用户对应消息缓存”的二级结构。

消息缓存是一个存储某个用户当前所有消息的缓存系统，该系统内部是一个二级结构。第一级是不同的用户，每个用户有一个对应的缓存结构体。缓存结构体内是第二级结构，区分该用户相关的所有消息描述对象。消息描述对象即是用户所关系其状态的一个概念，可能是抽象的概念，比如系统中的一个任务。每一个消息描述对象对应存储着一条消息。

第四方面，用户消息推送锁。

对于每一个用户，本申请为其维护一个消息推送锁，该锁可使用任意分布式锁方案实现。当推送事件触发时，基于该推送事件，尝试获取该锁，如果获取成功，则该推送事件对应的推送消息获得发送权。如果获取失败，则放弃发送行为，因为当前占有锁的请求占有了发送权，会帮助捎带发送该推送事件对应的推送消息。

请参阅图11，图11是本申请实施例提供的消息推送系统的一个可选的系统架构图。该消息推送系统包括消息管理模块1102、任务管理后台1103和消息状态缓存1104。其中，该消息管理模块1102可以接收用户1101主动查询消息的操作，同时，具有消息聚合功能，还以向用户1101推送生成的聚合消息。消息管理模块1102还用于向消息状态缓存1104发送静默消息刷新的请求，也可以从消息状态缓存1104中读取捎带消息。任务管理后台1103用于是任意需要同步状态消息的后台逻辑，在需要的时候生成静默消息或推送消息向用户表达当前的状态。

请参阅图12，图12是本申请实施例提供的消息推送方法的一个可选的流程示意图。其中，本申请提供的消息推送系统可以通过用户查询触发，也可以通过后台调用触发。

图12中后台调用触发的流程包括：

在步骤1201中，生成消息。

其中，后台生成消息后，调用消息管理系统的接口提交消息。有效期与任务对象相关。

在步骤1202中，判断该消息是否有祖先消息。在该消息有祖先的情况下，执行步骤1203，在该消息没有祖先的情况下，执行步骤1204。

在步骤1203中，利用该消息顶替缓存中的祖先消息。

在步骤1204中，在缓存中创建消息状态。

其中，可以通过以下方式实现上述步骤1202，检查该消息在缓存中是否有祖先消息，如果有祖先消息，则祖先的内容已过时，该消息将顶替祖先；如果无祖先，本申请根据该消息的描述对象生成唯一id，并在缓存中创建上文所述的消息缓存结构，即缓存消息。

在步骤1205中，更新该消息的有效期。

其中，由于该消息已经被重新顶替或重新创建，因此，需要重新计算该消息的有效期。该消息的有效期与该消息对应的任务对象有关。

在步骤1206中，判断该消息是否为推送消息。在该消息为推送消息的情况下，执行步骤1207，在该消息不是推送消息的情况下，流程结束。

其中，消息中有一个字段说明是否是推送消息。

在步骤1207中，判断当前是否有待推送消息。在当前有待推送消息的情况下，执行步骤1208，在当前没有待推送消息的情况下，流程结束。

其中，推送消息触发推送行为后，处理该请求的线程尝试获取用户的消息发送锁，如果失败，说明该用户当前有其他消息等待推送。

在步骤1208中，判断该消息是否为紧急消息。在该消息为紧急消息的情况下，执行步骤1210，在该消息不是紧急消息的情况下，执行步骤1209。

其中，跳过消息缓发阶段的消息称为紧急消息，在后台调用消息发送接口时传入一个参数说明是否是紧急消息。本申请检查该消息是否为紧急消息，如果是，直接进入聚合流程；如果不是，等待规定时间(若干秒)后进入聚合流程，这个等待阶段称为消息缓发。聚合流程包括：拉取缓存中所有消息，清除过期消息，生成聚合消息。

在步骤1209中，等待规定时间。

在步骤1210中，拉取缓存中所有消息。

其中，在聚合流程中，本申请拉取缓存中该用户所有的消息。

在步骤1211中，清除过期消息。

其中，根据各消息的有效期，所有消息中的过期消息。

在步骤1212中，生成聚合消息。

其中，步骤1212按照清晰的板式将所有消息进行文字排版(该板式没有硬性规定，通常是对每一个用户，根据该用户当前相关的所有消息描述对象，逐一列出对象的名称和相关的消息)。

在步骤1213中，清除一次性消息。

在步骤1214中，呈现聚合消息。

其中，排版完成后，本申请清除缓存中的一次性消息。完成后，即可推送聚合后的消息给用户，流程结束。

图12中用户主动触发的流程包括：

在步骤1215中，用户主动查询。

在步骤1210中，拉取缓存中所有消息。

在步骤1211中，清除过期消息。

在步骤1212中，生成聚合消息。

在步骤1213中，清除一次性消息。

在步骤1214中，呈现聚合消息。

针对传统技术中，当多个任务产生多个独立的会话消息时，新的任务的会话消息会将前面任务的会话消息淹没，用户需要进行消息回溯才能找到上一个任务会话消息，无法做到并行跟踪多个任务的状态。通过上述实施例提供的消息推送方法和消息推送系统，可以根据多个任务的状态，实时进行消息追踪和合并，方便用户能同时管理多个任务的状态，有利于效率的提升。

下面继续说明本申请实施例提供的消息推送装置555的实施为软件模块的示例性结构，在本申请的一些实施例中，如图2所示，存储在存储器550的消息推送装置555中的软件模块可以包括：

获取模块5551，用于响应于推送事件，获取至少两个任务对象中每一任务对象的状态消息；状态消息用于表征任务对象的任务状态；

呈现模块5552，用于在会话界面中呈现目标会话消息；其中，目标会话消息包括每一任务对象的状态消息；会话界面用于为至少一个真实用户呈现虚拟用户发出的目标会话消息；虚拟用户用于通过预设接口执行每一任务对象。

在本申请的一些实施例中，所述呈现模块5552，还用于包括：在会话界面中呈现基于展示模板和每一任务对象的状态消息生成的目标会话消息；展示模板是根据会话界面的界面类型信息和每一任务对象的类型信息得到的。

在本申请的一些实施例中，在任务对象为可操作任务对象的情况下，所述可操作任务对象的状态消息包括至少一个操作选项；操作选项用于响应于触发事件执行对应的预设操作。

在本申请的一些实施例中，在会话界面的界面类型信息为单人会话界面的情况下，展示模板用于根据每一任务对象的业务类型对每一任务对象的状态消息进行划分，确定至少一个第一组别，并在目标会话消息中分别呈现每一第一组别的第一组别消息；第一组别消息包括第一组别的第一组别信息和第一组别内的状态消息。

在本申请的一些实施例中，在会话界面的界面类型信息为群组会话界面的情况下，展示模板用于根据每一任务对象的第一类型对每一任务对象的状态消息进行划分，确定至少一个第二组别；根据每一任务对象的第二类型对每一第二组别内的任务对象进行划分，确定每一第二组别对应的至少一个第三组别；并在目标会话消息中分别呈现每一第二组别的第二组别消息；第二组别消息包括第二组别信息和第二组别内的每一第三组别的第三组别消息；第三组别消息包括第三组别的第三组别信息和第三组别内的状态消息；其中，第一类型为业务类型且第二类型为用户类型，或，第一类型为用户类型且第二类型为业务类型。

在本申请的一些实施例中，所述获取模块5551，还用于确定会话界面对应的至少一个真实用户；在至少一个真实用户对应的消息缓存中获取每一任务对象的状态消息；

在本申请的一些实施例中，所述获取模块5551，还用于确定推送事件对应的第一用户；在第一用户的消息缓存中获取至少一个第一任务对象的第一状态消息；基于至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息。

在本申请的一些实施例中，在会话界面为单人会话界面的情况下，所述获取模块5551，还用于将至少一个第一任务对象的第一状态消息，确定为至少一个任务对象的状态消息。

在本申请的一些实施例中，在会话界面为群组会话界面的情况下，所述获取模块5551，还用于获取预设的第一等待时间；在第一等待时间内未接收到第二用户对应的推送事件的情况下，将至少一个第一任务对象的第一状态消息，确定为至少一个任务对象的状态消息；第二用户为群组会话界面中除第一用户之外的其他真实用户；在第一等待时间内接收到至少一个第三用户对应的推送事件的情况下，在每一第三用户对应的消息缓存中获取每一第三用户对应的至少一个第三任务对象的第三状态消息；将至少一个第一任务对象的第一状态消息和每一第三用户对应的至少一个第三任务对象的第三状态消息，确定为至少一个任务对象的状态消息。

在本申请的一些实施例中，所述呈现模块5552，还用于基于每一任务对象的状态消息，生成目标会话消息。

在本申请的一些实施例中，所述呈现模块5552，还用于根据会话界面的界面类型信息和每一任务对象的类型信息选择展示模板；基于每一任务对象的状态消息和展示模板，生成目标会话消息。

在本申请的一些实施例中，所述呈现模块5552，还用于基于每一状态消息的有效期，去除过期的状态消息。

在本申请的一些实施例中，所述在推送事件为后台触发事件的情况下，所述呈现模块5552，还用于响应于后台生成的状态变更事件，获取状态变更事件中的第四任务对象和第四状态消息；利用第四任务对象和第四状态消息更新状态变更事件对应的第四用户的消息缓存；在第四状态消息的消息类别为推送类别的情况下，生成后台触发事件。

在本申请的一些实施例中，所述呈现模块5552，还用于在第四用户的消息缓存中不存在第四任务对象的情况下，在第四用户的消息缓存中创建第四任务对象，并将第四状态消息确定为第四任务对象对应的状态消息；在第四用户的消息缓存中存在第四任务对象的情况下，利用第四状态消息替换第四用户的消息缓存中第四任务对象对应的历史状态消息。

在本申请的一些实施例中，所述呈现模块5552，还用于在第四状态消息的消息类别为推送类别的情况下，获取第四用户的消息推送状态；在消息推送状态表征第四用户不存在需要推送的状态消息的情况下，生成后台触发事件；后台触发事件用于推送第四状态消息。

在本申请的一些实施例中，所述呈现模块5552，还用于在消息推送状态表征第四用户不存在需要推送的状态消息的情况下，获取第四状态消息的紧急参数；确定紧急参数对应的第二等待时间；在第二等待时间之后，生成后台触发事件。

在本申请的一些实施例中，在推送事件为用户触发事件的情况下，所述呈现模块5552，还用于接收第一用户发出的状态更新请求；基于状态更新请求，生成用户触发事件。

在本申请的一些实施例中，所述接收第一用户发出的状态更新请求，包括以下至少之一：接收第一用户针对会话界面中的状态更新选项的触发操作，基于触发操作生成状态更新请求；接收第一用户在会话界面输入的会话信息，提取会话信息中的关键字，在关键字用于查询任务对象的状态消息的情况下，生成状态更新请求；接收第一用户对虚拟标识的选择操作，虚拟标识用于确定虚拟对象。

本公开实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的消息推送方法。

本公开实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的消息推送方法，例如，如图3A、图4A、图5、图6、图7、图8或图9示出的方法。

在本申请的一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在本申请的一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

综上所述，通过本申请实施例能够实现以下技术效果：

(1)本申请实施例通过会话界面呈现虚拟用户发出的目标会话消息，可以使会话界面对应的至少一个真实用户及时获知关注的任务对象的任务状态，省去了访问服务端口查询状态的步骤，降低了状态查询时的运行成本；其次，由于本申请将多个任务对象的状态信息放在当前会话界面中的一个目标会话消息中进行呈现，相比于传统技术中发送大量的通知消息的方案，可以避免会话界面中重要的消息被大量通知消息淹没的情况，不仅提升了任务对象的状态消息的可读性，还可以降低其他重要消息被忽略的风险。

(2)本申请实施例利用预设的展示模板对需要显示的至少两个任务对象的状态消息进行重构，在目标会话消息中显示重构后的状态消息，不仅实现了多个状态消息的同时显示，而且提升了消息重构的效率。另外，本申请通过任务对象的业务类别对各状态消息进行分组显示，可以使用户直观的获取各个业务接口的任务执行情况，以便用户对业务接口的整体运行情况进行把控；另外，本申请还可以通过任务对象的用户类型对各状态消息进行分组，可以在群组会话界面中的至少两个真实用户可以直观的获取自身关注的任务对象的任务状态。

(3)本申请实施例通过消息缓存保存生成的状态消息，在需要推送的时候在统一从消息缓存中获取待推送的消息，实现了消息生成和消息推送的分离，相比于传统技术中生成消息后直接推送的方案，本申请将消息通知系统的状态与后台内部状态解耦，编程者想发通知消息就可以生成消息并调用接口，仅需考虑用户是否马上需要被通知即可，无需在编写后台逻辑时考虑消息管理，实现异步状态刷新。这种方式对于未做消息合并系统的现存旧模块的兼容性也较好。

(4)本申请实施例通过判断状态消息的消息类别，仅仅获取推送类别的状态消息，可以避免在目标会话消息中显示过多的冗余消息，可以使目标会话消息中重要消息直观的呈现给至少一个真实用户。同时，通过在获取第一用户关注的至少一个任务对象的状态信息的同时，获取其他的至少一个第二用户关注的至少一个任务对象的状态信息，可以使生成的目标会话消息不仅可以为第一用户展示其关注的任务状态，也可以为各第二用户展示各第二用户关注的任务状态；同时，还可以避免一个时间段内虚拟用户连续发出大量会话消息，而造成真实用户发出的重要信息被大量会话消息淹没的问题。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (13)

1.一种消息推送方法，其特征在于，包括：

响应于推送事件，确定会话界面对应的至少一个真实用户；

确定所述推送事件对应的第一用户；

在所述第一用户的消息缓存中获取至少一个第一任务对象的第一状态消息；

基于所述至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息；所述状态消息用于表征所述任务对象的任务状态；

在所述会话界面中呈现目标会话消息；

其中，所述目标会话消息包括每一所述任务对象的状态消息；所述会话界面用于为所述至少一个真实用户呈现虚拟用户发出的所述目标会话消息；所述虚拟用户用于通过预设接口执行每一所述任务对象。

2.根据权利要求1所述的方法，其特征在于，所述在所述会话界面中呈现目标会话消息，包括：

在所述会话界面中呈现基于展示模板和每一所述任务对象的状态消息生成的目标会话消息；所述展示模板是根据所述会话界面的界面类型信息和每一所述任务对象的类型信息得到的。

3.根据权利要求2所述的方法，其特征在于，在所述会话界面的界面类型信息为单人会话界面的情况下，所述展示模板用于根据每一所述任务对象的业务类型对每一所述任务对象的状态消息进行划分，确定至少一个第一组别，并在所述目标会话消息中分别呈现每一所述第一组别的第一组别消息；所述第一组别消息包括所述第一组别的第一组别信息和所述第一组别内的状态消息。

4.根据权利要求2所述的方法，其特征在于，在所述会话界面的界面类型信息为群组会话界面的情况下，所述展示模板用于根据每一所述任务对象的第一类型对每一所述任务对象的状态消息进行划分，确定至少一个第二组别；根据每一所述任务对象的第二类型对每一所述第二组别内的任务对象进行划分，确定每一所述第二组别对应的至少一个第三组别；并在所述目标会话消息中分别呈现每一所述第二组别的第二组别消息；所述第二组别消息包括所述第二组别信息和所述第二组别内的每一所述第三组别的第三组别消息；所述第三组别消息包括所述第三组别的第三组别信息和所述第三组别内的状态消息；

其中，所述第一类型为业务类型且所述第二类型为用户类型，或，所述第一类型为用户类型且所述第二类型为业务类型。

5.根据权利要求1所述的方法，其特征在于，在所述会话界面为单人会话界面的情况下，所述基于所述至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息，包括：

将所述至少一个第一任务对象的第一状态消息，确定为所述至少一个任务对象的状态消息。

6.根据权利要求1所述的方法，其特征在于，在所述会话界面为群组会话界面的情况下，所述基于所述至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息，包括：

获取预设的第一等待时间；

在所述第一等待时间内未接收到第二用户对应的推送事件的情况下，将所述至少一个第一任务对象的第一状态消息，确定为所述至少一个任务对象的状态消息；所述第二用户为所述群组会话界面中除所述第一用户之外的其他真实用户；

在所述第一等待时间内接收到至少一个第三用户对应的推送事件的情况下，在每一所述第三用户对应的消息缓存中获取每一所述第三用户对应的至少一个第三任务对象的第三状态消息；将所述至少一个第一任务对象的第一状态消息和每一所述第三用户对应的至少一个第三任务对象的第三状态消息，确定为所述至少一个任务对象的状态消息。

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

基于每一所述任务对象的状态消息，生成所述目标会话消息。

8.根据权利要求7所述的方法，其特征在于，所述基于每一所述任务对象的状态消息，生成所述目标会话消息，包括：

根据所述会话界面的界面类型信息和每一所述任务对象的类型信息选择展示模板；

基于每一所述任务对象的状态消息和所述展示模板，生成所述目标会话消息。

9.根据权利要求1所述的方法，其特征在于，在所述推送事件为后台触发事件的情况下，所述方法还包括：

响应于后台生成的状态变更事件，获取所述状态变更事件中的第四任务对象和第四状态消息；

利用所述第四任务对象和所述第四状态消息更新所述状态变更事件对应的第四用户的消息缓存；

在所述第四状态消息的消息类别为推送类别的情况下，生成所述后台触发事件。

10.根据权利要求9所述的方法，其特征在于，所述利用所述第四任务对象和所述第四状态消息更新所述状态变更事件对应的第四用户的消息缓存，包括：

在所述第四用户的消息缓存中不存在所述第四任务对象的情况下，在所述第四用户的消息缓存中创建所述第四任务对象，并将所述第四状态消息确定为所述第四任务对象对应的状态消息；

在所述第四用户的消息缓存中存在所述第四任务对象的情况下，利用所述第四状态消息替换所述第四用户的消息缓存中所述第四任务对象对应的历史状态消息。

11.一种消息推送装置，其特征在于，包括：

获取模块，用于响应于推送事件，确定会话界面对应的至少一个真实用户；确定所述推送事件对应的第一用户；在所述第一用户的消息缓存中获取至少一个第一任务对象的第一状态消息；基于所述至少一个第一任务对象的第一状态消息，确定至少一个任务对象的状态消息；所述状态消息用于表征所述任务对象的任务状态；

呈现模块，用于在所述会话界面中呈现目标会话消息；其中，所述目标会话消息包括每一所述任务对象的状态消息；所述会话界面用于为所述至少一个真实用户呈现虚拟用户发出的所述目标会话消息；所述虚拟用户用于通过预设接口执行每一所述任务对象。

12.一种消息推送设备，其特征在于，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至10任一项所述的方法。

13.一种计算机可读存储介质，其特征在于，存储有可执行指令，用于被处理器执行时，实现权利要求1至10任一项所述的方法。

Images