通知消息的处理方法、电子设备及计算机存储介质与流程

1.本技术涉及计算机技术领域，尤其涉及一种通知消息的处理方法、电子设备及计算机存储介质。


背景技术：

2.目前，手机、平板电脑等电子设备中安装的应用(application，app)越来越多，各个应用会不断产生各种通知消息以提示用户查看，例如短信通知消息、来电通知消息、广告推送通知消息等。具体的，各个应用的通知消息排列形成通知消息列表之后，会显示在电子设备的状态栏中。当用户要查看通知消息时，则可以下拉状态栏，查看通知消息列表，从中筛选出通知消息进行查看。
3.然而，通知消息列表里显示的通知消息过多，当中包含着许多用户并不关心的不重要的通知消息，用户在筛选过程中容易遗漏重要的通知消息，且还可能出现误操作清除所有通知的情况，导致错过用户所关心的重要通知消息。


技术实现要素：

4.本技术提供了一种通知消息的处理方法、电子设备及计算机存储介质，目的在于解决通知消息列表不利于用户筛选出重要通知消息的问题。
5.为了实现上述目的，本技术提供了以下技术方案：
6.第一方面，本技术公开了一种通知消息的处理方法，应用于电子设备，通知消息的处理方法包括：响应于用户的点击操作，显示第一通知区域，第一通知区域用于根据每一个通知消息的紧急程度和重要程度，区分显示每一个通知消息的控件，响应于用户点击第一通知区域内的通知消息的操作，显示用户点击的通知消息对应的详情界面，通知消息对应的详情界面用于显示通知消息的详情内容。
7.本技术实施例中，由于第一通知区域用于根据每一个通知消息的紧急程度和重要程度，区分显示每一个通知消息的控件。因此用户能够从第一通知区域内辨别筛选出重要程度高，和/或紧急程度高的通知消息，进而能够使得用户可快速点击出自身所需的查看的、第一通知区域内的通知消息，电子设备再响应于用户点击第一通知区域内的通知消息的操作，显示用户点击的通知消息对应的详情界面给用户查看。
8.在一种可能的实现方式中，第一通知区域用于根据每一个通知消息的紧急程度和重要程度，通过通知消息的控件在第一通知区域内的显示位置和/或显示颜色，区分显示每一个通知消息的控件。
9.第一通知区域根据每一个通知消息的紧急程度和重要程度，通过通知消息的控件在第一通知区域内的显示位置和/或显示颜色，区分显示每一个通知消息的控件，以使得用户能够通过通知消息的控件在第一通知区域内的显示位置和/或显示颜色，区分开各个通知消息的紧急程度和重要程度。
10.在另一种可能的实现方式中，第一通知区域，包括：多个显示区域，每一个显示区
域上分别显示属于显示区域的通知消息的控件，不同的显示区域上显示的通知消息的重要程度或紧急程度互不相同。用户可以通过优先查看重要程度或紧急程度更高的显示区域中的通知消息，迅速筛选出重要紧急的通知消息，保证了用户不会错过重要紧急的通知。
11.在另一种可能的实现方式中，多个显示区域，包括：第一显示区域、第二显示区域、第三显示区域以及第四显示区域。第一显示区域用于显示代表重要程度的数值大于重要程度临界值、且代表紧急程度的数值大于紧急程度临界值的通知消息的控件，第二显示区域用于显示代表重要程度的数值不大于重要程度临界值、且代表紧急程度的数值大于紧急程度临界值的通知消息的控件，第三显示区域用于显示代表重要程度的数值不大于重要程度临界值、且代表紧急程度的数值不大于紧急程度临界值的通知消息的控件，第四显示区域用于显示代表重要程度的数值大于重要程度临界值、且代表紧急程度的数值不大于紧急程度临界值的通知消息的控件。
12.在另一种可能的实现方式中，针对每一个显示区域，显示区域内显示的通知消息的控件和第一通知区域中心点之间的距离越小，则通知消息的重要紧急程度越高。代表通知消息的重要紧急程度的数值，通过对代表通知消息的重要程度和紧急程度的数值计算得到。
13.在另一种可能的实现方式中，第一通知区域的形状为圆盘形状。第一通知区域的原点为圆心，第一显示区域位于第一通知区域的第一象限，第二显示区域位于第一通知区域的第二象限，第三显示区域位于第一通知区域的第三象限，第四显示区域位于第一通知区域的第四象限。
14.在另一种可能的实现方式中，第一通知区域，包括：多个显示区域，每一个显示区域上分别显示属于显示区域的通知消息的控件。不同的显示区域上显示的通知消息的重要紧急程度互不相同，代表通知消息的重要紧急程度的数值，通过对代表通知消息的重要程度和紧急程度的数值计算得到。
15.在另一种可能的实现方式中，第一通知区域中，不同的显示区域与第一通知区域中心点之间的距离互不相同，与第一通知区域中心点之间的距离越小的显示区域，显示的通知消息的重要紧急程度越高。
16.在另一种可能的实现方式中，还包括：响应于解锁操作，判断所有通知消息中是否存在重要紧急的通知消息。重要紧急的通知消息为代表重要紧急程度的数值大于重要紧急程度临界值的通知消息。代表通知消息的重要紧急程度的数值，通过对代表通知消息的重要程度和紧急程度的数值计算得到，若所有通知消息中存在重要紧急的通知消息，则显示第一通知区域。
17.在另一种可能的实现方式中，响应于用户的点击操作，包括：响应于用户的点击悬浮导航控件的操作。
18.在另一种可能的实现方式中，第一通知区域的位置为可调整的位置，和/或，第一通知区域的尺寸为可调整的尺寸。
19.在另一种可能的实现方式中，还包括：
20.响应于用户的下拉操作，显示第二通知区域；第二通知区域用于显示按照接收时间顺序排列的每一个通知消息的控件。响应于用户点击第二通知区域内的通知消息的操作，显示点击的通知消息对应的详情界面。
21.在另一种可能的实现方式中，显示第一通知区域之后，还包括：
22.响应于删除第一通知区域内的通知消息的操作，在第一通知区域上不显示删除的通知消息。
23.在另一种可能的实现方式中，显示第二通知区域之后，还包括：
24.响应于删除第二通知区域内的通知消息的操作，在第二通知区域上不显示删除的通知消息。
25.在另一种可能的实现方式中，通知消息的紧急程度根据通知消息的历史接收时间和历史查看时间确定或者由用户进行设定。
26.在另一种可能的实现方式中，电子设备的操作系统，包括：通知管理中心、悬浮导航模块以及至少一个应用。响应于用户的点击操作，显示第一通知区域之前，还包括：通知管理中心接收至少一个应用发送的每一个通知消息，悬浮导航模块从通知管理中心获取到每一个通知消息。响应于用户的点击操作，显示第一通知区域，包括：悬浮导航模块响应于用户的点击操作，控制电子设备的显示屏显示第一通知区域。
27.在另一种可能的实现方式中，电子设备的操作系统，包括：悬浮导航模块；响应于用户的点击操作，显示第一通知区域，包括：悬浮导航模块响应于用户的点击操作，控制电子设备的显示屏显示第一通知区域。悬浮导航模块控制电子设备的显示屏显示第一通知区域之前，还包括：悬浮导航模块针对每一个通知消息，根据通知消息的紧急程度和重要程度，确定通知消息的控件所属的显示区域。
28.在另一种可能的实现方式中，悬浮导航模块针对每一个通知消息，根据通知消息的紧急程度和重要程度，确定通知消息的控件所属的显示区域，包括：
29.悬浮导航模块判断代表通知消息的重要程度的数值是否大于重要程度临界值，并判断代表通知消息的紧急程度的数值是否大于紧急程度临界值。若代表通知消息的重要程度的数值大于重要程度临界值、且代表通知消息的紧急程度的数值大于紧急程度临界值，则确定出通知消息的控件所属的显示区域为第一显示区域。若代表通知消息的重要程度的数值不大于重要程度临界值、且代表通知消息的紧急程度的数值大于紧急程度临界值，则确定出通知消息的控件所属的显示区域为第二显示区域。若代表通知消息的重要程度的数值不大于重要程度临界值、且代表通知消息的紧急程度的数值不大于紧急程度临界值，则确定出通知消息的控件所属的显示区域为第三显示区域。若代表通知消息的重要程度的数值大于重要程度临界值、且代表通知消息的紧急程度的数值不大于紧急程度临界值，则确定出通知消息所属的显示区域为第四显示区域。
30.在另一种可能的实现方式中，电子设备的操作系统，还包括：设置数据库；悬浮导航模块判断代表通知消息的重要程度的数值是否大于重要程度临界值，并判断代表通知消息的紧急程度的数值是否大于紧急程度临界值之前，还包括：
31.悬浮导航模块从设置数据库中获取到每一个代表通知消息的紧急程度的数值；代表通知消息的重要程度的数值携带在通知消息中，或者由用户进行设定。
32.在另一种可能的实现方式中，电子设备的操作系统，包括：悬浮导航模块；响应于用户的点击操作，显示第一通知区域，包括：悬浮导航模块响应于用户的点击操作，控制电子设备的显示屏显示第一通知区域。悬浮导航模块控制电子设备的显示屏显示第一通知区域之前，还包括：悬浮导航模块针对每一个通知消息，根据通知消息的重要紧急程度，确定
通知消息的控件所属的显示区域。
33.在另一种可能的实现方式中，电子设备的操作系统，还包括：系统应用和悬浮导航模块，响应于解锁操作，判断所有通知消息中是否存在重要紧急的通知消息，包括：系统应用响应于解锁操作，对电子设备进行解锁。悬浮导航模块若监听到系统应用对电子设备进行解锁，则判断所有通知消息中是否存在重要紧急的通知消息。
34.在另一种可能的实现方式中，电子设备的操作系统，包括：通知管理中心、悬浮导航模块、system ui以及至少一个应用。方法还包括：
35.通知管理中心接收至少一个应用发送的每一个通知消息，悬浮导航模块和system ui，分别从通知管理中心获取到每一个通知消息。
36.响应于用户的点击操作，显示第一通知区域，包括：悬浮导航模块响应于用户的点击操作，控制电子设备的显示屏显示第一通知区域。
37.响应于查看第二通知区域的操作，显示第二通知区域，包括：system ui响应于查看第二通知区域的操作，控制电子设备的显示屏显示第二通知区域。
38.在另一种可能的实现方式中，响应于用户点击第二通知区域内的通知消息的操作，显示用户点击的通知消息对应的详情界面之后，还包括：
39.system ui将用于指示已查看的第二通知区域内的通知消息的信息发送至通知管理中心，通知管理中心将用于指示已查看的第二通知区域内的通知消息的信息发送至悬浮导航模块，悬浮导航模块从获取到的通知消息中删除已查看的第二通知区域内的通知消息。第一通知区域内不显示已查看的第二通知区域内的通知消息的控件。响应于用户点击第一通知区域内的通知消息的操作，显示用户点击的通知消息对应的详情界面之后，还包括：悬浮导航模块将用于指示已查看的第一通知区域内的通知消息的信息发送至通知管理中心，通知管理中心将用于指示已查看的第一通知区域内的通知消息的信息发送至system ui，system ui从获取到的通知消息中删除已查看的第一通知区域内的通知消息，第二通知区域内不显示已查看的第一通知区域内的通知消息的控件。
40.在另一种可能的实现方式中，还包括：
41.悬浮导航模块响应于删除第一通知区域内的通知消息的操作，将用于指示已删除的第一通知区域内的通知消息的信息发送至通知管理中心。通知管理中心将用于指示已删除的第一通知区域内的通知消息的信息发送至system ui，system ui从获取到的通知消息中删除已删除的第一通知区域内的通知消息。第二通知区域不显示已删除的第一通知区域内的通知消息的控件。
42.在另一种可能的实现方式中，还包括：system ui响应于删除第二通知区域内的通知消息的操作，将用于指示已删除的第二通知区域内的通知消息的信息发送至通知管理中心。通知管理中心将用于指示已删除的第二通知区域内的通知消息的信息发送至悬浮导航模块。悬浮导航模块从获取到的通知消息中删除已删除的第二通知区域内的通知消息，第一通知区域不显示已删除的第一通知区域内的通知消息的控件。
43.在另一种可能的实现方式中，悬浮导航模块从通知管理中心获取到每一个通知消息之前，还包括：悬浮导航模块向通知管理中心注册监听。悬浮导航模块从通知管理中心获取到每一个通知消息，包括：悬浮导航模块从通知管理中心监听到每一个通知消息。
44.在另一种可能的实现方式中，悬浮导航模块若监听到系统应用对电子设备进行解
锁，则判断所有通知消息中是否存在重要紧急的通知消息之前，还包括：悬浮导航模块向系统应用注册监听。
45.第二方面，本技术公开了一种电子设备，电子设备包括：一个或多个处理器和存储器，存储器与一个或多个处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，电子设备执行如上述第一方面中任一项的通知消息的处理方法。
46.第三方面，本技术公开了一种计算机存储介质，计算机存储介质包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备中的处理器执行如上述第一方面任意一项的通知消息的处理方法。
47.应当理解的是，本技术中对技术特征、技术方案、有益效果或类似语言的描述并不是暗示在任意的单个实施例中可以实现所有的特点和优点。相反，可以理解的是对于特征或有益效果的描述意味着在至少一个实施例中包括特定的技术特征、技术方案或有益效果。因此，本说明书中对于技术特征、技术方案或有益效果的描述并不一定是指相同的实施例。进而，还可以任何适当的方式组合本实施例中所描述的技术特征、技术方案和有益效果。本领域技术人员将会理解，无需特定实施例的一个或多个特定的技术特征、技术方案或有益效果即可实现实施例。在其他实施例中，还可在没有体现所有实施例的特定实施例中识别出额外的技术特征和有益效果。
附图说明
48.图1a为本技术实施例提出的一种电子设备的软件架构图；
49.图1b为本技术实施例提出的查看通知消息的场景示意图一；
50.图1c为本技术实施例提出的查看通知消息的场景示意图二；
51.图2为本技术实施例提出的另一种电子设备的硬件结构图；
52.图3为本技术实施例提出的另一种电子设备的软件架构图；
53.图4a为本技术实施例提出的通知消息的处理方法的流程示意图一；
54.图4b为本技术实施例提出的查看通知消息的场景示意图三；
55.图4c为本技术实施例提出的一种通知消息的设置场景示意图；
56.图4d为本技术实施例提出的一种确定通知消息对应的圆盘位置的流程示意图；
57.图4e为本技术实施例提出的查看通知消息的场景示意图四；
58.图4f为本技术实施例提出的查看通知消息的场景示意图五；
59.图5a为本技术实施例提出的通知消息的处理方法的流程示意图二；
60.图5b为本技术实施例提出的查看通知消息的场景示意图六；
61.图5c为本技术实施例提出的通知消息的处理方法的流程示意图三。
具体实施方式
62.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述。以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本技术的限制。如在本技术的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形
式，除非其上下文中明确地有相反指示。还应当理解，在本技术实施例中，“一个或多个”是指一个、两个或两个以上；“和/或”，描述关联对象的关联关系，表示可以存在三种关系；例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b的情况，其中a、b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。
63.在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本技术的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
64.本技术实施例涉及的多个，是指大于或等于两个。需要说明的是，在本技术实施例的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。
65.为了下述各实施例的描述清楚简洁，首先给出一种通知消息的处理方案的简要介绍：
66.app的通知消息用于提醒用户查看app的消息，例如短信app的短信通知消息用于提醒用户查看未读短信，通话app的未接来电通知消息用于通知用户查看未接来电等等。各个app的通知消息通常会以通知消息列表的形式展示给用户。
67.示例性的，参阅图1a，通知消息列表的生成过程可以是：应用程序层中的通话应用发送通知消息给应用程序框架层的通知管理中心，应用程序层中的短消息应用也发送通知消息给应用程序框架层的通知管理中心，通知管理中心把接收到的通知消息又发送给系统用户界面(system ui)。system ui按照应用发送通知消息的时间的顺序排列所有未被用户查看的通知消息，形成通知消息列表，在用户下拉状态栏时，system ui将通知消息列表显示到状态栏中。
68.其中，应用程序层中还可以有其他的应用，其他的应用的通知消息的处理过程可参考前述提及的对通话应用的通知消息的处理过程，短消息应用和通话应用的通知消息的处理仅仅是示例性的，此处不再赘述。
69.示例性的，用户下拉状态栏查看通知消息列表的过程为：用户下拉状态栏之后的显示界面如图1b的(1)所示，状态栏上显示了日期为1月1号周四，显示了无线局域网(wireless local area network，wlan)、蓝牙、移动数据、静音、自动旋转以及手机亮度的状态，还显示有通知消息列表。通知消息列表上显示了app1的消息1、app2的消息2以及app3的消息3的通知消息。如(1)中的图标10所示，通知消息列表总共有三栏，当前为通知消息列表的第一栏。用户向左滑动屏幕，手机的状态栏变化为图1b示出的(2)。如图1b的(2)所示，通知消息列表的第二栏上显示有app4的消息4、app5的消息5以及app6的消息6的通知消息，用户点击自身需要查看的app4的消息4的通知消息，手机界面变化为图1b的(3)。如图1b的(3)所示，app的消息4的详情内容显示在手机界面上，以供用户浏览查看。
70.示例性的，用户下拉状态栏查看通知消息列表的过程也可以为：如图1c的(1)所示，用户下拉状态栏之后的显示界面与前述提及的图1b的(1)相同，当用户想滑动查看通知消息列表的第二栏时，误点击到清除消息的图标20，手机界面变化为图1c的(2)，即状态栏
显示没有通知消息，不显示通知消息列表。
71.由图1a、图1b以及图1c可以看出，通知消息列表内的通知消息按照应用发送通知消息的时间的顺序进行排列，当中包含了许多重要和不重要的消息，用户从通知消息列表中筛选通知消息进行阅读时，需要多次滑动查看通知消息列表，操作比较繁琐，耗时较长。且在筛选通知消息的过程中，容易出现如图1c示出的误操作的情况，清除掉所有通知消息。
72.综上所述，前述提及的通知消息的展示方式不够合理，不利于用户筛选通知消息，容易导致用户错失重要的、紧急的消息，给用户带来不好的体验。为此，本技术实施例提出了一种通知消息的处理方法，能够按照通知消息的重要程度和紧急程度的高低区分展示未读通知消息，以便于用户可快速筛选出用户所需查看的通知消息。
73.本技术实施例提出的一种通知消息的处理方法，可以适用于手机，平板电脑，笔记本电脑，超级移动个人计算机(ultra-mobile personal computer，umpc)，手持计算机，上网本，个人数字助理(personal digital assistant，pda)，可穿戴电子设备，智能手表等电子设备。
74.如图2所示，本技术实施例所提出的电子设备可以包括处理器110，外部存储器接口120，内部存储器121，充电管理模块130，电源管理模块131，电池132，天线1，天线2，移动通信模块140，无线通信模块150，传感器模块160，以及显示屏170等。其中传感器模块160可以包括指纹传感器160a，触摸传感器160b等。
75.可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
76.处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，ap)，调制解调处理器，图形处理器(graphics processing unit，gpu)，图像信号处理器(image signal processor，isp)，视频编解码器。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。例如，在本技术中，处理器110可以用于执行本技术实施例提出的任一通知消息的处理方法。具体的，可参阅下述图4a和图5a的相关内容，此处不再赘述。
77.处理器110中还可以设置存储器，用于存储指令和数据。
78.在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括移动产业处理器接口(mobile industryprocessor interface，mipi)等。
79.mipi接口可以被用于连接处理器110与显示屏170等外围器件。mipi接口包括显示屏串行接口(display serial interface，dsi)等。在一些实施例中，处理器110和显示屏170通过dsi接口通信，实现电子设备的显示功能。例如，本技术实施例中，处理器110和显示屏170通过dsi接口通信，实现在显示屏170上显示本技术实施例所提出的任一通知消息的处理方法中涉及的通知区域。具体的，可参阅下述图4a中显示悬浮导航圆盘的相关内容、图5a中显示悬浮导航圆盘、以及显示通知消息列表的相关内容，此处不再赘述。
80.可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在本技术另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
81.充电管理模块130用于从充电器接收充电输入。其中，充电器可以是无线充电器，
也可以是有线充电器。
82.电源管理模块131用于连接电池132，充电管理模块130与处理器110。电源管理模块131接收电池132和/或充电管理模块130的输入，为处理器110，内部存储器121，显示屏170等供电。
83.电子设备的无线通信功能可以通过天线1，天线2，移动通信模块140，无线通信模块150，调制解调处理器以及基带处理器等实现。
84.天线1和天线2用于发射和接收电磁波信号。
85.移动通信模块140可以提供应用在电子设备上的包括2g/3g/4g/5g等无线通信的解决方案。
86.无线通信模块150可以提供应用在电子设备上的包括无线局域网(wireless local area networks，wlan)(如无线保真(wireless fidelity，wi-fi)网络)，蓝牙(bluetooth，bt)等无线通信的解决方案。
87.在一些实施例中，电子设备的天线1和移动通信模块140耦合，天线2和无线通信模块150耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。
88.电子设备通过gpu，显示屏170，以及应用处理器等实现显示功能。gpu为图像处理的微处理器，连接显示屏170和应用处理器。gpu用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个gpu，其执行程序指令以生成或改变显示信息。例如，本技术实施例中，gpu可以用于实现在显示屏170上显示本技术实施例所提出的任一通知消息的处理方法中所涉及的通知区域。具体的，可参阅下述图4a中显示悬浮导航圆盘的相关内容、图5a中显示悬浮导航圆盘、以及显示通知消息列表的相关内容，此处不再赘述。
89.显示屏170用于显示图像，视频等。显示屏170包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，lcd)，有机发光二极管(organic light-emitting diode，oled)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的，amoled)等。在一些实施例中，电子设备可以包括1个或n个显示屏170，n为大于1的正整数。
90.电子设备的显示屏170上可以显示一系列图形用户界面(graphical user interface，gui)，这些gui都是该电子设备的主屏幕。例如，本技术实施例中，显示屏170可以用于显示本技术实施例所提出的任一通知消息的处理方法中所涉及的通知区域。具体的，可参阅下述图4a中显示悬浮导航圆盘的相关内容、图5a中显示悬浮导航圆盘、以及显示通知消息列表的相关内容，此处不再赘述。
91.外部存储器接口120可以用于连接外部存储卡，例如micro sd卡，实现扩展电子设备的存储能力。
92.内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备的各种功能应用以及数据处理。例如，在本实施例中，处理器110可以通过执行存储在内部存储器121中的指令，执行本技术实施例所提出的任一通知消息的处理方法。具体的，可参阅下述图4a和图5a的相关内容，此处不再赘述。
93.指纹传感器160a用于采集指纹。电子设备可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。例如，本技术实施例中，可以在指纹传感器
160a采集的指纹实现指纹解锁后，弹出本技术实施例所提出的任一通知消息的处理方法中的通知区域。具体的，可参阅图4a部分的步骤s409至步骤s413相关内容、以及图5a的步骤s510至步骤s514的相关内容，此处不再赘述。
94.触摸传感器160b，也称“触控器件”。触摸传感器160b可以设置于显示屏170，由触摸传感器160b与显示屏170组成触摸屏，也称“触控屏”。
95.另外，在上述部件之上，运行有操作系统。例如ios操作系统，android开源操作系统，windows操作系统等。在该操作系统上可以安装运行应用程序。
96.图3是本技术实施例的电子设备的结构框图。
97.分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(androidruntime)和系统库，以及内核层。
98.如图3所示，应用程序层可以包括短消息的应用程序、通话的应用程序、system ui、系统应用以及悬浮导航模块。
99.短消息应用用于接收或者外发短消息，还用于向用户推送短消息应用的通知消息。例如，当短消息应用在接收到新的短消息、或者出现短消息发送失败等情况时，可以将这些情况通过通知消息通知给用户。例如，本技术实施例中，短消息应用将通知消息发送至通知管理中心，由通知管理中心统一管理通知消息的推送。
100.通话应用用于实现拨打或者接听电话的功能，还用于向用户推送通话应用的通知消息。例如，本技术实施例中，通话应用将通知消息发送至通知管理中心，由通知管理中心统一管理通知消息的推送。
101.其中，应用程序层还可以包括有其他的应用，其他应用推送通知消息的过程和原理可以参考图3示出的短消息应用和通话应用。
102.system ui用于绘制通知消息列表，在用户下拉状态栏时显示通知消息列表。例如，本实施例中，system ui监听通知管理中心的通知消息，并按照通知管理中心接收到通知消息的时间顺序，排列通知消息，形成通知消息列表，然后将通知消息列表显示在状态栏上。具体的，可以参考下述图5a中的步骤s519。
103.又例如，system ui所显示的通知消息被查看或删除时，还会将被查看或删除的通知消息通知给通知管理中心，通知管理中心也会将悬浮导航模块中被查看或删除的通知消息，同步通知system ui。具体的，可以参考下述图5a中的步骤s516至步骤s518、以及步骤s520至步骤s524。
104.在另一些实施例中，图3示出的电子设备的软件框架中也可以不具有system ui，即不显示通知消息列表至状态栏。
105.系统应用用于实现解锁、锁屏等系统功能。例如，本实施例中，系统应用解锁时会回调至悬浮导航模块。
106.悬浮导航模块，用于绘制并显示悬浮导航圆盘，其中，悬浮导航圆盘用于按照重要程度和紧急程度区分显示多个通知消息。
107.例如，在本实施例中，悬浮导航模块在通知管理中心注册监听，当悬浮导航模块响应到弹出圆盘的操作时，例如悬浮导航模块响应于系统应用的解锁操作，根据设置数据库中读取到的紧急程度临界值，将监听到的通知消息按照重要程度和紧急程度区分绘制在悬
浮导航圆盘中，并将绘制好的悬浮导航盘圆进行显示。具体的，可以参考下述图4a中的步骤s405至步骤s408、以及图5a的s506至步骤s509。
108.又例如，本实施例中，悬浮导航模块还会接收通知管理中心通知的已删除或已查看的通知消息，将已删除或查看的通知消息从绘制的圆盘中删除，更新绘制的圆盘。具体的，可以参考下述图5a中的步骤s520至步骤s524。
109.应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，api)和编程框架。应用程序框架层包括一些预先定义的函数。如图3所示，应用程序框架层可以包括通知管理中心和设置数据库。
110.通知管理中心用于使应用程序可以在状态栏中、悬浮导航圆盘中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理中心被用于告知下载完成，消息提醒等。通知管理中心还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。
111.例如，本实施例中，通知管理中心可以监听短消息应用和通话应用的通知消息，然后将监听到的通知消息分别发送至system ui和悬浮导航模块。具体的，可以参考下述图4a中的步骤403和图5a的s503。
112.又例如，通知管理中心还可以将system ui所绘制的通知消息列表中被查看或删除的通知消息，同步通知给悬浮导航模块。同样的，还可以将悬浮导航模块所绘制的圆盘中被查看或删除的通知消息，同步通知给system ui。具体的，可以参考下述图5a中的步骤s515至步骤s524。
113.设置数据库，用于存储设置数据。例如，在本实施例中，可以用于存储紧急程度的临界值。在另一些实施例中，也可以不具有设置数据库，紧急程度的临界值也可以存储于悬浮导航模块内部。具体的，可以参考下述图4a中的步骤s405和步骤s411，图5a的s506和s512。
114.android runtime包括核心库和虚拟机。android runtime负责安卓系统的调度和管理。
115.核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
116.应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
117.系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(media libraries)，三维图形处理库(例如：opengl es)，2d图形引擎(例如：sgl)等。
118.表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2d和3d图层的融合。例如，本实施例中，表面管理器可以用于为悬浮导航模块提供悬浮导航圆盘相关的2d和3d图层的融合，以及为system ui提供提供通知消息列表相关的2d和3d图层的融合。具体的，可以参考下述图4a显示悬浮导航圆盘的相关内容、以及图5a中显示悬浮导航圆盘和显示通知消息列表的相关内容。
119.三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。例如，本实施例中，用于实现悬浮导航模块所绘制的悬浮导航圆盘的图层处理，以及system ui绘制的通知消息列表的图层处理。具体的，可以参考下述图4a显示悬浮导航圆盘的相关内容、以及图5a中显示悬浮导航圆盘和显示通知消息列表的相关内容。
120.2d图形引擎是2d绘图的绘图引擎。
121.内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。例如，本实施例中，显示驱动用于驱动显示屏显示悬浮导航圆盘，以及驱动显示屏显示通知消息列表。具体的，可以参考下述图4a显示悬浮导航圆盘的相关内容、以及图5a中显示悬浮导航圆盘和显示通知消息列表的相关内容。
122.需要说明的是，本技术实施例虽然以android系统为例进行说明，但是其基本原理同样适用于基于ios或windows等操作系统的电子设备。
123.实施例一
124.参阅图4a，本技术的实施例提出了一种通知消息的处理方法，图4a示出的实施例方法可以不采用system ui绘制的通知消息列表展示通知消息，而通过悬浮导航模块所绘制的悬浮导航圆盘展示通知消息，该通知消息的处理方法应用于本技术实施例在前述提及的电子设备，具体包括以下步骤：
125.s401、悬浮导航模块向通知管理中心注册监听。
126.具体的，步骤s401可以理解为是悬浮导航模块向通知管理中心注册监听通知消息，注册监听之后，悬浮导航模块可实现监听获取通知管理中心所接收到的各个应用的通知消息，以便悬浮导航模块后续利用监听到的通知消息绘制悬浮导航圆盘。悬浮导航模块后续利用监听到的通知消息绘制悬浮导航圆盘的内容，具体可以参考下述的步骤s405至步骤s408的描述，此处不再赘述。
127.需要说明的是，悬浮导航模块可以只向通知管理中心注册一次监听，后续通知管理中心即可在每一次接收到通知消息时，均回调至悬浮导航模块，悬浮导航模块即可监听到通知管理中心所接收到的每一个通知消息。
128.其中，触发悬浮导航模块执行步骤s401的方式有很多，例如可以是电子设备开机则触发执行步骤s401，本技术实施例对此不作限制。
129.s402、悬浮导航模块向系统应用注册监听。
130.具体的，步骤s402可以理解为是悬浮导航模块向系统应用注册监听锁屏功能，以实现在监听到系统应用进行解锁时，悬浮导航模块可以控制是否绘制并展示悬浮导航圆盘至显示屏。具体可以参见下述的步骤s409至步骤s413的描述，此处不再赘述。
131.示例性的，可以是悬浮导航模块向系统应用中的锁屏模块注册监听，进而可监听到解锁和锁屏。
132.需要说明的是，悬浮导航模块可以只向系统应用注册一次监听，后续系统应用即可在每一次解锁时，回调至悬浮导航模块。
133.其中，触发悬浮导航模块执行步骤s402的方式有很多，例如可以是电子设备开机则触发执行步骤s402，本技术实施例对此不作限制。
134.还需要说明的是，步骤s401和步骤s402的执行先后顺序并不影响本技术实施例的实现，步骤s401和步骤s402中涉及到的注册监听的技术原理和过程，可以参考android系统
等操作系统中注册监听相关的技术原理和功能，此处不再赘述。
135.s403、应用发送通知消息至通知管理中心。
136.其中，通知消息可以理解为是应用的通知消息，可用于提醒或者推送用户查看应用相关的内容。例如应用为短消息应用时，短消息应用的通知消息可以为新接收短消息的提醒，应用为软件商城类的应用时，软件商城类的应用的通知消息可以为下载完成的提醒。通知消息可以由应用创建得到，也可以由应用对应的服务器向应用所在的客户端发送得到，通知消息的产生方式的不同并不影响本技术实施例的实现。
137.其中，应用的通知消息内可以携带有应用的包名、应用的图标、需要推送给用户的内容摘要、通知消息的重要程度(importance)、通知消息的接收时间等通知消息的属性信息。其中，通知消息的重要程度用于说明通知消息是否重要。通知消息的重要程度越高，说明通知消息越具有重要性。
138.通知消息的重要程度的值可以由应用设定，也可以由用户设定，例如用户若对某一个应用的通知消息较为重视，可以将该应用的通知消息的重要程度设定得较高。通知消息的接收时间也可以理解为是通知消息的产生时间，通知消息的接收时间与通知消息的查看时间之间的差值，能够反映通知消息对于用户而言的紧急程度，当通知消息的接收时间与通知消息的查看时间越接近，则说明通知消息对于用户来说越为紧急，越需要尽快查看，而通知消息的接收时间与通知消息的查看时间越远，则说明通知消息对于用户而言越不紧急，越不需要紧急查看。因此，通知消息中包括的信息可以直接或间接的反映出通知消息的重要程度和紧急程度。
139.示例性的，通知消息的紧急程度可以通过该通知消息所属应用的各个通知消息的历史接收时间和历史查看时间确定。例如，可以收集某一个应用在某个历史时段内的每一个通知消息的历史接收时间和历史查看时间，并计算每一个通知消息的历史接收时间与历史查看时间之间的差值，然后将计算出的每一个通知消息的历史接收时间与历史查看时间之间的差值进行平均，得到该应用当前的通知消息的紧急程度。
140.需要说明的是，通知消息的重要程度的取值可以与紧急程度的取值之间不具有任何关联性。即重要程度高的通知也可以紧急程度较低，例如系统升级提醒这类通知消息，虽然具有重要程度较高，但紧急程度较低，用户可以在空闲的时候再查看通知消息，然后进行系统升级。
141.在一些实施例中，步骤s403的实施方式可以为：通知管理中心监听电子设备内已安装的每一个应用，当有应用产生了通知消息时，通知管理中心即可监听并获取该应用的通知消息。
142.其中，步骤s403中应用发送的通知消息的数量本技术实施例不作限制，若应用产生的通知消息有n条，可将n条通知消息均发送至通知管理中心，由通知管理中心统一管理。
143.需要说明的是，前述对步骤s403的描述是针对每一个应用所进行的示例性说明，步骤s403的执行方可以是电子设备已安装的任意的应用。任意一个应用产生或接收到了通知消息之后，均可执行步骤s403。
144.通知消息中所包括的内容的具体形式有多种，具体可以参考android系统等操作系统中通知消息的相关内容，此处不再赘述。
145.s404、通知管理中心将每一个通知消息发送至悬浮导航模块。
146.由于步骤s401中，悬浮导航模块在通知管理中心中注册了监听，因此通知管理中心会将接收到的每一个通知消息，均回调至悬浮导航模块。悬浮导航模块进而可以接收到每一个应用的通知消息。
147.示例性的，可以是在每一次产生新的通知消息时，即可由产生通知消息的应用触发执行步骤s403至步骤s404，进而实现通知管理中心每一次接收到通知消息时，则将接收到的通知消息发送至悬浮导航模块。
148.s405、悬浮导航模块响应于弹出圆盘的操作，从设置数据库中读取每一个通知消息的紧急程度。
149.弹出圆盘的操作可以理解为是触发悬浮导航圆盘弹出的操作。悬浮导航圆盘用于显示通知消息。示例性，弹出圆盘的操作可以是点击悬浮导航圆点的操作，也可以是解锁操作。
150.举例说明，如图4b的(1)所示，当用户想查看通知消息时，用户执行点击或者长按悬浮导航控件20的操作，触发悬浮导航模块执行步骤s405。具体的，可以触发电子设备弹出圆盘的操作有很多，包括但不限于本技术实施例所提出的内容。
151.示例性的，设置数据库中可以存储有每一个应用的通知消息所对应的紧急程度。悬浮导航模块可以根据通知消息中携带的应用的包名，从设置数据库中读取到该通知消息对应的紧急程度。
152.示例性的，应用的通知消息所对应的紧急程度可以通过大数据收集用户对该应用的通知消息的响应时间确定。其中，响应时间指的是接收到通知消息的时间与查看通知消息的时间之间的时间间隔。响应时间越小，紧急程度越大。
153.示例性的，针对每一个应用设置数据库收集用户对该应用的每一个通知消息的响应时间，然后求取通知消息的平均响应时间。根据该应用的通知消息的平均响应时间，确定该应用的通知消息对应的紧急程度。在另一些实施例中，若设置数据库没有收集到某一个应用的通知消息的查看通知消息的时间，进而无法收集该应用的通知消息的响应时间时，可以将该通知消息的紧急程度值默认为0，或者默认为一个预设的负数。
154.示例性的，可以将求取出的平均响应时间代入到预设的计算规则中，计算出该应用的通知消息对应的紧急程度。还可以是预先存储好平均响应时间与紧急程度之间的关系对应表，通过使用平均响应时间查看关系对应表的方式，确定出该应用的通知消息对应的紧急程度。其中，平均响应时间越小，确定出的紧急程度越高。
155.需要说明的是，每一个应用的通知消息所对应的紧急程度的设定方式有很多，包括但不限于本技术实施例所提出的内容。
156.在另一些实施例中，也可以直接由用户设定通知消息所对应的紧急程度。举例说明，如图4c所示，图4c为app1的通知消息的设置界面，用户可通过滑动圆点70，调整app1的通知消息的紧急程度的值，还可以通过滑动圆点80，调整该app1的通知消息的重要程度的值。在一些实施例中，用户设定的app1的通知消息的紧急程度和重要程度的值可以存储在设置数据库中。进而在执行步骤s405的过程中，可以从设置数据库中读取用户设定的通知消息的紧急程度和重要程度。
157.需要说明的是，通知消息的紧急程度除了可以是从设置数据库中读取得到，也可以是存储在其他模块中，由其他模块中读取到，即悬浮导航模块读取每一个通知消息的紧
急程度的具体方式有很多，包括但不限于本技术所提出的内容。
158.s406、悬浮导航模块针对每一个通知消息，根据该通知消息的紧急程度和重要程度，确定该通知消息对应的圆盘位置。
159.其中，通知消息对应的圆盘位置可以理解为是通知消息显示在悬浮导航圆盘上的位置。悬浮导航圆盘可以通过各个通知消息对应的圆盘位置的不同，以区分各个通知消息的重要程度和紧急程度。例如，相同重要程度的通知消息可以划分在同样的区域，相同紧急程度的通知消息也可划分在同样的区域。
160.示例性的，可以将悬浮导航圆盘划分成第一象限、第二象限、第三象限以及第四象限这四个区域。然后根据通知消息的紧急程度和重要程度，确定通知消息对应的象限。举例说明，如图4b的(2)所示，悬浮导航圆盘划分成了4个象限，分别是第一象限30，第二象限40，第三象限50，以及第四象限60。
161.其中，通知消息的重要程度可以是从通知消息携带的信息中获取。在另一些实施例中，通知消息的重要程度也可以由用户设定，用户设定的通知消息可以存储在设置数据库中，悬浮导航模块可以从设置数据库中查看到通知消息的重要程度。示例性的，针对每一个通知消息，悬浮导航模块可以先查找是否存储有用户对该通知消息设定的重要程度，若存储有用户对该通知消息设定的重要程度，则从中获取该用户对该通知消息设定的重要程度，再执行步骤s406。若设置数据库中不存储有该用户对该通知消息设定的重要程度，则使用通知消息中携带的重要程度，执行步骤s406。示例性的，用户对通知消息设定的重要程度、紧急程度等属性信息可以均存储在设置数据库，也可以存储在其他模块。
162.示例性的，执行步骤s406的过程可以是，悬浮导航模块针对每一个通知消息，根据通知消息的紧急程度和重要程度，按照预设的通知筛选逻辑，确定该通知消息对应的圆盘位置。
163.示例性的，参阅图4d，图4d为本技术实施例针对每一个通知消息，提出的一种执行步骤s406的方式，应用于悬浮导航模块，悬浮导航模块通过执行图4d的流程，可根据任意一个通知消息的紧急程度和重要程度，确定该通知消息对应的圆盘位置，具体包括以下步骤：
164.s4001、判断通知消息的重要程度是否大于重要程度临界值。
165.其中，重要程度临界值用于区分重要的通知消息和不重要的通知消息。当通知消息的重要程度大于重要程度临界值，则认为该通知消息属于重要的通知消息，当通知消息的重要程度小于或等于重要程度临界值时，则认为该通知消息属于不重要的通知消息。
166.在一些实施例中，重要程度临界值可以由用户设定，用户可自定义一个重要程度临界值，以区分重要的通知消息和不重要的通知消息。在另一些实施例中，也可以是通过大数据收集各个应用的通知消息的重要程度，确定出一个重要程度临界值。例如可以对各个应用的通知消息的重要程度求取平均值，将求取得到的重要程度平均值作为重要程度临界值。也可以是根据经验设定重要程度临界值。需要说明的是，重要程度临界值的设定方式有很多，包括但不限于本技术实施例所提出的内容。
167.示例性的，重要程度临界值可以存储在设置数据库中，悬浮导航模块可以在执行步骤s4001之前，从设置数据库中获取重要程度临界值。在另一些实施例中，重要程度临界值可以是一个固定值，存储在悬浮导航模块中。
168.若步骤s4001判断出通知消息的重要程度大于重要程度临界值，则可以确定出通
知消息为重要的通知消息，确定出放置在悬浮导航模块的第一象限或第四象限，即放置在图4b的(2)中示出的圆盘的右半圆，进而再执行步骤s4002，进一步确定是将通知消息放置在第一象限还是第四象限。若步骤s4001判断出通知消息的重要程度小于或等于重要程度临界值，则可以确定出通知消息为不重要的通知消息，确定出放置在悬浮导航模块的第二象限或第三象限，即放置在图4b的(2)中示出的圆盘的左半圆，进而执行步骤s4003，进一步确定通知消息是放置在第二象限还是第三象限。
169.s4002、判断通知消息的紧急程度是否大于紧急程度临界值。
170.其中，紧急程度临界值用于区分重要的通知消息和不重要的通知消息。当通知消息的紧急程度大于紧急程度临界值，则认为该通知消息属于重要的通知消息，当通知消息的紧急程度小于或等于紧急程度临界值时，则认为该通知消息属于不重要的通知消息。
171.在一些实施例中，紧急程度临界值可以通过设置数据库中各个应用的通知消息所对应的紧急程度确定。例如，可以对各个应用的通知消息所对应的紧急程度求取平均值，将求取得到的紧急程度平均值作为紧急程度临界值。也可以是根据经验设定紧急程度临界值。需要说明的是，紧急程度临界值的设定方式有很多，包括但不限于本技术实施例所提出的内容。
172.示例性的，紧急程度临界值可以存储在设置数据库中，悬浮导航模块可以在执行步骤s4001之前，从设置数据库中获取紧急程度临界值。在另一些实施例中，紧急程度临界值可以是一个固定值，存储在悬浮导航模块中。
173.由前述步骤s4001中已确定出通知消息属于重要的通知消息，进而通过步骤s4002，可以确定出该通知消息是属于重要且紧急的通知消息，还是重要但不紧急的通知消息。
174.若步骤s4002判断出通知消息的紧急程度大于紧急程度临界值，则说明该通知消息为重要且紧急的消息，执行步骤s4004，确定该通知消息对应的圆盘位置为第一象限。
175.若步骤s4002判断出通知消息的紧急程度小于或等于紧急程度临界值，则说明该通知消息为重要但不紧急的消息，执行步骤s4005，确定该通知消息对应的圆盘位置为第四象限。
176.s4003、判断通知消息的紧急程度是否大于紧急程度临界值。
177.其中，紧急程度临界值的相关介绍可以参考前述步骤s4002中的相关描述，此处不再赘述。
178.由前述步骤s4001中已确定出通知消息属于不重要的通知消息，进而通过步骤s4003，可以确定出该通知消息是属于不重要但紧急的通知消息，还是不重要且不紧急的通知消息。
179.若步骤s4003判断出通知消息的紧急程度大于紧急程度临界值，则说明该通知消息为不重要但紧急的消息，执行步骤s4006，确定该通知消息对应的圆盘位置为第二象限。
180.若步骤s4006判断出通知消息的紧急程度小于或等于紧急程度临界值，则说明该通知消息为不重要且不紧急的消息，执行步骤s4007，确定该通知消息对应的圆盘位置为第三象限。
181.s4004、确定通知消息对应的圆盘位置为第一象限。
182.其中，第一象限的区域放置重要且紧急的通知消息，由前述步骤s4001和步骤
s4002，已确定出通知消息为重要且紧急的消息，因此确定出通知消息对应的圆盘位置为第一象限。
183.在另一些实施例中，还可以在执行完步骤s4004之后，进一步确定通知消息在第一象限中的具体位置。示例性的，可以根据通知消息的重要程度与紧急程度的乘积，确定通知消息在第一象限中的位置。例如，若通知消息的重要程度与紧急程度的乘积大于第一预设值，则确定通知消息在第一象限中的第一区域，若通知消息的重要程度与紧急程度的乘积小于或等于第一预设值，则确定通知消息在第一象限中的第二区域。其中，第一区域与悬浮导航圆盘的圆心之间的距离小于第二区域与悬浮导航圆盘的圆心的距离。即通知消息的重要程度与紧急程度的乘积越大，在第一象限中的位置离圆心越近。进而用户可以通过通知消息距离圆心的远近，优先查看离圆心更近的通知消息，实现优先查看最重要紧急的通知消息。
184.例如图4b的(2)所示，app1的通知消息经过图4d的流程后，确定出为重要紧急的消息，确定在圆盘中的第一象限。又通过通知消息的重要程度与紧急程度的乘积，确定出在第一象限中的第一区域，即在第一象限中距离圆心最近的区域。而app5的通知消息、app6的通知消息以及app7的通知消息则确定出了在第一象限中的第二区域，即在第一象限中距离圆心最远的区域。
185.需要说明的是，根据通知消息的重要程度和紧急程度，确定通知消息在第一象限中的位置的方式有很多，例如第一象限还可以包括两个以上的区域，离圆心越近的区域重要程度和紧急程度的乘积越高，确定通知消息在第一象限中的位置的方式包括但不限于本技术实施例所提出的内容。
186.s4005、确定通知消息对应的圆盘位置为第四象限。
187.其中，第四象限的区域放置重要但不紧急的通知消息。由前述步骤s4001和步骤s4002，已确定出通知消息为重要但不紧急的消息，因此确定出通知消息对应的圆盘位置为第四象限。
188.在另一些实施例中，还可以在执行完步骤s4005之后，进一步确定通知消息在第四象限中的具体位置。示例性的，可以根据通知消息的重要程度与紧急程度的乘积，确定通知消息在第四象限中的位置。例如，若通知消息的重要程度与紧急程度的乘积大于第二预设值，则确定通知消息在第四象限中的第一区域，若通知消息的重要程度与紧急程度的乘积小于或等于第二预设值，则确定通知消息在第四象限中的第二区域。其中，第一区域与悬浮导航圆盘的圆心之间的距离小于第二区域与悬浮导航圆盘的圆心的距离。即通知消息的重要程度与紧急程度的乘积越大，在第四象限中的位置离圆心越近。进而用户可以通过通知消息距离圆心的远近，优先查看离圆心更近的通知消息，实现优先查看最重要紧急的通知消息。
189.例如图4b的(2)所示，app2的通知消息经过图4d的流程后，确定出在第四象限，又通过通知消息的重要程度与紧急程度的乘积，确定出在第四象限中的第一区域，即在第四象限中距离圆心最近的区域。
190.需要说明的是，根据通知消息的重要程度和紧急程度，确定通知消息在第四象限中的位置的方式有很多，例如第四象限还可以包括两个以上的区域，离圆心越近的区域重要程度和紧急程度的乘积越高，确定通知消息在第四象限中的位置的方式包括但不限于本
申请实施例所提出的内容。
191.s4006、确定通知消息对应的圆盘位置为第二象限。
192.其中，第二象限的区域放置不重要但紧急的通知消息。由前述步骤s4001和步骤s4003，已确定出通知消息为不重要但紧急的消息，因此确定出通知消息对应的圆盘位置为第二象限。
193.在另一些实施例中，还可以在执行完步骤s4006之后，进一步确定通知消息在第二象限中的具体位置。示例性的，可以根据通知消息的重要程度与紧急程度的乘积，确定通知消息在第二象限中的位置。具体的，可以参考前述s4004中根据通知消息的重要程度与紧急程度的乘积，确定通知消息在第一象限的位置的方式，此处不再赘述。
194.例如图4b的(2)所示，app3的通知消息以及app4的通知消息，分别经过图4d的流程后，确定出在第二象限，又通过通知消息的重要程度与紧急程度的乘积，确定出app3的通知消息和app4的通知消息在第二象限中的第一区域，即在第二象限中距离圆心最近的区域。
195.需要说明的是，根据通知消息的重要程度和紧急程度，确定通知消息在第二象限中的位置的方式有很多，例如第二象限还可以包括两个以上的区域，离圆心越近的区域重要程度和紧急程度的乘积越高，确定通知消息在第二象限中的位置的方式包括但不限于本技术实施例所提出的内容。
196.s4007、确定通知消息对应的圆盘位置为第三象限。
197.其中，第三象限的区域放置不重要且不紧急的通知消息。由前述步骤s4001和步骤s4003，已确定出通知消息为不重要且不紧急的消息，因此确定出通知消息对应的圆盘位置为第三象限。
198.在另一些实施例中，还可以在执行完步骤s4007之后，进一步确定通知消息在第三象限中的具体位置。示例性的，可以根据通知消息的重要程度与紧急程度的乘积，确定通知消息在第二象限中的位置。具体的，可以参考前述s4004中根据通知消息的重要程度与紧急程度的乘积，确定通知消息在第一象限的位置的方式，此处不再赘述。
199.例如图4b的(2)所示，app8的通知消息，经过图4d的流程后，确定出在第三象限，又通过通知消息的重要程度与紧急程度的乘积，确定出app8的通知消息在第三象限中的第二区域，即在第三象限中距离圆心最远的区域。
200.需要说明的是，根据通知消息的重要程度和紧急程度，确定通知消息在第三象限中的位置的方式有很多，例如第三象限还可以包括两个以上的区域，离圆心越近的区域重要程度和紧急程度的乘积越高，确定通知消息在第三象限中的位置的方式包括但不限于本技术实施例所提出的内容。
201.由图4d示出的流程可知，第一象限用于显示重要且紧急的通知消息，第二象限用于显示不重要但紧急的通知消息，第三象限用于显示不重要且不紧急的消息，第四象限用于显示重要但不紧急的通知消息。通过图4d的流程，确定每一个通知消息对应的圆盘位置后，用户可以优先查看第一象限的通知消息，即最为重要紧急的通知消息，然后再查看第二象限或者第四象限的消息，最后再查看第三象限的消息。即通过圆盘的位置，区分了各个通知消息的重要紧急程度，便于用户优先查看重要且紧急的消息，避免用户遗漏查看重要紧急的通知消息。
202.还需要说明的是，图4d仅仅是根据通知消息的重要程度和紧急程度，确定通知消
息对应的圆盘位置的一种实施方式。
203.在另一些实施例中，根据通知消息的重要程度和紧急程度，所确定出的通知消息对应的圆盘位置也可以与图4d示出的不同，例如执行步骤s406的方式还可以是，悬浮导航模块针对每一个通知消息，计算该通知消息的重要程度与紧急程度的乘积。然后根据通知消息的重要程度与紧急程度的乘积，确定通知消息对应的圆盘区域。
204.例如，可以将悬浮导航圆盘划分为第一圆环区域和第二圆环区域。若通知消息的重要程度与紧急程度的乘积大于第三预设值，则确定出通知消息对应的圆盘区域为第一圆环区域，若通知消息的重要程度与紧急程度的乘积小于或等于第三预设值，则确定出通知消息对应的圆盘区域为第二圆环区域。其中，第一圆环区域用于显示重要程度以及紧急程度高的通知消息，第二圆环区域用于显示重要程度以及紧急程度较低的通知消息。
205.举例说明，如图4e所示，第一圆环区域为90，第二圆环区域为91，由于app1的通知消息、app2的通知消息、app3的通知消息以及app4的通知消息的重要程度与紧急程度的乘积均大于第三预设值，因此确定出app1的通知消息、app2的通知消息、app3的通知消息以及app4的通知消息对应的圆盘位置为第一圆环区域90。而app5的通知消息、app6的通知消息、app7的通知消息以及app8的通知消息的重要程度与紧急程度的乘积均小于或等于第三预设值，因此确定出而app5的通知消息、app6的通知消息、app7的通知消息以及app8的通知消息对应的圆盘位置为第二圆环区域91。
206.还需要说明的是，在另一些实施例中，还可以使用颜色结合圆盘的位置，进一步区分通知消息的重要程度和紧急程度，例如，对于用于显示重要且紧急的通知消息的第一象限，可以确定第一区域对应的颜色最深，而第二象限和第三象限的区域对应的颜色深度次之，第三象限对应的颜色深度最浅。进而用户就可以按照颜色的深浅，优先查看颜色深的区域的通知消息。
207.实现在圆盘上区分不同重要程度、不同紧急程度的通知消息的方式有很多，步骤s406仅仅是其中一种实施方式，在另一些实施例中，悬浮导航模块也可以针对每一个通知消息，根据该通知消息的紧急程度和重要程度，确定该通知消息对应的圆盘颜色。其中，通知消息对应的圆盘颜色指的是通知消息显示在圆盘中的区域的颜色。即使用不同的颜色区分不同重要程度、不同紧急程度的通知消息。在另一些实施例中，还可以使用通知消息所在区域的面积的大小，以区分不同重要程度、不同紧急程度的通知消息等等。
208.在另一些实施例中，步骤s406中的通知消息对应的圆盘位置也可以由用户设定，例如用户可以直接设定app1的通知消息对应的圆盘位置为第一象限。
209.s407、悬浮导航模块根据每一个通知消息和通知消息对应的圆盘位置，绘制悬浮导航圆盘。
210.具体的，悬浮导航模块针对每一个通知消息，将通知消息绘制在悬浮导航圆盘中该通知消息对应的圆盘位置，以使得悬浮导航模块可以根据重要程度和紧急程度，使用圆盘位置区分显示多个通知消息。
211.示例性的，若通知消息中携带有通知消息所属app的图标，通知消息的摘要等信息，也可以将通知消息中携带的信息绘制在通知消息对应的圆盘位置上。
212.在另一些实施例中，也可以使用除圆盘位置之外的其他的圆盘属性来区分各个通知消息的重要程度和紧急程度。例如，可以根据通知消息的重要程度和紧急程度，确定通知
消息对应的圆盘颜色，然后根据通知消息对应的圆盘颜色，绘制悬浮导航圆盘，实现通过通知消息对应的圆盘颜色，在圆盘中区分各个通知消息的重要程度和紧急程度。
213.在另一些实施例中，悬浮导航模块可以调用绘制渲染线程，根据每一个通知消息对应的圆盘位置，绘制悬浮导航圆盘。悬浮导航模块根据每一个通知消息对应的圆盘位置，绘制悬浮导航圆盘具体方式有很多，具体可以参考android等操作系统的绘制渲染流程，本技术实施例不作限制。
214.s408、悬浮导航模块显示悬浮导航圆盘。
215.其中，悬浮导航圆盘可以理解为是步骤s407绘制出的悬浮导航圆盘。悬浮导航圆盘用于将每一个通知消息显示在通知消息对应的圆盘位置，以实现区分显示每一个通知消息的重要程度和紧急程度，进而便于用户迅速找到最重要最紧急的通知消息，而不会出现遗漏重要紧急的通知消息的情况。
216.悬浮导航模块显示悬浮导航圆盘的具体过程，可以参考android等操作系统将图像显示至显示屏的过程，此处不再赘述。
217.示例性的，悬浮导航圆盘包括每一个通知消息对应的控件。悬浮导航圆盘可响应于用户对任意一个通知消息对应的控件的操作，跳转显示该通知消息对应的详情内容。
218.在一些实施例中，悬浮导航模块所显示的悬浮导航圆盘悬浮在手机的桌面页面，悬浮导航圆盘可以在手机的桌面页面上可移动、可编辑。例如长按悬浮导航圆盘，可以拖拽移动至手机的另一个页面。例如可以上滑收起悬浮导航圆盘，可以编辑调整悬浮导航的尺寸等等。
219.举例说明，如图4b的(1)所示，当用户想查看通知消息时，用户执行点击或者长按悬浮导航控件20的操作，触发悬浮导航模块执行步骤s405至步骤s408，进而手机的界面变化为图4b的(2)。即弹出悬浮导航圆盘，将各个通知消息显示在了悬浮导航圆盘上。其中，第一象限内显示的重要且紧急的通知消息，且第一象限中越靠近圆心的通知消息，在第一象限的通知消息中的重要程度以及紧急程度越高。而第二象限内显示了不重要但紧急的消息，同样的，越靠近圆心的通知消息，在第二象限的通知消息中的重要程度以及紧急程度越高。第三象限内显示不重要且不紧急的消息，第四象限内则显示重要但不紧急的消息。
220.在一些实施例中，执行步骤s408之后，还可以响应于用户点击悬浮导航圆盘内的通知消息的操作，显示用户点击的通知消息对应的详情界面。通知消息对应的详情界面用于显示通知消息的详情内容。例如，如果点击的是短信的通知消息，则在显示屏上显示短信界面，界面内展示短信的详情内容。
221.举例说明，继续参阅图4b的(2)，用户长按悬浮导航圆盘，将悬浮导航圆盘向上移动，进入图4b的(3)。用户将悬浮导航圆盘移动至了图4b的(3)所示出的位置后，迅速从第一象限中挑选出最为重要紧急的app1的通知消息点击查看，手机的界面进入图4b的(4)，展示app1的通知消息对应的详情内容。
222.由步骤s406至步骤s408可知，本实施例中，悬浮导航模块根据每一个通知消息的重要程度和紧急程度，绘制悬浮导航圆盘，将绘制出的悬浮导航圆盘进行显示。悬浮导航圆盘用于根据重要程度和紧急程度，区分显示每一个通知消息，以使得用户通过悬浮导航圆盘可以区分出每一个通知消息的紧急程度和重要程度。而悬浮导航圆盘区分显示每一个通知消息的方式有很多，例如可以使用步骤s406至步骤s408的方式，通过通知消息对应的圆
盘位置的方式实现区分显示，也可以使用颜色、或者颜色结合位置，实现按照重要程度和紧急程度区分显示每一个通知消息。
223.示例性的，步骤s405至步骤s408可以是在电子设备接收到用户弹出圆盘的操作时触发执行的。即每一次电子设备需要显示悬浮导航圆盘时，可以通过步骤s405至步骤s408，实现显示悬浮导航圆盘。需要说明的是，悬浮导航圆盘中显示的每一个通知消息均指的是未被用户查看且未被用户删除的通知消息，即步骤s405至步骤s408，仅用于确定未被用户查看且未被用户删除的每一个通知消息，在悬浮导航圆盘中的位置。
224.示例性的，悬浮导航模块显示悬浮导航圆盘的方式有很多，例如可以在电子设备的显示界面以弹出悬浮导航圆盘的方式显示悬浮导航圆盘，也可以是闪现悬浮导航圆盘的方式显示悬浮导航圆盘等，本技术对于显示悬浮导航圆盘的方式不作限制。
225.其中，本技术实施例中的绘制显示悬浮导航圆盘的过程可以涉及到表面管理器、三维图形处理库、显示驱动等多个模块配合执行完成，具体的显示过程和原理可以参考android系统等操作系统的实现过程。
226.s409、系统应用响应于解锁操作，对电子设备进行解锁。
227.其中，步骤s409与步骤s405之间不具有先后执行顺序的限制。具体的，当电子设备进入锁屏状态之后，用户需要解锁以使用电子设备时，系统应用接收到用户的解锁操作，触发执行步骤s409。
228.电子设备解锁之后，即可进入可供用户操作的状态。其中，用户的解锁操作有很多，例如可以是上滑解锁、输入密码进行解锁等，本技术实施例对于具体的解锁操作不作限制。
229.s410、系统应用将解锁信息发送至悬浮导航模块。
230.由前述的步骤s402可知，悬浮导航模块向系统应用注册了监听，因此当系统应用对电子设备进行解锁时，即可将解锁信息发送(回调)至悬浮导航模块，以通知悬浮导航模块当前电子设备已触发解锁。
231.其中，解锁信息用于说明当前电子设备进行了解锁。
232.s411、悬浮导航模块从设置数据库中读取每一个通知消息的紧急程度。
233.其中，步骤s411中的每一个通知消息指的是悬浮导航模块通过步骤s404接收到的、未被用户查看、未被用户删除的通知消息。
234.具体的，悬浮导航模块从设置数据库中读取每一个通知消息的紧急程度的原理和执行过程可以操作前述步骤s405的相关内容，此处不再赘述。
235.s412、悬浮导航模块根据每一个通知消息的重要程度和紧急程度，确定是否存在重要紧急的通知消息。
236.其中，重要紧急的通知消息可以理解为是需要用户紧急查看的重要通知消息。针对每一个通知消息，悬浮导航模块可以通过通知消息的重要程度和紧急程度，确定该通知消息是否为重要紧急的通知消息。例如，悬浮导航模块判断该通知消息的重要程度与紧急程度的乘积是否大于重要紧急程度临界值，若大于重要紧急程度临界值，则认为该通知消息为重要紧急的通知消息。若小于或等于重要紧急程度临界值，则认为该通知消息不为重要紧急的通知消息。
237.当悬浮导航模块确定存在有重要紧急的通知消息时，则执行步骤s413，以避免用
户错过重要紧急的通知消息。当悬浮导航模块确定不存在重要紧急的通知消息，则结束流程。
238.s413、悬浮导航模块显示悬浮导航圆盘。
239.其中，悬浮导航模块显示悬浮导航圆盘的过程和原理，可以参考前述步骤s406至步骤s408的相关内容，即悬浮导航模块针对每一个通知消息，根据该通知消息的紧急程度和重要程度，确定该通知消息对应的圆盘位置，然后再根据通知消息以及通知消息对应的圆盘位置，绘制并显示悬浮导航圆盘。
240.由于步骤s412确定出了存在重要紧急的通知消息，因此悬浮导航模块在用户完成解锁之后，就将悬浮导航圆盘显示给用户，以提醒用户查看通知消息，避免遗漏重要紧急的通知消息。
241.示例性的，悬浮导航模块显示悬浮导航圆盘的方式有很多，例如可以在电子设备的显示界面以弹出悬浮导航圆盘的方式显示悬浮导航圆盘，例如可以在显示悬浮导航圆盘时配以振动提醒。本技术实施例对于显示悬浮导航圆盘的方式不作限制。
242.当用户在完成解锁后在显示界面看到悬浮导航圆盘，即可了解到当前有需要紧急查看的重要通知，进而通过悬浮导航圆盘查看通知消息。
243.举例说明，如图4f的(1)所示，为手机的锁屏界面，当用户向右滑动解锁时，触发手机执行步骤s409至步骤s413，由于执行步骤s412时确定有重要紧急的通知消息，因此手机的界面进入到图4f的(2)，显示悬浮导航圆盘。其中，图4f的(2)的相关描述可以参考前述的图4b的(2)此处不再赘述。
244.在一些实施例中，也可以不执行步骤s412，直接执行步骤s413，即每一次电子设备进行解锁，即触发显示悬浮导航圆盘，不只是在存在有重要紧急的通知消息时显示。
245.需要说明的是，图4a示出的实施例中的悬浮导航圆盘仅仅是本实施例中的一种通知区域控件的示例，本实施例中也可以使用其他任意形状、颜色、背景的通知区域控件，以根据重要程度和紧急程度，区分显示每一个通知消息，本技术实施例对于通知区域控件的具体外观不作限制。
246.实施例二
247.参阅图5a，本技术的实施例提出了一种通知消息的处理方法，图5a示出的实施例方法在仍然有采用system ui绘制的通知消息列表展示通知消息的基础上，还通过悬浮导航模块所绘制的悬浮导航圆盘展示通知消息，该通知消息的处理方法应用于本技术实施例在前述提及的电子设备，具体包括以下步骤：
248.s501、悬浮导航模块向通知管理中心注册监听。
249.具体的，步骤s501的执行过程和原理，可以参考前述图4a示出的步骤s401的执行过程和原理，此处不再赘述。
250.s502、悬浮导航模块向系统应用注册监听。
251.具体的，步骤s502的执行过程和原理，可以参考前述图4a示出的步骤s402的执行过程和原理，此处不再赘述。
252.s503、应用发送通知消息至通知管理中心。
253.具体的，步骤s503的执行过程和原理，可以参考前述图4a示出的步骤s403的执行过程和原理，此处不再赘述。
254.s504、通知管理中心将每一个通知消息发送至悬浮导航模块。
255.具体的，步骤s504的执行过程和原理，可以参考前述图4a示出的步骤s404的执行过程和原理，此处不再赘述。
256.s505、通知管理中心将每一个通知消息发送至system ui。
257.其中，步骤s504和步骤s505的执行先后顺序不作限制。示例性的，实现通知管理中心发送每一个通知消息至system ui的方式，可以参考前述步骤s501至步骤s504部分的相关内容、以及前述图1a的通知消息列表的生成过程的相关内容。示例性的，可以通过system ui向通知管理中心注册监听的方式，实现令通知管理中心将接收到的每一个通知消息发送至system ui。
258.s506、悬浮导航模块响应于弹出圆盘的操作，从设置数据库中读取每一个通知消息的紧急程度。
259.具体的，步骤s506的执行过程和原理，可以参考前述图4a示出的步骤s405的执行过程和原理，此处不再赘述。
260.s507、悬浮导航模块针对每一个通知消息，根据该通知消息的紧急程度和重要程度，确定该通知消息对应的圆盘位置。
261.具体的，步骤s507的执行过程和原理，可以参考前述图4a示出的步骤s406的执行过程和原理，此处不再赘述。
262.s508、悬浮导航模块根据每一个通知消息和通知消息对应的圆盘位置，绘制悬浮导航圆盘。
263.具体的，步骤s508的执行过程和原理，可以参考前述图4a示出的步骤s407的执行过程和原理，此处不再赘述。
264.s509、悬浮导航模块显示悬浮导航圆盘。
265.具体的，步骤s509的执行过程和原理，可以参考前述图4a示出的步骤s408的执行过程和原理，此处不再赘述。
266.s510、系统应用响应于解锁操作，对电子设备进行解锁。
267.具体的，步骤s510的执行过程和原理，可以参考前述图4a示出的步骤s409的执行过程和原理，此处不再赘述。
268.s511、系统应用将解锁信息发送至悬浮导航模块。
269.具体的，步骤s511的执行过程和原理，可以参考前述图4a示出的步骤s410的执行过程和原理，此处不再赘述。
270.s512、悬浮导航模块从设置数据库中读取每一个通知消息的紧急程度。
271.具体的，步骤s512的执行过程和原理，可以参考前述图4a示出的步骤s411的执行过程和原理，此处不再赘述。
272.s513、悬浮导航模块根据每一个通知消息的重要程度和紧急程度，确定是否存在重要紧急的通知消息。
273.具体的，步骤s513的执行过程和原理，可以参考前述图4a示出的步骤s412的执行过程和原理，此处不再赘述。
274.s514、悬浮导航模块显示悬浮导航圆盘。
275.具体的，步骤s514的执行过程和原理，可以参考前述图4a示出的步骤s413的执行
过程和原理，此处不再赘述。
276.s515、悬浮导航模块响应于用户点击所述第一通知区域内的通知消息的操作，将已查看的通知消息发送至通知管理中心。
277.其中，已查看的通知消息指的是用户已进行查看的通知消息。由于前述步骤s514中向用户显示了悬浮导航圆盘，因此用户可能会对悬浮导航圆盘进行查看通知消息。当用户查看通知消息时，则触发悬浮导航模块执行步骤s515。
278.示例性的，当悬浮导航模块接收到用户查看通知消息的操作时，响应于用户查看通知消息的操作，将查看的通知消息发送至通知管理中心，以通知通知管理中心该通知消息不再需要提供给用户查看。其中，悬浮导航模块接收到用户查看通知消息的操作时，还响应于用户查看通知消息的操作，跳转显示通知消息对应的详情内容。
279.其中，查看通知消息的操作的具体形式本技术实施例不作限制。
280.s516、通知管理中心将已查看的通知消息发送至system ui。
281.其中，已查看的通知消息为用户通过步骤s514中显示的悬浮导航圆盘所查看的通知消息。
282.通知管理中心将接收到的已查看的通知消息回调至system ui，进而可以使得system ui中存储的所有待查看的通知消息与悬浮导航模块中的一致。后续在显示通知消息列表时，即可不再将已查看的通知消息显示给用户。
283.示例性的，在执行步骤s516之后，system ui可以从步骤s505中接收到的通知消息中，删除掉已查看的通知消息，以保持system ui中存储的所有待查看的通知消息与悬浮导航模块中的一致。
284.需要说明的是，步骤s515至步骤s516可以是由悬浮导航模块接收到查看通知消息的操作触发执行，若未接收到查看通知消息的操作，则不执行步骤s515至步骤s516。
285.s517、悬浮导航模块响应于删除通知消息的操作，将已删除的通知消息发送至通知管理中心。
286.其中，已删除的通知消息指的是用户未查看而直接删除的通知消息。由于前述步骤s514中向用户显示了悬浮导航圆盘，因此用户可能会对悬浮导航圆盘进行删除通知消息，以使得悬浮导航圆盘不再为用户显示该通知消息。
287.当悬浮导航模块接收到用户删除通知消息的操作时，悬浮导航模块响应于用户删除通知消息的操作，将已删除的通知消息发送给通知管理中心。
288.其中，删除通知消息的操作的具体形式本技术实施例不作限制。
289.s518、通知管理中心将已删除的通知消息发送至system ui。
290.其中，已删除的通知消息为用户通过步骤s514中显示的悬浮导航圆盘所删除的通知消息。
291.通知管理中心将接收到的已删除的通知消息回调至system ui，进而可以使得system ui中存储的所有待查看的通知消息与悬浮导航模块中的一致。后续在显示通知消息列表时，即可不再将已删除的通知消息显示给用户。示例性的，在执行步骤s518之后，system ui可以从步骤s505中接收到的通知消息中，删除掉已删除的通知消息，以保持system ui中存储的所有待查看的通知消息与悬浮导航模块中的一致。
292.需要说明的是，步骤s517至步骤s517可以是由悬浮导航模块接收到删除通知消息
的操作触发执行，若未接收到查看通知消息的操作，则不执行步骤s517至步骤s518。
293.s519、system ui响应于用户的下拉状态栏的操作，显示通知消息列表。
294.其中，通知消息列表用于按照接收到通知消息的时间顺序，显示每一个通知消息。其中，若system ui在步骤s516中接收到了已查看的通知消息，则显示的通知消息列表中不包括已查看的通知消息。若system ui在步骤s518中接收到了已删除的通知消息，则显示的通知消息列表中不包括已删除的通知消息。
295.在另一些实施例中，若用户未触发执行步骤s515至s518，则system ui显示的通知消息列表中，包括每一个从步骤s505中接收到的通知消息。
296.示例性的，执行步骤s515的过程可以是，system ui将每一个通知消息后按照通知消息的接收时间(即通知管理中心接收到通知消息的时间，也可以理解为是通知消息的产生时间)进行排列，然后当system ui接收到下拉状态栏的操作时，则响应用户的下拉状态栏的操作，根据排列好的通知消息，绘制通知消息列表，将绘制后的通知消息列表进行显示。示例性的，还可以是在接收到用户的下拉状态栏的操作之后，再触发system ui按照通知消息的接收时间，对每一个通知消息进行排列，然后绘制生成通知消息列表，并显示通知消息列表。具体的，通知消息列表的显示过程还可以参考前述对图1a和图1b的相关描述。
297.需要说明的是，本技术实施例对于步骤s519与步骤s505之间的执行先后顺序可不作限制，即步骤s519可在s505之前触发，也可在步骤s505之后触发。
298.其中，本技术实施例中的绘制显示通知消息列表的过程可以涉及到表面管理器、三维图形处理库、显示驱动等多个模块配合执行完成，具体的显示过程和原理可以参考android系统等操作系统的实现过程。
299.s520、system ui响应于用户点击所述第一通知区域内的通知消息的操作，将已查看的通知消息发送至通知管理中心。
300.其中，步骤s520的执行过程和原理可以参考前述的步骤s515，区别点在于步骤s520中的已查看的消息，是用户通过通知消息列表查看的通知消息，且步骤s520由system ui执行。
301.s521、通知管理中心将已查看的通知消息发送至悬浮导航模块。
302.其中，步骤s521的执行过程和原理，可以参考前述的步骤s516，区别点在于步骤s521中的已查看的通知消息是发送至悬浮导航模块，目的在于使悬浮导航模块中存储的待查看的通知消息能与system ui中的一致。后续在悬浮导航模块显示悬浮导航圆盘时，即可不再将已查看的通知消息显示给用户。
303.示例性的，在执行步骤s521之后，悬浮导航模块可以从步骤s504中接收到的通知消息中，删除掉已查看的通知消息，以保持悬浮导航模块中存储的所有待查看的通知消息与system ui中的一致。
304.s522、system ui响应于删除通知消息的操作，将已删除的通知消息发送至通知管理中心。
305.其中，步骤s522的执行过程和原理可以参考前述的步骤s517，区别点在于步骤s522中的已删除的消息，是用户通过通知消息列表删除的通知消息，且步骤s522由system ui执行。
306.s523、通知管理中心将已删除的通知消息发送至悬浮导航模块。
307.其中，步骤s523的执行过程和原理，可以参考前述的步骤s518，区别点在于步骤s523中的已删除的通知消息是发送至悬浮导航模块，目的在于使悬浮导航模块中存储的待查看的通知消息能与system ui中的一致。后续在悬浮导航模块显示悬浮导航圆盘时，即可不再将已删除的通知消息显示给用户。
308.示例性的，在执行步骤s523之后，悬浮导航模块可以从步骤s504中接收到的通知消息中，删除掉已删除的通知消息，以保持悬浮导航模块中存储的所有待查看的通知消息与system ui中的一致。
309.s524、悬浮导航模块响应于弹出圆盘操作，刷新显示悬浮导航圆盘。
310.其中，由于前述步骤s520至步骤s523中，悬浮导航模块接收到了已删除的通知消息和已查看的通知消息，因此步骤s524中显示的悬浮导航圆盘与前述的s514中显示的悬浮导航圆盘有所区别，步骤s524中的悬浮导航模块中不包括已删除的通知消息和已查看的通知消息，实现悬浮导航圆盘中仅显示待查看的通知消息。
311.其中，悬浮导航模块响应于弹出圆盘操作，刷新显示悬浮导航圆盘的过程和原理可以参考前述步骤s506至步骤s509的显示悬浮导航圆盘的相关描述，此处不再赘述。
312.本实施例中，电子设备既可以通过悬浮导航圆盘，按照重要程度和紧急程度，区分显示每一个通知消息，也可以通过通知消息列表按照接收时间的顺序显示每一个通知。通过s515至s518、以及步骤s520至s523，保障悬浮导航模块与system ui之间存储的待查看通知消息的一致性，实现让通知消息列表和悬浮导航圆盘均能够显示每一个待查看的通知消息。
313.举例说明，用户下拉状态栏后，触发执行步骤s519，进而显示如图5b的(1)所示的界面，界面上的通知消息列表显示有app1的通知消息、app2的通知消息、app3的通知消息以及app4的通知消息。用户向左滑动之后进入图5b的(2)的界面，用户从图5b的(2)中的通知列表中点击查看app4的通知消息，触发执行步骤s520至步骤s521，并进入到图5b的(3)，显示app4的消息4的详情内容。用户又点击主界面控件500，返回至图5b的(4)的主界面。在图5b的(4)的主界面上，用户点击悬浮圆点20，触发执行s524，进入到图5b的(5)，图5b的(5)所显示的悬浮导航圆盘中区分显示了app1的通知消息、app2的通知消息、app3的通知消息、app5的通知消息、app6的通知消息、app7的通知消息以及app8的通知消息，而不再显示用户已查看的app4的通知消息。
314.需要说明的是，步骤s524除了可以是由弹出圆盘的操作触发的，也可以是如步骤s510至步骤s514的方式触发显示悬浮导航圆盘的，即步骤s524中触发圆盘显示的方式本技术不作限制。
315.还需要说明的是，图4a和图5a中涉及到的应用、通知管理中心、悬浮导航模块、系统应用、设置数据库、以及system ui的功能介绍等相关描述，可以参考前述图3中的相关内容，此处不再赘述。
316.其中，本技术实施例中将前述提及的悬浮导航圆盘统称为第一通知区域，第一通知区域用于根据每一个通知消息的紧急程度和重要程度，区分显示每一个通知消息的控件。本技术实施例还将前述提及的通知消息列表则统称为第二通知区域，第二通知区域用于显示按照接收时间顺序排列的每一个通知消息的控件。第一通知区域的形状除了可以如前述提及的悬浮导航圆盘的形状和样式，也可以是其他形状、样式的通知区域，只需能根据
每一个通知消息的紧急程度和重要程度，区分显示每一个通知消息的控件，以使得用户通过第一通知区域可挑选出重要紧急的通知消息即可。
317.本技术实施例中，还将system ui发送至通知管理中心的已查看的通知消息，统称为用于指示已查看的第二通知区域内的通知消息的信息，用于指示已查看的第二通知区域内的通知消息的信息除了可以是已查看的通知消息，也可以是已查看的通知消息的标识，其中还可以携带有发送方的标识。本技术还将system ui发送至通知管理中心的已删除的通知消息，统称为用于指示已删除的第二通知区域内的通知消息的信息。
318.本技术实施例中，还将悬浮导航模块发送至通知管理中心的已查看的通知消息，统称为用于指示已查看的第一通知区域内的通知消息的信息，用于指示已查看的第一通知区域内的通知消息的信息除了可以是已查看的通知消息，也可以是已查看的通知消息的标识，其中还可以携带有发送方的标识。本技术还将悬浮导航模块发送至通知管理中心的已删除的通知消息，统称为用于指示已删除的第一通知区域内的通知消息的信息。
319.本技术实施例中，通知消息的重要程度和紧急程度均可以使用具体的数值代表。
320.参阅图5c，基于前述图4a和图4b本技术实施例提出了一种通知消息的处理方法，具体包括以下步骤：
321.s5001、响应于用户的点击操作，显示第一通知区域，第一通知区域用于根据每一个通知消息的紧急程度和重要程度，区分显示每一个通知消息的控件。
322.基于前述图4a和图5a可知，步骤s405至步骤s413、以及步骤s506至步骤s514的过程可以看出，本技术实施例可以通过响应于用户的点击操作，显示第一通知区域，第一通知区域用于根据每一个通知消息的紧急程度和重要程度，区分显示每一个通知消息的控件。
323.其中，用户的点击操作可以是如图4a和图5a中示出的，点击图4b的悬浮导航控件20。也可以是其他类型的用户操作触发显示第一通知区域，例如可以是语音触发，唤醒显示第一通知区域，还可以是用户下拉触发，本技术实施例对此不作限制。
324.基于前述对图4a、图4b以及图5a中的步骤s515的描述可知，第一通知区域k可以用于根据每一个通知消息的紧急程度和重要程度，通过通知消息的控件在第一通知区域内的显示位置和/或显示颜色，区分显示每一个通知消息的控件。即实现按照紧急程度和重要程度，区分显示每一个通知消息的方式有很多，例如可以使用通知消息的控件在第一通知区域内的显示位置和/或显示颜色区分。另一些实施例中，第一通知区域，包括：多个显示区域，每一个所述显示区域上分别显示属于显示区域的通知消息的控件。不同的显示区域上显示的通知消息的重要程度或紧急程度互不相同。其中，第一通知区域的多个显示区域具体可以是图4b示出的第一象限30，第二象限40，第三象限50，以及第四象限60，也可以是图4e示出的第一圆环区域90和第二圆环区域91。
325.基于前述图4d中对悬浮导航圆盘的描述可知，第一显示区域用于显示代表重要程度的数值大于重要程度临界值、且代表紧急程度的数值大于紧急程度临界值的通知消息的控件。第二显示区域用于显示代表重要程度的数值不大于所述重要程度临界值、且代表紧急程度的数值大于所述紧急程度临界值的通知消息的控件。第三显示区域用于显示代表重要程度的数值不大于重要程度临界值、且代表紧急程度的数值不大于所述紧急程度临界值的通知消息的控件。第四显示区域用于显示代表重要程度的数值大于重要程度临界值、且代表紧急程度的数值不大于紧急程度临界值的通知消息的控件。其中，第一显示区域可以
为圆盘的第一象限的区域，第二显示区域可以为圆盘的第二象限的区域，第三显示区域可以为圆盘的第三象限的区域，第四显示区域可以为圆盘的第四象限的区域。圆盘的第一象限、第二象限、第三象限以及第四象限是以圆盘的圆心为原点划分出的。
326.在另一些实施例中，针对每一个显示区域，显示区域内显示的通知消息的控件和第一通知区域中心点之间的距离越小，则通知消息的重要紧急程度越高，代表通知消息的重要紧急程度的数值，通过对代表通知消息的重要程度和紧急程度的数值计算得到，例如代表通知消息的重要紧急程度的数值可以为代表通知消息的重要程度和紧急程度的数值的乘积，具体可以参见图4b的(2)的描述，此处不再赘述。
327.在另一些实施例中，第一通知区域，包括：多个显示区域，每一个显示区域上分别显示属于所述显示区域的通知消息的控件。不同的显示区域上显示的通知消息的重要紧急程度互不相同，代表通知消息的重要紧急程度的数值，通过对代表通知消息的重要程度和紧急程度的数值计算得到。
328.示例性的，第一通知区域中，不同的显示区域与第一通知区域中心点之间的距离互不相同，与第一通知区域中心点之间的距离越小的显示区域，显示的通知消息的重要紧急程度越高。例如可参阅图4e所示的悬浮导航圆盘的描述，此处不再赘述。
329.在另一些实施例中，还可以包括响应于解锁操作，判断所有通知消息中是否存在重要紧急的通知消息。重要紧急的通知消息为代表重要紧急程度的数值大于重要紧急程度临界值的通知消息，代表通知消息的重要紧急程度的数值，通过对代表通知消息的重要程度和紧急程度的数值计算得到。若所有通知消息中存在重要紧急的通知消息，则显示第一通知区域。若没有重要紧急的通知消息，则不显示第一通知区域。具体可参阅图4a的s409至s413，以及图5a的s510至s514的相关内容，此处不再赘述。
330.在另一些实施例中，第一通知区域的位置为可调整的位置，和/或，第一通知区域的尺寸为可调整的尺寸。具体可参阅前述图4b的(2)的相关描述，此处不再赘述。
331.s5002、响应于用户点击第一通知区域内的通知消息的操作，显示用户点击的通知消息对应的详情界面，通知消息对应的详情界面用于显示通知消息的详情内容。
332.具体的，步骤s5001和步骤s5002的执行过程和原理可参考前述的图4a和图4b的流程描述，此处不再赘述。
333.本实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中包括指令，当上述指令在具有测试装置的电子设备上运行时，使得该具有测试装置的电子设备执行本技术实施例提出的任一通知消息的处理方法步骤。
334.本实施例还提供了一种包含指令的计算机程序产品，当该计算机程序产品在电子设备上运行时，使得该电子设备执行如本技术实施例提出的任一通知消息的处理方法的相关方法步骤，以实现上述实施例中的方法。
335.本实施例还提供了一种控制设备，所述控制设备包括处理器和存储器，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述处理器执行所述计算机指令时，所述控制设备执行如本技术实施例提出的任一通知消息的处理方法步骤实现上述实施例中的方法。该控制设备可以是一个集成电路ic，也可以是一个片上系统soc。其中集成电路可以是通用集成电路，也可以是一个现场可编程门阵列fpga，也可以是一个专用集成电路asic。
336.通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
337.在本实施例所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
338.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
339.另外，在本实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
340.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
341.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何在本技术揭露的技术范围内的变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。