CN111381976B - 消息提示数据的更新方法、装置、存储介质及计算机设备 - Google Patents

Abstract

本发明涉及互联网技术领域，尤其涉及一种消息提示数据的更新方法、装置、存储介质及计算机设备，其中，所述消息提示数据的更新方法，包括如下步骤：接收表征对消息进行处理操作的消息任务；按照时间顺序将所述消息任务存储于缓存队列中；依次提取缓存队列中的消息任务，解析所述消息任务获得消息任务的属性信息，根据所述属性信息进行消息提示数据的更新。本申请提供的方案，通过队列的形式保证消息提示逻辑执行的有序性，以解决多线程处理消息提示的并发问题。

Description

消息提示数据的更新方法、装置、存储介质及计算机设备

技术领域

本发明涉及互联网技术领域，具体而言，本发明涉及一种消息提示数据的更新方法、装置、存储介质及计算机设备。

背景技术

我们平常接触到的大部分应用程序(简称：App)，在收到新消息的时候一般都会以数字或红点的形式提示出来。比如在微信当中，当某位好友给我们发来新的聊天消息的时候，在相应的会话上就会有一个数字来表示未读消息的数目；再比如当微信朋友圈里有人发布新的内容时，朋友圈的入口就会出现一个红点，而当朋友圈里有人给我们点了赞，或者对我们发布的内容进行了评论的时候，朋友圈的入口就会显示一个数字。

目前很多应用程序都能够接收系统或其他用户发送的消息，将消息到来的提示信息展示于该用户在本地端的对话框位置，以便用户掌握当前需要处理或回复的消息，常用的消息提示的形式是消息红点及数字提示，由于没有对数字和红点的展示做一个统一的抽象和管理，以至于数字和红点之间的关系错综复杂，牵一发而动全身。在App的维护过程中，稍微有一点改动(比如增加几个数字或红点类型)，出现错误提示问题的概率很高。比如，红点怎么点击也清除不掉；或者，发现有数字了，点进去却什么也没有；或者，点进去看到的数字和外面看到的不一样。

现有技术中有采用树型管理数字和红点提示的技术，使用树型结构管理消息红点的增删查改，且使用异步消息进行回调。但这种方式未考虑多线程并发的情况，容易由于并发问题而导致实际显示不符合预期或者遭遇并发处理的崩溃性异常。

发明内容

本发明提供了一种消息提示数据的更新方法、装置、存储介质及计算机设备，以解决多线程处理消息提示的并发问题。

本申请实施例首先提供了一种消息提示数据的更新方法，包括：

接收表征对消息进行处理操作的消息任务；

按照时间顺序将所述消息任务存储于缓存队列中；

依次提取缓存队列中的消息任务，解析所述消息任务获得消息任务的属性信息，根据所述属性信息进行消息提示数据的更新。

可选地，所述消息提示数据的更新方法，还包括：所述消息任务采用树型结构中的节点路径表示。

可选地，所述的消息提示数据的更新包括：子节点路径消息提示数据的更新及父节点路径消息提示数据的更新，所述根据所述属性信息进行消息提示数据的更新的步骤，包括：

获得子节点路径对应的消息提示数据的更新数据，根据父节点路径中所有子节点路径的更新数据更新父节点路径的消息提示数据。

可选地，所述父节点路径中所有子节点路径的更新数据更新父节点路径的消息提示数据的步骤，包括：

根据路径信息确定父节点路径下所有子节点路径；

获得所述所有子节点路径的消息提示数据的更新数据，结合子节点路径当前的消息提示数据获得子节点路径的消息提示数据；

累加所述子节点路径的消息提示数据获得父节点路径的消息提示数据。

可选地，所述根据所述属性信息进行消息提示数据的更新的步骤，包括：

若消息任务的属性信息是接收到新消息，获得该消息任务的路径，该消息路径对应的消息提示数据为当前消息提示数据加一；

若消息任务的属性信息是未读消息展示，根据该消息任务的路径获得当前时刻该路径对应的消息提示数据，该消息路径对应的消息提示数据为零。

可选地，所述获得所述所有子节点路径的消息提示数据的更新数据的步骤之前，还包括：

启动对消息任务的监听，获得该消息任务对应的节点路径及树节点，并将该消息任务展示于交互界面上。

可选地，所述缓存队列为非阻塞队列，所述非阻塞队列包括：Handler+HandlerThread、ConcurrentLinkedQueue中的任一种。

可选地，所述消息提示数据的更新方法，还包括：自定义所述消息提示的展示属性，所述展示属性包括：消息提示的展示方式、展示位置、展示形状、展示颜色、展示状态中的至少一种。

进一步地，本申请实施例还提供了一种消息提示的控制装置，包括：

接收模块，用于接收表征对消息进行处理操作的消息任务；

存储模块，用于按照时间顺序将所述消息任务存储于缓存队列中；

更新模块，用于依次提取缓存队列中的消息任务，解析所述消息任务获得消息任务的属性信息，根据所述属性信息进行消息提示数据的更新。

更进一步地，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机指令，当其在计算机上运行时，使得计算机执行上述任意一项技术方案所述的消息提示数据的更新方法的步骤。

更进一步地，本申请实施例还提供了一种计算机设备，所述计算机设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上述任意一技术方案所述的消息提示数据的更新方法的步骤。

与现有技术相比，本申请提供的方案至少具备如下优点：

本申请实施例提供的消息提示数据的更新方法，通过采用消息队列的形式将消息任务存储与缓存队列中，依次提取并处理缓存队列中的消息任务，来进行消息提示数据的更新，该种任务队列的形式能够保证消息提示逻辑执行的有序性，避免多线程并发问题。

本申请实施例提供的消息提示数据的更新方法，通过属性结构的节点路径表征消息任务，通过定义各消息任务对应页面层次的路径，能够便于依据该路径构建树型结构，进而同一管理路径节点的状态变化。

本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明一个实施例提供的消息提示数据的更新方法的流程示意图；

图2为本发明一个实施例提供的消息提示在交互界面上的展示示意图；

图3为本发明一个实施例提供的根据所述属性信息进行消息提示数据的更新的步骤的流程示意图；

图4为本发明另一个实施例提供的消息提示数据的更新方法的执行过程示意图；

图5为本发明一种实施例提供的消息提示的控制装置的结构示意图；

图6为本申请一种实施例提供的消息提示数据的更新方法的应用环境示意图；

图7为本发明一种实施例提供的计算机设备的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。

可以理解，本发明所使用的术语“第一”、“第二”等可在本文中用于描述各种元件，但这些元件不受这些术语限制。这些术语仅用于将第一个元件与另一个元件区分。举例来说，在不脱离本发明的范围的情况下，可以将第一直播视频图像称为第二直播视频图像，且类似地，可将第二直播视频图像称为第一直播视频图像。第一直播视频图像和第二直播视频图像两者都是直播视频图像，但其不是同一个直播视频图像。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

本技术领域技术人员可以理解，这里所使用的执行服务器既包括无线信号接收器的设备，其仅具备无发射能力的无线信号接收器的设备，又包括接收和发射硬件的设备，其具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备；PCS(Personal Communications Service，个人通信系统)，其可以组合语音、数据处理、传真和/或数据通信能力；PDA(Personal Digital Assistant，个人数字助理)，其可以包括射频接收器、寻呼机、互联网/内联网访问、网络浏览器、记事本、日历和/或GPS(Global Positioning System，全球定位系统)接收器；常规膝上型和/或掌上型计算机或其他设备，其具有和/或包括射频接收器的常规膝上型和/或掌上型计算机或其他设备。这里所使用的客户端可以是便携式、可运输、安装在交通工具(航空、海运和/或陆地)中的，或者适合于和/或配置为在本地运行，和/或以分布形式，运行在地球和/或空间的任何其他位置运行。

本申请实施例中使用到的部分名词释义如下：

树结构：一种数据结构，由n(n>＝1)个有限节点组成一个具有层次关系的集合。非阻塞队列：特指异步以及队列式处理任务的数据结构形式。消息提示：指用于桌面或应用程序的功能项上显示的用于提示用户有新内容的人机界面展示。并发问题：在多线程并发的环境下，同一个线程的多个操作在不同的CPU时间片上执行，若中间出现停滞，后面的操作在执行时可能某个共享数据被其他线程修改，而该修改并未同步到当前线程中，导致当前线程操作的数据与实际不符的问题。监听函数用于监听播放器的状态用以做出回应。本发明首先提供了一种消息提示数据的更新方法，其流程示意图如图1所示，包括如下步骤：

S110，接收表征对消息进行处理操作的消息任务；

S120，按照时间顺序将所述消息任务存储于缓存队列中；

S130，依次提取缓存队列中的消息任务，解析所述消息任务获得消息任务的属性信息，根据所述属性信息进行消息提示数据的更新。

本申请实施例所述的消息任务是指对接收到的消息进行的某种操作，如接收到一则新消息，在交互界面上展示消息等操作。所述消息任务的属性信息包括：新消息、消息任务的路径信息等。

举例阐释本申请提供的方案：当前接收到两个消息任务，按照接收消息任务的时间顺序将这两个消息任务存储于缓存队列中，从缓存队列的出口端提取缓存队列中的消息任务，解析消息任务获得消息任务的属性信息，消息任务的属性信息包括：新消息、消息展示、消息任务的路径信息，若消息任务是接收到一则新消息，所述属性信息中还包括消息任务的路径，在该路径对应的消息提示数据的基础上增加1，即获得消息提示数据的增加值，若消息任务是未读消息展示，则根据该消息任务的路径获得该路径的第一消息提示数据，所述第一消息提示数据为消息提示数据的减少值，将当前路径对应的消息展示于交互界面上，并将该路径的消息提示数据减去第一消息任务数据获得当前时刻对应的消息任务数据，由于当前消息任务执行结束之前，并不会执行其他消息任务，因此当前消息任务执行之后，该节点路径对应的消息提示数据为零。

本申请实施例提供的方案，将消息任务存储于缓存队列中，每个消息任务通过队列进行串行处理，避免了异步处理过程中可能会遇到的并发问题，保证消息提示数据进行有序变化，获得准确的消息提示数据。

本申请实施例提供的方案可应用于需要显示数字或红点提示的应用程序中，本方案能够管理具有复杂层级关系的红点模块功能，根据业务需求显示不同样式的提示界面，如提示提示是红点还是数字，消息提示的位置、形状、颜色等。消息提示显示于应用程序的顶部与底部具有不同的层级，如可以在子节点路径的页面的消息提示设置于顶部，属于下级节点，父节点路径的页面的消息提示设置于底部，属于上级节点，该种情况下的界面显示如图2所示，子节点可控制父节点的消息提示的显隐状态，若子节点的消息提示为零，此时父节点的消息提示的数量可以为隐匿状态。若子节点的消息提示不为零，此时父节点的消息提示状态为显示状态。

鉴于应用程序内页面的层级关系，消息提示也需要表现出层级关系，且不同层级之间的消息提示的显示数量和显示状态是相互关联，基于该种考虑，本申请实施例提供的方案采用树型结构处理，不同页面层级关系采用节点路径来表示。消息提示的方式包括：红点提示或数字提示。每个节点都对应设有自己的节点路径，本方案使用“root.x.y”的形式来进行指明节点全路径，前面的”root.x”表示父节点路径，后面的”y”则代表本节点的值。通过定义对应页面层次的路径，以便根据路径构建层次树，进而统一管理路径节点值的变化，即统一管理各路径的消息提示数据的变化。

本申请实施例提供的缓存队列为非阻塞队列，且优先采用HandlerThread+Handler或ConcurrentLinkedQueue的非阻塞队列的方式进行实现。HandlerThread+Handler是一种组合类型的非阻塞队列，负责安卓系统中消息的分发，且在处理耗时操作时，专门开设一个线程处理该耗时操作，本申请中利用该种机制专门开设了进行消息提示的控制线程。ConcurrentLinkedQueue是一个基于链表实现的无界线程安全队列，ConcurrentLinkedQueue的线程安全是通过其插入、删除时采取CAS(Compare-And-Swap,比较和替换)操作来保证的，不会出现同一个尾部节点的next指针被多个同时插入的结点所抢夺的情况出现。据此保证队列线程处理并发问题及保证执行过程的有序性。

本申请优选采用HandlerThread+Handler非阻塞队列的形式，以避免使用ConcurrentLinkedQueue带来的相对更繁琐处理流程。对于开发者来说，采用HandlerThread+Handler非阻塞队列的形式能够降低出错率，且处理流程相对简便。

一种实施例中，所述的消息提示数据的更新包括：子节点路径提示数据的更新及父节点路径消息提示数据的更新，根据所述属性信息进行消息提示数据的更新的步骤，其流程示意图如图3所示，包括如下子步骤：

S310，根据路径信息确定父节点路径下所有子节点路径；

S320，获得所述所有子节点路径的消息提示数据的更新数据，结合子节点路径当前的消息提示数据获得子节点路径的消息提示数据；

S330，累加所述子节点路径的消息提示数据获得父节点路径的消息提示数据。

根据上述实施例获得子节点路径对应的消息提示数据的更新数据，根据树型结构的路径信息获得某一父节点路径下的所有子节点路径，结合子节点路径当前的消息提示数据获得子节点路径的消息提示数据，再根据父节点路径中所有子节点路径的更新数据更新父节点路径的消息提示数据。由于父节点路径是子节点路径的上级节点，其更新数据是子节点路径的所有更新数据之和，如父节点路径由2个子节点路径甲、乙组成，甲、乙消息提示数据的更新数据分别为+1和-2，即甲节点路径接收到一则新消息，乙节点路径展示当前消息，甲、乙在当前消息任务之前的消息提示数据分别为3和2，则执行当前接收到的消息任务后，甲、乙节点的消息提示数据分别为4和0，则其二者的父节点的消息提示数据为4，为甲、乙当前的消息提示数据之和，本申请实施例提供的方案只需获得父节点路径下所有子节点路径的消息提示数据，经过简单地计算即可获得父节点路径的消息提示数据的更新数据，降低系统资源的消耗。

一种实施例中，消息提示数据的更新方法的执行过程如图4所示，所有的消息任务经由Handler+HandlerThread变成异步队列处理，消息任务的处理在Thread构建的线程中进行，并不占用主线程资源，因此并不会造成线程堵塞。首先建立消息任务的监听视图及对应路径，根据消息任务的节点路径构建对应的树节点，完成之后通知交互界面绑定操作。通过路径绑定，能够将消息任务的处理结果反映到页面上，若不绑定路径，有消息的更新时无法在页面上显示。该步骤完成消息任务的路径创建，将消息任务的监听函数绑定到指定路径节点上。

完成路径创建之后，根据消息任务的属性信息进行消息任务的状态更新，调用方通过解析消息任务的属性信息，获得其消息任务类型及节点路径，将该节点路径的消息提示数据通知发送至红点管理模块，红点管理模块接收到消息提示数据的更新数据，确定该节点路径对应的消息提示数据，根据父节点下所有子节点路径对应的消息题述数据获得父节点路径的消息提示数据，并发送所有节点路径的消息提示数据的通知至交互界面进行更新，并发回异步回调路径节点变化的通知。该过程可以根据业务需要更新指定路径节点的消息提示数据的数量，该操作变化会影响父节点路径的消息提示数据的刷领，并更新当前节点绑定视图，以及通知绑定的监听函数。

完成上述操作之后，进行解除绑定操作，过程如下：接收到关闭当前展示界面的指令，发送解绑操作指令，解绑、销毁对应路径的视图，查找并移除该路径对应的节点，同时递归更新父路径节点的节点状态，并将操作结果通知至交互界面执行解绑操作。该步骤完成部分节点路径的移除，解除上述已经绑定到指定路径的视图以及监听函数。

当路径节点的消息提示数据发生变化时，通过该节点对应的视图更新IBadgeView动态地更新要显示提示视图的当前状态。当第三方调用IBadgeView时，只需要传入实现该接口的处理逻辑，后续的视图变化全部交由管理器负责，最大限度地简化调用层实现的繁琐程度。

本申请实施例提供的方案还提供了一种基本的消息提示的交互界面接口，即上述的视图更新，如上所述，第三方需调用视图更新时，只需要传入实现该接口的处理逻辑，简化了消息提示状态的交互实现逻辑，便于后续对该技术的扩展和维护。

本申请实施例能够自定义消息提示的展示属性，所述展示属性包括：消息提示的展示方式、展示位置、展示形状、展示颜色、展示状态等等，所述展示方式如静止或动态展示，展示位置如应用程序的任一上下左右，展示形状如圆点、方形等，展示位置为红色、黄色等，展示状态如隐匿或显示。当然，也可以采用默认的形式展示属性来展示消息提示。

本申请实施例提供自定义的形式展示消息提示的展示属性，能够使消息提示的展示形式更加灵活和个性化，提升用户体验。

进一步地，本申请实施例还提供了一种消息提示的控制装置，包括如下模块：接收模块510、存储模块520、更新模块530，其结构示意图如图5所示,

接收模块510，用于接收表征对消息进行处理操作的消息任务；

存储模块520，用于按照时间顺序将所述消息任务存储于缓存队列中；

更新模块530，用于依次提取缓存队列中的消息任务，解析所述消息任务获得消息任务的属性信息，根据所述属性信息进行消息提示数据的更新。

其中，更新模块530，还包括确定子节点路径单元、获得子节点路径的消息提示数据单元、获得父节点路径的消息提示数据单元，具体如下：

确定子节点路径单元，被配置为根据路径信息确定父节点路径下所有子节点路径；

获得子节点路径的消息提示数据单元，被配置为获得所述所有子节点路径的消息提示数据的更新数据，结合子节点路径当前的消息提示数据获得子节点路径的消息提示数据；

获得父节点路径的消息提示数据单元，被配置为累加所述子节点路径的消息提示数据获得父节点路径的消息提示数据。

关于上述实施例中的消息提示的控制装置，其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图6为本申请实施例提供的消息提示数据的更新方法的应用环境示意图，服务器端接收到其他终端发送到当前用户端的消息任务，将该消息任务存储于缓存队列中，依次处理缓存队列中各消息任务，根据消息任务的属性更新消息提示数据的更新，并将提示数据的更新指令及更新数据下发给对应客户端，客户端根据更新指令及更新数据进行消息提示数据的更新。举例说明，服务器依次接收到同一用户端发送到当前用户端的2条新消息，则按照时间顺序建立两个消息任务，将发送端用户对应的消息栏的提示数据加1，发送更新指令及更新数据至当前用户终端，再处理下一个消息任务，这种顺序操作能够避免程序在运行过程中数据的更新混乱问题。

更进一步地，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机指令，该计算机指令被处理器执行时实现上述任意一项所述的消息提示数据的更新方法的步骤。其中，所述存储介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory，只读存储器)、RAM(Random AcceSS Memory，随即存储器)、EPROM(EraSable Programmable Read-Only Memory，可擦写可编程只读存储器)、EEPROM(Electrically EraSable Programmable Read-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，存储介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。可以是只读存储器，磁盘或光盘等。

更进一步地，本申请实施例还提供一种计算机设备，所述计算机设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任意一项所述的消息提示数据的更新方法。

图7是根据一示例性实施例示出的一种用于计算机设备700的框图。例如，计算机设备700可以被提供为一服务器。参照图7，计算机设备700包括处理组件722，其进一步包括一个或多个处理器，以及由存储器732所代表的存储器资源，用于存储可由处理组件722的执行的指令，例如应用程序。存储器732中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件722被配置为执行指令，以执行上述消息提示数据的更新方法的步骤。

计算机设备700还可以包括一个电源组件726被配置为执行计算机设备700的电源管理，一个有线或无线网络接口750被配置为将计算机设备700连接到网络，和一个输入输出(I/O)接口758。计算机设备700可以操作基于存储在存储器732的操作系统，例如WindowsServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

应该理解的是，在本发明各实施例中的各功能单元可集成在一个处理模块中，也可以各个单元单独物理存在，也可以两个或两个以上单元集成于一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (9)

1.一种消息提示数据的更新方法，其特征在于，包括：

接收表征对消息进行处理操作的消息任务；所述消息任务采用树型结构中的节点路径表示；

按照时间顺序将所述消息任务存储于缓存队列中；

通过专用线程启动对消息任务的监听，获得该消息任务对应的节点路径及树节点，并将该消息任务通过路径绑定之后展示于交互界面上；

依次提取缓存队列中的消息任务，解析所述消息任务获得消息任务的属性信息，根据所述属性信息进行消息提示数据的更新；

任一消息任务对应的展示界面关闭之后，对该消息任务对应的节点路径及树节点执行解绑操作之后再展示于交互界面上。

2.根据权利要求1所述的消息提示数据的更新方法，其特征在于，所述的消息提示数据的更新包括：子节点路径消息提示数据的更新及父节点路径消息提示数据的更新，所述根据所述属性信息进行消息提示数据的更新的步骤，包括：

获得子节点路径对应的消息提示数据的更新数据，根据父节点路径中所有子节点路径的更新数据更新父节点路径的消息提示数据。

3.根据权利要求2所述的消息提示数据的更新方法，其特征在于，所述父节点路径中所有子节点路径的更新数据更新父节点路径的消息提示数据的步骤，包括：

根据路径信息确定父节点路径下所有子节点路径；

获得所述所有子节点路径的消息提示数据的更新数据，结合子节点路径当前的消息提示数据获得子节点路径的消息提示数据；

累加所述子节点路径的消息提示数据获得父节点路径的消息提示数据。

4.根据权利要求3所述的消息提示数据的更新方法，其特征在于，所述根据所述属性信息进行消息提示数据的更新的步骤，包括：

若消息任务的属性信息是接收到新消息，获得该消息任务的路径，该消息路径对应的消息提示数据为当前消息提示数据加一；

若消息任务的属性信息是未读消息展示，根据该消息任务的路径获得当前时刻该路径对应的消息提示数据，该消息路径对应的消息提示数据为零。

5.根据权利要求1所述的消息提示数据的更新方法，其特征在于，所述缓存队列为非阻塞队列，所述非阻塞队列包括：Handler+HandlerThread、ConcurrentLinkedQueue中的任一种。

6.根据权利要求1所述的消息提示数据的更新方法，其特征在于，还包括：

自定义所述消息提示的展示属性，所述展示属性包括：消息提示的展示方式、展示位置、展示形状、展示颜色、展示状态中的至少一种。

7.一种消息提示的控制装置，其特征在于，包括：

接收模块，用于接收表征对消息进行处理操作的消息任务；所述消息任务采用树型结构中的节点路径表示；

存储模块，用于按照时间顺序将所述消息任务存储于缓存队列中；

更新模块，用于通过专用线程启动对消息任务的监听，获得该消息任务对应的节点路径及树节点，并将该消息任务通过路径绑定之后展示于交互界面上；依次提取缓存队列中的消息任务，解析所述消息任务获得消息任务的属性信息，根据所述属性信息进行消息提示数据的更新；任一消息任务对应的展示界面关闭之后，对该消息任务对应的节点路径及树节点执行解绑操作之后再展示于交互界面上。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机指令，当其在计算机上运行时，使得计算机执行上述权利要求1至6中任意一项所述的消息提示数据的更新方法的步骤。

9.一种消息提示数据的更新设备，其特征在于，所述消息提示数据的更新设备包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1至6中任意一项所述的消息提示数据的更新方法的步骤。