CN105426189A - 一种通知栏合并的方法及*** - Google Patents

Abstract

本发明公开了一种通知栏合并的方法及***，该方法包括：接收通知消息；获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息；根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息；如果是，则将所述可合并通知消息在合并通知栏中显示。由于根据接收的通知消息的终端信息、***信息和应用信息判断该通知消息是否为可合并通知消息，对所述可合并通知消息进行合并显示，能有效解决由于手机型号、***和/或应用存在多种版本，导致无法判断哪些通知消息能进行合并显示的问题，提高了通知栏的空间利用率，进而提高用户的体验。

Description

一种通知栏合并的方法及***

技术领域

本发明涉及终端技术领域，具体涉及一种通知栏合并的方法及***。

背景技术

随着移动互联网技术的不断进步，作为移动互联网的信息传播的载体——智能移动终端设备的信息聚合的作用日益凸显，智能终端一般都允许***或第三方应用程序推送通知消息，例如Android***为应用程序提供了用于生成通知栏的***接口，应用程序在指定了应用程序的包名(Packagename)、布局文件的身份(Identity，ID)、图片资源的ID等信息之后，向***发出生成通知栏的请求，以由***根据请求在当前界面中生成通知栏。通知栏由于其便捷、直观的信息展示位的优势，被认为是一种快速与用户产生沟通的交互方式。

但是，随着手机应用市场的快速发展及手机应用数量的井喷式的增加，用户的手机每天接收到的通知栏消息越来越多，其中，多数通知消息来自不同的手机应用，各种通知栏的信息相互堆叠成一长串的通知栏列表展示在手机上，这些数目众多、排列杂乱的信息使得用户难以找到自己感兴趣的通知信息；使用起来非常的不便，大大降低了用户的体验。

为了解决以上问题，现有技术中通常是通过预先设置的分类规则对接收到的通知消息进行分类处理，然后将符合分类规则的通知消息视为同一类通知消息，并将同一类通知消息合并为一条通知消息进行显示。现有技术通过预先设置的分类规则对接收到的通知消息进行分类解决了信息排列杂乱的问题，将通知消息分门别类地、有序地展示给用户。但是，随着手机应用数量的井喷式的增加，并且，多数手机应用为满足不同手机型号和/或***的要求，会存在多种版本，导致无法判断哪些通知消息能进行合并显示，使得通知消息所占用的空间并未被减少，通知消息排列的冗长问题并未得到解决。此外，现有的通知消息显示过程中，也会将部分不必要的通知消息内容进行显示，进一步导致通知消息占用过大空间。

发明内容

本发明实施例提供一种通知栏合并的方法及***，解决由于手机型号、***和/或应用存在多种版本，导致无法判断哪些通知消息能进行合并显示的问题，以提高通知栏的空间利用率，进而提高用户的体验。

为此，本发明实施例提供如下技术方案：

一种通知栏合并的方法，包括：

接收通知消息；

获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息；

根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息；

如果是，则将所述可合并通知消息在合并通知栏中显示。

优选地，所述方法还包括：

根据所述可合并通知消息的字段对所述可合并通知消息进行有效性判断；

如果所述可合并通知消息有效，则获取所述可合并通知消息的显示部分，所述显示部分包括以下任意一种或多种：标题、内容、图标或扩展部分；

所述将所述可合并通知消息在合并通知栏中显示包括：

将所述可合并通知消息的显示部分在合并通知栏中显示。

优选地，所述应用信息包括：包名、应用版本以及通知消息的核心服务器和接入应用之间的鉴权码，所述通知消息的核心服务器和接入应用之间采用客户端/服务器模式。

优选地，所述方法还包括：

接收通知消息之后，检验该通知消息的完整性和合法性，检验结果为通过，则获取该通知消息的属性特征，检验结果为不通过，则忽略该通知消息。

优选地，所述根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息包括：

将所述通知消息的属性特征在预先构建的可合并通知消息数据库中进行匹配，确定所述通知消息是否为可合并通知消息，所述可合并通知消息数据库至少包括可合并通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息。

优选地，所述方法还包括：

预先制定用于显示不同通知消息个数的各种合并通知栏；

确定可合并通知消息的数目；

所述将所述可合并通知消息在合并通知栏中显示包括：

根据可合并通知消息的数目选取合并通知栏，并将所有可合并通知消息在选取的合并通知栏中显示。

优选地，所述方法还包括：

监听***的应用卸载情况，并删除已卸载应用的通知消息在合并通知栏中的内容。

优选地，所述方法还包括：

在固定周期或监听到新应用时，对所述数据库进行更新。

一种通知栏合并的***，包括：

接收模块，用于接收通知消息；

获取模块，用于获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息；

判断模块，用于根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息；

显示模块，用于将所述可合并通知消息在合并通知栏中显示。

优选地，所述***还包括：

有效性判断模块，用于根据所述可合并通知消息的字段对所述可合并通知消息进行有效性判断；

显示部分获取模块，用于如果所述可合并通知消息有效，则获取所述可合并通知消息的显示部分，所述显示部分包括以下任意一种或多种：标题、内容、图标或扩展部分；

所述显示模块具体用于将所述可合并通知消息的显示部分在合并通知栏中显示。

优选地，所述判断模块具体用于将所述通知消息的属性特征在预先构建的可合并通知消息数据库中进行匹配，确定所述通知消息是否为可合并通知消息，所述可合并通知消息数据库至少包括可合并通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息。

优选地，所述***还包括：

预制模块，用于预先制定用于显示不同通知消息个数的各种合并通知栏；

数目确定模块，用于确定可合并通知消息的数目；

所述显示模块，具体用于根据可合并通知消息的数目选取相应的合并通知栏，并将所有可合并通知消息的显示部分在合并通知栏中显示。

优选地，所述***还包括：

监听模块，用于监听***的应用卸载情况，并删除已卸载应用的通知消息在合并通知栏中的内容。

优选地，所述***还包括：

更新模块，用于在固定周期或监听到新应用时，对所述数据库进行更新。

一种终端，包括：

处理器，用于接收通知消息；获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息；根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息；

存储器，用于存储处理器可执行指令和/或用于存储数据库；

通信组件，用于进行数据传输；

多媒体组件，用于将所述可合并通知消息在合并通知栏中显示。

本发明实施例提供的通知栏合并的方法及***，根据接收的通知消息的属性特征判断该通知消息是否为可合并通知消息，所述属性特征包括：终端信息、***信息和应用信息，然后将判定为可合并通知消息在合并通知栏中显示。由于根据接收的通知消息的终端信息、***信息和应用信息判断该通知消息是否为可合并通知消息，对所述可合并通知消息进行合并显示，能有效解决由于手机型号、***和/或应用存在多种版本，导致无法判断哪些通知消息能进行合并显示的问题，提高了通知栏的空间利用率，进而提高用户的体验。

进一步地，本发明通过对可合并通知消息的字段进行有效性判断，并获取判断结果为有效的可合并通知消息的显示部分，所述显示部分包括以下任意一种或多种：标题、内容、图标或扩展部分，并在合并通知栏中显示可合并通知消息的显示部分，由于获取了可合并通知消息的显示部分，可以仅将显示部分在合并通知栏中进行显示，而不必将所有可合并通知消息的全部信息进行显示，有效解决了现有技术中对通知消息进行简单合并显示，使得通知消息所占用的空间并未有效减少，通知消息排列的冗长的问题，并且显示部分的具体内容可根据实际应用效果而定，如仅显示标题和图标，便于用户方便快捷的了解通知消息的大致内容，并且显示部分还可以包括扩展部分，例如按钮点击跳转，以便于查看合并通知栏各通知消息的详细内容等。

附图说明

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

图1是现有技术提供的通知消息显示方法的一种流程图；

图2是根据本发明实施例提供的通知栏合并方法的流程图；

图3是根据本发明实施例提供的选择核心服务器的方法的一种流程图；

图4是根据本发明实施例提供的能展示两个通知消息的合并通知栏布局的一种结构示意图；

图5是根据本发明实施例提供的合并通知栏的各通知消息的详细信息的一种结构示意图；

图6是根据本发明实施例提供的包括按钮点击跳转功能的合并通知栏布局的一种结构示意图；

图7是根据本发明实施例提供的通知栏合并的***的一种结构示意图；

图8是根据本发明实施例提供的一种终端的框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明实施例的方案，下面结合附图和实施方式对本发明作进一步的详细说明。以下实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。

为了更好地理解本发明，下面首先对现有技术中通知消息显示方法进行简单说明。现有的通知消息显示方法流程图如图1所示，首先，接受通知消息，然后根据预设分类规则对所述通知消息进行分类，并按照所述分类在通知栏中对所述通知消息进行显示。由于按照预先设定的分类在通知栏中对通知消息进行显示，能够解决信息排列杂乱的问题，将通知消息分门别类地、有序的展示给用户。但是，随着手机应用种类及数量的井喷式的增加，并且，不同手机型号和/或***的应用的版本也可能不同，甚至由于应用未更新而导致应用版本不是最新版本的情况也时常发生。使得无法判断哪些通知消息可以进行合并显示，以减小通知消息所占用的空间，提高通知消息排列的空间占用率，进而提高用户的使用体验。

本发明提供的通知栏合并的方法及***，由于在接收通知消息后，接收的通知消息的属性特征判断该通知消息是否为可合并通知消息，所述属性特征包括：终端信息、***信息和应用信息，然后将判定为可合并通知消息在合并通知栏中显示。由于根据接收的通知消息的终端信息、***信息和应用信息判断该通知消息是否为可合并通知消息，对所述可合并通知消息进行合并显示，能有效解决由于手机型号、***和/或应用存在多种版本，导致无法判断哪些通知消息能进行合并显示的问题，提高了通知栏的空间利用率，进而提高用户的体验。

为了更好的理解本发明的技术方案和技术效果，以下将结合流程图和具体的实施例进行详细的描述。

如图2所示，是本发明实施例提供的一种通知栏合并的方法的流程图，包括以下步骤：

步骤S01，接收通知消息。

在本实施例中，以智能终端，例如智能手机为例，手机***中预装了多种应用程序(Application，App)，包括工具类、社交类、电商类、安全类等，例如小米商城、移动营业厅等；此外，还有手机软件开发商等推出的第三方App，涉及范围很广，例如手机QQ、微信、手机淘宝商城、嘀嘀打车、ZAKER等用户自己安装的各类App。这些App都会产生通知消息，例如通知、提示、报警等，具体的，如打折通知、新聊天消息通知、新闻通知、更新提示、流量报警、安全报警等通知消息，这些消息都可以作为本发明的通知消息。

在实际应用中，可以在接收通知消息之后，检验该通知消息的完整性和合法性，检验结果为通过，则获取该通知消息的属性特征，检验结果为不通过，则忽略该通知消息。通常可以通过数据加密、密码分析、数字签名、信息鉴别、秘密共享等技术保证获取的消息的完整性及合法性，消息完整性检查(MessagesIntegrityCheck，MIC)通常可以用于防止中间人攻击(Man-In-The-Middle，MITM)和重放攻击(replayattack)。在本实施例中通过检查通知消息的数字签名，来检测所述通知消息的完整性及合法性。具体的，对每一个应用发送的通知消息采用MD5加密算法进行数字签名，并且附加在通知消息的尾部一并发送，消息服务接收到通知消息后先进行第一道检验：对接收到的通知消息同样采用MD5加密算法进行计算，如果两个数字签名一致，则确认该信息的完整性和合法性，否则认为这是一条错误的通知消息。

步骤S02，获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息。

在本实施例中，获取该通知消息的属性特征，包括：终端信息、***信息及应用信息；其中，所述应用信息包括：包名、应用版本以及通知消息的核心服务器和接入应用之间的鉴权码，所述通知消息的发送和接收采用客户端/服务器模式(C/S模式)。其中，通知消息的接收为整个合并通知栏的核心服务器，其他应用通过进程间通信的方式向合并通知栏的核心服务器进行信息的传递；并且，合并通知栏的核心服务器采用轮换的方式进行自启动，即每个向核心服务器推送通知消息的应用程序都是一个潜在的、备份的服务器。在实际应用中可根据一定规则选取某个应用作为核心服务器，例如，询问***是否已经有应用注册了合并通知栏服务的服务作为核心服务器，如果没有，则将当前应用注册合并通知栏服务后，充当核心服务器，接收其它应用发送的合并通知栏的消息；如果有，则以启动了合并通知栏服务的应用作为核心服务器，接收其它应用发送的合并通知栏的消息，如图3所示。

具体的，所述通知消息的属性特征包括：终端信息、***信息和应用信息。终端信息包括但不限于：终端品牌(manifactor)、终端型号(model)、中央处理器(cpu)型号、分辨率(revolution)等；***信息包括但不限于：操作***(OperatingSystem，OS)、***版本(Systemversion)等；应用信息包括但不限于：应用包名(pkgname)、应用的版本(version)、通知消息的核心服务器和接入应用之间的鉴权码(appkey)等。

实际应用中，核心服务器可以直接调取手机预置的***信息、终端信息以及该通知消息相应的应用信息；还可以为：核心服务器获取该终端的身份(Identity，ID)，然后核心服务器再根据终端的ID获取该通知消息的终端信息及***信息，例如，终端ID为“35203906323601”的手机，地理位置是在“深圳”，手机品牌为“Huawei”，手机型号为“HuaweiP8”，***信息为：“基于Android5.0***”进行设计的“EMUI”***，版本为“3.1”；当然，还可以通过通讯运营商或手机生产商提供的服务获取终端信息及***信息等，在此不做限制。

步骤S03，根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息。

在本实施例中，所述根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息包括：将所述通知消息的属性特征在预先构建的可合并通知消息数据库中进行匹配，确定所述通知消息是否为可合并通知消息，所述可合并通知消息数据库至少包括可合并通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息。例如，通过将该通知消息的终端信息、***信息以及应用信息和预先构建的可合并通知消息数据库进行匹配，判断该通知消息的属性特征是否与可合并通知消息的属性特征相吻合，将匹配成功的通知消息作为可合并通知消息。例如，当该通知消息相应的终端信息：终端品牌、终端型号等和/或该通知消息相应的***信息：OS、***版本等，以及该通知消息的应用信息包括：应用包名、版本、该应用与通知消息的核心服务器之间的appkey等，全部在所述数据库中匹配成功，则该通知消息为可合并通知消息。当然，未匹配成功的通知消息，如果满足安全性及合法性等要求时，可以按原显示方式进行显示。

在实际应用中，所述数据库可以为本地数据库，例如MySQL、OracleDatabase等数据库，也可以为远程数据库，例如建立在云端的数据库，当然，也可以同时存在本地数据库及远程数据库，通过通讯来进行数据传输。所述数据库存储可合并通知消息的属性特征。

进一步的，可以对所述数据库进行更新。由于不停地有新的终端、App版本产生，需要将新发布的可合并通知消息相应属性特征添加到数据库中，例如，可以规定更新周期，当到达更新周期相应时间时，对所述数据进行更新，还可以是根据一定规则对数据库进行实时更新，例如，当更新后的应用推送的通知消息的终端信息及***信息都能在数据库中匹配到，但是应用信息的版本匹配不成功时，则自动将该通知消息相应的应用信息发送给服务器，如果服务器收到的无法进行通知栏合并的消息的次数超过设置的报警阈值，则进行报警，同时通知合并通知栏的开发人员进行检查，以判断该应用信息是否能添加到数据库中。当然，也可以根据终端和/或应用人员认为必要时对该数据库进行更新。

需要说明的是，当同时存在本地数据库及远程数据库时，远程数据库的数据信息可以和本地数据库的数据信息相同，例如通过实时同步来保持两个数据库的一致性；此外，本地数据库包含的数据信息可以是从远程数据库中选取的部分数据信息，例如，根据本地终端的型号或者已知的OS，从远程数据库中选取相应的可合并通知消息相应属性特征，下载存储到本地数据库中。当然，两个数据库只要能进行数据传输即可，并不要求上述数据库的版本等相同，在此不作限制。特别的，当终端中卸载了某个应用时，可以对本地数据进行更新，例如，删除应用信息中该应用版本。

此外，核心服务器监听***的应用卸载的消息，如果监测到当前卸载的应用信息属于数据库中的应用信息，则可以对数据库进行更新，例如将该应用从本地数据库中的可合并通知的应用信息中删除，当然，如果又重新安装了该应用，还可以再次对数据库进行更新，以将该应用添加进本地数据库中的可合并通知的应用信息。

步骤S04，如果是，则将所述可合并通知消息在合并通知栏中显示。

在本实施例中，所述方法还包括：预先制定用于显示不同通知消息个数的各种合并通知栏；确定可合并通知消息的数目；所述将所述可合并通知消息在合并通知栏中显示包括：根据可合并通知消息的数目选取合并通知栏，并将所有可合并通知消息在选取的合并通知栏中显示。

进一步地，所述方法还包括：根据所述可合并通知消息的字段对所述可合并通知消息进行有效性判断；如果所述可合并通知消息有效，则获取所述可合并通知消息的显示部分，所述显示部分包括以下任意一种或多种：标题、内容、图标或扩展部分；所述将所述可合并通知消息在合并通知栏中显示包括：将所述可合并通知消息的显示部分在合并通知栏中显示。其中，可以通过字段判断来进一步检验通知消息是否有效，例如，通过检测通知消息中每个字段的顺序是否为正确的，来检验该通知消息是否为一个有效的可合并通知消息，当判断为否，则舍弃这条通知消息；当判断为是，则进行显示等操作。

在实际应用中，可以在需要进行合并通知消息的应用程序中集成N个布局文件，例如能展示一个通知消息的布局、能展示两个通知消息的布局、……、能展示N个通知消息的布局，参考图4所示，将这些布局作为合并通知栏的布局。其中，N为＞0的正整数。此外，合并通知栏内可以预留了按钮位置，以便于进行按钮点击跳转操作，查看该合并通知消息的详细内容。

进一步地，所述方法还包括：监听***的应用卸载情况，并删除已卸载应用的通知消息在合并通知栏中的内容。具体的，当核心服务器监听***的应用卸载的消息，并且当前卸载的应用属于数据库中应用信息中的合法应用，并且当前的合并通知栏中存在该应用的信息展示的位置，则核心服务器删去该应用在合并通知栏的位置，根据剩下的合并通知栏的应用数目查找符合的通知栏的布局，重新生成一条新的合并通知栏并进行显示。

进一步地，为了便于用户了解应用情况，例如本月流量使用情况以及剩余流量情况，所述合并通知栏还可以对通知消息的内容进行统计，并把统计结果进行可视化显示，如简洁的统计图表显示，参考图5所示；当然，还可以通过对合并通知栏的操作，例如点击合并通知栏、点击合并通知栏中预置的“详情”按钮等，查看合并前各通知消息的详细信息及属性特征。

在一个实施例中，将步骤S03获取的可合并通知消息，全部放入一个可合并通知栏中显示，该合并通知栏可以对所有可合并通知消息进行简单合并显示，以提高通知栏空间的利用率。

在另一个实施例中，预先制定用于显示不同通知消息个数的各种合并通知栏，例如用于显示N个可合并通知消息的合并通知栏，其中，N为＞0的正整数；确定可合并通知消息的数目M；根据可合并通知消息的数目M选取用于显示M个可合并通知消息的合并通知栏，并将这M个可合并通知消息在对应的合并通知栏中显示。这样可以针对不同可合并通知消息的数目选择更适合的合并通知栏展现形式，例如：对于两个可合并通知消息，该合并通知栏可以为两层的长条状以便于客户查看；对于4个可合并通知消息，该合并通知栏可以为正方形，其中，每一个角用于显示一条可合并通知消息等，在此不再列举。

在其它实施例中，通过对可合并通知消息的字段进行判断，获取该可合并通知消息是否有效，去除判断为有效的可合并通知消息中的空白信息，得到可合并通知消息的有用信息部分，然后根据预先设定的规则从有用信息部分中提取出显示部分。例如，在实际应用中，上述规则可以是从通知栏的基本信息中选取重要的部分作为显示部分，其中，所述基本信息包括：标题(title)、内容(content)、图标(icon)、图表等，还可以包括支持进行通知栏的多个按钮的组织形式的扩展：按钮文案(btn:text)、按钮图标(btn:img)、按钮点击跳转(btn:action)等；此外，还可以是根据合并通知栏需要，由开发人员通过经验总结而设定的规则，例如当合并通知栏中仅包括标题、图标、按钮、按钮点击跳转几个部分，则仅提取通知消息的标题、图标、按钮、按钮点击跳转信息部分，其余通知消息信息作为附属信息，通过按钮点击跳转来查看附属信息，如图6所示。当然也可以通过一定操作来查看合并前的完整通知消息，这里不做限定。需要说明的是，上述基本信息也可以存储到所述数据库中，以便于服务器获取通知消息的显示部分。

需要说明的是，为了保证合并通知栏的消息重要性分层布局、可视性、便于操作性等要求，并不是所有的可合并通知消息都必须在同一个合并通知栏中显示，例如，可以设定一个合并通知栏中不许超过的显示通知消息的指定个数，超过指定个数的通知消息放在另一个合并通知栏中显示；或者一个合并通知栏内不能显示超过指定个数的应用的通知消息，例如，一个合并通知栏中不能显示超过4种应用推送的通知消息；当然，还可以设定***的通知消息不能和第三方应用的通知消息放在同一个合并通知栏中显示；此外，不同类型的通知消息不能放在同一个合并通知栏中显示，例如，警告类通知消息不能和广告类通知消息放在同一个合并通知栏中显示等。具体设定需要根据实际情况、应用效果以及生活常识等而定，这里不作特别限定。进一步的，还可以对合并通知栏布局进行优化，例如，当某个应用推送了较多的通知消息，而且不涉及警告类的重要通知消息和不涉及用户利益的通知消息，则可以在合并通知栏中显示某应用推送了M个通知消息即可，其中，M代表该应用实际推送的通知消息个数。优选的，核心服务器会根据当前推送通知消息的应用数目选择能展示对应的展示布局文件，然后删去原来的合并通知栏，重新选取符合要求的合并通知栏。

在实际应用中，根据当前使用合并通知栏的信息列表构建展示布局文件的各个展示区域的View；各个展示区域的View的绑定的页面数据包括(显示的文本信息、显示图标的标号、按钮的信息列表)、按钮的信息列表包括(按钮上显示的文本信息、按钮上显示图标的标号、按钮的下一跳的执行动作)，这些数据通过实现Parcelable的接口实现；合并通知栏的显示步骤为利用上述合并通知栏的各个区域对应携带数据采用RemoteView的方法构建，RemoteView中的布局由发送通知栏合并通知消息的应用内部预先制定的布局来确定，然后构建一个Notification的对象，将生成的RemoteView设置为Notification的对象的contentView的属性，然后通过Android***的NotificationManager的对象将构建的Notification对象推送出去。当然，iOS***以及非基于Android的***的通知栏合并的过程与Android***的通知栏合并的具体过程不同，但是合并通知栏的主体及合并显示的内容及思路等可以相同，在此不作详述。

本发明实施例提供的通知栏合并方法，首先接收通知消息，然后获取该通知消息的属性特征，并根据该属性特征判断该通知消息是否为可合并通知消息，所述属性特征包括：终端信息、***信息和应用信息，然后将判定为可合并通知消息在合并通知栏中显示。由于根据通知消息的终端信息、***信息和应用信息判断该通知消息是否为可合并通知消息，能有效解决由于手机型号、***和/或应用存在多种版本，导致无法判断哪些通知消息能进行合并显示的问题，提高了通知栏的空间利用率，进而提高用户的体验。

相应的，本发明还提供了通知栏合并的***，如图7所示：

接收模块701，用于接收通知消息；

获取模块702，用于获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息；

判断模块703，用于根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息；

显示模块704，用于将所述可合并通知消息在合并通知栏中显示。

其中，所述判断模块703具体用于将所述通知消息的属性特征在预先构建的可合并通知消息数据库中进行匹配，确定所述通知消息是否为可合并通知消息，所述可合并通知消息数据库至少包括可合并通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息。

在实际应用中，所述***还包括：

有效性判断模块805，用于根据所述可合并通知消息的字段对所述可合并通知消息进行有效性判断；

显示部分获取模块806，用于如果所述可合并通知消息有效，则获取所述可合并通知消息的显示部分，所述显示部分包括以下任意一种或多种：标题、内容、图标或扩展部分；

显示模块具体用于将所述可合并通知消息的显示部分在合并通知栏中显示。

此外，在实际应用中，所述接收模块701具体可以为通知消息的核心服务器，与接入应用之间采用C/S模式，即接收模块701为核心服务器，其他应用通过进程间通信的方式向核心服务器进行信息的传递。

为了进一步提高合并通知栏的空间利用率，所述***还包括：

预制模块809，用于预先制定用于显示不同通知消息个数的各种合并通知栏；

数目确定模块810，用于确定可合并通知消息的数目；

所述显示模块，具体用于根据可合并通知消息的数目选取相应的合并通知栏，并将所有可合并通知消息的显示部分在合并通知栏中显示。

由于不停的有新的终端及应用的产生，需要经常更新数据库，为了满足用户需求，因此所述***还包括更新模块807，用于在固定周期或监听到新应用时，对所述数据库进行更新。

进一步地，所述***还包括：

监听模块808，与显示模块704、显示部分获取模块806及更新模块807相连接，用于监听***的应用卸载情况，并删除已卸载应用的通知消息在合并通知栏中的内容。

当然，该***还可以进一步包括存储模块(未图示)，用于保存预制的合并通知栏及其相关信息、可合并通知消息相应属性特征等，如合并通知栏布局、终端信息、***信息、应用信息等。这样，以方便对通知消息进行计算机自动处理，并存储合并通知栏的通知消息及其合并前相关信息等。

本发明实施例提供的通知栏合并的***，通过接收模块701接收通知消息，然后通过获取模块702获取通知消息的终端信息、***信息和应用信息等属性特征，接着通过判断模块703根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息，并通过显示模块704将所有可合并通知消息进行显示，由于通过属性特征判断各通知消息是否为可合并通知消息，解决了现有技术无法解决现存手机型号、应用及应用版本过多导致无法判断哪些通知消息可以进行合并显示的问题，提高了通知消息排列的空间占用率，使得用户的使用体验得以提高。

相应的，本发明还提供了一种终端2800，包括：

处理器2820，用于接收通知消息；获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息；根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息；

存储器2804，用于存储处理器2820可执行指令和/或用于存储可合并通知消息相应属性特征的数据库；

通信组件2816，用于进行数据传输；

多媒体组件2808，用于按一定的形式将所有有效通知消息的显示部分在通知栏中显示。

图8是一示例性实施例示出的一种用于通知栏合并的终端2800的框图。例如，

该移动终端2800可以是智能手机，便携计算机，数字广播终端，消息收发设备，游戏机，平板设备，医疗设备，健身设备，个人数字助理等。

参照图8所示，移动终端2800可以包括以下一个或多个组件：处理组件2802，存储器2804，电源组件2806，多媒体组件2808，音频组件2810，输入/输出(I/O)的接口2812，传感器组件2814，以及通信组件2816。

处理组件2802通常控制移动终端2800的整体操作，例如与数据库，验证，查找，显示，电话呼叫，数据通信和记录操作相关联的操作等。处理组件2802可以包括一个或多个处理器2820来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件2802可以包括一个或多个模块，便于处理组件2802和其他组件之间的交互。例如，处理组件2802可以包括多媒体模块，以方便多媒体组件2808和处理组件2802之间的交互。

存储器2804被配置为存储各种类型的数据以支持在设备2800的操作。这些数据的示例包括用于在移动终端2800上操作的任何应用程序或方法的指令，数据库，如在本实施例中可存储可合并通知消息的属性特征等，联系人数据，地理位置信息，网络信息，消息，图片，视频等。存储器2804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现。

电源组件2806为移动终端2800的各种组件提供电力。电源组件2806可以包括电源管理***，一个或多个电源，及其他与为移动终端2800生成、管理和分配电力相关联的组件。

多媒体组件2808包括在所述移动终端2800和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)，以向用户显示信息等。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号，例如点击合并通知栏中“详情”按钮输入的信号。此外，还可以包括：一个前置摄像头和/或后置摄像头。

音频组件2810被配置为输出和/或输入音频信号。例如，音频组件2810包括一个麦克风(MIC)，当移动终端2800处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器2804或经由通信组件2816发送。在一些实施例中，音频组件2810还包括一个扬声器，用于输出音频信号。

I/O接口2812为处理组件2802和***接口模块之间提供接口，上述***接口模块可以是触摸屏，键盘，点击轮，按钮等。这些按钮可以为实体的，也可以是虚拟的，例如触摸屏上的虚拟按键等，具体可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件2814包括一个或多个传感器，用于为移动终端2800提供各个方面的状态评估。在一些实施例中，该传感器组件2814可以包括GPS模组，加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器等。

通信组件2816被配置为便于移动终端2800和其他设备之间有线或无线方式的通信。移动终端2800可以接入基于通信标准的无线网络并可以获得当前网络信息，例如信号强度等。所述基于通信标准的无线网络如WiFi，2G或3G，或它们的组合。当然，还可以包括：近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的***实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本发明实施例进行了详细介绍，本文中应用了具体实施方式对本发明进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及设备；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (15)

1.一种通知栏合并的方法，其特征在于，包括：

接收通知消息；

获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息；

根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息；

如果是，则将所述可合并通知消息在合并通知栏中显示。

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

根据所述可合并通知消息的字段对所述可合并通知消息进行有效性判断；

如果所述可合并通知消息有效，则获取所述可合并通知消息的显示部分，所述显示部分包括以下任意一种或多种：标题、内容、图标或扩展部分；

所述将所述可合并通知消息在合并通知栏中显示包括：

将所述可合并通知消息的显示部分在合并通知栏中显示。

3.根据权利要求1所述的方法，其特征在于，所述应用信息包括：包名、应用版本以及通知消息的核心服务器和接入应用之间的鉴权码，所述通知消息的核心服务器和接入应用之间采用客户端/服务器模式。

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

接收通知消息之后，检验该通知消息的完整性和合法性，检验结果为通过，则获取该通知消息的属性特征，检验结果为不通过，则忽略该通知消息。

5.根据权利要求1所述的方法，其特征在于，所述根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息包括：

将所述通知消息的属性特征在预先构建的可合并通知消息数据库中进行匹配，确定所述通知消息是否为可合并通知消息，所述可合并通知消息数据库至少包括可合并通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息。

6.根据权利要求1至5任一项所述的方法，其特征在于，所述方法还包括：

预先制定用于显示不同通知消息个数的各种合并通知栏；

确定可合并通知消息的数目；

所述将所述可合并通知消息在合并通知栏中显示包括：

根据可合并通知消息的数目选取合并通知栏，并将所有可合并通知消息在选取的合并通知栏中显示。

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

监听***的应用卸载情况，并删除已卸载应用的通知消息在合并通知栏中的内容。

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

在固定周期或监听到新应用时，对所述数据库进行更新。

9.一种通知栏合并的***，其特征在于，包括：

接收模块，用于接收通知消息；

获取模块，用于获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息；

判断模块，用于根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息；

显示模块，用于将所述可合并通知消息在合并通知栏中显示。

10.根据权利要求9所述的***，其特征在于，所述***还包括：

有效性判断模块，用于根据所述可合并通知消息的字段对所述可合并通知消息进行有效性判断；

显示部分获取模块，用于如果所述可合并通知消息有效，则获取所述可合并通知消息的显示部分，所述显示部分包括以下任意一种或多种：标题、内容、图标或扩展部分；

所述显示模块具体用于将所述可合并通知消息的显示部分在合并通知栏中显示。

11.根据权利要求9所述的***，其特征在于，所述判断模块具体用于将所述通知消息的属性特征在预先构建的可合并通知消息数据库中进行匹配，确定所述通知消息是否为可合并通知消息，所述可合并通知消息数据库至少包括可合并通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息。

12.根据权利要求9至11任一项所述的***，其特征在于，所述***还包括：

预制模块，用于预先制定用于显示不同通知消息个数的各种合并通知栏；

数目确定模块，用于确定可合并通知消息的数目；

所述显示模块，具体用于根据可合并通知消息的数目选取相应的合并通知栏，并将所有可合并通知消息的显示部分在合并通知栏中显示。

13.根据权利要求9所述的***，其特征在于，所述***还包括：

监听模块，用于监听***的应用卸载情况，并删除已卸载应用的通知消息在合并通知栏中的内容。

14.根据权利要求11或13所述的***，其特征在于，所述***还包括：

更新模块，用于在固定周期或监听到新应用时，对所述数据库进行更新。

15.一种终端，其特征在于，包括：

处理器，用于接收通知消息；获取所述通知消息的属性特征，所述属性特征包括：终端信息、***信息和应用信息；根据所述通知消息的属性特征判断该通知消息是否为可合并通知消息；

存储器，用于存储处理器可执行指令和/或用于存储数据库；

通信组件，用于进行数据传输；

多媒体组件，用于将所述可合并通知消息在合并通知栏中显示。