输出通知信息的方法及装置与流程

本公开涉及计算机技术领域，尤其涉及一种输出通知信息的方法及装置。

背景技术：

随着移动互联网的发展，移动终端已经成为人们生活中不可缺少的设备，移动端应用也随之蓬勃发展，为人们生活的信息化带来巨大变革。移动终端中的应用可以包括专注类应用(例如手机游戏、视频软件等)和通知类应用(例如某聊等)。其中，用户在使用专注类应用时，不希望被其他应用打扰；通信类应用则是一种需要及时交互的应用。可见，这两类应用在用户使用过程中存在着较大的交互冲突，往往无法同时满足专注类应用的专注需求和通知类应用的及时输出需求，这一问题亟需解决。

技术实现要素：

为克服相关技术中存在的问题，本公开提供一种输出通知信息的方法及装置。

根据本公开实施例的第一方面，提供一种输出通知信息的方法，包括：

确定当前运行的第一应用程序的显示状态；

在所述显示状态指示全屏显示时，检测第二应用程序的通知信息，所述第二应用程序不同于所述第一应用程序；

在检测到所述通知信息时，通过所述第一应用程序中的信息输出功能输出所述通知信息。

在一种可能的实现方式中，所述通过所述第一应用程序中的信息输出功能输出所述通知信息，包括：

在检测到所述通知信息时，通过所述第一应用程序的通知处理模块接收所述通知信息，其中，所述第一应用程序通过注册系统广播，检测并接收所述通知信息；

通过所述第一应用程序中的信息输出功能输出所述通知信息。

在一种可能的实现方式中，所述第一应用程序为游戏类应用程序。

在一种可能的实现方式中，所述通过所述第一应用程序中的信息输出功能输出所述通知信息，包括以下至少一项：

通过所述第一应用程序中的非玩家控制角色(Non Player Character，NPC)输出所述通知信息；

通过所述第一应用程序中的聊天频道输出所述通知信息。

在一种可能的实现方式中，所述方法还包括：

在所述显示状态指示全屏显示时，检测针对所述通知信息的回复信息；

在检测到所述回复信息时，通过针对所述第二应用程序的应用程序编程接口API(Application Programming Interface)输出所述回复信息。

根据本公开实施例的第二方面，提供一种输出通知信息的装置，包括：

显示状态确定模块，用于确定当前运行的第一应用程序的显示状态；

通知信息检测模块，用于在所述显示状态指示全屏显示时，检测第二应用程序的通知信息，所述第二应用程序不同于所述第一应用程序；

通知信息输出模块，用于在检测到所述通知信息时，通过所述第一应用程序中的信息输出功能输出所述通知信息。

在一种可能的实现方式中，所述通知信息输出模块包括：

通知信息接收子模块，用于在检测到所述通知信息时，通过所述第一应用程序的通知处理模块接收所述通知信息，其中，所述第一应用程序通过注册系统广播，检测并接收所述通知信息；

通知信息输出子模块，用于通过所述第一应用程序中的信息输出功能输出所述通知信息。

在一种可能的实现方式中，所述第一应用程序为游戏类应用程序。

在一种可能的实现方式中，所述通知信息输出模块包括以下子模块中的至少一个：

第一输出子模块，用于通过所述第一应用程序中的非玩家控制角色输出所述通知信息；

第二输出子模块，通过所述第一应用程序中的聊天频道输出所述通知信息。

在一种可能的实现方式中，所述装置还包括：

回复信息检测模块，用于在所述显示状态指示全屏显示时，检测针对所述通知信息的回复信息；

回复信息输出模块，用于在检测到所述回复信息时，通过针对所述第二应用程序的应用程序编程接口API输出所述回复信息。

根据本公开实施例的第三方面，提供一种输出通知信息的装置，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行上述方法。

根据本公开实施例的第四方面，提供一种非临时性计算机可读存储介质，当所述存储介质中的指令由移动终端的处理器执行时，使得移动终端能够执行上述输出通知信息的方法。

本公开的实施例提供的技术方案可以包括以下有益效果：能够确定当前运行的第一应用程序的显示状态，在显示状态指示全屏显示时，检测不同于第一应用程序的第二应用程序的通知信息；在检测到通知信息时，通过第一应用程序中的信息输出功能输出通知信息，从而解决了第一应用程序和通知信息之间的冲突，同时保证了第一应用程序的流畅使用以及通知信息的及时输出，进而便利了用户操作。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种输出通知信息的方法的流程图。

图2是根据一示例性实施例示出的一种输出通知信息的方法的流程图。

图3是根据一示例性实施例示出的一种输出通知信息的方法的流程图。

图4是根据一示例性实施例示出的一种输出通知信息的方法的应用场景的示意图。

图5是根据一示例性实施例示出的一种输出通知信息的装置的框图。

图6是根据一示例性实施例示出的一种输出通知信息的装置的框图。

图7是根据一示例性实施例示出的一种输出通知信息的装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在移动终端中的应用中，可以根据应用的使用类型划分为专注类应用(例如手机游戏)和通知类应用(例如某聊)，这两类应用在用户使用过程中存在一定的交互冲突。例如，用户在使用专注类应用时(例如手机游戏)，此时，用户为了更好地体验游戏，多设置为全屏显示，而通知类应用往往通过弹出通知栏输出通知信息(例如，弹出某聊信息)。在这种情况下，通知信息会遮挡部分屏幕，影响手机游戏的操作。

举例来说，当用户希望了解通知栏的通知信息时，在这种情况下，如果该通知信息是通过弹出信息提示框提示用户查看相关信息，例如，在全屏游戏状态中，通知栏显示某聊用户A发送了一条某聊信息，当用户在某聊内部设置通知不显示信息详情时，此时，该条某聊的详细内容只有跳转至某聊里才能查看，此时，用户只有切换到相关通信类应用才可了解到相应的通知信息的详细内容，这显然会影响到手机游戏的操作流畅性。

再举例来说，用户希望专注于手机游戏时，此时，弹出的通知栏的通知信息会影响到用户的游戏界面，用户需要进行单独的关闭通知信息操作才能继续游戏，此时可能会存在比较高误触可能性。例如，误触通知栏的通知信息从而切换至通知类应用，这一操作会带来移动终端的卡顿，并影响到用户的游戏流畅性。另外，因为用户选择关闭通知栏的通知信息，使得用户对该通知信息的接收产生一定的延迟，甚至会因此遗忘而错过回复该通知信息。

相关技术中，可以通过在用户使用专注类应用时屏蔽通知栏信息来满足用户的专注类应用的专注需求，即牺牲通知类应用的及时展现需求以获得专注类应用的专注需求。例如，在检测到用户使用手机游戏时，则屏蔽通知栏的通知信息，以获得良好的游戏操作环境。然而，这种方式根据通知信息的重要度和是否开启屏蔽模式的不同情况带给用户不同的影响。

例如，当通知信息为非重要信息，没有开启屏蔽模式时，会实时弹出通知信息，弹出的悬浮通知栏会占用屏幕上不小的空间，而且会占用一段时间，使得对应区域处于不可交互的状态，从而影响了用户的游戏操作，而让通知栏尽快消失的方法多为向上滑动通知信息以隐藏通知栏，这种方式容易产生误触，从而跳出游戏界面，转至通知类应用界面，对进行中的游戏流畅性产生不良影响。

当通知信息为非重要信息，开启屏蔽模式时，此时虽然牺牲了通知类信息的及时输出需求，但因其为非重要信息，因此，给用户带来的不良影响较小。然而，这种状态属于一种理想状态，即所有通知信息非重要，显然，这个假设不会一直成立。

当通知信息为重要信息，没有开启屏蔽模式时，此时，通知栏正常弹出，用户在游戏过程中可以及时看到相应通知，从而调整游戏进度，切换到通知类应用进行相关操作，在这种情况下，用户切换应用会从横屏的全屏游戏界面切换至竖屏的通知类应用，会占用一定的资源消耗，从而带来手机卡顿现象，影响用户的操作流畅性。

当通知信息为重要信息，开启屏蔽模式时，此时通知栏无法弹出，虽然保证了游戏的流畅性，但是重要信息无法得到及时地处理，从而导致用户错过一些不想错过的机会。例如，手机提前设置了某电商应用中的抢购信息，但因在游戏状态且开启了屏蔽模式，导致无法看到提示通知栏信息。而对于一些需要交互的重要信息，可能无法及时回复，造成机会的流失或者出现不必要的问题。例如，在一定时间前回复信息可以获取某种参与资格，因在游戏状态且开启了屏蔽模式，导致错过此机会。

应当理解，上述几种情况的出现具有一定的不确定性，因此，通过设置屏蔽模式，直接牺牲通知类信息的及时输出需求无法真正满足用户的操作需求。

本公开的输出通知信息的方法及装置，能够同时满足用户专注类应用的专注类需求和通知类应用的及时输出需求，从而实现无需推出专注类应用就能及时接收并响应通知类应用的通知信息的效果，进而便利了用户操作。

图1是根据一示例性实施例示出的一种输出通知信息的方法的流程图。该输出通知信息的方法可应用于终端设备(例如智能手机)等，在此不做限制。如图1所示，该输出通知信息的方法，包括以下步骤。

在步骤S101中，确定当前运行的第一应用程序的显示状态；

在步骤S102中，在所述显示状态指示全屏显示时，检测第二应用程序的通知信息，所述第二应用程序不同于所述第一应用程序；

在步骤S103中，在检测到所述通知信息时，通过所述第一应用程序中的信息输出功能输出所述通知信息。

根据本公开的实施例，能够确定当前运行的第一应用程序的显示状态，在显示状态指示全屏显示时，检测不同于第一应用程序的第二应用程序的通知信息；在检测到通知信息时，通过第一应用程序中的信息输出功能输出通知信息，从而解决了第一应用程序和通知信息之间的冲突，同时保证了第一应用程序的流畅使用以及通知信息的及时输出，进而便利了用户操作。

举例来说，终端设备可以确定当前运行的第一应用程序的显示状态。其中，第一应用程序可以为游戏类应用程序。例如，手机游戏等可全屏显示的应用程序。本领域技术人员应理解，第一应用程序不限于游戏类应用程序、视频类应用程序等，只要专注类应用(需要专注进行的应用)即可，本公开对此不做限制。

在显示状态指示全屏显示时，例如，终端设备确定当前运行的第一应用程序的显示状态为全屏显示时，检测不同于第一应用程序的第二应用程序的通知信息。其中，第二应用程序可以为通知类应用(例如，会弹出通知栏，进行信息的通知等)。例如，在当前运行的第一应用程序的显示状态为全屏显示时，可以检测通知类应用的通知信息。并在检测到通知信息时，通过第一应用程序中的信息输出功能输出所述通知信息。其中，输出的通知信息可以包括多种形式，例如，可包括文字显示、语音播放等，本公开对第一应用程序中的信息输出功能输出的通知信息的形式不作限制。

在一种可能的实现方式中，在显示状态指示全屏显示时，可以将系统通知调整为免打扰模式。例如，在手机游戏全屏显示过程中，系统通知随之调整为免打扰模式。在这种情况下，通知栏上的通知信息将不再进行震动或者铃声提醒，而是通过第一应用程序中的信息输出功能输出通知信息，从而使得用户使用专注类应用时不被系统通知打扰，保证了专注操作环境。

在一种可能的实现方式中，在检测到来自第二应用程序的通知信息时，通过第一应用程序中的信息输出功能输出所述通知信息，第二应用程序中也显示有该通知信息。举例来说，用户全屏显示某手机游戏，其手机确定当前运行的手机游戏的显示状态指示为全屏显示，可以检测第二应用程序的通知信息。在检测到来自第二应用程序的通知信息时，例如，检测到来自某聊的通知信息，此时，可以通过手机游戏中的信息输出功能输出该通知信息。另外，用户的第二应用程序(某聊)中依旧显示该通知信息。这样，在第二应用程序中同样保留被第一应用程序中的信息输出功能输出的通知信息，可以便利用户后续通过第二应用程序进行相应处理操作等。

在一种可能的实现方式中，第一应用程序可以通过注册系统广播，检测并接收系统通知栏的通知信息。

举例来说，可以在第一应用程序启动阶段，通过注册系统广播，实现检测(监听)并接收系统通知栏的通知信息。例如，在手机游戏启动阶段，该手机游戏可以注册系统广播开始检测(监听)并接收系统通知栏的通知信息。例如，该手机游戏注册系统广播后，可以检测系统所有通知栏的消息。例如，系统接收到某一通知类应用的通知信息时，该手机游戏可以接收到该系统接收的通知信息。这样，第一应用程序可以检测并接收系统通知栏的通知信息。本领域技术人员应理解，第一应用程序可以通过相关技术中公知的方式注册系统广播，检测并接收系统通知栏的通知信息，只要可以检测并接收系统通知栏的通知信息即可，本公开对此不做限制。

图2是根据一示例性实施例示出的一种输出通知信息的方法的流程图。在一种可能的实现方式中，如图2所示，步骤S103可以包括：

在步骤S1031中，在检测到所述通知信息时，通过所述第一应用程序的通知处理模块接收所述通知信息，其中，所述第一应用程序通过注册系统广播，检测并接收所述通知信息；

在步骤S1032中，通过所述第一应用程序中的信息输出功能输出所述通知信息。

举例来说，在检测到通知信息时(例如，来自第二应用程序的某通知信息)，可以通过第一应用程序的通知处理模块接收该通知信息。如前文所述，第一应用程序可以通过注册系统广播，检测并接收通知信息。在第一应用程序的显示状态指示全屏显示时，例如，手机游戏全屏显示过程中，在检测到来自第二应用程序的某通知信息时，例如，某聊的通知信息，此时，可以通过手机游戏的通知处理模块接收某聊的通知信息。并可以通过第一应用程序中的信息输出功能输出所述通知信息。例如，通过手机游戏的信息输出功能输出所述通知信息。

通过这种方式，可以实现第一应用程序全屏显示时，通知栏的通知信息不再直接弹出提醒，而是被第一应用程序的通知处理模块接收，并通过第一应用程序中的信息输出功能输出所述通知信息，避免了因通知栏的通知信息弹出占据一部分屏幕带来的操作中断，更省去了点击通知栏的悬浮窗(包括主动点击和误触)后切换应用所带来的系统资源消耗，为第一应用程序的沉浸式交互过程提供了保障。

在一种可能的实现方式中，所述通过所述第一应用程序中的信息输出功能输出所述通知信息，包括以下至少一项：

通过所述第一应用程序中的非玩家控制角色输出所述通知信息；

通过所述第一应用程序中的聊天频道输出所述通知信息。

举例来说，通过所述第一应用程序中的信息输出功能输出所述通知信息可以是通过第一应用程序中的非玩家控制角色输出所述通知信息，也可以是通过第一应用程序中的聊天频道输出所述通知信息，还可以通过第一应用程序中的非玩家控制角色和聊天频道输出所述通知信息。例如，当用户在全屏显示手机游戏时，在检测到有通知栏的通知信息(例如，日历提醒打开热水器)，在这种情况下，可以通过手机游戏中的信息输出功能输出该条提醒信息，例如，可以通过手机游戏中用户角色附近的NPC输出该条提醒信息(在用户角色靠近某NPC时，在NPC身上弹出对话框，对话框中显示该通知信息)，也可以通过手机游戏的聊天频道输出该通知信息，还可以同时通过手机游戏中某个NPC以及手机游戏的聊天频道同时输出该通知信息。

通过这种方式，可以多种方式通过所述第一应用程序中的信息输出功能输出所述通知信息，便利用户及时收到通知信息。

在一种可能的实现方式中，通过第一应用程序中的NPC输出该通知信息时，可以在通知信息内容前显示该通知信息的来源，例如，在NPC身上弹出的对话框中写明“来自某聊好友A的信息：XX。”其中，该聊天频道的聊天对象头像可以为对应的第二应用程序中通知信息发送者的头像。

通过这种方式，可以利于用户快速识别出通知信息的发送者，对不同的通知信息进行区分，避免用户因收到多个通知信息而发生信息混淆。同时，用户还可以根据信息的来源或者聊天对象的头像判断通知信息的重要性，进而确定查看优先级。例如，聊天对象A的重要性大于日历通知F的重要性，从而用户可能优先处理聊天对象A发来的通知信息。

在一种可能的实现方式中，该聊天频道可以为私密聊天频道，即只有当前用户能够看到该聊天信息(通知栏的通知信息)。通过私密聊天频道输出通知信息，可以保证用户通知信息的隐私性。

在一种可能的实现方式中，在该聊天频道输出的通知信息可以通过高亮颜色显示，还可以根据通知信息的来源分别用不同颜色进行高亮显示。例如，可以通过设置，使得来自备忘录的通知信息用黄色高亮显示，来自某聊的通知信息用红色高亮显示，还可以根据不同的某聊发送人设置不同颜色高亮显示。通过这种方式，可以增加该通知信息的识别度，便于用户区分各种通知信息。本公开对聊天频道输出通知信息的方式、形式等不作限制。

在一种可能的实现方式中，可以在第一应用程序中指定输出通知信息时是否有声音和/或震动提醒。举例来说，可以在手机游戏中设置，在通过NPC或者聊天频道输出通知栏的通知信息时，可以有声音和/或震动提醒。其中，该声音或者震动提醒的模式可以区别于手机游戏中非通知栏的通知信息的提醒模式。例如，通常手机游戏中NPC或者聊天频道出现信息时采用提醒声音B和/或震动模式C，在通过手机游戏中NPC或者聊天频道输出通知栏的通知信息时，可以采用提醒声音D和/或震动模式E。本领域技术人员应理解，只要可以在第一应用程序中指定提醒模式，从而提醒用户第一应用程序中输出了通知栏的通知信息即可，本公开对此不做限制。

图3是根据一示例性实施例示出的一种输出通知信息的方法的流程图。在一种可能的实现方式中，如图3所示，所述方法还包括：

在步骤S104中，在所述显示状态指示全屏显示时，检测针对所述通知信息的回复信息；

在步骤S105中，在检测到所述回复信息时，通过针对所述第二应用程序的应用程序编程接口API输出所述回复信息。

举例来说，在显示状态指示全屏显示时，可以检测针对通知信息的回复信息。例如，在该通知信息属于可回复信息时，用户可以在第一应用程序中直接回复该通知信息。例如，在手机游戏中，用户收到了一条某聊信息，用户在看到NPC或者聊天频道发来的通知信息后，可以在手机游戏中直接回复该通知信息。如上文所述，用户可以通过NPC或聊天频道进行信息回复，例如，在通知信息对应的聊天频道处显示输入框，用户可以在该输入框内输入回复的内容，触发发送确认控件，从而发送该回复信息。在终端设备检测到该回复信息时，可以通过针对所述第二应用程序的应用程序编程接口API输出所述回复信息。例如，可以由第一应用程序调用第二应用程序的API(Application Programming Interface，应用程序编程接口)输出回复信息。如上文所述，用户直接在手机游戏的聊天频道对该通知信息进行回复，此时，手机游戏可以通过调用某聊提供的API完成通知信息的回复。

通过这种方式，可以直接在第一应用程序中与通知栏的通知信息进行交互，无需退出该第一应用程序，提供了第一应用程序沉浸式使用环境，同时保证了通知栏的通知信息的及时接收和回复。本领域技术人员应理解，可以通过相关技术中公知的方式在检测到所述回复信息时，通过针对所述第二应用程序的应用程序编程接口API输出所述回复信息，本公开对此不作限制。

在一种可能的实现方式中，在检测到所述通知信息时，可以检测第一应用程序是否处于通知接收模式，在检测到第一应用程序处于通知接收模式时，通过第一应用程序中的信息输出功能输出所述通知信息。其中，第一应用程序是否处于通知接收模式可以由用户设置。例如，可以在游戏应用或者终端设备的设置页面中进行相关设置。

在一种可能的实现方式中，该输出通知信息的方法还可包括以下步骤。

响应于通知接收模式的设置请求，显示通知接收控件；

在所述通知接收控件被触发时，控制第一应用程序进入通知接收模式。

举例来说，可以在第一应用程序(例如，手机游戏)中的设置页面里显示通知接收控件，或者在终端设备的设置页面里显示通知接收控件。在用户选中该通知接收控件时，该通知接收控件被触发，此时，可以控制该第一应用程序进入通知接收模式。需要说明的是，该第一应用程序或者终端设备中的通知接收控件被触发，都可以控制该第一应用程序进入通知接收模式。本领域技术人员应理解，该通知接收控件可以包括多种形式，只要响应于通知接收模式的设置请求，显示通知接收控件，在所述通知接收控件被触发时，控制第一应用程序进入通知接收模式即可，本公开对此不做限制。

在一种可能的实现方式中，通知接收模式是指可以由该第一应用程序的通知处理模块接收通知栏的通知信息。举例来说，用户的手机操作系统中可以设置通知接收模式，例如，该用户手机显示通知接收控件，用户触发该通知接收控件，因用户手机操作系统中的通知接收控件被触发，所以该手机游戏进入通知接收模式，并通过该手机游戏的通知处理模块接收通知栏的通知信息。

通过这种方式，实现第一应用程序全屏显示时，通知栏的通知信息不再直接弹出提醒，而是被第一应用程序的通知处理模块接收，避免了因通知栏的通知信息弹出占据一部分屏幕带来的操作中断，更省去了点击通知栏的悬浮窗(包括主动点击和误触)后切换应用所带来的系统资源消耗，为第一应用程序的沉浸式交互过程提供了保障。

应用示例

以下结合“用户全屏使用手机游戏时，某聊用户A向其发送某聊信息”作为一个示例性应用场景，给出根据本公开实施例的应用示例，以便于理解输出通知信息的方法。本领域技术人员应理解，以下应用示例仅仅是出于便于理解本公开实施例的目的，不应视为对本公开实施例的限制。

图4是根据一示例性实施例示出的一种输出通知信息的方法的应用场景的示意图。如图4所示，在该应用示例中，用户开启某手机游戏，在手机游戏启动阶段，注册系统广播，检测并接收系统通知栏的通知信息。在该应用示例中，用户全屏运行该手机游戏。在该应用示例中，用户的手机确定当前运行的手机游戏的显示状态，例如，显示状态指示全屏显示，此时，用户的手机检测第二应用程序的通知信息，其中，第二应用程序不同于该手机游戏。在该应用示例中，用户的手机检测到某聊用户A发送了一条某聊信息，此时，第二应用程序(某聊)中，用户与用户A的聊天界面出现该某聊信息。用户手机的通知栏也接收到该某聊信息。例如，用户的手机处于免打扰模式，此时，用户通知栏上的该某聊信息不再进行震动或响铃提醒。在该应用示例中，通过手机游戏中的信息输出功能输出该某聊信息。例如，可以通过手机游戏的通知处理模块接收该某聊信息，并通过手机游戏中的信息输出功能输出该某聊信息。

在该应用示例中，通过手机游戏中的NPC输出该通知信息。例如，如图4所示，由手机游戏中的用户角色附近的NPC说出该某聊信息(例如，某聊某好友：晚上聚会啊)。

在该应用示例中，用户在查看了某聊用户A发来的某聊信息后，认为需要回复该信息时，其可以通过针对所述第二应用程序的应用程序编程接口API输出所述回复信息，例如，其可以通过NPC对某聊用户A进行回复，例如，发送相应的回复信息。在该应用示例中，手机游戏内部可以调用由某聊提供的API发送用户的回复信息，从而完成对某聊用户A的回复。

根据本公开的实施例，能够确定当前运行的第一应用程序的显示状态，在显示状态指示全屏显示时，检测不同于第一应用程序的第二应用程序的通知信息；在检测到通知信息时，通过第一应用程序中的信息输出功能输出通知信息，从而解决了第一应用程序和通知信息之间的冲突，同时保证了第一应用程序的流畅使用以及通知信息的及时输出，进而便利了用户操作。

图5是根据一示例性实施例示出的一种输出通知信息的装置的框图。参照图5，该装置包括显示状态确定模块501，通知信息检测模块502和通知信息输出模块503。

该显示状态确定模块501，被配置为确定当前运行的第一应用程序的显示状态；

该通知信息检测模块502，被配置为在所述显示状态指示全屏显示时，检测第二应用程序的通知信息，所述第二应用程序不同于所述第一应用程序；

该通知信息输出模块503，被配置为在检测到所述通知信息时，通过所述第一应用程序中的信息输出功能输出所述通知信息。

图6是根据一示例性实施例示出的一种输出通知信息的装置的框图。参照图6，在一种可能的实现方式中，所述通知信息输出模块503包括：

通知信息接收子模块5031，被配置为在检测到所述通知信息时，通过所述第一应用程序的通知处理模块接收所述通知信息，其中，所述第一应用程序通过注册系统广播，检测并接收所述通知信息；

通知信息输出子模块5032，被配置为通过所述第一应用程序中的信息输出功能输出所述通知信息。

在一种可能的实现方式中，所述第一应用程序为游戏类应用程序。

在一种可能的实现方式中，所述通知信息输出模块包括以下子模块中的至少一个：

第一输出子模块，被配置为通过所述第一应用程序中的非玩家控制角色输出所述通知信息；

第二输出子模块，被配置为通过所述第一应用程序中的聊天频道输出所述通知信息。

参照图6，在一种可能的实现方式中，所述装置还包括：

回复信息检测模块504，被配置为在所述显示状态指示全屏显示时，检测针对所述通知信息的回复信息；

回复信息输出模块505，被配置为在检测到所述回复信息时，通过针对所述第二应用程序的应用程序编程接口API输出所述回复信息。

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

根据本公开的实施例，能够确定当前运行的第一应用程序的显示状态，在显示状态指示全屏显示时，检测不同于第一应用程序的第二应用程序的通知信息；在检测到通知信息时，通过第一应用程序中的信息输出功能输出通知信息，从而解决了第一应用程序和通知信息之间的冲突，同时保证了第一应用程序的流畅使用以及通知信息的及时展示，进而便利了用户操作。

图7是根据一示例性实施例示出的一种输出通知信息的装置的框图。例如，装置800可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图7，装置800可以包括以下一个或多个组件：处理组件802，存储器804，电源组件806，多媒体组件808，音频组件810，输入/输出(I/O)的接口812，传感器组件814，以及通信组件816。

处理组件802通常控制装置800的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件802可以包括一个或多个处理器820来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件802可以包括一个或多个模块，便于处理组件802和其他组件之间的交互。例如，处理组件802可以包括多媒体模块，以方便多媒体组件808和处理组件802之间的交互。

存储器804被配置为存储各种类型的数据以支持在装置800的操作。这些数据的示例包括用于在装置800上操作的任何目标应用或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件806为装置800的各种组件提供电力。电源组件806可以包括电源管理系统，一个或多个电源，及其他与为装置800生成、管理和分配电力相关联的组件。

多媒体组件808包括在所述装置800和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件808包括一个前置摄像头和/或后置摄像头。当装置800处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

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

I/O接口812为处理组件802和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件814包括一个或多个传感器，用于为装置800提供各个方面的状态评估。例如，传感器组件814可以检测到装置800的打开/关闭状态，组件的相对定位，例如所述组件为装置800的显示器和小键盘，传感器组件814还可以检测装置800或装置800一个组件的位置改变，用户与装置800接触的存在或不存在，装置800方位或加速/减速和装置800的温度变化。传感器组件814可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件814还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件816被配置为便于装置800和其他设备之间有线或无线方式的通信。装置800可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件816经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件816还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，装置800可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器804，上述指令可由装置800的处理器820执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器804，上述指令可由装置800的处理组件820执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。