悬浮通知的处理方法、装置和移动终端与流程

本发明涉及移动终端技术领域，具体而言，本发明涉及一种悬浮通知的处理方法、装置和移动终端。

背景技术：

目前用户在使用移动终端玩游戏的时候，如果接收到远程或系统推送的通知信息例如即时信息时，这些通知信息就会以悬浮窗的形式出现在游戏界面，一方面会影响用户玩游戏的心情，另一方面如果用户不小心碰触到悬浮通知就会导致页面跳转，游戏中断，用户体验不佳。

技术实现要素：

本发明的目的旨在至少能解决上述的技术缺陷之一，特别是容易误触通知信息的技术缺陷。

本发明提供一种悬浮通知的处理方法，应用于移动终端，包括如下步骤：

接收通知信息；

判断所述通知信息是否需要悬浮显示；

若需要悬浮显示，判断所述移动终端是否处于全屏游戏状态，若是则禁止悬浮显示所述通知信息。

在其中一个实施例中，所述判断所述通知信息是否需要悬浮显示的过程包括：

判断推送所述通知信息的应用是否设置了fullScreenIntent。

在其中一个实施例中，所述判断所述通知信息是否需要悬浮显示的过程包括：

判断所述通知信息的等级是否是默认等级以上且所述通知信息设置有声音或者振动。

在其中一个实施例中，所述判断所述移动终端是否处于全屏游戏状态的过程包括：

获取前台应用的包名；

判断前台应用的包名是否存在于预设的游戏数据库中，若是则确定所述移动终端处于全屏游戏状态。

在其中一个实施例中，所述游戏数据库包括本地游戏数据库和/或云端游戏数据库。

在其中一个实施例中，所述游戏数据库包括本地游戏数据库和云端游戏数据库；

所述判断所述移动终端是否处于全屏游戏状态的过程包括：

获取前台应用的包名；

首先判断前台应用的包名是否存在于预设的本地游戏数据库中，若是则确定所述移动终端处于全屏游戏状态，若否则继续执行以下步骤：

判断前台应用的包名是否存在于预设的云端游戏数据库中，若是则确定所述移动终端处于全屏游戏状态。

在其中一个实施例中，若判断前台应用的包名不存在于预设的游戏数据库中，则继续判断所述移动终端是否满足以下条件：

用户触摸操作频率是否超过预设频率阈值；

CPU占用是否超过预设CPU阈值；

内存占用是否超过预设内存阈值；

若皆满足所述条件，则确定所述移动终端处于全屏游戏状态。

在其中一个实施例中，若所述移动终端处于全屏游戏状态，则禁止悬浮显示所述通知信息，并在所述移动终端退出全屏游戏状态之后，悬浮显示所述通知信息。

在其中一个实施例中，若被禁止悬浮显示的所述通知信息多于一条，则在所述移动终端退出全屏游戏状态之后，悬浮显示最晚接收到的N条所述通知信息，N为正整数。

在其中一个实施例中，在所述移动终端退出全屏游戏状态之后，以时间倒序的方式依次悬浮显示最晚接收到的N条所述通知信息。

本发明还提供一种悬浮通知的处理装置，应用于移动终端，包括：

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

判断模块，用于判断所述通知信息是否需要悬浮显示；

处理模块，用于若需要悬浮显示，判断所述移动终端是否处于全屏游戏状态，若是则禁止悬浮显示所述通知信息。

在其中一个实施例中，所述判断模块用于：

判断推送所述通知信息的应用是否设置了fullScreenIntent。

在其中一个实施例中，所述判断模块用于：

判断所述通知信息的等级是否是默认等级以上且所述通知信息设置有声音或者振动。

在其中一个实施例中，所述处理模块用于：

获取前台应用的包名；

判断前台应用的包名是否存在于预设的游戏数据库中，若是则确定所述移动终端处于全屏游戏状态。

在其中一个实施例中，所述游戏数据库包括本地游戏数据库和/或云端游戏数据库。

在其中一个实施例中，所述游戏数据库包括本地游戏数据库和云端游戏数据库；

所述处理模块用于：

获取前台应用的包名；

首先判断前台应用的包名是否存在于预设的本地游戏数据库中，若是则确定所述移动终端处于全屏游戏状态，若否则所述处理模块继续用于：

判断前台应用的包名是否存在于预设的云端游戏数据库中，若是则确定所述移动终端处于全屏游戏状态。

在其中一个实施例中，若所述处理模块判断前台应用的包名不存在于预设的游戏数据库中，则继续判断所述移动终端是否满足以下条件：

用户触摸操作频率是否超过预设频率阈值；

CPU占用是否超过预设CPU阈值；

内存占用是否超过预设内存阈值；

若皆满足所述条件，则确定所述移动终端处于全屏游戏状态。

在其中一个实施例中，若所述移动终端处于全屏游戏状态，则所述处理模块禁止悬浮显示所述通知信息，并在所述移动终端退出全屏游戏状态之后，悬浮显示所述通知信息。

在其中一个实施例中，若被禁止悬浮显示的所述通知信息多于一条，则所述处理模块在所述移动终端退出全屏游戏状态之后，悬浮显示最晚接收到的N条所述通知信息，N为正整数。

在其中一个实施例中，在所述移动终端退出全屏游戏状态之后，所述处理模块以时间倒序的方式依次悬浮显示最晚接收到的N条所述通知信息。

本发明还提供一种移动终端，其包括：

触敏显示器；

一个或多个处理器；

存储器；

一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序被配置用于执行如上述任一实施例的悬浮通知的处理方法。

上述的悬浮通知的处理方法、装置和移动终端，接收通知信息；判断所述通知信息是否需要悬浮显示；若需要悬浮显示，判断所述移动终端是否处于全屏游戏状态，若是则禁止悬浮显示所述通知信息。本发明可以判断通知信息是否需要悬浮显示，以及移动终端当前的使用状态，确定当前是否处于全屏游戏状态。如果判断结果为是，则在此期间接收到的所有通知信息都禁止悬浮显示，用户不用再担心出现玩游戏时会误触悬浮通知而导致的页面跳转，游戏中断现象。功能更加强大，不仅提升了用户的游戏体验，也使移动终端变的更加的智能化。

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

附图说明

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

图1为一个实施例的悬浮通知的处理方法流程图；

图2为一个实施例的悬浮通知的处理装置模块图；

图3示出的是与本发明实施例提供的终端相关的手机的部分结构的框图。

具体实施方式

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

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

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

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

本技术领域技术人员可以理解，这里所使用的远端网络设备，其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云。在此，云由基于云计算(Cloud Computing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。本发明的实施例中，远端网络设备、终端设备与WNS服务器之间可通过任何通讯方式实现通讯，包括但不限于，基于3GPP、LTE、WIMAX的移动通讯、基于TCP/IP、UDP协议的计算机网络通讯以及基于蓝牙、红外传输标准的近距无线传输方式。

以下描述的悬浮通知的处理方法和装置，可以应用于移动终端，例如应用于手机、平板电脑，总之是具有通信功能的终端，在以下说明中以终端为例子。该方法和装置可以以应用程序(APP)的形式实现，例如快递公司APP或外卖平台APP。

图1为一个实施例的悬浮通知的处理方法流程图。

本发明提供一种悬浮通知的处理方法，包括如下步骤：

步骤S100：接收通知信息。

本发明主要应用于移动终端系统，接收远程推送的通知信息，该通知信息可以是短信、邮件、即时信息、系统或应用推送的信息等。应用的类型可以但不限于包括：影音图像、通讯社交、生活助理、网上购物、交通出行、学习教育、商业办公、娱乐游戏等。通知信息内容可以但不限于包括：移动终端根据自身状态或应用状态获取并接收通知，例如，系统内存不足、系统应用运行中崩溃或应用的进程结束等，系统实时监测移动终端的运行状态，当监测到异常时，通过通知方式通知用户；移动终端接收服务器转发的聊天消息，基于接收的消息生成通知；或接收服务器推送的告知用户进行应用升级的通知。以上都可以认为移动终端接收通知信息。

步骤S200：判断该通知信息是否需要悬浮显示。

通知信息是否需要悬浮显示主要是由应用自身控制的,只要满足以下几个条件通知信息就会悬浮显示。判断通知信息能否悬浮显示的代码如下：

boolean interrupt＝(isFullscreen||(isHighPriority&&(isNoisy||hasTicker)))&&mPowerManager.isScreenOn()&&(！mStatusBarKeyguardVie wManager.isShowing()||mStatusBarKeyguardViewManager.isOccluded())；

上述代码中“isFullscreen”表示判断发送通知信息的应用是否设置了fullScreenIntent，由于Android5.0之后才有setFullScreenIntent方法，所以这是为了兼容5.0以前的应用。

除移动终端全屏显示可以使通知信息悬浮外，按照上述代码(isHighPriority&&(isNoisy||hasTicker))所表达的，当满足通知的等级在默认等级以上且有声音或者振动时，也可以使通知信息悬浮显示，通知信息设置有等级，通常为通知信息设定了5档重要程度，分别为:MAX最高等级，重要而紧急的通知，通知用户这个事件是时间上紧迫的或者需要立即处理的，例如来电提醒；HIGH高等级，用于重要的通信内容，例如短消息或者聊天，这些都是对用户来说比较有兴趣的；DEFAULT默认等级，用于没有特殊等级分类的通知，在此等级之上的一般都设置有铃声或者振动的提醒；LOW低等级，可以通知用户但又不是很紧急的事件，例如系统升级类通知；MIN最低等级，用于后台消息，例如天气或者位置信息，最低等级的通知只在状态栏显示图标，只有用户下拉通知栏时才能看到内容。同时，通知信息的等级也会干预状态栏图标的位置，比如用户希望电池、天气等保持在通知列表顶层，就可设定其等级到高位，而等级低的通知就会出现在通知列表最底层。

除为通知信息设置等级外，应用在发通知的时候可以设置fullScreenIntent，响应紧急状态的全屏事件。即当接收到通知信息后，可直接跳过在通知区域点击通知这一步，直接执行fullScreenIntent所代表的事件，例如来电事件。但是由于Android5.0之后才有设置FullScreenIntent的方法，所以为了兼容Android5.0以前的应用，如果没有设置fullScreenIntent，就按照上述代码判断通知的等级是否在默认等级以上且有声音或者振动来确定通知是否可以悬浮显示。

通知信息可以悬浮显示的第三个判断条件就是移动终端亮屏并且不在锁屏状态，代码如下：

mPowerManager.isScreenOn()&&(！mStatusBarKeyguardViewManager.i sShowing()||mStatusBarKeyguardViewManager.isOccluded())，

如果移动终端在黑屏且锁屏的状态下接收到通知信息，通常只会伴随指示灯的闪烁提醒或者显示屏苏醒，而不会出现悬浮窗的呈现方式。所以移动终端只有在亮屏且不显示设备锁或者系统未开启设备锁的状态下接收到通知信息才有可能悬浮显示该通知信息。

步骤S300：若需要悬浮显示，判断该移动终端是否处于全屏游戏状态，若是则禁止悬浮显示该通知信息。

判断该移动终端是否处于全屏游戏状态需要确定前台正在运行的应用是否为游戏类，由于应用的包名和签名都具有唯一性，因此理论上讲都可以用来确定当前运行的应用，但是应用签名的意义在于防止已安装的应用被其它相同包名的程序替换掉，相比较包名，虽然签名的特征性更强，但是本方案只是需要确定应用的类别，所以只要通过包名就可以达到要求。获取前台应用的包名，系统就可以通过包名识别出应用并确定它的类别。当然不排除可以通过应用的签名来识别应用并确定应用类型。获取到前台应用的包名后遍历预设的游戏数据库，该游戏数据库存储大量的游戏应用包名，判断获取到的前台应用的包名是否存在于预设的游戏数据库中，对比判断后若是，则可以确定该移动终端处于全屏游戏状态。

该游戏数据库包括本地游戏数据库和云端游戏数据库。当获取到前台应用的包名后，首先判断该包名是否存在于预设的本地游戏数据库中，本地游戏数据库包含了当下比较热门的游戏。通过对比若匹配到相同的包名则确定该移动终端处于全屏游戏状态，若未能匹配到相应的包名则可以继续对比判断前台应用的包名是否存在于预设的云端游戏数据库中。虽然云端游戏数据库收录的游戏比较全面，但是为了加快比对速度，一般情况下还是先与本地游戏数据库作对比。用户也可以选择直接将获取到的包名上传到云端进行对比。因此，游戏数据库既可以仅仅包括本地游戏数据库，或者仅仅包括云端游戏数据库，或者包括本地游戏数据库和云端游戏数据库。云端游戏数据库弥补了本地游戏数据库收录游戏包名不够全面的缺点，本地游戏数据库则弥补了发送应用包名至云端游戏数据库的繁琐步骤。但是由于云端游戏数据库中收录了大量的游戏包名，对比速度也必定要比本地游戏数据库慢。

在其他实施例中，如果通过上述判断方法仍然无法确定移动终端的当前使用状态，也就是说遍历本地游戏数据库以及云端游戏数据库后都没有获取到前台正在运行应用的包名，则可以继续判断该移动终端当前状态下是否满足以下条件：1、用户触摸操作频率是否超过预设频率阈值；处于游戏状态时，用户的触摸操作频率高于平常状态，因此可以预设一定的触摸频率阈值，如果检测到当前触摸操作频率已经高于阈值，则认为该移动终端可能处于游戏状态。2、CPU占用是否超过预设CPU阈值；CPU占用就是运行的程序占用的CPU资源，表示移动终端在某个时间点的运行程序的情况。占用值越高，说明移动终端在这个时间上运行了很多程序，反之较少。处于游戏状态时需要大量的CPU资源，占用率必然很高，系统每当接收到通知信息就会检测此时CPU占用率，并把实际CPU占用率和阈值相比较。预设CPU占用率阈值范围。当检测到CPU使用率超出阈值范围时则认为该移动终端可能处于游戏状态。3、内存占用是否超过预设内存阈值；Android系统有六类进程：前台进程、可见进程、辅助服务、后台进程、内容供应节点、空闲程序。玩游戏属于前台进程，用户可以根据自身需求调整阈值参数，首先查看在开启游戏之前系统的运行内存为何值，然后确定阈值上限，游戏运行会占用前台进程内存，一旦超过预设的阈值上限，则认为该移动终端可能处于游戏状态。若同时满足以上三个条件，则可以确定该移动终端正处于全屏游戏状态。由于移动终端运行游戏与运行其他应用的差异性，因此通过判断系统当前是否符合以上三个条件就可以准确判断出移动终端的当前使用状态，但是判断是否符合这三个条件步骤是比较繁琐的，所以只有在通过遍历游戏库都无法获得应用包名的情况下，才会执行上述判断方案。

如果通过判断确定该移动终端处于全屏游戏状态，则禁止悬浮显示所有通知信息，直到该移动终端退出全屏游戏状态之后，通知信息才可以悬浮显示。如果用户长时间处于游戏状态，移动终端在此期间接收到了N条通知信息，N为预先设置的通知上限，则在该移动终端退出全屏游戏状态之后，以时间倒序的方式依次悬浮显示所有在此期间接收到的这N条通知信息。例如用户运行游戏期间，系统共接收到了n条通知信息(n小于等于N)，按照接收通知信息的时间先后顺序依次编号为1，2，3，…，n,当移动终端不再处于全屏游戏状态，该五条通知信息按照时间倒序的方式悬浮显示则依次为n，n-1，…，3，2，1，即优先显示最新通知信息，这样设置有利于用户及时查看新近事件通知。如果在此期间，移动终端接收到了多于N条的通知，则按照上述显示方式悬浮显示最新接收到的N条信息。大于N条的部分按时间倒序依次排列显示在通知栏底部，而不会悬浮显示。设定悬浮显示上限可以防止多条信息重叠覆盖，以免达不到提示的作用。

因此，判断是否需要悬浮显示和是否处于全屏游戏状态可以是以下代码：

boolean interrupt＝

isPlayGame&&(isFullscreen||(isHighPriority&&(isNoisy||hasTicker)))&&mPowerManager.isScreenOn()&&(！mStatusBarKeyguardVie wManager.isShowing()||mStatusBarKeyguardViewManager.isOccluded())；

其中isPlayGame表示是否在玩游戏；

mPowerManager.isScreenOn()表示是否亮屏；

(！mStatusBarKeyguardViewManager.isShowing()||mStatusBarKeyguard ViewManager.isOccluded())表示是不是在锁屏界面。

图2为一个实施例的悬浮通知的处理装置模块图。

基于上述的悬浮通知的处理方法，本发明还提供一种悬浮通知的处理装置，应用于移动终端，包括：接收模块100、判断模块200和处理模块300。

接收模块100用于接收通知信息；判断模块200用于判断所述通知信息是否需要悬浮显示；处理模块300用于若需要悬浮显示，判断所述移动终端是否处于全屏游戏状态，若是则禁止悬浮显示所述通知信息。

接收模块100接收通知信息。

本发明主要应用于移动终端系统，接收模块100接收远程推送的通知信息，该通知信息可以是短信、邮件、即时信息、系统或应用推送的信息等。应用的类型可以但不限于包括：影音图像、通讯社交、生活助理、网上购物、交通出行、学习教育、商业办公、娱乐游戏等。通知信息内容可以但不限于包括：接收模块100根据自身状态或应用状态获取并接收通知，例如，系统内存不足、系统应用运行中崩溃或应用的进程结束等，系统实时监测移动终端的运行状态，当监测到异常时，通过通知方式通知用户；接收模块100接收服务器转发的聊天消息，基于接收的消息生成通知；或接收服务器推送的告知用户进行应用升级的通知。以上都可以认为接收模块100接收通知信息。

判断模块200判断该通知信息是否需要悬浮显示。

通知信息是否需要悬浮显示主要是由应用自身控制的,只要满足以下几个条件通知信息就会悬浮显示。判断通知信息能否悬浮显示的代码如下：

boolean interrupt＝(isFullscreen||(isHighPriority&&(isNoisy||hasTicker)))&&mPowerManager.isScreenOn()&&(！mStatusBarKeyguardVie wManager.isShowing()||mStatusBarKeyguardViewManager.isOccluded())；

上述代码中“isFullscreen”表示判断发送通知信息的应用是否设置了fullScreenIntent，由于Android5.0之后才有setFullScreenIntent方法，所以这是为了兼容5.0以前的应用。

除移动终端全屏显示可以使通知信息悬浮外，判断模块200按照上述代码(isHighPriority&&(isNoisy||hasTicker))所表达的，当满足通知的等级在默认等级以上且有声音或者振动时，也可以使通知信息悬浮显示，通知信息设置有等级，判断模块200通常为通知信息设定了5档重要程度，分别为:MAX最高等级，重要而紧急的通知，通知用户这个事件是时间上紧迫的或者需要立即处理的，例如来电提醒；HIGH高等级，用于重要的通信内容，例如短消息或者聊天，这些都是对用户来说比较有兴趣的；DEFAULT默认等级，用于没有特殊等级分类的通知，在此等级之上的一般都设置有铃声或者振动的提醒；LOW低等级，可以通知用户但又不是很紧急的事件，例如系统升级类通知；MIN最低等级，用于后台消息，例如天气或者位置信息，最低等级的通知只在状态栏显示图标，只有用户下拉通知栏时才能看到内容。同时，通知信息的等级也会干预状态栏图标的位置，比如用户希望电池、天气等保持在通知列表顶层，就可设定其等级到高位，而等级低的通知就会出现在通知列表最底层。

判断模块200除为通知信息设置等级外，应用在发通知的时候判断模块200可以设置fullScreenIntent，响应紧急状态的全屏事件。即当接收到通知信息后，可直接跳过在通知区域点击通知这一步，直接执行fullScreenIntent所代表的事件，例如来电事件。但是由于Android5.0之后才有设置FullScreenIntent的方法，所以为了兼容Android5.0以前的应用，如果判断模块200没有设置fullScreenIntent，就按照上述代码判断通知的等级是否在默认等级以上且有声音或者振动来确定通知是否可以悬浮显示。

判断模块200判断通知信息可以悬浮显示的第三个判断条件就是移动终端亮屏并且不在锁屏状态，代码如下：

mPowerManager.isScreenOn()&&(！mStatusBarKeyguardViewManager.i sShowing()||mStatusBarKeyguardViewManager.isOccluded())，

如果接收模块100在黑屏且锁屏的状态下接收到通知信息，通常只会伴随指示灯的闪烁提醒或者显示屏苏醒，而不会出现悬浮窗的呈现方式。所以只有在亮屏且不显示设备锁或者系统未开启设备锁的状态下接收模块100接收到通知信息才有可能悬浮显示该通知信息。

处理模块300若需要悬浮显示，判断所述移动终端是否处于全屏游戏状态，若是则禁止悬浮显示所述通知信息。

判断该移动终端是否处于全屏游戏状态处理模块300需要确定前台正在运行的应用是否为游戏类，由于应用的包名和签名都具有唯一性，因此理论上讲都可以用来确定当前运行的应用，但是应用签名的意义在于防止已安装的应用被其它相同包名的程序替换掉，相比较包名，虽然签名的特征性更强，但是本方案只是需要确定应用的类别，所以只要通过包名就可以达到要求。获取前台应用的包名，处理模块300就可以通过包名识别出应用并确定它的类别。当然不排除可以通过应用的签名来识别应用并确定应用类型。

处理模块300获取到前台应用的包名后遍历预设的游戏数据库，该游戏数据库存储大量的游戏应用包名，判断获取到的前台应用的包名是否存在于预设的游戏数据库中，对比判断后若是，则可以确定该移动终端处于全屏游戏状态。

该游戏数据库包括本地游戏数据库和云端游戏数据库。当获取到前台应用的包名后，处理模块300首先判断该包名是否存在于预设的本地游戏数据库中，本地游戏数据库包含了当下比较热门的游戏。通过对比若匹配到相同的包名则确定该移动终端处于全屏游戏状态，若未能匹配到相应的包名则处理模块300可以继续对比判断前台应用的包名是否存在于预设的云端游戏数据库中。虽然云端游戏数据库收录的游戏比较全面，但是为了加快比对速度，一般情况下还是先与本地游戏数据库作对比。用户也可以选择直接将获取到的包名上传到云端进行对比。因此，游戏数据库既可以仅仅包括本地游戏数据库，或者仅仅包括云端游戏数据库，或者包括本地游戏数据库和云端游戏数据库。云端游戏数据库弥补了本地游戏数据库收录游戏包名不够全面的缺点，本地游戏数据库则弥补了发送应用包名至云端游戏数据库的繁琐步骤。但是由于云端游戏数据库中收录了大量的游戏包名，对比速度也必定要比本地游戏数据库慢。

在其他实施例中，如果通过上述判断方法仍然无法确定移动终端的当前使用状态，也就是说处理模块300遍历本地游戏数据库以及云端游戏数据库后都没有获取到前台正在运行应用的包名，则可以继续判断该移动终端当前状态下是否满足以下条件：1、用户触摸操作频率是否超过预设频率阈值；处于游戏状态时，用户的触摸操作频率高于平常状态，因此可以预设一定的触摸频率阈值，如果检测到当前触摸操作频率已经高于阈值，则认为该移动终端可能处于游戏状态。2、CPU占用是否超过预设CPU阈值；CPU占用就是运行的程序占用的CPU资源，表示移动终端在某个时间点的运行程序的情况。占用值越高，说明移动终端在这个时间上运行了很多程序，反之较少。处于游戏状态时需要大量的CPU资源，占用率必然很高，系统每当接收到通知信息就会检测此时CPU占用率，并把实际CPU占用率和阈值相比较。预设CPU占用率阈值范围。当检测到CPU使用率超出阈值范围时则认为该移动终端可能处于游戏状态。3、内存占用是否超过预设内存阈值；Android系统有六类进程：前台进程、可见进程、辅助服务、后台进程、内容供应节点、空闲程序。玩游戏属于前台进程，用户可以根据自身需求调整阈值参数，首先查看在开启游戏之前系统的运行内存为何值，然后确定阈值上限，游戏运行会占用前台进程内存，一旦超过预设的阈值上限，则认为该移动终端可能处于游戏状态。若同时满足以上三个条件，则可以确定该移动终端正处于全屏游戏状态。由于移动终端运行游戏与运行其他应用的差异性，因此处理模块300通过判断系统当前是否符合以上三个条件就可以准确判断出移动终端的当前使用状态，但是判断是否符合这三个条件步骤是比较繁琐的，所以只有在通过遍历游戏库都无法获得应用包名的情况下，才会执行上述判断方案。

如果通过判断确定该移动终端处于全屏游戏状态，则处理模块300禁止悬浮显示所有通知信息，直到该移动终端退出全屏游戏状态之后，通知信息才可以悬浮显示。如果用户长时间处于游戏状态，移动终端在此期间接收到了N条通知信息，N为预先设置的通知上限，则在该移动终端退出全屏游戏状态之后，以时间倒序的方式依次悬浮显示所有在此期间接收到的这N条通知信息。例如用户运行游戏期间，系统共接收到了n条通知信息(n小于等于N)，按照接收通知信息的时间先后顺序依次编号为1，2，3，…，n,当移动终端不再处于全屏游戏状态，该五条通知信息按照时间倒序的方式悬浮显示则依次为n，n-1，…，3，2，1，即优先显示最新通知信息，这样设置有利于用户及时查看新近事件通知。。如果在此期间，移动终端接收到了多于N条的通知，则按照上述显示方式悬浮显示最新接收到的N条信息。大于N条的部分按时间倒序依次排列显示在通知栏底部，而不会悬浮显示，设定悬浮显示上限可以防止多条信息重叠覆盖，以免达不到提示的作用。

因此，判断是否需要悬浮显示和是否处于全屏游戏状态可以是以下代码：

boolean interrupt＝

isPlayGame&&(isFullscreen||(isHighPriority&&(isNoisy||hasTicker)))&&mPowerManager.isScreenOn()&&(！mStatusBarKeyguardVie wManager.isShowing()||mStatusBarKeyguardViewManager.isOccluded())；

其中isPlayGame表示是否在玩游戏；

mPowerManager.isScreenOn()表示是否亮屏；

(！mStatusBarKeyguardViewManager.isShowing()||mStatusBarKeyguard ViewManager.isOccluded())表示是不是在锁屏界面。

上述移动终端悬浮通知处理的装置，可以判断通知信息是否需要悬浮显示，以及移动终端当前的使用状态，确定当前是否处于全屏游戏状态。如果判断结果为是，则在此期间接收到的所有通知信息都禁止悬浮显示，因此用户不用再担心出现玩游戏时会误触悬浮通知而导致的页面跳转，游戏中断现象。功能更加强大，不仅提升了用户的游戏体验，也使移动终端变的更加的智能化。

本发明实施例还提供了移动终端，如图3所示，为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该终端可以为包括手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、POS(Point of Sales，销售终端)、车载电脑等任意终端设备，以终端为手机为例：

图3示出的是与本发明实施例提供的终端相关的手机的部分结构的框图。参考图3，手机包括：射频(Radio Frequency，RF)电路1510、存储器1520、输入单元1530、显示单元1540、传感器1550、音频电路1560、无线保真(wireless fidelity，WiFi)模块1570、处理器1580、以及电源1590等部件。本领域技术人员可以理解，图3中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图3对手机的各个构成部件进行具体的介绍：

RF电路1510可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1580处理；另外，将设计上行的数据发送给基站。通常，RF电路1510包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low Noise Amplifier，LNA)、双工器等。此外，RF电路1510还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(Global System of Mobile communication，GSM)、通用分组无线服务(General Packet Radio Service，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution，LTE)、电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储器1520可用于存储软件程序以及模块，处理器1580通过运行存储在存储器1520的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1520可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1520可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1530可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1530可包括触控面板1531以及其他输入设备1532。触控面板1531，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1531上或在触控面板1531附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1531可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1580，并能接收处理器1580发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1531。除了触控面板1531，输入单元1530还可以包括其他输入设备1532。具体地，其他输入设备1532可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1540可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1540可包括显示面板1541，可选的，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板1541。进一步的，触控面板1531可覆盖显示面板1541，当触控面板1531检测到在其上或附近的触摸操作后，传送给处理器1580以确定触摸事件的类型，随后处理器1580根据触摸事件的类型在显示面板1541上提供相应的视觉输出。虽然在图3中，触控面板1531与显示面板1541是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1531与显示面板1541集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器1550，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1541的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1541和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1560、扬声器1561，传声器1562可提供用户与手机之间的音频接口。音频电路1560可将接收到的音频数据转换后的电信号，传输到扬声器1561，由扬声器1561转换为声音信号输出；另一方面，传声器1562将收集的声音信号转换为电信号，由音频电路1560接收后转换为音频数据，再将音频数据输出处理器1580处理后，经RF电路1510以发送给比如另一手机，或者将音频数据输出至存储器1520以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块1570可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图3示出了WiFi模块1570，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1580是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1520内的软件程序和/或模块，以及调用存储在存储器1520内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1580可包括一个或多个处理单元；优选的，处理器1580可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1580中。

手机还包括给各个部件供电的电源1590(比如电池)，优选的，电源可以通过电源管理系统与处理器1580逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本发明实施例中，该终端所包括的处理器1580还具有以下功能：接收通知信息；判断所述通知信息是否需要悬浮显示；若需要悬浮显示，判断所述移动终端是否处于全屏游戏状态，若是则禁止悬浮显示所述通知信息。也即处理器1580具备执行上述的悬浮通知的处理方法的功能，在此不再赘述。

上述的悬浮通知的处理方法、装置和移动终端，接收通知信息；判断所述通知信息是否需要悬浮显示；若需要悬浮显示，判断所述移动终端是否处于全屏游戏状态，若是则禁止悬浮显示所述通知信息。因此用户不用再担心出现玩游戏时会误触悬浮通知而导致的页面跳转，游戏中断现象。功能更加强大，不仅提升了用户的游戏体验，也使移动终端变的更加的智能化。

应该理解的是，虽然图1的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，图1中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

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