CN110069174A - 一种消息处理的方法及装置 - Google Patents

Abstract

本申请实施例公开了一种消息处理的方法及装置。所述方法包括：统计推送消息的未读状态持续时长；当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。利用本申请各个实施例，可以分别设置各个推送消息的保留时长，避免在一段时间后暴力清除所有未读推送消息的未读提示。另外，当所述推送消息的未读状态持续时长超过所述保留时长时，可以清除针对所述推送消息的未读提示，从根本上解决了现有技术中只限于提醒而不清除消息未读提示的技术问题。不仅可以消除推送消息对用户分辨应用内有用消息的干扰，还可以提升用户界面的整洁性和美观性。

Description

一种消息处理的方法及装置

技术领域

本申请涉及数据处理技术领域，特别涉及一种消息处理的方法及装置。

背景技术

近年来，随着智能设备的普及，各类功能强大的应用(Application，APP)也应运而生。应用内消息的推送也成为应用运营商对用户的引导、营销等手段之一。应用内推送的部分消息的确可以对用户产生积极的引导作用，例如，在支付应用中，若用户账户中产生消费、转账等事件时，应用可以及时地向用户推送消费消息。用户可以在账户产生消费时，第一时间了解状况。但是，应用内推送的很多消息属于应用内的营销消息，如广告推送、订阅号内容推送等。在此情况下，大部分应用中设置下述机制：当用户未点击阅读应用内推送的消息时，则会在应用中的消息提醒处设置消息未读提示(如一个点、一个数字等)，甚至在应用处于退出状态时，在应用图标上设置消息未读提示(如角标)。

基于上述机制，可以发现，如果用户一直未点击应用内的消息，则所述消息未读提示一直存在于应用内消息提醒处或者应用图标上。对于用户来说，用户分不清应用内推送的消息是具有引导作用的消息，还是不具实际意义的营销消息。并且，一直不能消除的消息未读提示可能影响用户界面的美观性。

因此，现有技术中亟需一种能够去除应用中消息未读提示的方法。

发明内容

本申请实施例的目的在于提供一种消息处理的方法及装置，不仅可以消除推送消息对用户分辨应用内有用消息的干扰，还可以提升用户界面的整洁性和美观性。

本申请实施例提供的一种消息处理的方法及装置具体是这样实现的：

一种消息处理的方法，包括：

统计推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。

一种消息处理的方法，包括：

获取针对目标用户的推送消息；

获取所述推送消息的消息类型和/或所述目标用户的历史行为数据；

根据所述消息类型和/或所述历史行为数据设置所述推送消息的保留时长；

当所述推送消息的未读状态持续时长超过所述保留时长时，清除针对所述推送消息的未读提示。

一种消息处理的装置，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

统计推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。

一种消息处理的装置，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

获取针对目标用户的推送消息；

获取所述推送消息的消息类型和/或所述目标用户的历史行为数据；

根据所述消息类型和/或所述历史行为数据设置所述推送消息的保留时长；

当所述推送消息的未读状态持续时长超过所述保留时长时，清除针对所述推送消息的未读提示。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现以下步骤：

统计推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现以下步骤：

获取针对目标用户的推送消息；

获取所述推送消息的消息类型和/或所述目标用户的历史行为数据；

根据所述消息类型和/或所述历史行为数据设置所述推送消息的保留时长；

当所述推送消息的未读状态持续时长超过所述保留时长时，清除针对所述推送消息的未读提示。

一种移动设备消息处理方式，包括：

在移动设备上显示用于推送消息的未读提示；

确定所述推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除所述未读提示。

本申请提供的消息处理方法及装置，可以统计应用内推送消息的未读状态持续时长。当所述未读状态持续时长超过保留时长时，可以清除针对所述推送消息的未读提示。与现有技术中清除消息未读提示的方式相比，本申请各个实施例提供的消息处理方法可以分别设置各个推送消息的保留时长，避免在一段时间后暴力清除所有未读推送消息的未读提示。另外，当所述推送消息的未读状态持续时长超过所述保留时长时，可以清除针对所述推送消息的未读提示，从根本上解决了现有技术中只限于提醒而不清除消息未读提示的技术问题。不仅可以消除推送消息对用户分辨应用内有用消息的干扰，还可以提升用户界面的整洁性和美观性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请提供的应用场景示意图；

图2是本申请提供的应用场景示意图；

图3是本申请提供的应用场景示意图；

图4是本申请提供的消息处理方法的一个实施例的流程示意图；

图5是本申请提供的消息处理装置的一个实施例的模块结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

为了方便本领域技术人员理解本申请实施例提供的技术方案，下面先对技术方案实现的技术环境进行说明。

如上所述，应用内的消息未读提示不仅对于用户分辨应用内必要消息和有用消息具有干扰作用，另外，消除不了的消息未读提示还会影响用户界面的整洁性和美观性。针对上述问题，现有技术中具有几种处理方式。第一种方式是获取应用中接收到的所有未读消息，判断获取的未读消息是否为公众类消息。若所述未读消息均为公众类消息，则将所有的未读消息设置为已读状态，并清除相应消息的未读提示。第二种方式是当应用中有未读消息时，可以在应用界面被展示时，触发展示提醒通知，以提醒用户阅读应用中的未读消息。根据上述两种方式的描述，第一种方式在无论未读消息重要性的情况下，暴力清除所有未读消息。对于部分用户来说，其中的一些公众类消息可能是用户经常关注的内容，如果清除所有公众类消息，可能会对部分用户产生不良的影响。第二种方式中，虽然对用户进行了阅读提醒，但是并不能从根本上解决问题，即消除不了消息未读提示。

基于类似于上文所述的实际技术需求，本申请提供的消息处理方式，不仅可以消除推送消息对用户分辨应用内有用消息的干扰，还可以提升用户界面的整洁性和美观性。

下面通过一个具体的应用场景具体说明本申请消息处理方法的实现方式。

如图1是用户小明的客户端展示的用户界面，在该用户界面展示了多个应用的图标，通过点击图标可以访问对应的应用。如图1所示，当应用中存在未读推送消息时，可以在相应应用的图标上设置未读标志，如图1中的角标，该角标不仅可以标识该应用中具有未读推送消息，还可以标识该应用中未读推送消息的个数。例如，应用2中有1条未读推送消息，应用4中有6条未读推送消息，应用6中有3条未读推送消息。点击应用4的图标后，进入应用4的主界面。如图2所示，在应用4的主界面还包括多个子控件，且各个子控件具有对应的图标。同样地，通过点击图标，可以进入与子控件相对应的用户界面。如图2所示，当应用4中有未读推送消息时，在“消息”子控件的图标上设置有未读标志(如图标右上角的黑点)。点击“消息”图标之后，进入如图3所示的消息主界面。图3展示了多个推送消息，其中，未读推送消息之前设置有点状的未读标志。在展示的多个未读推送消息中，有通知类消息，如账户通知类消息“您的账户于2018年1月17日……”，也有优惠促销类消息“新年大促，全场五折封顶，……”，订单类消息“您的订单(238765466)……”等。

利用本实施例的实施方式，可以对上述推送消息设置保留时长，若从客户端接收到所述推送消息至所述保留时长内小明未阅读所述推送消息时，可以清除所述推送消息的未读标志。例如，当应用4接收到服务器发送的推送消息时，可以识别所述推送消息的标识信息。例如图3中最近一条的账户变动消息，对于此类消息，由于对用户来说比较重要，不需要清除未读标志。而对于一些优惠促销类消息，如消息“新年大促，全场五折封顶，……”和“[XX牛肉]您收藏的牛腩降价啦！……”，根据用户小明一段时间的历史行为数据，可以发现，小明几乎不查看此类消息。基于此，可以设置针对小明的优惠促销类消息的保留时长稍短一点，如4小时，若超过4小时，小明未阅读消息，则清除消息的未读标志。而对于订单类消息，如“您的订单(238765466)……”等，根据用户小明一段时间的历史行为数据，可以发现，小明查看此类消息的平均时长为从客户端接收到消息的6小时内。基于此，可以设置针对小明的订单类消息的保留时长为8小时，若超过8小时，小明未阅读消息，则清除消息的未读标志。

另外，对于推送消息“您的订单(238765466)已签收”和“您的订单(238765466)正在派送，请注意查收”，由于上述两条推送消息均属于订单类消息，且属于同一订单(订单编号一致)的推送消息。由于推送消息“您的订单(238765466)正在派送，请注意查收”在前收到，推送消息“您的订单(238765466)已签收”在后收到。也就是说，当收到第二条推送消息的时候，针对第一条推送消息的定时器已经启动。例如，在第一条推送消息已经计时4小时时接收到第二条推送消息，此时，为了防止多条同类型消息使用多个定时器计时，浪费客户端资源，可以将同类型的消息使用同一定时器进行统一计时。例如，本场景中，可以将上述两条订单类推送消息进行统一计时，如从接收第二条推送消息开始计时，如超过8小时，小明均未读上述两条消息，可以清除这两条消息的未读标志。

下面结合附图4对本申请所述的消息处理的方法进行说明。图4是本申请提供的消息处理方法的一种实施例的方法流程示意图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑性上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。所述方法在实际中的消息处理过程中，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

具体的本申请提供的标签预测方法的一种实施例如图1所示，所述方法可以包括：

S401：统计所述推送消息的未读状态持续时长。

S403：当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。

本实施例中，所述推送消息可以包括多种消息类型。例如，在大部分应用中，应用中的推送消息可以包括系统推送的通知类消息，还可以包括应用所在平台上各个商家的营销类推送消息，如广告推送消息、订阅推送消息等非通知类消息。其中，系统推送的通知类消息对用户来说，具有较高的重要程度，如涉及到用户账号安全、重要通知、银行账户交易提醒等推送消息。例如，对于一些支付应用，若用户账户中产生消费或者转账，所述支付应用一般会向用户推送通知类消息，以通知用户账户产生变动。而对于另外一些营销类推送消息，对于用户来说，其中大部分是不必要的推送消息，若长时间不清除此类消息的未读提示，可能对用户产生干扰。基于此，在本申请的一个实施例中，可以统计推送消息的未读状态持续时长。当所述未读状态持续时长超过保留时长时，可以清除针对所述推送消息的未读提示。

在本申请的一个实施例中，可以保留通知类消息的未读提示，只针对非通知类消息进行未读提示清除。具体地，所述通知类消息和/或非通知类消息可以具有标识信息。在本申请的一个实施例中，服务器在生成所述推送消息时，可以在所述推送消息中添加所述推送消息的标识信息，以标注所述推送消息是否为通知类消息。基于此，当客户端接收到推送消息时，可以获取所述推送消息的标识信息，并根据所述标识信息判断所述推送消息是否通知类消息，若判断结果为否，则可以触发开始统计所述推送消息的未读状态持续时长。

本实施例中，在统计所述推送消息的未读状态持续时长的过程中，可以在所述推送消息所在的应用内设置针对所述推送消息的未读提示。所述未读提示可以包括设置于应用图标上的数字(表示未读消息的数量)、点、角标、文字等任意形式的标识，本申请对此不做限制。本实施例中，由于需要统计所述推送消息的未读状态持续时长，因此，可以设置定时器，且设置当所述定时器的定时时长达到保留时长时，发送定时提醒。其中，所述定时器可以由应用本身内部实现，还可以由应用调用外部环境，如客户端的操作系统实现，本申请在此不做限制。本实施例中，可以在应用从服务器接收到所述推送消息的时刻，或者，确定所述推送消息为非通知类消息的时刻，触发启动所述定时器。

如上所述，当所述推送消息的未读状态持续时长超过所述保留时长时，清除针对所述推送消息的未读提示。在本申请的一个实施例中，所述保留时长可以根据所述推送消息的消息类型进行设置。基于以上所述，应用中可以包括通知类消息与非通知类消息，其中，所述非通知类消息还可以具有多种消息类型。例如，对于购物应用来说，所述非通知类消息往往可以包括营销类推送消息、优惠活动类推送消息、订单类推送消息等等。上述各个类别的推送消息中，营销类推送消息的保留时长往往需要比优惠活动类推送消息的保留时长要久一点。当然，所述保留时长还可以根据广告截止日期、优惠活动截止日期等信息进行设置。具体地，可以根据所述推送消息类型的业务要求进行设置，对此，本申请不做限制。

需要说明的是，对于具有相同消息类型的推送消息，可以使用同一定时器产生定时提醒。在实际应用中，应用平台每天发送给用户的推送消息数量较多，若给每个消息设置一个定时器，则将消耗较多的计算资源，增大客户端的资源消耗率。因此，在本申请中，可以设置针对相同类型的推送消息的定时器使用同一定时器，由上述实施例可知，具有相同类型的推送消息可以设置相同的保留时长，那么，利用同一定时器对相同类型的推送消息定时，也可以保持定时器的定时时长的统一性。例如营销类推送消息使用同一定时器，优惠活动类推送消息使用同一定时器。

用户对不同的推送消息具有不同的关注程度。例如在某理财应用中，应用平台经常向A、B等多个用户推送各种股票、基金等理财产品的广告信息、订阅信息。经统计，其中，用户A经常关注股票类的订阅信息，用户B经常关注基金类的订阅信息。由此可见，不同的用户对于推送消息的关注程度不相同。基于此，在本申请的另一个实施例中，所述保留时长还可以根据所述推送消息所针对目标用户的历史行为数据设置。其中，所述历史行为数据可以包括下述中的至少一种：

所述目标用户在从接收至查看与所述推送消息具有相同消息类型的历史推送消息时所需的时长；

所述目标用户查看与所述推送消息具有相同消息类型的历史推送消息的频繁程度。

本实施例中，在用户的历史行为数据中，可以记录用户对各种类型的推送消息的访问数据，所述访问数据可以包括访问时间、所访问的推送消息类型等等。用户在接收推送消息至查看所述推送消息往往具有时间间隔，基于此，在本实施例中，可以获取目标用户在从接收至查看与所述推送消息具有相同消息类型的历史推送消息时所需的时长。然后，可以根据所述时长，确定所述推送消息的保留时长。在一个示例中，可以根据获取的多个历史推送消息对应的多个时长，统计得到所述目标用户查看所述消息类型的推送消息所需的平均时长。在获取所述平均时长之后，可以根据所述平均时长设置所述推送消息的保留时长。例如，在一个示例中，若统计得到用户A在接收至查看订单类历史推送消息平均耗时为4小时，基于此，所述保留时长可以根据所述平均耗时进行设置，例如所述保留时长可以设置为4.5小时，即若订单类推送消息推送给用户A之后，若用户A在4.5小时之内一直未查看此类推送消息，则可以清除订单类推送消息的未读标志。

在本实施例中，所述保留时长还可以根据所述目标用户查看与所述推送消息具有相同消息类型的历史推送消息的频繁程度设置。例如，在用户A的历史行为数据中，在向用户A推送营销类推送消息之后，用户A几乎不查看此类推送消息。基于此，可以设置向A推送的营销类推送消息的保留时长比较短暂，这样，在一段时间之后，可以清除营销类推送消息的未读提醒，避免给用户A造成干扰。

本实施例中，在所述定时器被启动且所述推送消息被发布之后，客户端可以监视所述推送消息的状态，即已读和未读。若客户端监测到所述推送消息的状态由未读变成已读，则停止所述定时器的计时。当所述定时器的定时时长达到所述保留时长时，可以发送定时提醒。客户端在接收到所述定时提醒时，可以响应于所述定时提醒，判断所述推送消息是否为未读状态。若判断结果为所述推送消息为未读状态时，可以确定所述推送消息的未读状态持续时长超过保留时长，并清除针对所述推送消息的未读提示。

在本申请的一个实施例中，有可能在所述保留时长之内再次发送与所述推送消息具有相同消息类型的第二推送消息。例如，对于用户的购物订单类推送消息，若第一条推送消息关于商品的派送信息，保留时长设置为5小时。在针对第一条推送消息的定时器定时3小时的时刻，产生第二条推送消息，所述第二条推送消息关于同一商品的签收信息。此时，所述第二条推送消息的接收时刻位于第一条推送消息的保留时长之内。可以发现，所述第一条推送消息与所述第二条推送消息属于同一个商品订单的推送消息。针对上述应用场景，本实施例中，当第二推送消息与在此之前的第一推送消息属于同一类型，且所述第一推送消息还处于未读状态时，可以重新统计所述推送消息的未读状态持续时长，使得所述推送消息与所述第二推送消息的统计步骤相一致。例如，在上述示例中，可以将第一条推送消息重新开始计时，且定时时长为5小时。或者，设置第二条推送消息的定时时长为2小时，与第一条推送消息的剩余定时时长一致。

本申请提供的消息处理方法，可以统计应用内推送消息的未读状态持续时长。当所述未读状态持续时长超过保留时长时，可以清除针对所述推送消息的未读提示。与现有技术中清除消息未读提示的方式相比，本申请各个实施例提供的消息处理方法可以分别设置各个推送消息的保留时长，避免在一段时间后暴力清除所有未读推送消息的未读提示。另外，当所述推送消息的未读状态持续时长超过所述保留时长时，可以清除针对所述推送消息的未读提示，从根本上解决了现有技术中只限于提醒而不清除消息未读提示的技术问题。不仅可以消除推送消息对用户分辨应用内有用消息的干扰，还可以提升用户界面的整洁性和美观性。

图5是本申请提供的消息处理装置的一种实施例的模块结构示意图，如图5所示，所述装置包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时可以实现：

统计推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。

可选的，在本申请的一个实施例中，所述保留时长可以根据所述推送消息的消息类型设置。

可选的，在本申请的一个实施例中，所述保留时长可以根据所述推送消息所针对目标用户的历史行为数据设置。

可选的，在本申请的一个实施例中，所述历史行为数据可以包括下述中的至少一种：

所述目标用户在从接收至查看与所述推送消息具有相同消息类型的历史推送消息时所需的时长；

所述目标用户查看与所述推送消息具有相同消息类型的历史推送消息的频繁程度。

可选的，在本申请的一个实施例中，所述处理器在实现步骤统计推送消息的未读状态持续时长时可以包括：

获取推送消息的标识信息；

根据所述标识信息判断所述推送消息是否为通知类消息；

若判断结果为否，则触发开始统计所述推送消息的未读状态持续时长。

可选的，在本申请的一个实施例中，所述处理器在实现步骤统计推送消息的未读状态持续时长时可以包括：

设置定时器，且当定时时长达到保留时长时，发送定时提醒；

在所述推送消息所在的应用内设置针对所述推送消息的未读提示。

可选的，在本申请的一个实施例中，所述处理器在实现步骤当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示时可以包括：

接收所述定时器的定时提醒；

响应于所述定时提醒，判断所述推送消息是否处于未读状态；

若判断结果为是，则清除针对所述推送消息的未读提示。

可选的，在本申请的一个实施例中，所述处理器在实现步骤所述统计所述推送消息的未读状态持续时长之后，还可以包括：

当所述未读状态持续时长不超过保留时长时，获取与所述推送消息针对相同目标用户的第二推送消息；

当确定所述第二推送消息与所述推送消息属于相同消息类型时，重新统计所述推送消息的未读状态持续时长，使得所述推送消息与所述第二推送消息的统计步骤相一致。

可选的，在本申请的一个实施例中，所述处理器在实现步骤清除针对所述推送消息的未读提示时可以包括：

删除设置在所述推送消息上的下述至少一种未读提示：数字、角标、文字。

本申请另一方面还提供消息处理装置的另一种实施例的模块结构示意图，所述装置包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时可以实现：

获取针对目标用户的推送消息；

获取所述推送消息的消息类型和/或所述目标用户的历史行为数据；

根据所述消息类型和/或所述历史行为数据设置所述推送消息的保留时长；

当所述推送消息的未读状态持续时长超过所述保留时长时，清除针对所述推送消息的未读提示。

可选的，在本申请的一个实施例中，所述处理器在实现步骤根据所述历史行为数据设置所述待推送消息的保留时长时可以包括：

获取所述目标用户的用户标识；

根据所述用户标识获取所述目标用户的历史行为数据，所述历史行为数据中包括所述目标用户在从接收至查看与所述推送消息具有相同消息类型的多个历史推送消息时所需的时长；

根据所述时长设置所述推送消息的保留时长。

可选的，在本申请的一个实施例中，所述处理器在实现步骤根据所述历史行为数据设置所述待推送消息的保留时长时可以包括：

获取所述目标用户的用户标识；

根据所述用户标识获取所述目标用户的历史行为数据，所述历史行为数据中包括所述目标用户查看与所述推送消息具有相同消息类型的历史推送消息的频繁程度；

根据所述频繁程度设置所述推送消息的保留时长。

本申请另一方面还提出一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时可以实现以下步骤：

统计推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。

本申请另一方面还提出一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时可以实现以下步骤：

获取针对目标用户的推送消息；

获取所述推送消息的消息类型和/或所述目标用户的历史行为数据；

根据所述消息类型和/或所述历史行为数据设置所述推送消息的保留时长；

当所述推送消息的未读状态持续时长超过所述保留时长时，清除针对所述推送消息的未读提示。

所述计算机可读存储介质可以包括用于存储信息的物理装置，通常是将信息数字化后再以利用电、磁或者光学等方式的媒体加以存储。本实施例所述的计算机可读存储介质有可以包括：利用电能方式存储信息的装置如，各式存储器，如RAM、ROM等；利用磁能方式存储信息的装置如，硬盘、软盘、磁带、磁芯存储器、磁泡存储器、U盘；利用光学方式存储信息的装置如，CD或DVD。当然，还有其他方式的可读存储介质，例如量子存储器、石墨烯存储器等等。

本申请另一方面还提供一种移动设备消息处理方法，所述方法可以包括：

在移动设备上显示用于推送消息的未读提示；

确定所述推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除所述未读提示。

尽管本申请内容中提到实施例中的深度学习方法、标签预测、数据统计等之类的数据学习、处理描述，但是，本申请并不局限于必须是完全符合行业编程语言设计标准或实施例所描述的数据展示、处理的情况。某些页面设计语言或实施例描述的基础上略加修改后的实施方案也可以实行上述实施例相同、等同或相近、或变形后可预料的实施效果。当然，即使不采用上数据处理的方式，只要符合本申请上述各实施例的数据学习、处理描述，仍然可以实现相同的申请，在此不再赘述。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，移动终端，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (27)

1.一种消息处理的方法，其特征在于，包括：

统计推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。

2.根据权利要求1所述的方法，其特征在于，所述保留时长根据所述推送消息的消息类型设置。

3.根据权利要求1所述的方法，其特征在于，所述保留时长根据所述推送消息所针对目标用户的历史行为数据设置。

4.根据权利要求3所述的方法，其特征在于，所述历史行为数据包括下述中的至少一种：

所述目标用户在从接收至查看与所述推送消息具有相同消息类型的历史推送消息时所需的时长；

所述目标用户查看与所述推送消息具有相同消息类型的历史推送消息的频繁程度。

5.根据权利要求1所述的方法，其特征在于，所述统计推送消息的未读状态持续时长包括：

获取推送消息的标识信息；

根据所述标识信息判断所述推送消息是否为通知类消息；

若判断结果为否，则触发开始统计所述推送消息的未读状态持续时长。

6.根据权利要求1所述的方法，其特征在于，所述统计推送消息的未读状态持续时长包括：

在所述推送消息所在的应用内设置针对所述推送消息的未读提示；

设置定时器，且当定时时长达到保留时长时，发送定时提醒。

7.根据权利要求6所述的方法，其特征在于，所述当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示包括：

接收所述定时器的定时提醒；

响应于所述定时提醒，判断所述推送消息是否处于未读状态；

若判断结果为是，则清除针对所述推送消息的未读提示。

8.根据权利要求1所述的方法，其特征在于，在所述统计推送消息的未读状态持续时长之后，所述方法还包括：

当所述未读状态持续时长不超过保留时长时，获取与所述推送消息针对相同目标用户的第二推送消息；

当确定所述第二推送消息与所述推送消息属于相同消息类型时，重新统计所述推送消息的未读状态持续时长，使得所述推送消息与所述第二推送消息的统计步骤相一致。

9.根据权利要求1所述的方法，其特征在于，所述清除针对所述推送消息的未读提示包括：

删除设置在所述推送消息上的下述至少一种未读提示：数字、角标、文字。

10.一种消息处理的方法，其特征在于，包括：

获取针对目标用户的推送消息；

获取所述推送消息的消息类型和/或所述目标用户的历史行为数据；

根据所述消息类型和/或所述历史行为数据设置所述推送消息的保留时长；

当所述推送消息的未读状态持续时长超过所述保留时长时，清除针对所述推送消息的未读提示。

11.根据权利要求10所述的方法，其特征在于，所述根据所述历史行为数据设置所述推送消息的保留时长包括：

获取所述目标用户的用户标识；

根据所述用户标识获取所述目标用户的历史行为数据，所述历史行为数据中包括所述目标用户在从接收至查看与所述推送消息具有相同消息类型的多个历史推送消息时所需的时长；

根据所述时长设置所述推送消息的保留时长。

12.根据权利要求10所述的方法，其特征在于，所述根据所述历史行为数据设置所述推送消息的保留时长包括：

获取所述目标用户的用户标识；

根据所述用户标识获取所述目标用户的历史行为数据，所述历史行为数据中包括所述目标用户查看与所述推送消息具有相同消息类型的历史推送消息的频繁程度；

根据所述频繁程度设置所述推送消息的保留时长。

13.一种消息处理的装置，其特征在于，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

统计推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。

14.根据权利要求13所述的装置，其特征在于，所述保留时长根据所述推送消息的消息类型设置。

15.根据权利要求13所述的装置，其特征在于，所述保留时长根据所述推送消息所针对目标用户的历史行为数据设置。

16.根据权利要求15所述的装置，其特征在于，所述历史行为数据包括下述中的至少一种：

所述目标用户在从接收至查看与所述推送消息具有相同消息类型的历史推送消息时所需的时长；

所述目标用户查看与所述推送消息具有相同消息类型的历史推送消息的频繁程度。

17.根据权利要求13所述的装置，其特征在于，所述处理器在实现步骤统计推送消息的未读状态持续时长时包括：

获取推送消息的标识信息；

根据所述标识信息判断所述推送消息是否为通知类消息；

若判断结果为否，则触发开始统计所述推送消息的未读状态持续时长。

18.根据权利要求13所述的装置，其特征在于，所述处理器在实现步骤统计推送消息的未读状态持续时长时包括：

设置定时器，且当定时时长达到保留时长时，发送定时提醒；

在所述推送消息所在的应用内设置针对所述推送消息的未读提示。

19.根据权利要求18所述的装置，其特征在于，所述处理器在实现步骤当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示时包括：

接收所述定时器的定时提醒；

响应于所述定时提醒，判断所述推送消息是否处于未读状态；

若判断结果为是，则清除针对所述推送消息的未读提示。

20.根据权利要求13所述的装置，其特征在于，所述处理器在实现步骤所述统计所述推送消息的未读状态持续时长之后，还包括：

当所述未读状态持续时长不超过保留时长时，获取与所述推送消息针对相同目标用户的第二推送消息；

当确定所述第二推送消息与所述推送消息属于相同消息类型时，重新统计所述推送消息的未读状态持续时长，使得所述推送消息与所述第二推送消息的统计步骤相一致。

21.根据权利要求13所述的装置，其特征在于，所述处理器在实现步骤清除针对所述推送消息的未读提示时包括：

删除设置在所述推送消息上的下述至少一种未读提示：数字、角标、文字。

22.一种消息处理的装置，其特征在于，包括处理器以及用于存储处理器可执行指令的存储器，所述处理器执行所述指令时实现：

获取针对目标用户的推送消息；

获取所述推送消息的消息类型和/或所述目标用户的历史行为数据；

根据所述消息类型和/或所述历史行为数据设置所述推送消息的保留时长；

当所述推送消息的未读状态持续时长超过所述保留时长时，清除针对所述推送消息的未读提示。

23.根据权利要求22所述的装置，其特征在于，所述处理器在实现步骤根据所述历史行为数据设置所述推送消息的保留时长时包括：

获取所述目标用户的用户标识；

根据所述用户标识获取所述目标用户的历史行为数据，所述历史行为数据中包括所述目标用户在从接收至查看与所述推送消息具有相同消息类型的多个历史推送消息时所需的时长；

根据所述时长设置所述推送消息的保留时长。

24.根据权利要求22所述的装置，其特征在于，所述处理器在实现步骤根据所述历史行为数据设置所述推送消息的保留时长时包括：

获取所述目标用户的用户标识；

根据所述用户标识获取所述目标用户的历史行为数据，所述历史行为数据中包括所述目标用户查看与所述推送消息具有相同消息类型的历史推送消息的频繁程度；

根据所述频繁程度设置所述推送消息的保留时长。

25.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被执行时实现以下步骤：

统计推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除针对所述推送消息的未读提示。

26.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被执行时实现以下步骤：

获取针对目标用户的推送消息；

获取所述推送消息的消息类型和/或所述目标用户的历史行为数据；

根据所述消息类型和/或所述历史行为数据设置所述推送消息的保留时长；

当所述推送消息的未读状态持续时长超过所述保留时长时，清除针对所述推送消息的未读提示。

27.一种移动设备消息处理方法，其特征在于，包括：

在移动设备上显示用于推送消息的未读提示；

确定所述推送消息的未读状态持续时长；

当所述未读状态持续时长超过保留时长时，清除所述未读提示。