CN107548489B - 广播的管控方法、装置及终端 - Google Patents

Abstract

本发明实施例涉及一种广播的管控方法、装置及终端，该方法包括：对终端当前运行的一个或者多个应用程序进行识别，当一个或者多个应用程序处于后台运行，且满足第一预设条件时，发出第一控制指令；或者，当一个或者多个应用程序由后台切换到前台运行，和/或满足第二预设条件，发出第二控制指令；当接收到第一控制指令时，将即将发送给一个或者多个应用程序的广播进行冻结，并缓存；或者，当接收到第二控制指令时，将发送给一个或者多个应用程序的广播进行解冻，分发给一个或者多个应用程序。本发明实施例提供的广播的管控方法及终端，可以避免一个或者多个应用程序在后台频繁的接收广播，导致的系统卡顿的问题，以及终端发热的问题等。

Description

广播的管控方法、装置及终端

技术领域

本发明涉及移动通信技术领域，尤其涉及一种广播的管控方法、装置及终端。

背景技术

广播作为Android系统的四大组件之一，属于进程间的一种通讯机制，在很多操作系统中都被广泛应用。广播可以用于传递数据、发送通知等。但是，也正是因为广播被广泛应用，所以也就出现了一些不可避免的困扰。例如，当应用处于后台运行时，虽然暂时不被用户所用，但是应用可以频繁的接收广播，利用广播来实现自启动，从而消耗终端设备的电量。

发明内容

本发明实施例提供了一种智能管控广播的方法、装置及终端。

第一方面，本发明提供了一种广播的管控方法，该方法应用于终端中，其中，第一应用运行于终端的操作系统上，所述方法包括：

当第一应用运行于终端的操作系统的后台时，获取待发送至第一应用的第一广播；

缓存第一广播，停止发送第一广播至第一应用。

结合第一方面，在第一方面的第一种可能的实现方式中，缓存第一广播，停止发送第一广播至第一应用，该方法还包括：

确定第一应用的运行特征满足第一预设冻结条件，其中第一应用的运行特征包括第一应用在终端的操作系统的后台持续运行时间，第一预设冻结条件包括应用的后台持续运行时间大于预设运行时间。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，缓存第一广播，停止发送第一广播至第一应用，该方法还包括：

确定第一广播属于预设冻结广播，其中，预设冻结广播包括预设的系统广播和预设的第二应用广播中的至少一个。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第三种可能的实现方式中，缓存第一广播，停止发送第一广播至第一应用，该方法还包括：

确定第一广播的运行特征满足第二预设冻结条件，其中第一广播的运行特征包括第一广播的接收者数量，第二预设冻结条件包括广播的接收者数量大于预设接收者数量；或者，

确定第一广播的运行特征满足第二预设冻结条件，其中第一广播的运行特征包括第一广播的发送频率，第二预设冻结条件包括广播的发送频率高于预设发送频率。

结合第一方面至第一方面的第三种可能的实现方式中的任一种，在第一方面的第四种可能的实现方式中，缓存第一广播，停止发送至第一应用之后，该方法还包括：解冻第一广播，发送第一广播至第一应用。

结合第一方面的第四种可能的实现方式，在第一方面的第五种可能的实现方式中，解冻第一广播之前，该方法还包括：检测到第一应用由终端的操作系统的后台运行切换至前台运行。

结合第一方面的第一方面的第四种可能的实现方式，在第一方面的第六种可能的实现方式中，解冻第一广播之前，该方法还包括：获取待发送至第一应用的第二广播，其中，第二广播属于预设重要广播。

结合第一方面至第一方面的第三种可能的实现方式中的任一种，在第一方面的第七种可能的实现方式中，缓存第一广播之后，该方法包括：

获取待发送至第一应用的第三广播；

确定第三广播与第一广播是否属于同一类型的广播；

如果第三广播与第一广播为同一类型的广播，则缓存第三广播，并删除已缓存的第一广播。

第二方面，本发明提供了一种广播的管控装置，其中，第一应用运行于终端的操作系统上，该装置包括：

广播获取模块，用于当第一应用运行于终端的操作系统的后台时，获取待发送至第一应用的第一广播；

广播分发模块，用于缓存第一广播，停止发送第一广播至第一应用。

结合第二方面，在第二方面的第一种可能的实现方式中，广播分发模块还用于，确定第一应用的运行特征满足第一预设冻结条件，其中第一应用的运行特征包括第一应用在终端的操作系统的后台持续运行时间，第一预设冻结条件包括应用的后台持续运行时间大于预设运行时间。

结合第二方面或第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，广播分发模块还用于，确定第一广播属于预设冻结广播，其中，预设冻结广播包括预设的系统广播和预设的第二应用广播中的至少一个。

结合第二方面或第二方面的第一种可能的实现方式，在第二方面的第三种可能的实现方式中，广播分发模块还用于，确定第一广播的运行特征满足第二预设冻结条件，其中第一广播的运行特征包括第一广播的接收者数量，第二预设冻结条件包括广播的接收者数量大于预设接收者数量；或者，

确定第一广播的运行特征满足第二预设冻结条件，其中第一广播的运行特征包括第一广播的发送频率，第二预设冻结条件包括广播的发送频率高于预设发送频率。

结合第二方面至第二方面的第三种可能的是实现方式中的任一种，在第二方面的第四种可能的实现方式中，广播分发模块还用于，解冻第一广播，发送第一广播至第一应用。

结合第二方面的第四种可能的实现方式，在第二方面的第五种可能的实现方式中，广播分发模块还用于检测所述第一应用由终端的操作系统的后台运行切换至前台运行。

结合第二方面的第四种可能的实现方式，在第二方面的第六种可能的实现方式中，广播分发模块还用于获取待发送至第一应用的第二广播，其中，第二广播属于预设重要广播。

结合第二方面至第二方面的第三种可能的是实现方式中的任一种，在第二方面的第七种可能的实现方式中，广播分发模块还用于：获取待发送至第一应用的第三广播；

确定第三广播与第一广播是否属于同一类型的广播；

如果第三广播与第一广播为同一类型的广播，则缓存第三广播，并删除已缓存的第一广播。

第三方面，本发明实施例提供了一种终端，所述终端包括处理器、存储器、系统总线及通信接口；处理器、存储器以及通信接口通过系统总线建立连接，一个或多个程序都将被存储在存储器中并被配置为所述处理器执行，一个或多个程序包括用于执行第一方面所述的广播的管控方法的所有指令。

基于上述技术方案，本发明实施例提供的一种广播的管控方法、装置及终端，当识别到一个或者多个应用程序处于后台运行，以及满足一定的条件时，则将一个或者多个应用程序即将要接收的广播进行冻结。由此解决一个或者多个应用程序在后台频繁的接收广播，导致的系统卡顿的问题，以及过高消耗终端设备的电量，导致终端设备发热的问题等，同时进一步的提高了系统的性能。而当一个或者多个应用程序由后台切换到前台运行时，和/或满足解冻条件时，可以解冻一个或者多个应用程序的广播，方便一个或者多个应用程序处理其要接收的广播。

附图说明

图1为现有技术中广播发送的信令流程图；

图2为本发明实施例提供的一种终端的系统架构图；

图3为本发明实施例提供的广播发送的信令流程图；

图4(a)-图4(c)为本发明实施例提供的一种广播的管控方法流程示意图；

图5(a)-图5(b)为本发明实施例提供的解冻广播的信令流程图；

图6为本发明实施例提供的一种广播的管控装置结构示意图。

具体实施方式

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

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

广播是一种消息传递机制，有发送方和接收方。其中，发送方和接收方均可以是终端中的系统应用程序或者是终端中安装的第三方应用程序。在现有技术中，发送方发送广播消息，可以有多个接收方。接收方可以指定接收哪些广播。发送方也可以指定发送给哪些接收方。接收方接收广播后可以在后台活动或者更新自己的状态。如果已经指定哪些发送方或者接收方时，广播分发模块在接收到发送方的广播后，无需一一查询哪个接收方需要接收这种广播，而是直接发送到指定的接收方中去。当然，如果发送方没有指定哪些接收方接收广播，或者接收方没有指定哪些发送方发送广播时，广播就会通过发送方发送到终端的广播分发模块中，由广播分发模块分发广播到相应的接收方中(在收发广播之前，接收方已经提前注册好需要接收哪种广播，当处理器收到这些广播时，自动将这些广播分发到对应的应用中)。以安卓操作系统为例，具体的广播分发过程如图1所示，图1为现有技术中的安卓操作系统的广播发送的信令流程图。

具体的，安卓操作系统提供的ActivityManagerService(简称AMS)系统服务用于管理安卓操作系统中activity的各种行为，控制activity的生命周期，派发消息事件，进行低内存管理等等。AMS实现了IBinder接口，可以用于进程间通信。Android广播分为两个方面：广播发送者和广播接收者，通常情况下，BroadcastReceiver指的是广播接收者(或广播接收器)。广播作为Android组件间的通信方式，可以使用的场景如下：

1.同一app内部的同一组件内的消息通信(单个或多个线程之间)；

2.同一app内部的不同组件之间的消息通信(单个进程)；

3.同一app具有多个进程的不同组件之间的消息通信；

4.不同app之间的组件之间消息通信；

5.Android系统在特定情况下与App之间的消息通信。每一个广播都会有自己的标识，方便AMS识别广播到底是什么广播，具体需要发送到哪个接收器中等。确定广播接收方后，AMS则会将广播的属性(例如广播发送方的进程ID和/或用户ID，广播发送方，广播接收方，广播接收方的进程ID和/或用户ID等)以及广播内容进行封装，形成一个broadcastrecord。AMS先确定广播的类别，例如广播是有序广播或者无序广播，假设广为有序广播，则将broadcast record加入到有序广播缓存队列，然后按序将broadcast record发送到对应的广播接收方中。具体实现原理如下：

1.广播接收者BroadcastReceiver通过Binder机制向AMS(Activity ManagerService)进行注册；

2.广播发送者通过binder机制向AMS发送广播；

3.AMS查找符合相应条件(IntentFilter/Permission等)的BroadcastReceiver，将广播发送到BroadcastReceiver(一般情况下是Activity)相应的消息循环队列中；

4.消息循环执行拿到此广播，回调BroadcastReceiver中的onReceive()方法，发送该广播至对应的广播接收者中。

而正是因为在现有技术中，AMS并不会刻意识别广播接收方当前的运行状态，也即是某应用程序正处于前台运行还是处于后台运行。而当应用处于后台运行时，虽然暂时不被用户所用，还是可以频繁的接收广播，利用广播来实现自启动，从而消耗终端设备的电量。

因此，为了解决上述技术问题，在本发明中，提出了一种广播的管控方法，该方法主要应用于一种终端，其中，第一应用运行于终端的操作系统上。如图2所示，图2为本发明实施例提供的一种终端的系统架构图200。

应理解，该终端可以是手机、平板电脑等任意一种终端设备，在本申请文件中不做任何限定。而终端的操作系统可以是安卓系统或者其他系统，在这里同样不做任何限定。只是在下文的具体实施例中，本申请文件均以安卓系统为例进行说明。其他系统的操作方式类似，这里不做限定。

终端可以包括处理器201，存储器202，系统总线203以及通信接口204。

其中，处理器201、存储器202和通信接口204可以通过总线203实现彼此之间的通信连接，也可以通过无线传输等其他手段实现通信。

处理器201可以为中央处理器(英文：central processing unit，缩写：CPU)。

存储器202可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：RAM)；存储器也可以包括非易失性存储器(英文：non-volatile memory)，例如只读存储器(英文：read-only memory，缩写：ROM)，快闪存储器，HDD或SSD；存储器202还可以包括上述种类的存储器的组合。在通过软件来实现本申请提供的技术方案时，用于实现本申请图4提供的广播的管控方法的程序代码保存在存储器202中，并由处理器201来执行。

另外，与图1对应的，在本发明的实施例中，还提供了一种广播发送的信令流程图，如图3所示。

如图3所示，广播发送方(例如，除第一应用之外的其他应用程序或者系统本身)在需要发出广播时，首先将广播发送到AMS。AMS则会查询该广播的接收方。当查询到该广播的其中一个接收方是第一应用时，而第一应用已经处于后台运行。那么此时，AMS暂时不会将该广播发送到第一应用中，而是将该广播缓存。具体的，AMS中新增用于存储该广播的存储区，用于冻结该广播的发送。进一步地，该存储区还可以具体分为有序广播存储区和无序广播存储区。

可选的，可以首先确定广播的种类，例如第一广播为有序广播，则将其缓存在有序广播的存储区。当第一广播为无序广播时，则将其缓存在无序广播的存储区。

通过将广播缓存，停止发送到第一应用中，可以避免应用在处于后台运行时不断的接收广播，以此降低了系统功耗，大大提高系统的性能。

应理解的是，应用程序在终端的操纵系统中的运行状态可以分为前台运行和后台运行。前台运行，即直接在显示屏的显示的窗口或界面上运行，呈现出程序运行的当前界面，可以和终端设备的使用者(即用户)通过显示的界面进行互动。后台运行，是指显示屏不呈现应用程序的运行界面，但该应用程序在后台继续提供服务，可以随时切换成前台运行并在显示屏上显示出来。

以安卓操作系统为例，说明系统如何判断一个应用的当前运行状态，具体地：

当应用被打开后，Android系统会调用onResume等方法来使该应用的activity处于运行状态。在该应用的activity启动后，activity包括：运行Resumed状态、暂停Paused状态以及停止Stopped状态。如果所述应用的activity处于Resumed状态，则可以认为所述应用处于前台运行状态，而如果所述应用的activity处于Paused状态，则认为所述应用处于后台运行。

图3所示的广播的管控方法信令流程图仅仅是简单的介绍了本发明的技术方案。而具体的方法步骤可以参考下文中广播的管控方法流程的具体介绍。

图4(a)-图4(c)为本发明提供的一种广播的管控方法的流程示意图，该方法流程主要是通过软件形式来实现，但是实体上是由处理器来完成的。具体工作过程如下：

S410,当第一应用运行于终端的操作系统的后台时，获取待发送至第一应用的第一广播。

S420，缓存第一广播，停止发送第一广播至第一应用。

具体的，由步骤410可知，第一应用已经处于后台运行。所以，AMS在接收到广播发送方发出的第一广播后，就会将第一广播暂时缓存，停止发送第一广播至第一应用中。

当应用程序处于后台运行时，就将其即将要接收的所有广播都缓存，可以避免应用在后台运行时频繁的接收广播，增加系统功耗，降低系统的性能。

但是，一旦检测到第一应用处于后台，就缓存其所要接收的所有广播，将有可能造成第一应用不能及时处理重要的广播。因为，本发明还提出了其他优选地方案，来避免应用不能及时处理重要的广播的问题。

优选的，可以在第一广播发送到第一应用之前，该方法还可以包括：S415，首先确定第一应用的运行特征是否满足第一预设条件，例如，第一应用在终端的操作系统的后台持续运行时间大于预设运行时间。那么将第一广播缓存，停止发送第一广播至第一应用中。

进一步优选的，在缓存广播时，为了避免系统功耗增加，降低系统的性能。可以只冻结接收者众多的广播和发送频率过高的广播。因此，在步骤420之前，该方法还可以包括S430，确定第一广播的运行特征是否满足第二预设冻结条件。

例如，确定第一广播的接收者数量是否大于预设接收者数量；或者，确定第一广播的发送频率是否高于预设发送频率。当第一广播的接收者数量大于预设的接收者数量时，若同时将该第一广播发送到多个接收者中时，很容易造成系统的瞬时卡顿，甚至会消耗系统的功耗。类似的，当第一广播的发送频率高于预设的发送频率时，也会造成系统的瞬时卡顿和系统功耗的消耗。因此，当第一广播为这两类广播时，同样需要将第一广播缓存，停止发送到第一应用中。

当然，不仅仅是在上述两种情形时，需要将第一广播缓存。还可以包括以下情形：如果在接收第一广播时，消耗电量大于预设的电量阈值，或者接收的第一广播，会导致系统瞬时卡顿时，同样需要将该第一广播立即缓存。

应理解，步骤430与步骤415并不冲突。步骤430可以在没有步骤415的情况下，在步骤410之后执行。也可以在存在步骤415的情况下，在步骤415之后执行。具体如图4(a)，4(b)和4(c)所示。图4(a)是仅包含步骤410和420的方法流程图。4(b)是包括步骤430，但是不包含步骤415的方法流程图。图4(b)是同时包含步骤415和步骤430的方法流程图。

进一步优选的，因为广播可以分为系统广播和非系统广播。这里的非系统广播就是第三方应用程序所发出的广播。AMS在确定第一广播是否是接收者众多的广播，或者判断第一广播是否是发送频率过高的广播时，可以设定一个广播名单。该广播名单中包括的是预设冻结广播。预设冻结广播包括预设的系统广播和预设的第二应用广播中的至少一个。在接收第一广播时，可可以先确定是否存在该广播名单中，当第一广播存在于这个广播名单中时，则说明该广播是属于接收者众多或者发送频率过高的广播中一类，需要将第一广播缓存。如此，可以更加方便AMS尽快的处理所有的广播。

在安卓系统中，AMS本身就可以识别出哪些系统广播是符合频繁发出的广播，例如电量更新的广播等。哪些又是接收者众多的系统广播，例如亮屏和灭屏的广播等。哪些是容易导致系统瞬时卡顿的系统广播，例如WiFi广播等。还有哪些是速率过高的系统广播，或者接收哪些系统广播将会导致耗电严重的系统广播等(这里不再一一举例)，这些都是提前可以预知的广播，因此可以提前静态的配置好。而有一些广播，并不是系统本身发出的，而是第二应用发出的广播。这些非系统广播则需要AMS动态的确定。

因此，缓存第一广播，停止发送第一广播至第一应用，就还包括另一种方法，确定第一广播的运行特征是否满足第二预设冻结条件。而第一广播的运行特征可以是第一广播的接收者数量或者第一广播的发送频率等等。预设冻结条件则是广播的接收者数量大于预设接收者数量，或者广播的发送频率高于预设发送频率。

在一个具体的例子中，需要动态确定的非系统广播可以包括：一些速率过高的非系统广播，接收者众多的非系统广播，造成系统卡顿的非系统广播等等。AMS在一个固定的时间段内，统计出这些非系统广播。例如，频繁发出的非系统广播，AMS将会统计在十分钟内，该广播发出的次数。又例如，一种非系统广播，AMS在分发的过程中，就会统计这种广播都会发送到哪些应用中，当接收该广播的应用个数过多时，则将这种非系统广播缓存。而可以准确识别广播发送方发出的广播是上述所介绍的任一种广播方法就是识别广播的标识。每一个广播都有自己的标识(例如微信广播的标识是：com.tencent.mm.broadcast)。确定好这些广播之后，可以将这些广播加入到广播名单中。加入到广播名单中之后，也就成为了预设的第二应用的广播。

当AMS在接收到第一广播时，可以将第一广播与广播名单进行匹配，当确定第一广播属于名单中的广播时，则缓存第一广播，停止发送到第一应用。

此外，缓存第一广播之后，该方法还可以包括步骤440，获取待发送至第一应用的第三广播。

AMS在接收广播时，可以会在不同的时间段接收到同一种广播或者是同一类型的广播。因此，在接收到第三广播时，则需要判断第三广播与第一广播是否属于同一种或者是同一类型的广播；如果第三广播与第一广播为同一种或者同一类型的广播时，则缓存第三广播，并删除已缓存的第一广播。

这里所说的同一种广播，例如电量广播，在第一时刻，广播发送方发出的电量广播显示电量的数值是90％，而在第二时刻，广播发送方发出的电量广播显示电量是70％。而这两个广播本来就是同一种广播，如果都进行缓存的话，将会占用系统资源，而电量本身就是需要实时更新的，当接收到第二时刻发送的电量广播时，第一时刻接收的电量广播已经没有任何意义。所以，当AMS接收到显示电量为70％的电量广播时，就可以将显示电量为90％的电量广播删除，只缓存显示电量为70％的电量广播即可。

类似的，当接收到的第三广播是和第一广播属于同一类型的广播，例如第一广播是亮屏广播，而第三广播是灭屏广播。这类广播同样只缓存最后一次更新的广播就好，因此，可以删除第一广播，而只缓存第三广播即可。如此可以大大节省系统资源，提高系统的性能。

还应说明的是，一种广播，可能仅仅是针对某一应用程序或者某几个应用程序而言，需要冻结；而对于其他应用程序而言，不需要冻结。当该种广播需要发送到其他应用程序中时，AMS会按照规定将其发送到对应的应用程序中。例如，Facebook和MSN都将接收电量更新的广播。而Facebook已经处于后台，且满足上述所介绍的任意一种冻结广播的条件。那么，AMS将会将该电量广播暂时停止发送到Facebook中，而将其进行缓存。而MSN所要接收的广播并不需要冻结，因此，该广播将会照旧发送到MSN当中。

与缓存广播相对应的，本发明的实施例中，还包括解冻广播的方法步骤。

步骤450，解冻第一广播，发送第一广播至第一应用。

具体的解冻第一广播的条件可以包括：检测到第一应用由终端的操作系统的后台运行切换至前台运行。或者，获取待发送至第一应用的第二广播，其中，第二广播属于预设重要广播。

解冻的前提是，当第一应用处于后台运行时，所接收的全部或者部分广播已经被冻结。这里的部分广播是指步骤430中所介绍的接收者众多、发送频率过高以及导致系统卡顿等等类型的广播。当第一应用由后台切换到前台运行时，则将这些广播解冻，通过AMS依次发送到广播接收方。

而预设的重要的广播，可以是电话广播，或者短信广播等等。当有电话接入或者短信接入时，第一应用可能需要立即处理这些广播。而处理这些广播的前提是，需要处理当前正在缓存的广播。所以，AMS会将缓存的广播首先发送到第一应用中，当第一应用处理完毕之后，再将重要的广播发送到第一应用中，以便于第一应用及时的处理重要广播。

应理解，解冻第一广播的条件不仅仅包括上述介绍的两种情况。也可以是以下情形中的一种或者多种。

例如，第一应用与其他应用之间存在互相依赖关系，当其他应用需要解冻时，因为第一应用与该应用之间的依赖关系，所以需要将第一应用所要接收的广播解冻；和/或冻结的广播时间阈值大于第四预定阈值；和/或冻结的广播的数量大于第五预定阈值；又或者包括一些异常情况等等。

例如，A应用程序捆绑B应用程序的服务功能(比如，利用打车软件进行支付时，可能需要绑定手机银行客户端的支付功能)，和/或冻结的广播的时间大于1小时；和/或冻结的广播数量大于50条等等。当满足这些条件时，AMS同样会对第一应用需要接收，而当前正在被冻结的广播进行解冻。

优选的，在解冻广播时，AMS可以按照广播冻结的时间顺序对广播进行解冻，然后依次处理，也就是将解冻后的广播按照冻结的时间顺序依次分发到需要接收这些广播的一个或者多个应用程序中，直至所有冻结的广播都处理完毕。然后，再将待发送的重要的广播发送到该应用程序中。换言之，AMS再处理广播时，无论是冻结的广播或者未冻结的广播，都要按照接收广播时间的先后顺序进行处理。

还应理解的是，广播可以分为有序广播和无序广播。所以，AMS在接收到广播时，还可以先将广播分为有序广播和无序广播。若发现有序广播中的哪些广播需要冻结时，则将需要冻结的有序广播加入到有序广播冻结队列中进行缓存。若发现无序广播中的哪些广播需要冻结时，则将需要冻结的无序广播加入到无序广播的冻结队列中进行缓存。

而当冻结的广播需要解冻时，同样是分为解冻有序广播和解冻无序广播。在解冻无序广播之后，可以将一种无序广播同时发送到多个广播接收方中。而在解冻有序广播之后，则需要一个一个的发送广播，当一个广播发送到对应的某一个应用程序中后，AMS需要在接收到该应用程序发送的成功通知指令后，在将该广播发送到下一个对应的应用程序中，或者是将其他广播发送到对应的某一个应用程序中。

在一个具体的实施例中，终端以手机为例进行说明。手机中安装了Facebook、MSN、以及Skype等等中的一个或者多个应用程序，其中，Facebook和MSN正在后台运行，而Skype在前台运行。

当AMS在接收到广播发送方发送的电量广播后，已经确定该广播需要分别发送到Facebook、MSN以及Skype中。其中，Facebook已经在后台运行的时间超过了5分钟(假设第一阈值是5分钟)，MSN则是刚刚由前台切换到后台运行，运行时间并没有超过5分钟。Skype则一直处于前台运行。那么，AMS会根据上述情况，将电量广播分别发送到MSN和Skype中。而因为Facebook中要接收的广播则均需要进行缓存。所以，电量广播暂时不会发送到Facebook中，而是被缓存在存储器在某一个存储区中。暂时停止发送到Facebook中。

在另一个具体的例子中，假设终端在安装Skype时，Skype还绑定了一款游戏软件，该软件频繁的接收广播。目的就是为了在接收广播的过程中，频繁被唤醒，然后去下载一些广告等等，这样，在很短的时间内，例如30分钟内，该游戏软件就可以消耗电量值达到百分之五。所消耗的电量已经超过了第二预定阈值(例如一小时内消耗电量为4％)。

又或者，假设Facebook在后台运行时，中央AMS(Central Processing Unit，简称CPU)的资源为10～15％，而第四预定阈值为5％，那么360安全卫士在后台运行时，所占用的资源已经超过了第四预定阈值。

针对上述两种情况，AMS同样会缓存这两种应用程序所要接收的广播。

可选的，在某一些应用程序中，如果缓存该应用程序的所有广播，可能会造成一些不便，例如360安全卫士，它可能接收到一些广播是关于垃圾短信或者骚扰电话的。而这些广播如果都被缓存的话，那么360就无法立即拦截这些短信或者广播，从而对用户造成一些不必要的困扰。又或者，有一些广播是重要的广播，需要用户立即处理，而如果将这些广播同样冻结的话，也会对用户造成不便。

所以，在本实施例的另一个具体的例子中，可以只冻结预设冻结广播。其中，预设冻结广播包括静态配置的系统广播和动态确定的非系统广播。预设冻结广播可以显示在一个广播名单上。为了读者更好的理解预设冻结广播的表现形式，本实施例中画出一个表格，举例说明预设冻结广播种类以及广播名单的组成形式。当然，这里仅仅是一个范例，预设冻结广播的表现形式也可以采用其他方式，这里不做任何的限定。而在广播名单中的所有广播仅仅是有限的举例，并不能够完全代表广播名单中的所有广播。

具体的广播名单的表现形式如表1所示：

表1

AMS在接收到广播后，都将会与广播名单进行匹配，当确定某一广播存在于广播名单中时，说明该广播是预设冻结广播，而该广播所要发送的应用程序符合在上文中所介绍的任意一种缓存广播的条件，那么该广播则会被缓存到存储器中。否则，按照相应的规定，将该广播分发到对应的应用程序中。

而为了减少冻结广播的数量，提高系统的性能。在本实施例中的另一个具体的例子中，若AMS识别到广播发送方发出的广播是同一种广播和/或同一类广播时，例如发出的广播是电量广播，前一次冻结并缓存的电量广播显示电量的数值是90％，而本次显示的电量广播则是89％。那么，AMS将会将冻结的前一次广播删除掉，然后冻结本次的电量广播，即在存储器中只缓存89％的电量广播。类似的，若是同一类型的广播，例如是亮屏/灭屏广播，存储器中当前存储的是亮屏广播，而本次需要冻结的广播是灭屏广播，那么AMS将会将当前存储的亮屏广播删除，然后将本次的灭屏的广播冻结，也即是将本次的灭屏广播缓存到存储器中。从而节省资源，提高系统的性能。

当然，与冻结广播相对应的，AMS还用于为冻结的广播进行解冻。而具体的解冻条件已经在上文中详细说明，这里同样不在赘述。仅仅是说明解冻的过程，具体过程参见图5(a)-图5(b)所示的解冻广播的信令流程图。

图5(a)-图5(b)为本发明实施例提供的解冻广播的信令流程图，具体解冻广播的信令流程如图5(a)和图5(b)所示。其中，图5(a)是当检测到应用由后台切换到前台时，解冻广播的信令流程图。图5(b)是当AMS获取待发送到第一应用的第二广播时，解冻广播的信令流程图。

具体的，当已被冻结的广播满足图4中的步骤440所介绍的任一种解冻条件时，广播分发模块则将已冻结的广播从缓存中取出，确定冻结的广播需要发送到哪些广播接收方中，然后将广播的属性(例如广播发送方的进程ID和/或用户ID，广播发送方，广播接收方，广播接收方的进程ID和/或用户ID等)以及广播的内容进行封装，形成一个broadcastrecord。将broadcast record依次发送到广播的接收方中。

本发明实施例提供的一种管控广播的方法，当识别到一个或者多个应用程序处于后台运行，以及满足一定的条件时，则将一个或者多个应用程序即将要接收的广播进行冻结。由此解决一个或者多个应用程序在后台频繁的接收广播，导致的系统卡顿的问题，以及过高消耗终端设备的电量，导致终端设备发热的问题等，同时进一步的提高了系统的性能。而当一个或者多个应用程序由后台切换到前台运行时，和/或满足第二预设条件时，可以解冻一个或者多个应用程序的广播，方便一个或者多个应用程序处理其要接收的广播。

与上述广播的管控方法实施例相对应的，本发明实施例中还提供了一种广播的管控装置。图6为本发明实施例提供的一种广播的管控装置结构示意图600，如图6所示，该装置包括：广播获取模块601，广播分发模块602。

广播获取模块601，用于当第一应用运行于终端的操作系统的后台时，获取待发送至第一应用的第一广播。

广播分发模块602，用于缓存第一广播，停止发送第一广播至第一应用。

可选的，广播分发模块602还用于，确定第一应用的运行特征满足第一预设冻结条件，其中第一应用的运行特征包括第一应用在终端的操作系统的后台持续运行时间，第一预设冻结条件包括应用的后台持续运行时间大于预设运行时间。

进一步可选的，广播分发模块602还用于，确定第一广播属于预设冻结广播，其中，预设冻结广播包括预设的系统广播和预设的第二应用广播中的至少一个。

进一步可选的，广播分发模块602还用于，确定第一广播的运行特征满足第二预设冻结条件，其中第一广播的运行特征包括第一广播的接收者数量，第二预设冻结条件包括广播的接收者数量大于预设接收者数量；或者，确定第一广播的运行特征满足第二预设冻结条件，其中第一广播的运行特征包括第一广播的发送频率，第二预设冻结条件包括广播的发送频率高于预设发送频率。

可选的，广播分发模块602还用于：获取待发送至第一应用的第三广播；

确定第三广播与第一广播是否属于同一类型的广播；

如果第三广播与第一广播为同一类型的广播，则缓存第三广播，并删除已缓存的第一广播。

与缓存第一广播相对应的：

广播分发模块602还用于，解冻所述第一广播，发送所述第一广播至所述第一应用。

而解冻的条件可以包括：

广播分发模块602还用于检测第一应用由终端的操作系统的后台运行切换至前台运行；或者，广播分发模块还用于获取待发送至第一应用的第二广播，其中，第二广播属于预设重要广播。

而本实施例中的所有的功能模块所执行的具体的方法动作，可以参考广播的管控方法步骤，为叙述简便，这里不再赘述。

还应理解的是，在与本实施例对应的广播的管控方法实施例中，因为是以安卓系统为例进行说明，所以广播分发模块均以AMS为例进行说明。但是，本发明不仅仅可以应用到安卓系统中，同样可以应用到其他的系统中，因此，广播分发模块在其他应用系统中，可以表现其他形式，这里不做限定。

本实施例提供的一种广播的管控装置，当识别到一个或者多个应用程序处于后台运行，以及满足一定的条件时，则将一个或者多个应用程序即将要接收的广播进行冻结。由此解决一个或者多个应用程序在后台频繁的接收广播，导致的系统卡顿的问题，以及过高消耗终端设备的电量，导致终端设备发热的问题等，同时进一步的提高了系统的性能。而当一个或者多个应用程序由后台切换到前台运行时，和/或满足解冻条件时，可以解冻一个或者多个应用程序的广播，方便一个或者多个应用程序处理其要接收的广播。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理模块执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种广播的管控方法，其特征在于，所述方法应用于终端中，其中，第一应用运行于所述终端的操作系统上，所述方法包括：

当所述第一应用运行于所述终端的操作系统的后台时，获取待发送至所述第一应用的第一广播；

当确定所述第一应用的运行特征满足第一预设冻结条件时缓存所述第一广播，停止发送所述第一广播至所述第一应用，其中所述第一应用的运行特征包括所述第一应用在所述终端的操作系统的后台持续运行时间，所述第一预设冻结条件包括应用的后台持续运行时间大于预设运行时间；

当检测到所述第一应用由所述终端的操作系统的后台运行切换至前台运行时，解冻所述第一广播，发送所述第一广播至所述第一应用；

其中，所述缓存所述第一广播之后，所述方法包括：

获取待发送至所述第一应用的第三广播；

确定所述第三广播与所述第一广播是否属于同一类型的广播；

如果所述第三广播与所述第一广播为同一类型的广播，则删除已缓存的所述第一广播，并且缓存所述第三广播替代已缓存的所述第一广播。

2.根据权利要求1所述的方法，其特征在于，所述缓存所述第一广播，停止发送所述第一广播至所述第一应用，所述方法还包括：

确定所述第一广播属于预设冻结广播，其中，所述预设冻结广播包括预设的系统广播和预设的第二应用广播中的至少一个。

3.根据权利要求1所述的方法，其特征在于，所述缓存所述第一广播，停止发送所述第一广播至所述第一应用，所述方法还包括：

确定所述第一广播的运行特征满足第二预设冻结条件，其中所述第一广播的运行特征包括所述第一广播的接收者数量，所述第二预设冻结条件包括广播的接收者数量大于预设接收者数量；或者，

确定所述第一广播的运行特征满足第二预设冻结条件，其中所述第一广播的运行特征包括所述第一广播的发送频率，所述第二预设冻结条件包括广播的发送频率高于预设发送频率。

4.根据权利要求1所述的方法，其特征在于，所述解冻所述第一广播之前，所述方法还包括：

获取待发送至所述第一应用的第二广播，其中，所述第二广播属于预设重要广播。

5.一种广播的管控装置，其特征在于，第一应用运行于终端的操作系统上，所述装置包括：

广播获取模块，用于当所述第一应用运行于所述终端的操作系统的后台时，获取待发送至所述第一应用的第一广播；

广播分发模块，用于确定所述第一应用的运行特征满足第一预设冻结条件时缓存所述第一广播，停止发送所述第一广播至所述第一应用，其中所述第一应用的运行特征包括所述第一应用在所述终端的操作系统的后台持续运行时间，所述第一预设冻结条件包括应用的后台持续运行时间大于预设运行时间；其中，所述广播分发模块还用于：获取待发送至所述第一应用的第三广播；确定所述第三广播与所述第一广播是否属于同一类型的广播；如果所述第三广播与所述第一广播为同一类型的广播，则删除已缓存的所述第一广播，并且缓存所述第三广播替代已缓存的所述第一广播；

所述广播分发模块还用于，当检测所述第一应用由所述终端的操作系统的后台运行切换至前台运行时，解冻所述第一广播，发送所述第一广播至所述第一应用。

6.根据权利要求5所述的装置，其特征在于，所述广播分发模块还用于，确定所述第一广播属于预设冻结广播，其中，所述预设冻结广播包括预设的系统广播和预设的第二应用广播中的至少一个。

7.根据权利要求5所述的装置，其特征在于，所述广播分发模块还用于，确定所述第一广播的运行特征满足第二预设冻结条件，其中所述第一广播的运行特征包括所述第一广播的接收者数量，所述第二预设冻结条件包括广播的接收者数量大于预设接收者数量；或者，

确定所述第一广播的运行特征满足第二预设冻结条件，其中所述第一广播的运行特征包括所述第一广播的发送频率，所述第二预设冻结条件包括广播的发送频率高于预设发送频率。

8.根据权利要求5所述的装置，其特征在于，所述广播分发模块还用于获取待发送至所述第一应用的第二广播，其中，所述第二广播属于预设重要广播。

9.一种广播的管控终端，其特征在于，所述终端包括处理器、存储器、系统总线及通信接口；所述处理器、存储器以及通信接口通过系统总线建立连接，一个或多个程序都将被存储在存储器中并被配置为所述处理器执行，一个或多个程序包括用于执行权利要求1至4中任一项所述方法的所有指令。

Images