CN110691401B - 一种系统应用的管理方法及装置 - Google Patents

Abstract

本申请涉及功耗领域，公开了一种系统应用的管理方法及装置。其中方法包括：进入维护期，维护期可以包括统一休眠期和统一活跃期；在统一休眠期内，对处于后台运行状态的系统应用进行冻结；在统一休眠期之后出现的统一活跃期内，对系统应用解除冻结，从而便于处于后台运行状态的一个或多个系统应用统一活动，有效减少电子设备的电量消耗以减轻电子设备的发热现象。

Description

一种系统应用的管理方法及装置

技术领域

本申请涉及终端技术领域，尤其涉及一种系统应用的管理方法及装置。

背景技术

随着互联网的深度发展，越来越多的行业加入到互联网浪潮中，产生了无数基于互联网的应用，提供了基于文字、图片、视频、游戏、大数据服务等等的娱乐活动。为此人们对终端性能的要求也在不断提高，虽然现在手机的配置以及软件优化已经发展到不错的阶段，但随着应用的不断发展，手机上应用的种类和数量也越来越多。

当前的手机可以同时打开很多个应用，但通常只有一个应用可以在前台运行，其他开启的应用只能在后台运行。用户在打开新的应用时，很少会主动结束其它在后台运行的应用，因此在不知不觉中可能会打开很多的应用，从而会增加手机的处理负荷和电量消耗并导致手机发热，影响用户体验。

发明内容

有鉴于此，本申请提供了一种系统应用的管理方法及装置，用以减少手机电量消耗以减轻手机发热现象。

第一方面，本申请实施例提供一种系统应用的管理方法，该方法可以应用于诸如手机、平板电脑等电子设备。该方法包括：进入维护期，维护期可以包括统一休眠期和统一活跃期；在统一休眠期内，对处于后台运行状态的系统应用进行冻结；在统一休眠期之后出现的统一活跃期内，对系统应用解除冻结。

本申请实施例中，通过在维护期内设置统一休眠期和统一活跃期，并在统一休眠期内对系统应进行冻结，以及在统一活跃期对系统应用解除，从而便于处于后台运行状态的系统应用统一活动，避免频繁唤醒操作系统而导致电子设备的电量消耗较为严重。

在一种可能的设计中，对系统应用进行冻结，包括：挂起系统应用所使用的部分或全部资源。

在一种可能的设计中，系统应用所使用的资源包括第一资源和/或第二资源；方法还包括：在系统应用使用第一资源时，记录第一资源的资源宿主，第一资源的资源宿主包括系统应用的用户标识符UID和系统应用的第一进程的进程名或进程标识符PID；和/或，在系统应用使用第二资源时，记录第二资源的资源宿主，第二资源的资源宿主包括系统应用的包名和系统应用的第二进程的进程名或PID。

本申请实施例中，考虑到系统应用的包名可能为共享包名，UID可能为共享UID，因此在记录资源宿主时，除记录系统应用的包名或UID之外，还可以进一步记录系统应用的进程的进程名或PID，从而便于准确区分不同系统应用所使用的资源。

在一种可能的设计中，若系统应用的UID为共享UID，则根据第一进程的进程名或PID挂起第一资源；挂起第二资源，包括：若系统应用的包名为共享包名，则根据第二进程的进程名或PID挂起第二资源。

本申请实施例中，根据系统应用的进程的进程名或PID，对处于后台运行状态的系统应用所使用的资源进行管控，从而能够实现对系统应用所使用的资源进行准确有效的管控。

在一种可能的设计中，进入维护期，包括：激活系统应用的管理功能后，若确定进入第一模式，则启动第一计时器；第一模式包括灭屏模式或休眠模式；若第一计时器的时长大于或等于第一时长，则进入维护期。

本申请实施例中，第一模式可以包括灭屏模式或休眠模式。当电子设备进入灭屏模式或休眠模式时，电子设备上运行的一个或多个系统应用均进入后台运行状态，此时，可以预留一段时间(比如第一时长)再进入维护期，从而使得各个进入后台运行状态的系统应用能够在该段时间内执行相应的业务，避免过早进入统一休眠期而导致业务无法正常执行。且由于是在电子设备进入第一模式后，进入维护期对系统应用所使用的资源进行管控，从而能够有效降低电子设备在第一模式下的电量消耗。

在一种可能的设计中，进入维护期，包括：若激活系统应用的管理功能，则启动第二计时器；若第二计时器的时长大于或等于第四时长，则进入维护期。

本申请实施例中，激活系统应用的管理功能后，可以预留一段时间(比如第二时长)即进入维护期，也就是说，不论电子设备处于第一模式或第二模式，均可以进入维护期对系统应用所使用的资源进行管控，从而能够有效降低电子设备在第一模式和第二模式下的电量消耗。

在一种可能的设计中，在统一休眠期内，对处于后台运行状态的系统应用进行冻结，包括：检测到系统应用进入后台运行状态，启动系统应用对应的第三计时器；若第三计时器的时长大于或等于第五时长时处于统一休眠期内，则对系统应用进行冻结。

在一种可能的设计中，对系统应用进行冻结之前，还包括：确定系统应用不具有可感知业务，且系统应用未注册保活。

本申请实施例中，可感知业务可以理解为可以被用户听到、看到等可被用户感知到的业务，因此，为避免降低用户体验，保证可感知业务的正常执行，在对系统应用进行冻结之前需要确保系统应用不具有可感知业务；当系统应用需要执行紧急业务时可以注册保活，因此，为保证紧急业务的正常执行，在对系统应用进行冻结之前需要确保系统应用未注册保活。

在一种可能的设计中，该方法还包括：根据系统应用的休眠期，确定统一休眠期；其中，系统应用的休眠期等于系统应用的活动周期；根据系统应用的活跃期，确定统一活跃期；其中，系统应用的活跃期等于系统应用的活动时长。

第二方面，本申请实施例还提供一种电子设备。该电子设备包括显示屏，至少一个处理器和存储器；所述存储器用于存储一个或多个计算机程序；当所述存储器存储的一个或多个计算机程序被所述至少一个处理器执行时，使得所述电子设备能够实现上述第一方面及其第一方面任一可能设计的技术方案。

第三方面，本申请实施例还提供了一种电子设备，所述电子设备包括执行上述第一方面或者第一方面的任意一种可能的设计的方法的模块/单元；这些模块/单元可以通过硬件实现，也可以通过硬件执行相应的软件实现。

第四方面，本申请实施例还提供一种芯片，所述芯片与电子设备中的存储器耦合，用于调用存储器中存储的计算机程序并执行本申请实施例第一方面及其第一方面任一可能设计的技术方案；本申请实施例中“耦合”是指两个部件彼此直接或间接地结合。

第五方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，当计算机程序在电子设备上运行时，使得所述电子设备执行本申请实施例第一方面及其第一方面任一可能设计的技术方案。

第六方面，本申请实施例的中一种程序产品，包括指令，当所述程序产品在电子设备上运行时，使得所述电子设备执行本申请实施例第一方面及其第一方面任一可能设计的技术方案。

附图说明

图1a为本申请实施例提供的应用图标示意图；

图1b为本申请实施例提供的Android操作系统对系统应用的UID在Process.java中的定义示例；

图1c为本申请实施例提供的手机的结构示意图；

图2a为本申请实施例提供的手机的软件结构框图；

图2b为本申请实施例提供的应用程序层、资源管控模块、应用管控模块、注册回调模块的功能示意；

图3a为对后台运行的系统应用所使用的资源不做限制时系统应用的活跃情形示意图；

图3b为采用本申请实施例提供的系统应用的管理方法后系统应用的活跃情形示意图；

图4a为本申请实施例提供的记录资源宿主的过程示意图；

图4b为本申请实施例提供的资源管控模块所记录的资源宿主及资源的其它信息示例；

图4c为本申请实施例提供的对系统应用所使用的资源进行管控示意图；

图5a为本申请实施例场景1提供的一种系统应用的管理方法所对应的流程示意图；

图5b为本申请实施例场景1提供的又一种系统应用的管理方法所对应的流程示意图；

图6a为本申请实施例场景2提供的一种系统应用的管理方法所对应的流程示意图；

图6b为本申请实施例场景2提供的又一种系统应用的管理方法所对应的流程示意图；

图7为本申请实施例提供的电子设备的结构示意图。

具体实施方式

首先，对本申请实施例涉及的部分用语进行解释说明。

(1)电子设备：可以为安装各类应用程序，并且能够将已安装的应用程序中提供的对象进行显示的设备。示例性地，该电子设备可以包含能够实现数据处理功能的器件(比如处理器或图像处理器或其他处理器)，以及能够显示用户界面的器件(比如显示屏)。该电子设备可以是移动的，也可以是固定的。例如，电子设备可以为智能手机、平板电脑、各类可穿戴设备、车载设备、个人数字助理(personal digital assistant，PDA)或其它能够实现上述功能的电子设备等。

(2)操作系统(operating system，OS)：是运行在电子设备上的最基本的系统软件，例如windows系统、Android系统、IOS系统。以智能手机为例，操作系统可以是Android系统或IOS系统。本申请实施例主要以Android系统为例进行介绍。本领域技术人员可以理解，其它操作系统中，也可以采用类似的算法实现。

(3)应用程序(application，APP)：可以简称为应用，为能够完成某项或多项特定功能的计算机程序。它可以具有可视的显示界面，能与用户进行交互，比如设置、电子地图、微信、QQ等；或者，也可以不具有可视的显示界面，不能与用户进行交互。示例性地，应用可以划分为第三方应用和系统应用，其中，第三方应用可以理解为用户安装的应用，比如微信、腾讯聊天软件(QQ)、WhatsApp Messenger、连我(Line)、Kakao Talk、钉钉等；系统应用可以理解为操作系统预置的应用，比如设置、拨号、信息等。

(4)运行状态：应用在操作系统中的运行状态可以分为前台运行状态和后台运行状态。前台运行状态，即直接在显示屏的显示窗口或界面上运行，呈现出程序运行的当前界面，可以和终端设备的使用者(即用户)通过显示的界面进行互动。后台运行状态，是指显示屏不呈现应用的运行界面，但该应用在后台继续提供服务。对于具有可视的显示界面的应用来说，其可以随时从后台运行状态切换成前台运行状态，或者从前台运行状态切换为后台运行状态；对于不具有可视的显示界面的应用来说，其可以处于后台运行状态，而无法切换到前台运行状态。

(5)应用图标：为显示在桌面上供用户识别应用的图标，比如如图1a所示，相机、设置等即为应用图标，用户点击应用图标，就可以打开相应的应用。通常情况下，具有可视的显示界面的应用可以具有对应的应用图标，而不具有可视的显示界面的应用不具有对应的应用图标。

(6)应用标识符：也可以称为用户标识符(user identification，UID)或应用标识，是应用安装过程中系统为其分配的标识。多个应用可以共享一个应用标识符。示例性地，在Android系统中，第三方应用的UID是从10000(即FIRST_APPLICATION_UID)开始，到19999(即LAST_APPLICATION_UID)结束，可以在Process.java中查看到FIRST_APPLICATION_UID和LAST_APPLICATION_UID。其中，第三方应用的UID通常大于FIRST_APPLICATION_UID，而系统应用的UID通常小于FIRST_APPLICATION_UID，也存在一些UID大于FIRST_APPLICATION_UID的系统应用，参见图1b，示意出了Android操作系统对系统应用的UID在Process.java中的定义。

进程标识：可以为进程标识符(process identification，PID)或进程名，其中，PID是在应用运行后，操作系统为应用的进程分配的身份标识。在应用停止运行后，操作系统会将PID收回，当应用程序再次开始运行时，操作系统将重新分配新的PID。一个进程标识符唯一标识一个进程。

包名(package name)：包名主要用于系统识别应用程序，多个应用程序可以共享一个包名。

本申请实施例提供一种系统应用的管理方法，该方法可以适用于任何安装有多个系统应用的电子设备。以下实施例以电子设备是手机为例进行介绍。示例性地，图1c示出了一种手机100的结构示意图。

如图1c所示，手机100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块151，无线通信模块152，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。

其中，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中，控制器可以是手机100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。在本申请实施例中，处理器110可以运行系统应用的管理方法所对应的软件代码/模块，执行相应的流程，以在统一休眠期内对处于后台运行状态的系统应用进行冻结，在统一活跃期内对系统应用解除冻结，具体的流程将在后文介绍。

显示屏194用于显示手机100中的处于前台运行状态的系统应用的显示界面，比如处于前台运行状态的设置应用的显示界面等，当系统应用由前台运行状态切换为后台运行状态时，将不再在显示屏上显示。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organiclight emitting diode的，AMOLED)，柔性发光二极管(flex light-emitting diode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot light emittingdiodes，QLED)等。在一些实施例中，手机100可以包括1个或N个显示屏194，N为大于1的正整数。

摄像头193用于捕获静态图像、动态图像或视频。在本申请实施例中，手机100中摄像头193的数量可以是至少两个。以两个为例，其一个是前置摄像头，另一个是后置摄像头；以三个为例，其中一个是前置摄像头，另外两个是后置摄像头。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行手机100的各种功能以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如设置、手机管家)等。存储数据区可存储手机100使用过程中所创建的数据等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

另外，手机100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。手机100可以接收按键190输入，产生与手机100的用户设置以及功能控制有关的键信号输入。手机100可以利用马达191产生振动提示(比如来电振动提示)。手机100中的指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。手机100中的SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195，或从SIM卡接口195拔出，实现和手机100的接触和分离。

可以理解的是，本发明实施例示意的结构并不构成对手机100的具体限定。在本申请另一些实施例中，手机100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

上述图1c对手机100的硬件结构进行了描述，以下以安卓(Android)操作系统为例，介绍本申请实施例提供的手机100的软件结构。

图2a示出了本申请实施例提供的手机100的软件结构框图。如图2a所示，手机的软件结构采用分层式架构。分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。如图2a所示，应用程序层可以包括系统应用程序和第三方应用程序，其中，系统应用程序可以包括相机、设置、皮肤模块、用户界面(user interface，UI)、手机管家、通话、短信息等，第三方应用程序可以包括地图，导航，音乐，视频等。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图2a所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器、包管理服务模块、资源管控模块、应用管控模块、注册回调模块等，还可以包括Wakelock代理、Alarm代理、广播代理(暂未在图中示意)。其中，以注册回调模块为例，本申请实施例是为了便于描述将其称为注册回调模块，在其它可能的实施例中，还可以有其它名称，具体不做限定。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。

视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。电话管理器用于提供手机100的通信功能，例如通话状态的管理(包括接通，挂断等)。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

包管理服务模块，用于在应用启动时，获取应用的身份信息，例如应用的包名或UID等。

资源管控模块包括第一资源管控模块和第二资源管控模块，其中，第一资源管控模块，用于基于应用级别对资源进行管控，比如可以按照应用的包名或UID记录资源宿主。第二资源管控模块，用于基于进程级别对资源进行管控，比如可以按照进程的进程名或PID记录资源宿主。

应用管控模块，用于对应用进行管控，比如决定对应用进行冻结或者决定对应用解除冻结。广播代理，用于在接收到发送方的广播后，将该广播分发给相应的接收方；以及，在资源管控模块通知挂起某一系统应用的广播资源时，缓存发送给该系统应用的广播，在资源管控模块通知恢复某一系统应用的广播资源时，将缓存的该系统应用的广播发送给该系统应用。

注册回调模块，用于接收系统应用注册的休眠期和活跃期，并将系统应用的休眠期和活跃期通知给应用管控模块，以及接收系统应用的注册保活请求，并将系统应用的注册保活请求通知给应用管控模块，以及在接收到应用管控模块发出的某一系统应用的资源使用超标提示后，将该提示转发给该系统应用。

Wakelock代理，用于对系统应用的Wakelock资源进行管理，比如在资源管控模块通知挂起某一系统应用的Wakelock资源时，代理该系统应用的Wakelock资源，在资源管控模块通知恢复某一系统应用的Wakelock资源时，将代理的Wakelock资源还给该系统应用。

Alarm代理，用于对系统应用的Alarm资源进行管理，比如在资源管控模块通知挂起某一系统应用的Alarm资源时，代理该系统应用的Alarm资源，在资源管控模块通知恢复某一系统应用的Alarm资源时，将代理的Alarm资源还给该系统应用。

广播代理，用于对系统应用的广播资源进行管理，比如在资源管控模块通知挂起某一系统应用的广播资源时，代理该系统应用的广播资源，在资源管控模块通知恢复某一系统应用的广播资源时，将代理的广播资源还给该系统应用。

为便于清晰描述应用程序层、资源管控模块、应用管控模块、注册回调模块的功能，下面结合图2b进一步介绍。如图2b所示：(1)系统应用的进程可以向资源管控模块发送使用资源的请求，相应地，资源管控模块可以记录资源宿主，其中，记录的资源宿主可以包括系统应用的包名(或UID)和PID。(2)系统应用的进程还可以向注册回调模块注册系统应用的休眠期和活跃期，相应地，注册回调模块可以将系统应用注册的休眠期和活跃期通知给应用管控模块，以便于应用管控模块基于一个或多个系统应用注册的休眠期和活跃期确定统一休眠期和统一活跃期。(3)系统应用的进程还可以向注册回调模块注册保活，注册回调模块可以将系统应用的注册保活请求通知给应用管控模块，如此，在统一休眠期内，应用管控模块可以获知系统应用是否注册保活，若系统应用注册保活，则在对系统应用进行冻结时，可以不挂起注册保活的资源。(4)应用管控模块若确定冻结某一系统应用(或对某一系统应用解除冻结)，则可以向资源管控模块发出系统应用的资源挂起指示(或资源恢复指示)，相应地，资源管控模块可以根据记录的资源宿主挂起(或恢复)系统应用所使用的资源。(5)应用管控模块可以按照设定周期检测系统应用在设定时间段内的资源使用状况，若确定系统应用的资源使用超过预设阈值，则可以向注册回调模块发送系统应用资源使用超标的提示，进而由注册回调模块将该提示转发给系统应用，以便于系统应用进行自检和修复，具体自检和修复的方式本申请不做限定。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动等，本申请实施例对此不做任何限制。

以图1c和图2a所示的手机100为例，手机100中可以包括多个应用，手机100中可以同时有多个应用在运行，但通常只有一个应用可以在前台运行，其他开启的应用只能在后台运行。

目前，Android操作系统对于在后台运行的系统应用所使用的资源不做限制，因此，当在后台运行多个系统应用时，会导致终端设备耗电过快、发热严重。举个例子，参见图3a所示，处于后台运行状态的系统应用包括系统应用1、系统应用2、系统应用3，更具体的，这些系统应用可以是设置进程，Android OS核心服务、push进程、手机找回进程等。系统应用1、系统应用2和系统应用3可以执行周期性业务，进而会周期性使用某些资源，比如系统应用1需要周期性执行定位业务，进而需要周期性使用全球定位系统(global positioningsystem，GPS)资源。本申请实施例中，系统应用执行业务或者使用资源，可以理解为系统应用在活动；系统应用执行业务的时长或者使用资源的时长，可以理解为系统应用的活动时长。

参见表1所示，为系统应用的活动周期和活动时长示例。

表1：系统应用的活动周期和活动时长示例

系统应用	活动周期(单位为分钟)	活动时长(单位为分钟)
			系统应用1	5	0.5
系统应用2	6	0.6
			系统应用3	9	0.5

表1中，第二行表示：系统应用1每隔5分钟执行一次业务(或者说活动一次)，活动时长为30秒；第三行表示：应用程序2每隔6分钟活动一次，活动时长为36秒；第四行表示：应用程序3每隔9分钟活跃一次，活动时长为30秒。

此种情况下，由于Android操作系统对系统应用在后台所使用的资源不做限定，因此，在t0至t1这段时间内，系统应用1、系统应用2、系统应用3共活动七次，从而使得Android操作系统被频繁唤醒，导致电量消耗较大。

基于此，本申请实施例提供一种系统应用的管理方法，在统一休眠期内，对处于后台运行状态的至少一个系统应用进行冻结，以及在统一活跃期内，对至少一个系统应用解除冻结，从而使得处于后台运行状态的至少一个系统应用可以在统一活跃期内统一活动，避免多个系统应用在多个时间点频繁活动而导致终端设备的电量消耗较大。

下述实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a,b,或c中的至少一项(个)，可以表示：a,b,c,a-b,a-c,b-c,或a-b-c，其中a,b,c可以是单个，也可以是多个。

以及，除非有特别说明，本申请实施例提及“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的顺序、时序、优先级或者重要程度。例如，第一应用和第二应用，只是为了区分不同的应用，而并不是表示这两种应用的内容、优先级、发送顺序或者重要程度等的不同。

示例性地，基于图1c示出的手机的硬件结构图和图2a示出的手机的软件结构图，本申请实施例提供的系统应用的管理方法，可以由图1c所示的手机中的一种或多种物理元器件以及图2a所示的软件架构层的各层之间的相互配合来实现。

下面对本申请实施例涉及的相关技术特征进行介绍。

一，系统应用使用资源

本申请实施例中，触发系统应用启动(或者说打开系统应用)的方式可以有多种，比如可以是自动触发启动，也可以是由其它应用触发启动，还可以是用户触发启动。其中，自动触发启动是指系统应用自行启动；其它应用触发启动是指由电子设备的其它应用根据接口调用该系统应用启动；用户触发启动可以是指用户通过触发应用图标来启动系统应用，也可以是用户通过触发系统应用对应的启动手势或者快速启动路径来启动系统应用。

以用户触发系统应用(比如设置应用)启动为例，结合图1c和图2a来说，当手机中的触摸传感器180K接收到用户的触摸操作，相应的硬件中断被发给内核层。内核层将触摸操作加工成原始输入事件(包括触摸坐标，触摸操作的时间戳等信息)。原始输入事件被存储在内核层。应用程序框架层从内核层获取原始输入事件，识别该输入事件所对应的控件。以该触摸操作是触摸单击操作，且该单击操作所对应的控件为设置的应用图标的控件为例，设置应用调用应用框架层的接口，启动设置应用，进而通过调用内核层驱动显示屏显示设置应用的界面。

进一步地，设置应用启动后，设置应用的进程可以使用资源。其中，资源可以包括比如CPU资源、存储器资源(或者说内存资源)、网络资源、操作系统的资源等，操作系统的资源可以包括软资源(比如Alarm资源、Wakelock资源、广播资源)和硬资源(比如蓝牙资源、传感器资源、GPS资源)。

本申请实施例中，资源管控模块可以在设置应用的进程使用资源时记录资源宿主，比如资源管控模块可以在设置应用的进程开始使用资源时记录资源宿主。下面结合图4a描述记录资源宿主的过程示例。

示例性地，以设置应用使用Alarm资源为例，参见图4a所示，记录资源宿主的过程可以包括：

步骤401，设置应用的进程向第一资源管控模块发送使用Alarm资源的请求。示例性地，该请求中可以包括设置应用使用Alarm资源的开始时间。

步骤402，第一资源管控模块接收到该请求后，记录设置应用的包名(比如Com.android.settings)或UID(比如1000)作为Alarm资源的资源宿主。示例性地，还可以记录设置应用使用Alarm资源的开始时间。

步骤403，第一资源管控模块将设置应用的进程使用Alarm资源这一事件通知给第二资源管控模块。

步骤404，第二资源管控模块记录设置应用的进程的PID(比如com.android.setting)作为Alarm资源的资源宿主。

步骤405，第二资源管控模块向第一资源管控反馈响应，以通知第一资源管控模块已记录设置应用的进程的PID作为Alarm资源的资源宿主。

步骤406，第一资源管控模块接收到第一资源管控反馈的响应后，可以向设置应用的进程反馈请求成功的响应。

示例性地：(1)上述是以设置应用的进程请求成功为例进行描述的，在一些可能的场景下，设置应用的进程也可能请求失败，此种情形下，第一资源管控模块可以向设置应用的进程反馈请求失败的响应。(2)步骤401至步骤406中的所涉及的步骤编号仅为执行流程的一种可能的示例，并不构成对各个步骤先后顺序的限定。(3)本申请实施例中，系统应用可以通过多次执行上述步骤401至步骤406，比如系统应用需要周期性使用Alarm资源，则可以周期性执行上述步骤401至步骤406。(4)系统应用可以在前台运行时通过上述步骤401至步骤406，或者，也可以在后台运行时通过上述步骤401至步骤406，具体不做限定。

通过上述所描述的过程可知，本申请实施例中，参见图4b所示，当系统应用的进程向资源管控模块发送使用资源(比如Alarm资源)的请求后，资源管控模块中记录的Alarm资源的资源宿主可以包括系统应用的包名、系统应用的UID、系统应用的进程的PID或进程名，进一步地，资源管控模块还可以记录Alarm资源的其它信息，比如系统应用使用Alarm资源的开始时间。本申请实施例中，由于在系统应用使用资源时，资源管控模块记录的资源宿主包括PID，从而便于后续按照PID或进程名对系统应用所使用的资源进行管控。为便于说明，后文中当涉及到按照PID或进程名对系统应用所使用的资源进行管控时，将主要以按照PID对系统应用所使用的资源进行管控为例进行描述。

通常情况下，资源是以UID或包名为单位进行管控的，例如，网络资源、Wakelock资源等是以UID为单位进行管控的，Alarm资源、广播资源、GPS资源、蓝牙资源等是以包名为单位进行管控的。然而，考虑到系统应用的包名可能是共享包名，系统应用的UID可能是共享UID，若仅是基于系统应用的包名或系统应用的UID可能无法准确地对系统应用所使用的资源进行挂起或恢复，因此，本申请实施例中在系统应用使用资源时，记录的资源宿主还包括PID或进程名，从而在系统应用的包名是共享包名和/或系统应用的UID是共享UID时，可以基于系统应用的进程的PID或进程名准确对系统应用所使用的资源进行管控。也就是说，参见图4c所示，针对于一些按照UID管控的资源(比如网络资源、Wakelock资源)，当系统应用的UID为独立UID时，可以仍按照UID对其进行管控，而当系统应用的UID为共享UID时，本申请实施例中还可以按照PID或进程名对系统应用所使用的资源进行管控；针对于一些按照包名管控的资源(比如Alarm资源、广播资源)，当系统应用的包名为独立包名时，可以仍按照包名对其进行管控，而当系统应用的包名为共享包名时，本申请实施例中还可以按照PID或进程名对系统应用所使用的资源进行管控。

本申请实施例中，对系统应用所使用的资源进行管控的实现方式可以有多种，比如可以通过冻结系统应用(冻结系统应用后，系统应用处于冻结状态)或者对系统应用解除冻结(对系统应用解除冻结后，系统应用处于活跃状态)来对系统应用所使用的资源进行管控。

二，冻结系统应用

本申请实施例中，冻结系统应用可以包括限制系统应用使用资源或者说挂起系统应用所使用的资源，处于冻结状态的系统应用并没有被关闭，但限制了其对资源的使用。

示例性地，限制系统应用使用资源，可以包括限制系统应用使用全部资源或者限制系统应用使用部分资源。比如，系统应用正在使用的资源包括CPU资源、存储器资源、网络资源和操作系统的资源，限制系统应用使用全部资源可以为限制系统应用使用CPU资源、存储器资源、网络资源和操作系统的资源，或者也可以描述为挂起系统应用使用的CPU资源、存储器资源、网络资源和操作系统的资源；限制系统应用使用部分资源可以为限制系统应用使用CPU资源、存储器资源和操作系统的资源，但不限制系统应用使用网络资源，或者也可以描述为挂起系统应用使用的CPU资源、存储器资源和操作系统的资源，但保持系统应用使用的网络资源。

本申请实施例中，应用管控模块若确定冻结系统应用，则可以根据系统应用是否需要执行预设业务，来确定限制系统应用使用全部或部分资源。比如，应用管控模块若确定系统应用需要执行预设业务(假设系统应用执行预设业务需要使用的资源为网络资源和Alarm资源)，则可以挂起系统应用使用的网络资源和Alarm资源以外的资源，而保持系统应用使用的网络资源和Alarm资源；应用管控模块若确定系统该应用不需要执行预设业务，则可以挂起系统应用使用的全部资源。其中，预设任务可以由本领域技术人员根据实际需要来设置，比如预设任务可以为接收消息。应用管控模块可以在多种可能的情形下(比如进入统一休眠期)确定冻结系统应用，参见后文中的描述。

下面以系统应用1为例，描述挂起系统应用1使用的Alarm资源、Wakelock资源、广播资源、网络资源的可能的实现方式。

(1)Alarm资源

通常情况下，应用需要与该应用对应的应用服务器保持连接状态，以便该应用服务器可以向该应用执行数据的发送。各个应用与对应的应用服务器在进行连接之后才能进行数据的交互，或者各个应用与对应的应用服务器在进行连接之后才能进行应用之间数据的交互。应用服务器可以根据应用的状态(在线、离线)来决定是否需要向应用发送数据，所以应用可以使用Alarm资源定时向应用服务器发送心跳消息，来表示自己为在线状态，该心跳消息用于说明应用的状态为在线状态。

应用管控模块若确定挂起系统应用1使用的Alarm资源，由于Alarm资源为按照包名管控的资源，则应用管控模块可以判断系统应用1的包名是否为共享包名，若是，则指示资源管控模块按照系统应用1的PID(或者包名和PID)挂起系统应用1使用的Alarm资源，若否，则指示资源管控模块按照系统应用1的包名挂起系统应用1使用的Alarm资源。相应地，资源管控模块可以通知Alarm代理按照系统应用1的包名和/或PID将系统应用1使用的Alarm资源代理起来。如此，Alarm代理可以按照系统应用1的包名和/或PID遍历所有正在被使用的Alarm资源，找到系统应用1的包名和/或PID对应的Alarm资源，并将Alarm的定时时间往后延迟预设时长(比如1年)，从而达到暂停Alarm的效果，使得系统应用1的心跳暂停。示例性地，Alarm代理可以为alarmmanagerservice。

需要说明的是，上述描述中，挂起系统应用1使用的Alarm资源是指暂停系统应用1的心跳；在其它可能的实施例中，挂起系统应用1使用的Alarm资源也可以是指对系统应用1的心跳进行统一，比如可以设置一个统一心跳的周期，从而使得系统应用1按照该统一心跳的周期进行心跳。示例性地，可以按照系统应用1的包名和/或PID对系统应用1的心跳进行统一。其中，统一心跳和暂停心跳的差异之处在于：暂停心跳时，是将Alarm的定时时间往后延迟预设时长(比如1年)，从而达到暂停心跳的效果；而统一心跳，则可以将Alarm的定时时间往后延迟第八时长(第八时长可以是基于Alarm的定时时间和统一心跳的周期得到的，比如，Alarm的定时时间为1分钟，统一心跳的周期为2分钟，则第八时长可以为1分钟)，从而到达统一心跳的效果。

(2)广播资源

系统应用1可以通过广播资源接收手机中的其它应用发送的广播。本申请实施例中，广播的发送方发送广播消息，可以有多个接收方。接收方可以指定接收哪些广播。发送方也可以指定发送给哪些接收方。接收方接收广播后可以在后台活动或者更新自己的状态。如果已经指定哪些发送方或者接收方时，广播代理在接收到发送方的广播后，无需一一查询哪个接收方需要接收这种广播，而是直接发送到指定的接收方中去。当然，如果发送方没有指定哪些接收方接收广播，或者接收方没有指定哪些发送方发送广播时，广播就会通过发送方发送到手机的广播代理中，由广播代理分发广播到相应的接收方中(在收发广播之前，接收方已经提前注册好需要接收哪种广播，当广播代理收到这些广播时，自动将这些广播分发到对应的应用中)。

应用管控模块若确定挂起系统应用1使用的广播资源，由于广播资源为按照包名管控的资源，则应用管控模块可以判断系统应用1的包名是否为共享包名，若是，则指示资源管控模块按照系统应用1的PID(或者包名和PID)挂起系统应用1使用的广播资源，若否，则指示资源管控模块按照系统应用1的包名挂起系统应用1使用的广播资源。相应地，资源管控模块可以通知广播代理按照系统应用1的包名和/或PID将系统应用1要接收的广播代理起来。如此，当广播代理接收到要发送给系统应用1或系统应用1的进程的广播后，可以将该广播先缓存起来。

需要说明的是，广播代理按照系统应用1的包名和/或PID将系统应用1要接收的广播代理起来时，可以是将系统应用1要接收的所有广播代理起来，或者也可以是将系统应用1要接收的部分广播代理起来，比如，将预设类型的广播代理起来，而非预设类型的广播可以不代理。其中，预设类型可以由本领域技术人员根据实际需要来设置，比如预设类型的广播可以包括提醒电量的广播。

(3)Wakelock资源

Wakelock是一种锁的机制，只要有应用占用该锁，CPU则无法进入休眠状态。比如，手机屏幕在屏幕关闭的时候，有些应用依然可以唤醒屏幕提示用户消息，即是用到了Wakelock锁机制。

应用管控模块若确定挂起系统应用1使用的Wakelock资源，由于Wakelock资源为按照UID管控的资源，则应用管控模块可以判断系统应用1的UID是否为共享包名，若是，则指示资源管控模块按照系统应用1的PID(或者UID和PID)挂起系统应用1使用的Wakelock资源，若否，则指示资源管控模块按照系统应用1的UID挂起系统应用1使用的Wakelock资源。相应地，资源管控模块可以通知Wakelock代理按照UID和/或PID将系统应用1使用的Wakelock资源代理起来。如此，Wakelock代理可以按照系统应用1的UID和/或PID遍历所有正在被使用的Wakelock资源，找到系统应用1的UID和/或PID对应的Wakelock资源，并存入缓存中。示例性地，Wakelock代理可以为powermanagerservice。

(4)网络资源

应用管控模块若确定挂起系统应用1使用的网络资源，由于网络资源为按照UID管控的资源，则应用管控模块可以判断系统应用1的UID是否为共享UID，若是，则指示资源管控模块按照系统应用1的PID(或者UID和PID)挂起系统应用1的网络资源，若否，则指示资源管控模块按照系统应用1的UID挂起系统应用1使用的网络资源。相应地，资源管控模块按照UID和/或PID挂起系统应用1使用的网络资源。

三，对系统应用解除冻结

本申请实施例中，对系统应用解除冻结可以包括解除对系统应用使用资源的限制或者说恢复系统应用所使用的资源，处于活跃状态的系统应用可以无限制地使用资源。

示例性地，应用管控模块可以在多种可能的情形下确定对系统应用解除冻结，比如在进入统一活跃期或者有其它应用调用系统应用时，可以确定对系统应用解除冻结，参见后文中的描述。

下面仍以系统应用1为例，描述恢复系统应用1使用的Alarm资源、Wakelock资源、广播资源、网络资源的可能的实现方式。

(1)Alarm资源

应用管控模块若确定恢复系统应用1使用的Alarm资源，由于Alarm资源为按照包名管控的资源，则应用管控模块可以判断系统应用1的包名是否为共享包名，若是，则指示资源管控模块按照系统应用1的PID(或者包名和PID)恢复系统应用1使用的Alarm资源，若否，则指示资源管控模块按照系统应用1的包名挂起系统应用1使用的Alarm资源。相应地，资源管控模块可以通知Alarm代理按照系统应用1的包名和/或PID恢复系统应用1使用的Alarm资源。如此，Alarm代理可以按照系统应用1的包名和/或PID遍历所有已被延迟的Alarm，找到系统应用1的包名和/或PID对应的Alarm，恢复给系统应用1使用。

(2)广播资源

应用管控模块若确定恢复系统应用1使用的广播资源，由于广播资源为按照包名管控的资源，则应用管控模块可以判断系统应用1的包名是否为共享包名，若是，则指示资源管控模块按照系统应用1的PID(或者包名和PID)恢复系统应用1使用的广播资源，若否，则指示资源管控模块按照系统应用1的包名恢复系统应用1使用的广播资源。相应地，资源管控模块可以通知广播代理按照系统应用1的包名和/或PID恢复系统应用1使用的广播资源。如此，广播代理可以遍历缓存中已经被代理的广播，找到系统应用1的包名和/或PID对应的广播，并将广播发送给系统应用1。

(3)Wakelock资源

应用管控模块若确定恢复系统应用1使用的Wakelock资源，由于Wakelock资源为按照UID管控的资源，则应用管控模块可以判断系统应用1的UID是否为共享包名，若是，则指示资源管控模块按照系统应用1的PID(或者UID和PID)恢复系统应用1使用的Wakelock资源，若否，则指示资源管控模块按照系统应用1的UID挂起系统应用1使用的Wakelock资源。相应地，资源管控模块可以通知Wakelock代理按照UID和/或PID恢复系统应用1使用的Wakelock资源。如此，Wakelock代理可以按照系统应用1的UID和/或PID遍历缓存中已被代理的Wakelock资源，找到系统应用1的UID和/或PID对应的Wakelock资源，恢复给系统应用1使用。

(4)网络资源

应用管控模块若确定恢复系统应用1使用的网络资源，由于网络资源为按照UID管控的资源，则应用管控模块可以判断系统应用1的UID是否为共享UID，若是，则指示资源管控模块按照系统应用1的PID(或者UID和PID)恢复系统应用1使用的网络资源，若否，则指示资源管控模块按照系统应用1的UID恢复系统应用1使用的网络资源。相应地，资源管控模块按照UID和/或PID恢复系统应用1使用的网络资源。

四，统一休眠期和统一活跃期

在一种可能的实现方式中，统一休眠期的时长和统一活跃期的时长可以是默认的，比如可以为手机出厂前即已设置好的。

在又一种可能的实现方式中，统一休眠期的时长和统一活跃期的时长可以是用户设置的。比如，可以预先在设置应用中增添设置统一休眠期的时长和统一活跃期的时长的选项；如此，当用户需要设置统一休眠期的时长和统一活跃期的时长时，可以打开设置应用，进而基于相应的选项来进行设置。

在又一种可能的实现方式中，统一休眠期和/或统一活跃期可以是根据一个或多个系统应用的业务需求确定的，其中，系统应用的业务需求可以理解为系统应用需要周期性执行的业务，比如，前文中所描述的系统应用1需要周期性执行定位业务。

示例性地，系统应用可以根据自身的业务需求确定休眠期和活跃期，其中，系统应用的休眠期可以理解为系统应用执行业务的周期，即系统应用的活动周期；系统应用的活跃期可以理解为系统应用执行一次业务所需的时长，即系统应用的活动时长；进而，系统应用可以将休眠期和活跃期上报给注册回调模块(若系统应用不需要执行周期性业务，或者说系统应用不具有休眠期和活跃期，则可以不向注册回调模块上报)，由注册回调模块发送给应用管控模块；相应地，应用管控模块可以根据一个或多个系统应用的休眠期和活跃期确定统一休眠期和统一活跃期。其中，系统应用可以在启动后便将休眠期和活跃期上报给注册回调模块，或者也可以在启动一段时间后将休眠期和活跃期上报给注册回调模块，本申请实施例对系统应用上报休眠期和活跃期的时间不做限定。

在该实现方式的一个示例中，应用管控模块根据一个或多个系统应用的休眠期，确定每个系统应用的休眠期中的最短休眠期是否小于第二时长，若否，则将最短休眠期确定为统一休眠期，若是，则将第二时长确定为统一休眠期。其中，第二时长可以由本领域技术人员根据实际需要和经验来设置，比如第二时长为5分钟。举个例子，一个或多个系统应用可以包括系统应用1、系统应用2和系统应用3，其中，系统应用1的休眠期可以为系统应用1的活动周期，即为5分钟，系统应用2的休眠期可以为系统应用2的活动周期，即为6分钟，系统应用3的休眠期可以为系统应用3的活动周期，即为9分钟。系统应用1、系统应用2和系统应用3的最短休眠期为5分钟，且最短休眠期等于第二时长，因此，可以将最短休眠期(即5分钟)确定为统一休眠期。

在该实现方式的又一个示例中，应用管控模块根据一个或多个系统应用的活跃期，确定每个系统应用的休眠期中的最长活跃期是否大于或等于第三时长，若否，则将最长活跃期确定为统一活跃期，若是，则将第三时长确定为统一活跃期。其中，第三时长可以由本领域技术人员根据实际需要和经验来设置，比如第三时长为1分钟。举个例子，一个或多个系统应用可以包括系统应用1、系统应用2和系统应用3，其中，系统应用1的活跃期可以为系统应用1的活动时长，即为30秒，系统应用2的活跃期可以为系统应用2的活动时长，即为36秒，系统应用3的活跃期可以为系统应用3的活动时长，即为30秒。系统应用1、系统应用2和系统应用3的最长活跃期为36秒，且最长活跃期小于第三时长(1分钟)，因此，可以将最长活跃期确定为统一活跃期。

在该种实现方式中，可以在符合一定的条件时，对统一休眠期和统一活跃期进行更新。比如，当有新的系统应用(比如系统应用4)上报休眠期和活跃期后，则可以根据系统应用1、系统应用2、系统应用3和系统应用4的休眠期和活跃期对统一休眠期和统一活跃期进行更新。

基于上述对相关技术特征的介绍，下面结合一些可能的场景(比如场景1和场景2)，对本申请实施例提供的系统应用的管理方法进行描述。

场景1

图5a为本申请实施例场景1提供的一种系统应用的管理方法所对应的流程示意图，图5b为本申请实施例场景1提供的又一种系统应用的管理方法所对应的流程示意图。下面结合图5a和图5b进行描述。

如图5a和图5b所示，该方法包括：

步骤501，激活系统应用的管理功能。

示例性地，激活系统应用的管理功能的方式可以有多种。在一种可能的实现方式中，可以通过用户的触发来激活系统应用的功能。比如，可以预先在设置应用中增添激活或去激活系统应用的管理功能的按钮；如此，当用户需要激活系统应用的管理功能时，可以打开设置应用，通过触发按钮来激活系统应用的管理功能，当用户需要去激活系统应用的管理功能时，可以打开设置应用，通过触发按钮来去激活系统应用的管理功能。在又一种可能的实现方式中，系统应用的管理功能可以默认处于激活状态，比如电子设备开机时，系统应用的管理功能即激活，电子设备关机时，系统应用的管理功能即去激活。

步骤502，若电子设备进入第一模式，则启动计时器1。

此处，第一模式可以包括灭屏模式或休眠模式。

以Android操作系统为例，Android操作系统可以预先定义一个计时器(比如计时器1)，当检测到电子设备处于第一模式时，系统查找预先定义的计时器1，并通过调用timer.setbase(systemclock.elapsedrealtime())这一函数将计时器1清零，然后通过调用timer.start()这一函数启动计时器1，开始计时。

步骤503，若计时器1的时长大于或等于第一时长，则进入维护期。其中，维护期内可以包括至少一个统一休眠期，还可以包括至少一个统一活跃期；当维护期内包括多个统一休眠期和多个统一活跃期时，统一休眠期和统一活跃期可以循环出现。

示例性地，第一时长可以由本领域技术人员根据实际需要和经验进行设置，比如第一时长可以为30秒。

需要说明的是，进入维护期后，可以先出现统一休眠期再出现统一活跃期，或者也可以先出现统一活跃期再出现统一休眠期，具体不做限定。下文中仅是以先出现统一休眠期再出现统一活跃期为例进行描述的。

步骤504，在统一休眠期(该统一休眠期可以为维护期内出现的至少一个统一休眠期中的任一个统一休眠期，为便于描述，称为统一休眠期1)内，对处于后台运行状态的至少一个系统应用进行冻结；在统一活跃期(该统一活跃期可以为统一休眠期1之后第一次出现的统一活跃期，为便于描述，称为统一活跃期1)内，对至少一个系统应用解除冻结。

示例性地，判断系统应用是否处于后台运行状态的实现方式可以有多种。在一种可能的实现方式中，当系统应用(以系统应用1为例)被打开后，Android操作系统会调用onResume等方法来使系统应用1的activity处于运行状态。其中，activity是一个应用程序组件。若系统应用1具有可视的显示界面，则在系统应用1的activity启动后，activity包括：运行Resumed状态、暂停Paused状态以及停止Stopped状态；进而，如果系统应用1的activity处于Resumed状态，则表示系统应用1处于前台运行状态，而如果系统应用1的activity处于Paused状态，则表示系统应用1处于后台运行状态。若系统应用1不具有可视的显示界面，则在系统应用1的activity启动后，activity包括：Resumed状态、Stopped状态；进而，如果系统应用1的activity处于Resumed状态，则表示系统应用1处于后台运行状态。如此，可以根据系统应用的activity所处的状态，来判断系统应用是否处于后台运行状态。

示例性地，上述至少一个系统应用均为未处于冻结状态的系统应用，比如可以对系统应用的状态进行标记，进而通过读取系统应用的状态标识可以获知系统应用是否处于冻结状态。

示例性地，在统一休眠期1内，对至少一个系统应用进行冻结，包括：在统一休眠期1内，判断至少一个系统应用中的每个系统应用是否符合第一预设条件，若符合，则对至少一个系统应用中的每个系统应用进行冻结。其中，至少一个系统应用包括系统应用1，以系统应用1为例，系统应用1符合第一预设条件可以理解为系统应用1不具有可感知业务，且系统应用1未注册保活。也就是说，在统一休眠期1内，检测到系统应用1不具有可感知业务，且未注册保活，则可以对系统应用1进行冻结。若检测到系统应用1具有可感知业务或者系统应用1注册了保活(比如注册了保活1分钟)，则暂时不对系统应用1进行冻结；此种情形下，可以按照设定周期(比如30s)检测系统应用1的可感知业务是否结束或者是否到达保活时长，从而在检测到系统应用1的可感知业务结束或者到达保活时长后，对系统应用1进行冻结。其中，对系统应用进行冻结的具体实现可以参见上文中有关冻结系统应用的相关描述，此处不再赘述。

其中，可感知业务可以理解为可以被用户听到、看到等可被用户感知到的业务，例如播放音乐、下载文件等，但不限于此。若系统应用1具有可感知业务，则虽然系统应用1已进入到后台运行，但依然可被用户感知到系统应用1正在执行业务，此种情形下，可以不对系统应用1进行冻结。

由于系统应用可能需要执行紧急业务(或者说不可推迟的业务)，此种情形，若进入统一休眠期时，系统应用的紧急业务尚未执行完，此时，对系统应用进行冻结可能导致该紧急业务无法被正常执行。基于此，本申请实施例提供一种注册保活机制，从而保证紧急业务的正常执行。比如系统应用1确定有紧急业务需要处理，则可以根据紧急业务需要处理的时长，来注册保活时长，在系统应用1的保活时长内，可以不对系统应用1进行冻结。

示例性地，系统应用注册保活时，可以是注册保活系统应用所使用的全部资源，或者也可以是注册保活系统应用所使用的一种或多种资源，比如注册保活广播资源。此种情形下，上文的描述中，若在统一休眠期1内，系统应用注册了保活，则在系统应用的保活时长内，不对系统应用进行冻结，可以是指，若在统一休眠期1内，系统应用注册了保活全部资源，则在系统应用的保活时长内，不对系统应用进行冻结。若在统一休眠期1内，系统应用注册保活广播资源，则在系统应用的保活时长内，可以对系统应用进行冻结，但此时仅限制系统应用1所使用的除广播资源以外的其它资源，而不限制系统应用使用广播资源。本申请实施例中，若无特殊说明，则系统应用注册保活可以理解为系统应用注册保活全部资源。

本申请实施例中，在统一休眠期1内，还可以对系统应用解除冻结，比如在一个示例中，从系统应用的角度来看，在统一休眠期内，若确定某一系统应用需要解除冻结，则可以对该系统应用解除冻结。其中，确定某一系统应用需要解除冻结的情形可以有多种，比如若系统应用1处于冻结状态，且限制系统应用1使用全部资源，则当有其它应用调用系统应用1时，可以确定对系统应用1解除冻结；又比如，若系统应用1处于冻结状态，限制系统应用1使用部分资源而未限制系统应用1使用广播资源(或者仅限制部分广播资源)，则当有其它应用调用系统应用1或者系统应用1需要接收广播时，可以确定对系统应用1解除冻结。具体可以由本领域技术人员根据实际需要设置需要解除冻结的各种可能的情形，本申请实施例对此不做限定。

进一步地，在统一休眠期内对系统应用1解除冻结后，系统应用1处于活跃状态，若系统应用1处于活跃状态的时长大于或等于第六时长时，仍处于统一休眠期内，则可以再次对系统应用1进行冻结。其中，第六时长可以由本领域技术人员根据实际需要和经验来设置，具体不做限定，比如第六时长可以为6秒。

本申请实施例中，若电子设备进入第二模式，则可以退出维护期，其中，第二模式可以包括亮屏模式。示例性地，退出维护期时，可以对处于冻结状态的系统应用解除冻结。

可以理解地，维护期的时长与电子设备处于第一模式的时长相关，比如，电子设备处于第一模式的时长较长，则维护期的时长较长；电子设备处于第一模式的时长较短，则维护期的时长也较短。上述方案主要是基于维护期包括至少一个休眠期和至少一个活跃期的情形进行描述的，在其它可能的实施例中，也有可能出现维护期的时间较短的情形，比如维护期的时长可能小于或等于统一休眠期的时长，此种情形下，也可以按照上述方案来执行。

此外，本申请实施例还可以对系统应用使用资源的情况进行统计，若确定某一系统应用在预设时间段内所使用的资源量大于或等于预设阈值，则可以向该系统应用发出资源使用超标的提示，从而便于该系统应用进行自检和修复。其中，预设时间段可以由本领域技术人员根据实际需要和经验来设置，具体不做限定。

举个例子，预设时间段的时长可以小于或等于统一活跃期的时长，比如可以在统一活跃期内，统计系统应用在预设时间段内使用资源的情况，若使用的资源量大于或等于预设阈值，则可以向该系统应用发出提示。其中，使用的资源量可以从多个角度来衡量，比如，以Wakelock资源为例，可以从使用Wakelock资源的时长的角度来衡量其使用的资源量，若使用Wakelock资源的时长(比如可以根据资源管控模块所记录的使用Wakelock资源的开始时间和当前时间来确定使用Wakelock资源的时长)大于或等于第七时长(可以为预先设置的一个时长)，则可以理解为使用的资源量大于或等于预设阈值。在其它可能的实施例中，也可以从其它可能的角度来衡量，具体不做限定。

需要说明的是，若统一休眠期和统一活跃期是基于至少一个系统应用注册的休眠期和活跃期确定的，则针对于未向注册回调模块注册休眠期和活跃期的系统应用，为便于描述，以该系统应用为系统应用5为例，系统应用5处于后台运行状态，由于系统应用5未注册休眠期和活跃期，说明系统应用可能不需要执行周期性业务，因此，可以不对系统应用5进行管控，或者，也可以按照对至少一个系统应用的管控方式对系统应用5进行管控，即若在统一休眠期内，则对系统应用5进行冻结；若在统一活跃期内，则对系统应用5解除冻结。也就是说，若统一休眠期和统一活跃期是基于系统应用1、系统应用2和系统应用3上报的休眠期和活跃期确定的，则可以基于统一休眠期和统一活跃期仅对系统应用1、系统应用2和系统应用3进行管控，或者，也可以基于统一休眠期和统一活跃期对系统应用1、系统应用2和系统应用3以及其它处于后台运行状态的系统应用进行管控。

下面结合图3b描述采用本申请实施例提供的系统应用的管理方法后，相比于现有技术(图3a)的区别。如图3b所示，假设上述图5a中所描述的至少一个系统应用包括系统应用1、系统应用2和系统应用3，可以看出，在t0至t1这段时间内，系统应用1、系统应用2、系统应用3共活动7次，但Android操作系统仅被唤醒3次，从而能够有效减少电量消耗。

场景2

图6a为本申请实施例场景2提供的一种系统应用的管理方法所对应的流程示意图，图6b为本申请实施例场景2提供的又一种系统应用的管理方法所对应的流程示意图。下面结合图6a和图6b进行描述。

如图6a和图6b所示，该方法包括：

步骤601，激活系统应用的管理功能。

此处，步骤601的具体实现可以参照上述步骤501的相关描述。

步骤602，启动计时器2。

以Android操作系统为例，Android操作系统可以预先定义一个计时器(称为计时器2)，当激活系统应用的管理功能后，系统查找预先定义的计时器2，并通过调用timer.setbase(systemclock.elapsedrealtime())这一函数将计时器2清零，然后通过调用timer.start()这一函数启动计时器2，开始计时。

步骤603，若计时器2的时长大于或等于第四时长，则进入维护期。

示例性地，第四时长可以由本领域技术人员根据实际需要和经验进行设置，比如第一时长可以为30秒。

步骤604，确定某一系统应用(为便于描述，以系统应用1为例)在操作系统中的运行状态为后台运行状态，则启动系统应用1对应的计时器(称为计时器3)。

步骤605，计时器3的时长大于或等于第五时长时，若处于统一休眠期(比如统一休眠期2)内，则在统一休眠期2内对系统应用1进行冻结；在统一休眠期2之后第一次出现的统一活跃期2内，对系统应用1解除冻结。可以理解地，在系统应用1处于后台运行状态的时间段内，在统一活跃期2之后出现的统一休眠期3内，可以再次对系统应用1进行冻结，在统一休眠期3之后第一次出现的统一活跃期3内，对系统应用1解除冻结，依次类推。

示例性地，第五时长可以由本领域技术人员根据实际需要和经验进行设置，比如第五时长可以为30秒。

示例性地，当计时器3的时长大于或等于第五时长时，若处于统一休眠期，且电子设备处于第二模式(比如亮屏模式)，则判断系统应用1是否符合第二预设条件，若符合，则对系统应用1进行冻结。当计时器3的时长大于或等于第五时长时，若处于统一休眠期，且电子设备处于第一模式(比如灭屏模式)，则判断系统应用1是否符合第一预设条件，若符合，则对系统应用1进行冻结。当计时器3的时长大于或等于第五时长时，若处于统一活跃期，则不对系统应用1进行冻结。其中，系统应用1符合第二预设条件可以理解为系统应用1不具有可感知业务、系统应用1未注册保活且系统应用1不是前台运行的应用所依赖的系统应用。系统应用1符合第一预设条件可以参见上述场景1中的相关描述。

本申请实施例中，系统应用1是前台应用所依赖的应用程序是指前台应用需要利用系统应用1的数据才能执行。当前台应用的进程与系统应用1的进程之间有通信机制时，则系统应用1是前台应用所依赖的应用。其中，前台应用的进程与系统应用1的进程之间有通信机制包括：(1)系统应用1的进程与前台应用的进程之间有socket和binder通信中至少一种。(2)系统应用1的进程与前台应用的进程之间有内存共享。(3)前台应用的进程等待在锁资源上的系统应用1的进程，比如，当检测到发生锁资源等待时，可检测发生锁资源等待是否为前台应用程序的进程，若是，则遍历获取等待在该锁资源上的所有后台进程，上述等待在该锁资源上的所有后台进程均为前台应用程序的进程所依赖的后台进程。

本申请实施例中，在统一休眠期(可以是指统一休眠期2或者统一休眠期2之后的某个统一休眠期内)内，若确定系统应用1需要解除冻结，则可以对系统应用1解除冻结。其中，确定系统应用1需要解除冻结的情形可以有多种，比如若系统应用1处于冻结状态，且限制系统应用1使用全部资源，则当有其它应用调用系统应用1时，可以确定对系统应用1解除冻结；又比如，若系统应用1处于冻结状态，限制系统应用1使用部分资源而未限制系统应用1使用广播资源(或者仅限制部分广播资源)，则当有其它应用调用系统应用1或者系统应用1需要接收广播时，可以确定对系统应用1解除冻结；又比如，系统应用1由后台运行状态切换为前台运行状态，可以确定对系统应用1解除冻结。具体可以由本领域技术人员根据实际需要设置需要解除冻结的各种可能的情形，本申请实施例对此不做限定。

示例性地，若去激活系统应用的管理功能，则可以退出维护期。退出维护期时，可以对处于冻结状态的系统应用解除冻结。

此外，本申请实施例还可以对系统应用1使用资源的情况进行统计，若确定系统应用1在预设时间段内所使用的资源量大于或等于预设阈值，则可以向该系统应用1发出提示，从而便于该系统应用1进行自检和修复。

需要说明的是：场景1和场景2的差异之处在于：场景1中是在电子设备处于第一模式时，基于统一休眠期和统一活跃期对处于后台运行状态的系统应用所使用的资源进行管控；而场景2中不论电子设备处于第一模式或第二模式，均可以基于统一休眠期和统一活跃期对处于后台运行状态的系统应用所使用的资源进行管控。除此差异之外的其它内容，二者可以相互参照。

根据上述描述可知，本申请实施例中，通过在统一休眠期限制后台运行的系统应用使用资源，以及在统一活跃期解除对后台运行的系统应用使用资源的限制，从而便于在后台运行的系统应用统一活动，避免频繁唤醒操作系统而导致电子设备的电量消耗较为严重。进一步地，考虑到系统应用的包名可能为共享包名，UID可能为共享UID，因此可以在记录资源宿主时，除记录系统应用的包名和UID之外，还可以进一步记录系统应用的进程的PID，从而能够基于PID对系统应用所使用的资源进行限制或解除限制，实现对系统应用所使用的资源进行有效管控。

下面结合附图介绍本申请实施例提供的装置，以实现本申请上述方法实施例。

如图7所示，本申请另外一些实施例公开了一种电子设备，该电子设备可以包括：一个或多个处理器702，存储器703，一个或多个计算机程序704；上述各器件可以通过一个或多个通信总线705连接。其中，所述一个或多个计算机程序704被存储在上述存储器703中并被配置为被该一个或多个处理器702执行，该一个或多个计算机程序704包括指令，上述指令可以用于执行前述的图4a～图6b所示的实施例中记载的全部或部分步骤。

其中，处理器702可以是中央处理器(central processing unit，CPU)，或特定应用集成电路(application-specific integrated circuit，ASIC)，可以是一个或多个用于控制程序执行的集成电路，可以是基带芯片，等等。存储器703的数量可以是一个或多个，存储器703可以是只读存储器(read-only memory，ROM)、随机存取存储器(random accessmemory，RAM)或磁盘存储器，等等。

图7所示的电子设备可以是手机、ipad、笔记本电脑、智能电视、穿戴式设备(例如智能手表、智能头盔或智能手环等)等。当图7所示的电子设备是手机时，其结构可以参见图1c所示，比如，存储器703是内部存储器121。

上述本申请提供的实施例中，从终端设备(手机100)作为执行主体的角度对本申请实施例提供的方法进行了介绍。为了实现上述本申请实施例提供的方法中的各功能，终端设备可以包括硬件结构和/或软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能以硬件结构、软件模块、还是硬件结构加软件模块的方式来执行，取决于技术方案的特定应用和设计约束条件。

上述实施例中所用，根据上下文，术语“当…时”可以被解释为意思是“如果…”或“在…后”或“响应于确定…”或“响应于检测到…”。类似地，根据上下文，短语“在确定…时”或“如果检测到(所陈述的条件或事件)”可以被解释为意思是“如果确定…”或“响应于确定…”或“在检测到(所陈述的条件或事件)时”或“响应于检测到(所陈述的条件或事件)”。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘)等。

为了解释的目的，前面的描述是通过参考具体实施例来进行描述的。然而，上面的示例性的讨论并非意图是详尽的，也并非意图要将本申请限制到所公开的精确形式。根据以上教导内容，很多修改形式和变型形式都是可能的。选择和描述实施例是为了充分阐明本申请的原理及其实际应用，以由此使得本领域的其他技术人员能够充分利用具有适合于所构想的特定用途的各种修改的本申请以及各种实施例。

Claims (9)

1.一种系统应用的管理方法，其特征在于，所述方法包括：

进入维护期，所述维护期包括统一休眠期和统一活跃期；

在所述统一休眠期内，对处于后台运行状态的系统应用进行冻结；

在所述统一休眠期之后出现的所述统一活跃期内，对所述系统应用解除冻结；

其中，对处于后台运行状态的系统应用进行冻结，包括：

若所述系统应用的用户标识符UID为共享UID，则根据所述系统应用的第一进程的进程名或进程标识符PID挂起所述系统应用所使用的第一资源；和/或，

若所述系统应用的包名为共享包名，则根据所述系统应用的第二进程的进程名或PID挂起所述系统应用所使用的第二资源。

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

在所述系统应用使用所述第一资源时，记录所述第一资源的资源宿主，所述第一资源的资源宿主包括所述系统应用的用户标识符UID和所述第一进程的进程名或进程标识符PID；和/或，在所述系统应用使用所述第二资源时，记录所述第二资源的资源宿主，所述第二资源的资源宿主包括所述系统应用的包名和所述第二进程的进程名或PID。

3.根据权利要求1所述的方法，其特征在于，进入所述维护期，包括：

激活系统应用的管理功能后，若确定进入第一模式，则启动第一计时器；所述第一模式包括灭屏模式或休眠模式；

若所述第一计时器的时长大于或等于第一时长，则进入所述维护期。

4.根据权利要求1所述的方法，其特征在于，进入所述维护期，包括：

若激活系统应用的管理功能，则启动第二计时器；

若所述第二计时器的时长大于或等于第四时长，则进入所述维护期。

5.根据权利要求4所述的方法，其特征在于，在所述统一休眠期内，对处于后台运行状态的系统应用进行冻结，包括：

检测到所述系统应用进入后台运行状态，启动所述系统应用对应的第三计时器；

若所述第三计时器的时长大于或等于第五时长时处于所述统一休眠期内，则对所述系统应用进行冻结。

6.根据权利要求1至5中任一项所述的方法，其特征在于，对所述系统应用进行冻结之前，还包括：

确定所述系统应用不具有可感知业务，且所述系统应用未注册保活。

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

根据所述系统应用的休眠期，确定所述统一休眠期；其中，所述系统应用的休眠期等于所述系统应用的活动周期；

根据所述系统应用的活跃期，确定所述统一活跃期；其中，所述系统应用的活跃期等于所述系统应用的活动时长。

8.一种电子设备，其特征在于，包括：显示屏；一个或多个处理器；存储器；一个或多个程序；其中所述一个或多个程序被存储在所述存储器中，所述一个或多个程序包括指令，当所述指令被所述处理器执行时，使得所述电子设备执行如权利要求1-7中任一所述的方法步骤。

9.一种计算机可读存储介质，其特征在于，存储计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-7中任一项所述的方法。

Images