CN117349006A - Cpu资源管理方法及相关装置 - Google Patents

Cpu资源管理方法及相关装置 Download PDF

Info

Publication number
CN117349006A
CN117349006A CN202311194767.8A CN202311194767A CN117349006A CN 117349006 A CN117349006 A CN 117349006A CN 202311194767 A CN202311194767 A CN 202311194767A CN 117349006 A CN117349006 A CN 117349006A
Authority
CN
China
Prior art keywords
value
application
cpu
electronic equipment
cpu resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311194767.8A
Other languages
English (en)
Inventor
何佳乐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202311194767.8A priority Critical patent/CN117349006A/zh
Publication of CN117349006A publication Critical patent/CN117349006A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

本申请实施例提供的CPU资源管理方法及相关装置，涉及终端技术领域。方法包括：响应于用户的触发操作，电子设备可以识别用户触发的应用场景，并为该应用场景提前预留出所需要的CPU资源，这样可以使得用户触发的场景所需要的CPU资源较为充足，从而减少电子设备的卡顿。

Description

CPU资源管理方法及相关装置
技术领域
本申请涉及终端技术领域，尤其涉及CPU资源管理方法及相关装置。
背景技术
电子设备中可以支持安装多种类型的应用，例如游戏应用、短视频应用等，用户可以使用应用玩游戏、看短视频，或者浏览网页等。
然而，用户在使用应用时，可能会出现应用卡顿的情况。
发明内容
本申请实施例提供的CPU资源管理方法及相关装置，响应于用户的触发操作，电子设备可以识别用户触发的应用场景，并为该应用场景提前预留出所需要的CPU资源，这样可以使得用户触发的场景所需要的CPU资源较为充足，从而减少电子设备的卡顿。
第一方面，本申请实施例提供的CPU资源管理方法，方法包括：
电子设备显示第一应用的界面；响应于用户从第一应用的界面进入第二应用的界面的操作，电子设备查询第一预设文件，得到第一值和第二值，其中，第一值为电子设备显示第二应用的界面需要的CPU资源利用率，第二值为第一应用退到后台时的CPU资源回收率；电子设备基于第一值和第二值得到第三值，第三值为电子设备从第一应用的界面进入第二应用的界面时需要的CPU资源利用率；若第三值大于CPU资源空闲率，电子设备提升CPU资源空闲率。这样，可以使得电子设备所需要的CPU资源较为充足，从而减少电子设备的卡顿。
一种可能的实现中，电子设备的CPU包括n个内核，n为大于或等于1的整数，第一值与下述值成正比：电子设备显示第二应用的界面时占用n个内核的时间，以及n个内核的权重；第二值与第一应用的界面在前台显示时占用n个内核的时间成正比，与第一应用在后台运行时占用n个内核的时间成反比。这样，CPU状态预留机制可以针对各个应用的不同场景分别计算对应的预留资源占比和回落资源占比，进而可以得到应用运行时需要的CPU资源占比。
一种可能的实现中，第一值满足下述公式：
其中，sourcerate为第一值，m为预设时间段，n为CPU的内核个数，coreNi,j,time为电子设备显示第二应用的界面时占用第j个内核的时间，coreNi,j,weight为第j个内核的权重；第二值满足下述公式：
其中，subsiderate为第二值，coreNi,j,fg为第一应用的界面在前台显示时占用第j个内核的时间，coreNi,j,bg为第一应用在后台运行时占用第j个内核的时间。这样，可以提前预留出CPU资源，从而减少CPU高负载的情况。
一种可能的实现中，第三值为第一值和第二值的差值。这样，在计算第三值时，同时考虑预留资源占比和回落资源占比，可以更为准确、合理的计算出实际需要的CPU资源占比，从而可以执行相应的CPU查杀。
一种可能的实现中，电子设备提升CPU资源空闲率，包括：电子设备基于第三值和CPU资源空闲率的差值得到第四值，电子设备在第二预设文件中查询第四值所对应的提升CPU资源空闲率的策略；电子设备执行第四值所对应的提升CPU资源空闲率的策略。这样，执行模块根据查杀级别进行CPU查杀，可以合理的管理电子设备中的进程或服务，这样可以不会查杀过多的进程或服务，提升用户体验。
一种可能的实现中，第二预设文件中包括多个区间，若第四值在第一区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：前台应用的进程、用户可见应用的进程、用户可感知后台应用的进程、备份任务的进程、不具有恢复能力的后台进程、运行时长未超过第二预设时间段的服务、第一应用启动之前电子设备中前台运行的应用的进程、运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；若第四值在第二区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：不具有恢复能力的后台进程、运行时长未超过第二预设时间段的服务、第一应用启动之前电子设备中前台运行的应用的进程、运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；若第四值在第三区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；若第四值在第四区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：缓存的后台应用的进程、空进程；若第四值在第五区间，第四值所对应的提升CPU资源空闲率的策略包括：电子设备清理空进程；其中，第一区间中的值大于第二区间中的值，第二区间中的值大于第三区间中的值，第三区间中的值大于第四区间中的值，第四区间中的值大于第五区间中的值。这样，执行模块根据查杀级别进行CPU查杀，可以合理的管理电子设备中的进程或服务，这样可以先查杀优先级较低的进程或服务，减少对用户体验的影响。
一种可能的实现中，在电子设备执行第四值所对应的提升CPU资源空闲率的策略时，若策略中包括不允许清理的应用或服务，则不清理不允许清理的应用或服务；其中，不允许清理的应用或服务包括：预设应用名单中的应用或服务、和/或电子设备加载的应用中用户使用频率高于阈值的应用或服务、和/或电子设备加载的应用中用户使用频率排名前Q名的应用或服务。这样，策略中包括不允许清理的应用或服务，使得系统中某些较为重要的应用可以添加到应用白名单中，这样，应用不会被杀掉，进而不会影响用户体验。
一种可能的实现中，方法还包括：若电子设备提升CPU资源空闲率时，还需要提升内存空闲率，则电子设备先提升内存空闲率。这样，对内存查杀和CPU查杀安排优先级，可以使得相同的进程或系统资源不会被多次查杀，避免查杀流程变得冗余，且这样可以减少电子设备在运行时出现异常的概率。
一种可能的实现中，电子设备提升内存空闲率之后，还包括：电子设备更新CPU资源空闲率；若第三值大于更新后的CPU资源空闲率，电子设备继续提升CPU资源空闲率。这样，可以灵活控制查杀模块对进程或服务的查杀，使得电子设备不会过度查杀进程或服务，从而减少对用户的影响。
一种可能的实现中，电子设备提升CPU资源空闲率之后，还包括：若提升后的CPU资源空闲率与第三值的差值大于或等于第一预设阈值，则减小第一值和/或增大第二值；若提升后的CPU资源空闲率与第三值的差值小于第二预设阈值，则增大第一值和/或减小第二值。这样，CPU状态预留机制可以根据CPU查杀后回收的CPU资源情况，更为准确的计算出需要的CPU资源。
一种可能的实现中，方法还包括：响应于用户在第二应用的第一界面内滑动的操作，电子设备查询第一预设文件，得到第五值和第六值，其中，第五值为电子设备显示第一界面滑动后的界面需要的CPU资源利用率，第六值为电子设备退出显示第一界面滑动前的界面时的CPU资源回收率；电子设备基于第五值和第六值得到第七值，第七值为电子设备在第一界面内滑动时需要的CPU资源利用率；若第七值大于CPU资源空闲率，电子设备提升CPU资源空闲率。这样，可以使得应用界面滑动时需要的CPU资源较为充足，从而减少电子设备的卡顿。
一种可能的实现中，方法还包括：响应于用户从第一界面进入到第二应用的第二界面的操作，电子设备查询第一预设文件，得到第八值和第九值，其中，第八值为电子设备显示第二界面需要的CPU资源利用率，第九值为电子设备退出显示第一界面时的CPU资源回收率；电子设备基于第八值和第九值得到第十值，第十值为电子设备从第一界面进入到第二界面时需要的CPU资源利用率；若第十值大于CPU资源空闲率，电子设备提升CPU资源空闲率。这样，响应于用户的触发操作，电子设备可以在应用界面跳转之前，提前预留出所需要的CPU资源，减少电子设备的卡顿。
第二方面，本申请实施例提供一种CPU资源管理的装置，该装置可以是电子设备，也可以是电子设备内的芯片或者芯片系统。该装置可以包括处理单元和显示单元。处理单元用于实现第一方面或第一方面的任意一种可能的实现方式中电子设备执行的与处理相关的任意方法。显示单元用于实现第一方面或第一方面的任意一种可能的实现方式中电子设备执行的与显示相关的任意方法。当该装置是电子设备时，该处理单元可以是处理器。该装置还可以包括存储单元，该存储单元可以是存储器。该存储单元用于存储指令，该处理单元执行该存储单元所存储的指令，以使该电子设备实现第一方面或第一方面的任意一种可能的实现方式中描述的方法。当该装置是电子设备内的芯片或者芯片系统时，该处理单元可以是处理器。该处理单元执行存储单元所存储的指令，以使该电子设备实现第一方面或第一方面的任意一种可能的实现方式中描述的方法。该存储单元可以是该芯片内的存储单元(例如，寄存器、缓存等)，也可以是该电子设备内的位于该芯片外部的存储单元(例如，只读存储器、随机存取存储器等)。
示例性的，显示单元，用于显示第一应用的界面。处理单元，用于电子设备查询第一预设文件，得到第一值和第二值，还用于基于第一值和第二值得到第三值，具体还用于提升CPU资源空闲率。
一种可能的实现方式中，电子设备的CPU包括n个内核，n为大于或等于1的整数，第一值与下述值成正比：电子设备显示第二应用的界面时占用n个内核的时间，以及n个内核的权重；第二值与第一应用的界面在前台显示时占用n个内核的时间成正比，与第一应用在后台运行时占用n个内核的时间成反比。
一种可能的实现方式中，第一值满足下述公式：
其中，sourcerate为第一值，m为预设时间段，n为CPU的内核个数，coreNi,j,time为电子设备显示第二应用的界面时占用第j个内核的时间，coreNi,j,weight为第j个内核的权重；
第二值满足下述公式：
其中，subsiderate为第二值，coreNi,j,fg为第一应用的界面在前台显示时占用第j个内核的时间，coreNi,j,bg为第一应用在后台运行时占用第j个内核的时间。
一种可能的实现方式中，第三值为第一值和第二值的差值。
一种可能的实现方式中，处理单元，用于基于第三值和CPU资源空闲率的差值得到第四值，还用于在第二预设文件中查询第四值所对应的提升CPU资源空闲率的策略，具体还用于执行第四值所对应的提升CPU资源空闲率的策略。
一种可能的实现方式中，第二预设文件中包括多个区间，若第四值在第一区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：前台应用的进程、用户可见应用的进程、用户可感知后台应用的进程、备份任务的进程、不具有恢复能力的后台进程、运行时长未超过第二预设时间段的服务、第一应用启动之前电子设备中前台运行的应用的进程、运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；若第四值在第二区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：不具有恢复能力的后台进程、运行时长未超过第二预设时间段的服务、第一应用启动之前电子设备中前台运行的应用的进程、运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；若第四值在第三区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；若第四值在第四区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：缓存的后台应用的进程、空进程；若第四值在第五区间，第四值所对应的提升CPU资源空闲率的策略包括：电子设备清理空进程；其中，第一区间中的值大于第二区间中的值，第二区间中的值大于第三区间中的值，第三区间中的值大于第四区间中的值，第四区间中的值大于第五区间中的值。
一种可能的实现方式中，处理单元，用于若策略中包括不允许清理的应用或服务，则不清理不允许清理的应用或服务。
一种可能的实现方式中，处理单元，用于若电子设备提升CPU资源空闲率时，还需要提升内存空闲率，则先提升内存空闲率。
一种可能的实现方式中，处理单元，用于更新CPU资源空闲率，还用于继续提升CPU资源空闲率。
一种可能的实现方式中，处理单元，用于若提升后的CPU资源空闲率与第三值的差值大于或等于第一预设阈值，则减小第一值和/或增大第二值，还用于若提升后的CPU资源空闲率与第三值的差值小于第二预设阈值，则增大第一值和/或减小第二值。
一种可能的实现方式中，处理单元，用于查询第一预设文件，得到第五值和第六值，还用于基于第五值和第六值得到第七值，具体还用于若第七值大于CPU资源空闲率，提升CPU资源空闲率。
一种可能的实现方式中，处理单元，用于查询第一预设文件，得到第八值和第九值，还用于基于第八值和第九值得到第十值，具体还用于若第十值大于CPU资源空闲率，提升CPU资源空闲率。
第三方面，本申请实施例提供一种电子设备，包括处理器和存储器，存储器用于存储代码指令，处理器用于运行代码指令，以执行第一方面或第一方面的任意一种可能的实现方式中描述的方法。
第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序或指令，当计算机程序或指令在计算机上运行时，使得计算机执行第一方面或第一方面的任意一种可能的实现方式中描述的方法。
第五方面，本申请实施例提供一种包括计算机程序的计算机程序产品，当计算机程序在计算机上运行时，使得计算机执行第一方面或第一方面的任意一种可能的实现方式中描述的方法。
第六方面，本申请提供一种芯片或者芯片系统，该芯片或者芯片系统包括至少一个处理器和通信接口，通信接口和至少一个处理器通过线路互联，至少一个处理器用于运行计算机程序或指令，以执行第一方面或第一方面的任意一种可能的实现方式中描述的方法。其中，芯片中的通信接口可以为输入/输出接口、管脚或电路等。
在一种可能的实现中，本申请中上述描述的芯片或者芯片系统还包括至少一个存储器，该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元，例如，寄存器、缓存等，也可以是该芯片的存储单元(例如，只读存储器、随机存取存储器等)。
应当理解的是，本申请的第二方面至第六方面与本申请的第一方面的技术方案相对应，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。
附图说明
图1为本申请实施例提供的一种电子设备的结构示意图；
图2为本申请实施例提供的一种电子设备的软件结构示意图；
图3为本申请实施例提供的一种CPU资源管理方法的框架图；
图4为本申请实施例提供的一种CPU资源管理方法的流程图；
图5为本申请实施例提供的一种CPU状态预留机制的实现流程示意图；
图6为本申请实施例提供的一种CPU查杀和内存查杀的耦合实现流程图；
图7为本申请实施例提供的一种CPU资源管理方法的示意图；
图8为本申请实施例提供的一种芯片的结构示意图。
具体实施方式
为了便于清楚描述本申请实施例的技术方案，以下，对本申请实施例中所涉及的部分术语和技术进行简单介绍：
1、术语
在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一芯片和第二芯片仅仅是为了区分不同的芯片，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
需要说明的是，本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
本申请实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，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可以是单个，也可以是多个。
2、电子设备
本申请实施例的电子设备也可以为任意形式的终端设备，例如，电子设备可以包括：手机(mobile phone)、平板电脑、掌上电脑、笔记本电脑、移动互联网设备(mobileinternet device，MID)、可穿戴设备，虚拟现实(virtual reality，VR)设备、增强现实(augmented reality，AR)设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、蜂窝电话、无绳电话、会话启动协议(session initiation protocol，SIP)电话、无线本地环路(wirelesslocal loop，WLL)站、个人数字助理(personal digital assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，5G网络中的电子设备或者未来演进的公用陆地移动通信网络(public land mobilenetwork，PLMN)中的电子设备等，本申请实施例对此并不限定。
作为示例而非限定，在本申请实施例中，该电子设备还可以是可穿戴设备。可穿戴设备也可以称为穿戴式智能设备，是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。可穿戴设备不仅仅是一种硬件设备，更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能，例如：智能手表或智能眼镜等，以及只专注于某一类应用功能，需要和其它设备如智能手机配合使用，如各类进行体征监测的智能手环、智能首饰等。
此外，在本申请实施例中，电子设备还可以是物联网(internet of things，IoT)系统中的电子设备，IoT是未来信息技术发展的重要组成部分，其主要技术特点是将物品通过通信技术与网络连接，从而实现人机互连，物物互连的智能化网络。
本申请实施例中的电子设备也可以称为：用户设备(user equipment，UE)、移动台(mobile station，MS)、移动终端(mobile terminal，MT)、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置等。
在本申请实施例中，电子设备或各个网络设备包括硬件层、运行在硬件层之上的操作系统层，以及运行在操作系统层上的应用层。该硬件层包括中央处理器(centralprocessing unit，CPU)、内存管理单元(memory management unit，MMU)和内存(也称为主存)等硬件。该操作系统可以是任意一种或多种通过进程(process)实现业务处理的计算机操作系统，例如，Linux操作系统、Unix操作系统、Android操作系统、iOS操作系统或windows操作系统等。该应用层包含浏览器、通讯录、文字处理软件、即时通信软件等应用。
示例性的，图1示出了电子设备的结构示意图。
电子设备可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。
可以理解的是，本发明实施例示意的结构并不构成对电子设备的具体限定。在本申请另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以包括硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从上述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，SIM卡接口，和/或USB接口等。
可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在本申请另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
内部存储器121可以用于存储计算机可执行程序代码，可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备的各种功能应用以及数据处理。
图2是本申请实施例的电子设备的软件结构框图。分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为五层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，硬件抽象层(hardware adaptation layer，HAL)，以及内核层。
应用程序层也可以称为应用层，应用层可以包括一系列应用程序包。如图2所示，应用程序包可以包括电话、音乐、日历、相机、游戏、备忘录、视频等应用程序。应用程序可以包括系统应用和三方应用。
应用程序框架层也可以称为Framework层，Framework层可以为应用层的应用程序提供应用编程接口(application programming interface，API)和编程框架。Framework层可以包括一些预先定义的函数。
如图2所示，Framework层可以包括输入事件检测模块InputReader、桌面启动器Launcher、系统服务SystemServer、资源管理器和内容提供器等。
输入事件检测模块InputReader可以用于检测电子设备接收到的用户输入事件，例如输入事件可以包括用户的单击、双击、长按、滑动等操作事件。
桌面启动器Launcher可以用于启动应用。
系统服务SystemServer中可以包括决策模块和配置模块。决策模块可以包括状态预警模块，该状态预警模块中可以包括CPU状态阈值策略和CPU状态预留机制。配置模块中可以包括CPU查杀配置中心和系统应用管控接口。
其中，CPU状态阈值策略可以用于监控CPU状态是否达到需要管控查杀应用的门限，该门限也可以称为阈值或CPU高负载状态的阈值。
CPU状态预留机制可以用于生成CPU预留资源表cpu_pre.xml。电子设备在进行应用查杀时，CPU状态预留机制可以根据该CPU预留资源表cpu_pre.xml判断是否需要为某个应用预留一些CPU资源，以及确定某个进程的预留资源占比和回落资源占比的情况。此外，在电子设备查杀应用后，CPU状态预留机制还可以对回落的CPU资源的情况进行统计，这样可以准确了解到各个进程占用CPU资源的情况，方便下次对各个进程需要预留的资源进行计算。
CPU查杀配置中心可以用于生成CPU查杀配置表cpu_adj，电子设备在进行应用查杀时，可以按照CPU查杀配置表cpu_adj中的查杀等级执行应用查杀。
系统应用管控接口可以为CPU查杀配置中心提供一些应用管控接口。CPU查杀配置中心通过该应用管控接口可以获取应用黑名单、应用白名单，以及其他应用管控机制，从而可以确定哪些应用可以被查杀，或者哪些应用不可以被查杀等。
资源管理器为应用程序提供各种资源，例如本地化字符串、图标、图片、布局文件、视频文件等等。
内容提供器用于在不同的应用程序之间实现数据共享的功能，允许一个程序访问另一个程序中的数据，同时还能保证被访问的数据的安全性。
Android runtime包括核心库和虚拟机。Android runtime负责安卓系统的控制和管理。
核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
应用层和Framework层运行在虚拟机中。虚拟机将应用层和Framework层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。例如本申请实施例中，虚拟机可以用于执行CPU的状态采集、预留资源占比和回落资源占比的计算，以及应用的查杀和清理等功能。
系统库也可以称为Native层，Native层可以包括多个功能模块。例如函数库(function libraries)、图形处理库(例如：OpenGL ES)等。本申请实施例中，Native层还可以包括性能雷达识别模块。
函数库为开发者提供多种服务的API接口，方便开发者快速集成并实现各种功能。
图形处理库用于实现三维图形绘图、图像渲染、合成和图层处理等。
性能雷达识别模块可以用于识别当前的应用场景。其中，应用场景可以包括应用的启动场景、滑动场景、转场场景等。启动场景可以理解为应用启动时的场景，启动场景也可以称为冷启动场景；滑动场景可以理解包括用户上滑应用、下滑应用、左滑应用、右滑应用等场景；转场场景可以理解为从应用的界面1跳转到该应用的界面2的场景。
硬件抽象层是介于内核层和Android runtime之间的抽象出来的一层结构。硬件抽象层可以是对硬件驱动的一个封装，为上层应用的调用提供统一接口。
内核层是硬件和软件之间的层。内核层可以包括显示驱动、摄像头驱动、音频驱动、CPU驱动等。本申请实施例中，内核层还可以包括状态采集模块和执行模块。
状态采集模块可以用于获取CPU资源的使用情况、系统各大小核的平均利用率、CPU占用情况排序表、CPU负载情况分布等信息。其中，CPU占用情况排序表可以理解为各应用运行时占用CPU资源的排序表。
执行模块可以包括查杀模块，该查杀模块可以执行CPU查杀、内存查杀等流程。例如该查杀模块可以在达到CPU高负载状态的阈值时，根据CPU查杀配置表cpu_adj对应用进行查杀和清理，该流程也可以称为CPU查杀。此外，该查杀模块还可以在CPU查杀后，对CPU剩余资源进行分配以及CPU多核间进行协调。
需要说明的是，本申请实施例仅以安卓系统举例来说明，在其他操作系统中(例如Windows系统，IOS系统等)，只要各个功能模块实现的功能和本申请的实施例类似，也能实现本申请的方案。
电子设备中可以支持安装多种类型的应用，例如游戏应用、短视频应用等，用户可以使用应用玩游戏、看短视频，或者浏览网页等。然而，用户在使用应用时，可能会出现应用卡顿的情况。
一些场景中，虽然电子设备的内存较为充足，但是仍然会出现应用卡顿的情况。这是由于CPU的负载较高，在CPU高负载的情况下，CPU各个核的运行可能达到满载状态，使得CPU各个核之间调度不过来，从而使得电子设备出现卡顿，降低用户体验。
有鉴于此，本申请实施例提供的CPU资源管理方法，响应于用户的触发操作，电子设备可以识别用户触发的应用场景，并为该应用场景提前预留出所需要的CPU资源，这样可以使得用户触发的场景所需要的CPU资源较为充足，从而减少电子设备的卡顿。
图3示出了CPU资源管理方法的框架图。
CPU资源管理方法的框架图中可以包括下述几个模块：状态采集模块、配置模块、决策模块和执行模块。具体各个模块的功能介绍可以参照上述图2对应的实施例中的相关描述，不再赘述。
可能的实现中，状态采集模块在获取到CPU负载和CPU使用状态后，可以发送给决策模块中的状态预警模块。
状态预警模块中的CPU状态预留机制可以从配置模块的CPU查杀配置中心查询到CPU状态用户使用习惯，CPU状态预留机制可以结合用户使用习惯计算出应用运行时需要的CPU资源，并将需要的CPU资源传递给状态预警模块中的CPU状态阈值策略。具体CPU状态预留机制计算需要的CPU资源的实现可以参照图5对应的实施例中的相关描述。
CPU状态阈值策略可以结合CPU状态预留机制传递的需要的CPU资源，来判断是否达到CPU高负载状态的阈值。
若CPU状态阈值策略判断达到CPU高负载状态的阈值，则状态预警模块可以触发执行模块的查杀模块执行CPU查杀。例如查杀模块可以根据CPU查杀配置中心生成的CPU查杀配置表cpu_adj对应用进行查杀和清理。
在查杀模块完成CPU查杀后，可以回收一些CPU资源，该查杀模块还可以进行CPU剩余资源的分配以及多核间CPU资源的协调，从而降低CPU负载，减少电子设备的卡顿。
此外，该查杀模块还可以将CPU查杀后回收的CPU资源情况等反馈给状态预警模块中的CPU状态预留机制。可能的实现中，若CPU查杀之后，回收的CPU资源占比与需要的CPU资源占比的差值大于或等于第一阈值，则说明回收的CPU资源较多，可以适当减小预留资源占比，和/或适当增大回落资源占比；若CPU查杀之后，回收的CPU资源占比与需要的CPU资源占比的差值小于第二阈值，则说明回收的CPU资源较少，可以适当增大预留资源占比，和/或适当减小回落资源占比。其中，第一阈值和第二阈值均可以由电子设备预先设置，具体的第一阈值和第二阈值，本申请实施例不作限定。这样，CPU状态预留机制可以根据CPU查杀后回收的CPU资源情况，更为准确的计算出需要的CPU资源。
可以理解的是，CPU查杀配置中心在生成CPU查杀配置表cpu_adj时，一方面，CPU查杀配置中心可以结合CPU状态用户使用习惯生成该表。CPU查杀配置中心可以根据用户的高频使用场景，以及打开、操作应用的使用习惯等，判断CPU资源在不同应用间的占用值。例如，当用户使用某个应用的频率比较高时，CPU查杀配置中心可以为该应用分配较高的查杀等级，这样，查杀模块在查杀应用时，可以使得用户常用的应用不容易被杀掉，从而提升用户体验。
另一方面，CPU查杀配置中心还可以查询系统应用管控接口提供的应用黑名单、应用白名单，以及其他应用管控机制来生成该表。例如，若系统中某些应用较为重要，或者某些应用被杀掉后会影响用户体验，则系统可以将这些应用添加到应用白名单中，这样，查杀模块在查杀应用时，可以使得这些应用不会被杀掉。
此外，应用管控机制还可以包括：不清理电子设备加载的应用中用户使用频率高于阈值的应用或服务，和/或不清理电子设备加载的应用中用户使用频率排名较为靠前的应用或服务。具体的排名靠前的应用或服务的数量，可以由电子设备预先设置，本申请实施例不作限定。
图4示出了CPU资源管理方法的流程图。
S401、应用获取CPU资源。
当应用启动时，应用需要获取CPU资源。例如，应用获取CPU资源可以进行进程的启动、应用内存的分配，以及应用数据的处理等。可以理解的是，应用在运行过程中也需要获取CPU资源。例如应用需要CPU资源来执行各种指令以及对应用数据进行处理。
S402、状态采集模块获取当前CPU使用率、负载。
可能的实现中，状态采集模块可以在电子设备接收到用户操作时获取CPU使用率以及CPU负载等信息，用户操作可以包括单击操作、双击操作、滑动操作等。状态采集模块还可以在应用获取CPU资源时获取CPU使用率以及CPU负载等信息。状态采集模块还可以周期性获取CPU使用率以及CPU负载等信息，其中，获取周期可以由电子设备预先设置，具体的周期值，本申请实施例不作限定。
S403、用户点击应用图标。
当用户点击应用层的某个应用图标时，Framework层的输入事件检测模块InputReader可以检测到用户点击应用的事件，并向Framework层的桌面启动器Launcher传递该事件。
S404、桌面启动器Launcher启动应用。
桌面启动器Launcher获取到用户点击应用的事件后，可以启动该应用。
S405、性能雷达识别模块识别当前应用场景。
Native层的性能雷达识别模块可以识别当前的应用场景。其中，应用场景可以包括应用的启动场景、滑动场景、转场场景等。
可能的实现中，当输入事件检测模块InputReader检测到用户操作电子设备的事件时，可以触发性能雷达识别模块检测当前的应用场景。例如，上述步骤S403中，当输入事件检测模块InputReader检测到用户点击应用的事件时，可以向性能雷达识别模块上报该事件，则性能雷达识别模块可以识别到当前的应用场景为应用的启动场景。
性能雷达识别模块在识别到当前的应用场景后，可以执行步骤S406，获取当前的应用场景需要的预留资源占比与回落资源占比。
S406、性能雷达识别模块获取当前应用场景需要的预留资源与回落资源。
性能雷达识别模块可以通过Framework层的系统服务SystemServer获取当前应用场景需要的预留资源占比与回落资源占比。其中，预留资源占比也可以简称为预留资源，回落资源占比也可以简称为回落资源。
可能的实现中，系统服务SystemServer中可以包括状态预警模块，该状态预警模块中的CPU状态预留机制可以生成CPU预留资源表cpu_pre.xml。性能雷达识别模块可以通过该CPU预留资源表cpu_pre.xml获取当前应用场景所需的预留资源占比和回落资源占比。
其中，每个应用的不同应用场景可以有对应不同的预留资源占比和回落资源占比。例如，应用1的启动场景有对应的预留资源占比和回落资源占比，应用1的滑动场景可以有对应的预留资源占比和回落资源占比，应用1的转场场景也可以有对应的预留资源占比和回落资源占比。此外，不同应用的预留资源占比可以不同，不同应用的回落资源占比也可以不同。
以应用1为例，当应用1启动时，电子设备需要一些CPU资源来启动应用1，则CPU预留资源表cpu_pre.xml中应用1在启动场景下的预留资源占比可以表示应用1启动时所需要的CPU资源。当电子设备从应用1的界面跳转到应用2的界面时，由于应用1会退出电子设备的前台，这时，应用1所需要的CPU资源减少，存在CPU资源回落的情况，则CPU预留资源表cpu_pre.xml中应用1的回落资源占比可以表示应用1退出电子设备前台时的CPU回落资源。
该状态预警模块中的CPU状态阈值策略可以基于该表中当前应用场景的预留资源占比与回落资源占比判断否达到CPU高负载状态的阈值。
可以理解的是，决策模块的CPU状态预留机制获取当前应用场景所需的预留资源占比和回落资源占比，以及决策模块的CPU状态阈值策略判断是否达到CPU高负载状态的阈值的流程也可以在内核层中实现，还可以在电子设备的其他的软件架构层中实现，本申请实施例不作限定。
S407、决策模块判断是否达到阈值。
决策模块的CPU状态预留机制可以根据CPU预留资源表cpu_pre.xml中当前应用场景的预留资源占比与回落资源占比计算当前需要的CPU资源占比，并将需要的CPU资源占比传递给CPU状态阈值策略。
示例性的，以电子设备从应用1的界面跳转到应用2的界面为例，CPU状态预留机制可以通过计算应用2启动时的预留资源占比与应用1退出前台时的回落资源占比的差值，确定当前从应用1的界面跳转到应用2的界面所需的CPU资源占比。例如，应用2启动时的预留资源占比为30％，应用1退出前台时的回落资源占比为10％，则从应用1的界面跳转到应用2的界面所需的CPU资源占比可以为20％。
决策模块的CPU状态阈值策略可以判断当前CPU剩余资源占比是否能够满足当前需要的CPU资源占比。当CPU剩余资源占比大于或等于当前需要的CPU资源占比时，说明没有达到CPU高负载状态的阈值，可以不执行CPU查杀。当CPU剩余资源占比小于当前需要的CPU资源占比时，说明达到了CPU高负载状态的阈值，可以执行CPU查杀。
示例性的，假设当前CPU资源占用率为80％，也就是说，当前CPU剩余资源占比为20％，若当前需要的CPU资源占比为10％，则CPU剩余资源占比大于当前需要的CPU资源占比，说明CPU资源充足，可以不执行CPU查杀；若当前需要的CPU资源占比为30％，则CPU剩余资源占比小于当前需要的CPU资源占比，说明CPU资源不够充足，可以执行CPU查杀。其中，CPU资源占用率也可以理解为CPU资源使用率，CPU剩余资源占比也可以理解为CPU空闲资源占比。
S408、执行模块查找需要查杀的应用。
执行模块可以通过系统服务SystemServer的配置模块确定需要查杀的应用。其中，配置模块中的CPU查杀配置中心可以包括CPU查杀配置表cpu_adj，该CPU查杀配置表cpu_adj可以按照CPU使用率进行排序，为不同的CPU使用率设置不同的阈值。当达到CPU高负载状态的阈值时，执行模块可以基于CPU查杀配置表cpu_adj对应用进行查杀和清理。
示例性的，假设当前CPU使用率为80％，则CPU空闲资源占比为20％，若CPU状态预留机制计算当前还需要30％的CPU资源占比，由于当前CPU空闲资源占比20％小于当前需要的CPU资源占比30％，则CPU状态阈值策略可以判断当前达到CPU高负载状态的阈值，决策模块可以触发执行模块进行CPU查杀。
执行模块根据CPU查杀配置表cpu_adj进行CPU查杀时，由于当前CPU空闲资源占比为20％，当前需要的CPU资源占比为30％，也就是说，当前还需要回收10％的CPU资源才可以满足当前需要的30％的CPU资源，则当前的查杀级别可以对应为10％。相应的，从下述表1中可以确定，执行模块可以查杀一些空进程来回收一些CPU资源。
可以理解的是，电子设备中的进程或服务可以被划分为多种类型。例如包括前台应用、用户可见应用、用户可感知后台应用、备份任务、不具恢复能力的后台、A类应用服务、B类应用服务等。可能的实现中，电子设备中的应用管理服务(application managementservices，AMS)可以判断电子设备中各个进程或服务所属的类型。例如，电子设备可以通过调用AMS的相关接口，向AMS的相关接口传递应用的包名，进而AMS的相关接口可以返回该应用进程所属的类型。
示例性的，表1示出了CPU查杀配置表cpu_adj中的查杀级别和进程/服务的对应关系。其中，可以查杀的进程可以包括下述的一项或多项：前台应用的进程、用户可见应用的进程、用户可感知后台应用的进程、备份任务的进程、不具恢复能力的后台进程、前一个应用APP的进程、缓存的后台应用的进程、空进程等。可以查杀的服务可以包括下述的一项或多项：A类型的应用服务、B类型的应用服务等。
可以理解的是，当查杀级别小于或等于10％时，执行模块可以对空进程进行查杀；当查杀级别在10％～20％之间时，执行模块不仅可以对缓存的后台应用的进程进行查杀，还可以对查杀级别较低的空进程进行查杀。也就是说，执行模块可以将某个查杀级别对应的进程或服务进行查杀，还可以将低于该查杀级别的进程或服务进行查杀。因此，查杀级别越高，可以查杀的进程或服务的类型越多，这样，可以更多的回收CPU资源，减少电子设备的卡顿。
表1
S409、执行模块查杀应用，CPU资源回落。
查杀应用可以理解为将应用的进程杀掉，也可以理解为停止应用的运行，本申请实施例对查杀应用的具体实现不作限定。执行模块在查杀应用后，可以回收一些CPU资源，这样可以缓解CPU负载压力，减少电子设备的卡顿，提升用户体验。
图5示出了CPU状态预留机制的实现流程示意图。
CPU状态预留机制可以结合用户使用习惯场景计算出应用运行时需要的CPU资源占比。其中，用户使用习惯场景可以包括(1)应用维度和(2)用户使用维度。
(1)应用维度。
由于不同的应用在运行时所占用的CPU资源可以不同，且同一个应用在不同的应用场景下所占用的CPU资源也可以不同。因此，CPU状态预留机制可以针对各个应用的不同场景分别计算对应的预留资源占比和回落资源占比，进而可以得到应用运行时需要的CPU资源占比。其中，应用场景可以包括应用的启动场景、滑动场景、转场场景等，具体可以参照上述图2对应的实施例中的相关描述，不再赘述。
(2)用户使用维度。
CPU状态预留机制还可以从用户使用习惯考虑应用运行时需要的CPU资源占比。例如，用户A在使用应用1时，用户A的编辑操作较多，或者需要在应用1中跳转其他的应用进程，则应用1在运行过程中所占用的CPU资源较高。而用户B在使用应用1时，用户B的浏览操作较多，则应用1在运行过程中所占用的CPU资源较少。这样，CPU状态预留机制可以根据用户使用习惯为同一应用预留不同的CPU资源占比。
可能的实现中，如图5中的b所示，CPU状态预留机制可以根据大数据统计得到各个应用在电子设备前台运行预设时间所占用的CPU资源。其中，图5中的b也可以称为初始表或CPU资源占比表。预设时间也可以称为存续时间，该存续时间可以由电子设备预先设置，例如存续时间可以为5秒(s)，对于存续时间的具体值，本申请实施例不作限定。
为了便于描述，后续以应用的启动场景，预设时间为5s为例进行说明。
在CPU资源占比表中，各个应用可以有各自对应的CPU时间片存续值和CPU资源占比。
CPU时间片存续值可以理解为在5s内，某个应用在CPU各个核运行时所占用的时间值，也可以理解为该应用使用CPU的时间值。CPU时间片存续值可以基于大数据统计CPU各个核的存续时间以及CPU大核、中核、小核的比重计算得到，该CPU大核、中核、小核的比重也可以理解为CPU大核、中核、小核的权重。
其中，基于大数据统计CPU各个核的占用时间时，可以采用平均值、区间值或者极值等方式进行统计，极值也可以理解为极大值，本申请实施例对大数据的统计方式不作限定。示例性的，以采用平均值方式统计应用1在CPU各个核的存续时间为例，例如大数据可以统计得到在5s内，应用1在大核上的运行时间为1s，应用1在中核上的运行时间为700毫秒(ms)，应用1在小核上的运行时间为500ms。
由于应用在大核上运行时，对CPU资源的占用较多，应用在小核上运行时，对CPU资源的占用较少，因此，可以设置应用在大核上运行时，相应的权重较大，应用在小核上运行时，相应权重较小。可能的实现中，CPU大核、中核、小核的权重可以包括：大核:中核:小核＝3:2:1，CPU大核、中核、小核的权重也可以设置为其他比例，本申请实施例不作限定。
可能的实现中，应用的各个场景所需预留的CPU资源占比sourcerate可以满足下述公式：
其中，m为存续时间，n为CPU的内核个数，coreNi,j,time为应用在某个场景中占用第j个内核的存续时间，coreNi,j,weight为第j个内核的权重。
同理，应用退出电子设备前台时的CPU回落资源占比subsiderate可以满足下述公式：
其中，coreNi,j,fg为应用退出电子设备前台之前占用第j个内核的时间，coreNi,j,bg为应用退出电子设备前台之后占用第j个内核的时间。
CPU状态预留机制可以根据CPU资源占比表计算应用运行时需要的CPU资源占比，从而生成CPU预留资源表cpu_pre.xml。其中，应用需要的CPU资源占比cpu_App_source_pre可以满足下述公式：
cpu_App_source_pre＝sourcerate-subsidercte。
由于应用在不同的应用场景下所占用的CPU资源不同，因此，CPU状态预留机制可以从应用维度进行考虑，在不同应用场景下，为各个应用分别设置对应的CPU资源占比表。如图5的c所示，CPU资源占比表可以包括冷启动时各个应用的CPU资源占比表、应用内滑动时各个应用的CPU资源占比表，以及应用内转场时各个应用的CPU资源占比表等。
CPU状态预留机制可以从用户使用维度进行考虑，周期性采样统计各个应用的CPU时间片存续值，进而对各个应用的CPU资源占比表进行调整。也就是说，CPU状态预留机制可以定期更新CPU资源占比表中的预留资源占比和回落资源占比。例如，若某个用户的电子设备中使用了大数据未统计到的应用，则CPU状态预留机制可以为该应用设置对应的预留资源占比和回落资源占比。其中，电子设备可以预先设置采样周期，例如采样周期可以为一天或一周，具体的采样周期，本申请实施例不作限定。
可以理解的是，在电子设备运行过程中，查杀模块可能会同时接收到内存查杀命令和CPU查杀命令。若查杀模块同时执行内存查杀和CPU查杀，可能会导致相同的进程或系统资源被多次查杀，使得查杀流程变得冗余，且可能会导致电子设备的运行出现异常。因此，本申请实施例提供了一种CPU查杀和内存查杀的耦合实现方式。
图6示出了CPU查杀和内存查杀的耦合实现流程图。
S601、查杀模块接收外部查杀命令。
查杀模块可以接收外部查杀命令，例如内存查杀命令、CPU查杀命令等。为了便于描述，后续以内存查杀命令和/或CPU查杀命令为例进行描述。
当查杀模块接收到内存查杀命令和/或CPU查杀命令时，可以执行步骤S602。
S602、如果为内存查杀命令。
查杀模块在接收到查杀命令时，可以判断该查杀命令是否为内存查杀命令。
若查杀模块同时接收到内存查杀命令和CPU查杀命令，可以先执行步骤S603，即执行内存查杀的相关流程。
若查杀模块只接收到内存查杀命令，则可以执行步骤S603，执行内存查杀的相关流程。若查杀模块只接收到CPU查杀命令，则可以执行步骤S609，执行CPU查杀的相关流程。
S603、查询电子设备状态。
电子设备状态可以包括电子设备的内存状态和电子设备的CPU状态。在执行内存查杀的流程时，可以查询电子设备的内存状态。其中，电子设备的内存状态可以包括总内存、可用内存、内存使用率、某个应用使用的内存以及某个应用的内存限制大小等。
当查杀模块获取到内存状态后，可以执行步骤S604，判断是否需要进行内存查杀。
S604、查杀模块根据电子设备状态判断是否需要内存查杀。
若查杀模块判断已经达到内存查杀的条件，则可以执行步骤S605，进行内存查杀。具体内存查杀的条件可以由查杀模块设置，本申请实施例不作限定。
若查杀模块判断未达到内存查杀的条件，则可以执行步骤S608，判断是否接收到CPU查杀命令。
S605、内存查杀。
内存查杀可以包括杀死一些后台进程、回收内存等流程。例如，查杀模块可以将后台的一些不使用的内存资源或进程进行回收。具体内存查杀的流程可以由查杀模块设置，本申请实施例不作限定。
S606、进程池更新。
在执行内存查杀或CPU查杀后，进程池中的一些进程可能会被杀掉，因此，进程池会发生变化，更新到内存查杀或CPU查杀后的最新状态。
S607、电子设备状态更新。
在内存查杀或CPU查杀后，由于可以回收内存资源或CPU资源，因此，电子设备状态也会发生变化，更新为最新的电子设备状态。
S608、是否接收到CPU查杀命令。
在执行完内存查杀后，若查杀模块还接收到CPU查杀命令，则可以执行步骤S609，即执行CPU查杀的相关流程。
S609、查询电子设备状态。
可以理解的是，若执行CPU查杀之前，已经执行了内存查杀，则查询电子设备状态可以理解为查询更新后的电子设备状态。
在执行CPU查杀的流程时，查杀模块可以向状态采集模块查询电子设备的CPU状态。其中，CPU状态可以包括CPU资源的使用情况、系统各大小核的平均利用率、CPU占用情况排序表、CPU负载情况分布等。
当查杀模块获取到CPU状态后，可以执行步骤S610，判断是否需要进行CPU查杀。
S610、查杀模块根据电子设备状态判断是否需要CPU查杀。
若查杀模块判断已经达到CPU高负载状态的阈值，则可以执行步骤S611，进行CPU查杀。具体判断是否达到CPU高负载状态的阈值可以参照上述图4对应的实施例的步骤S407中的相关描述，不再赘述。
若查杀模块判断未达到CPU高负载状态的阈值，则可以不执行CPU查杀。
这样，查杀模块可以基于更新后的CPU状态灵活控制进程或服务的查杀，使得电子设备不会过度查杀进程或服务，从而减少对用户的影响。
S611、CPU查杀。
本申请实施例中，CPU查杀可以理解为根据上述图4对应的实施例中CPU查杀配置表cpu_adj中的查杀级别对应用或服务进行查杀，具体CPU查杀可以参照上述图4对应的实施例的步骤S408和步骤S409中的相关描述，不再赘述。
可以理解的是，在执行CPU查杀后，还可以执行步骤S606和步骤S607。也就是说，在执行CPU查杀后，进程池会更新到CPU查杀后的最新状态，电子设备状态也会更新为最新的电子设备状态，不再赘述。
本申请实施例中，若内存查杀之后，CPU不处于高负载状态，则可以不进行CPU查杀；若内存查杀之后，CPU处于高负载状态，则可以进行CPU查杀；这样，可以灵活控制电子设备对进程或服务的查杀，使得电子设备不会过度查杀进程或服务，从而提升用户体验。
下面通过具体的实施例对本申请实施例的方法进行详细说明。下面的实施例可以相互结合或独立实施，对于相同或相似的概念或过程可能在某些实施例中不再赘述。
图7示出了本申请实施例的CPU资源管理方法。方法包括：
S701、电子设备显示第一应用的界面。
本申请实施例中，第一应用可以为电子设备中的任一应用，本申请实施例不作限定。
S702、响应于用户从第一应用的界面进入第二应用的界面的操作，电子设备查询第一预设文件，得到第一值和第二值，其中，第一值为电子设备显示第二应用的界面需要的CPU资源利用率，第二值为第一应用退到后台时的CPU资源回收率。
本申请实施例中，第二应用可以为电子设备中的任一应用，本申请实施例不作限定。其中，第二应用与第一应用可以为不同的应用。从第一应用的界面进入第二应用的界面的场景也可以理解为上述实施例中应用的启动场景。
第一预设文件可以理解为上述实施例中的CPU预留资源表cpu_pre.xml。
第一值可以理解为CPU预留资源表cpu_pre.xml中的预留资源占比，第一值可以理解为，第二值可以理解为CPU预留资源表cpu_pre.xml中的回落资源占比。CPU资源利用率可以理解为已经使用的CPU资源占CPU总资源的百分比，也可以理解为上述实施例中的CPU资源使用率。CPU资源回收率可以理解为电子设备释放CPU资源时，可以回收的CPU资源占CPU总资源的百分比。
S703、电子设备基于第一值和第二值得到第三值，第三值为电子设备从第一应用的界面进入第二应用的界面时需要的CPU资源利用率。
本申请实施例中，第三值可以为第一值和第二值的差值，也可以为第一值和第二值的差值的倍数，还可以为第一值和第二值的差值的其他计算方式，本申请实施例不作限定。
S704、若第三值大于CPU资源空闲率，电子设备提升CPU资源空闲率。
本申请实施例中，CPU资源空闲率可以理解为CPU空闲资源占CPU总资源的百分比，也可以理解为上述实施例中的CPU剩余资源占比或CPU空闲资源占比。其中，CPU资源空闲率与CPU资源利用率可以成反比，例如CPU资源空闲率＝1-CPU资源利用率。
第三值大于CPU资源空闲率可以理解为电子设备当前的CPU剩余资源不够充足；电子设备提升CPU资源空闲率可以包括电子设备执行CPU查杀。
响应于用户的触发操作，电子设备可以提前预留出所需要的CPU资源，这样可以使得电子设备所需要的CPU资源较为充足，从而减少电子设备的卡顿。
可选的，在图7对应的实施例的基础上，电子设备的CPU包括n个内核，n为大于或等于1的整数，第一值与下述值成正比：电子设备显示第二应用的界面时占用n个内核的时间，以及n个内核的权重；第二值与第一应用的界面在前台显示时占用n个内核的时间成正比，与第一应用在后台运行时占用n个内核的时间成反比。
本申请实施例中，占用n个内核的时间可以理解为上述图5对应的实施例中的CPU时间片存续值；n个内核的权重可以参照上述图5对应的实施例中CPU大核、中核、小核的权重的相关描述，不再赘述。
第一值可以理解为预留资源占比，具体第一值的计算方法可以参照上述图5对应的实施例中CPU状态预留机制计算预留的CPU资源占比的相关描述，不再赘述。第二值可以理解为回落资源占比，具体第二值的计算方法可以参照上述图5对应的实施例中CPU状态预留机制计算CPU回落资源占比的相关描述，不再赘述。
由于不同的应用在运行时所占用的CPU资源可以不同，因此，CPU状态预留机制可以针对各个应用的不同场景分别计算对应的预留资源占比和回落资源占比，进而可以得到应用运行时需要的CPU资源占比。
可选的，在图7对应的实施例的基础上，第一值满足下述公式：
其中，sourcerate为第一值，m为预设时间段，n为CPU的内核个数，coreNi,j,time为电子设备显示第二应用的界面时占用第j个内核的时间，coreNi,j,weight为第j个内核的权重；
第二值满足下述公式：
其中，subsiderate为第二值，coreNi,j,fg为第一应用的界面在前台显示时占用第j个内核的时间，coreNi,j,bg为第一应用在后台运行时占用第j个内核的时间。
本申请实施例中，预设时间段可以理解为计算第一值或第二值的时间段，也可以理解为上述图5对应的实施例中的存续时间或预设时间，例如预设时间可以为5s，对于预设时间的具体值，本申请实施例不作限定。
具体第一值的计算方法可以参照上述图5对应的实施例中CPU状态预留机制计算预留的CPU资源占比的相关描述，不再赘述。具体第二值的计算方法可以参照上述图5对应的实施例中CPU状态预留机制计算CPU回落资源占比的相关描述，不再赘述。
CPU状态预留机制可以针对各个应用的不同场景分别计算对应的预留资源占比和回落资源占比，进而可以得到应用运行时需要的CPU资源占比，这样，可以提前预留出CPU资源，从而减少CPU高负载的情况。
可选的，在图7对应的实施例的基础上，第三值为第一值和第二值的差值。
本申请实施例中，第三值可以理解为上述图5对应的实施例应用需要的CPU资源占比，不再赘述。
在计算第三值时，同时考虑预留资源占比和回落资源占比，可以更为准确、合理的计算出实际需要的CPU资源占比，从而可以执行相应的CPU查杀。这样，可以既满足对CPU资源的需求，也可以合理的对进程或服务进行查杀。
可选的，在图7对应的实施例的基础上，电子设备提升CPU资源空闲率，可以包括：电子设备基于第三值和CPU资源空闲率的差值得到第四值，电子设备在第二预设文件中查询第四值所对应的提升CPU资源空闲率的策略；电子设备执行第四值所对应的提升CPU资源空闲率的策略。
本申请实施例中，第四值可以理解当前还缺少的CPU资源，也可以理解为还需要回收的CPU资源占比；第四值还可以理解为上述表1中的查杀级别。
电子设备执行第四值所对应的提升CPU资源空闲率的策略可以理解为执行模块根据表1执行CPU查杀。第四值所对应的提升CPU资源空闲率的策略可以理解为查杀级别对应的需要查杀的进程或服务。
第二预设文件可以理解为上述表1示出的CPU查杀配置表cpu_adj。
执行模块根据查杀级别进行CPU查杀，可以合理的管理电子设备中的进程或服务，这样可以不会查杀过多的进程或服务，提升用户体验。
可选的，在图7对应的实施例的基础上，第二预设文件中包括多个区间，若第四值在第一区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：前台应用的进程、用户可见应用的进程、用户可感知后台应用的进程、备份任务的进程、不具有恢复能力的后台进程、运行时长未超过第二预设时间段的服务、第一应用启动之前电子设备中前台运行的应用的进程、运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；若第四值在第二区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：不具有恢复能力的后台进程、运行时长未超过第二预设时间段的服务、第一应用启动之前电子设备中前台运行的应用的进程、运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；若第四值在第三区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；若第四值在第四区间，第四值所对应的提升CPU资源空闲率的策略包括电子设备清理下述的一项或多项：缓存的后台应用的进程、空进程；若第四值在第五区间，第四值所对应的提升CPU资源空闲率的策略包括：电子设备清理空进程；其中，第一区间中的值大于第二区间中的值，第二区间中的值大于第三区间中的值，第三区间中的值大于第四区间中的值，第四区间中的值大于第五区间中的值。
本申请实施例中，第四值所对应的提升CPU资源空闲率的策略可以参考上述表1对应的实施例的相关描述，不再赘述。
第一区间可以理解为表1中查杀级别在40％～50％的区间，第二区间可以理解为表1中查杀级别在30％～40％的区间，第三区间可以理解为表1中查杀级别在20％～30％的区间，第四区间可以理解为表1中查杀级别在10％～20％的区间，第五区间可以理解为表1中查杀级别在0～10％的区间。
其中，运行时长未超过第二预设时间段的服务可以理解为表1中的A类型的应用服务，第二预设时间段可以为电子设备预先设置的最近使用的应用服务的时间段，具体第二预设时间段，本申请实施例不作限定。
运行时长超过第三预设时间段，且在第三预设时间段内的部分时间段未被使用的服务可以理解为表1中的B类型的应用服务。可以理解的是，第三预设时间段可以大于或等于第二预设时间段，第三预设时间段可以由电子设备预先设置，具体第三预设时间段，本申请实施例不作限定。
执行模块根据查杀级别进行CPU查杀，可以合理的管理电子设备中的进程或服务，这样可以先查杀优先级较低的进程或服务，减少对用户体验的影响。
可选的，在图7对应的实施例的基础上，在电子设备执行第四值所对应的提升CPU资源空闲率的策略时，若策略中包括不允许清理的应用或服务，则不清理不允许清理的应用或服务；其中，不允许清理的应用或服务包括：预设应用名单中的应用或服务、和/或电子设备加载的应用中用户使用频率高于阈值的应用或服务、和/或电子设备加载的应用中用户使用频率排名前Q名的应用或服务。
本申请实施例中，电子设备的查杀模块可以执行第四值所对应的提升CPU资源空闲率的策略。示例性的，如上述图3对应的实施例中的相关描述，查杀模块可以根据CPU查杀配置中心生成的CPU查杀配置表cpu_adj对进程或服务进行查杀和清理。
其中，CPU查杀配置中心可以查询系统应用管控接口提供的应用黑名单、应用白名单，以及其他应用管控机制来生成该表。例如系统应用管控接口提供的管控机制可以设置不允许清理的应用或服务。
预设应用名单可以包括应用黑名单、应用白名单等。
对于排名前Q名的应用或服务，电子设备可以设置具体的Q值，例如Q可以取值为3，具体Q的取值，本申请实施例不作限定。
策略中包括不允许清理的应用或服务，使得系统中某些较为重要的应用可以添加到应用白名单中，这样，应用不会被杀掉，进而不会影响用户体验。
可选的，在图7对应的实施例的基础上，方法还可以包括：若电子设备提升CPU资源空闲率时，还需要提升内存空闲率，则电子设备先提升内存空闲率。
本申请实施例中，提升CPU资源空闲率可以理解为CPU查杀，提升内存空闲率可以理解为内存查杀。具体CPU查杀和内存查杀的耦合实现方式可以参照上述图6对应的实施例中的相关描述，不再赘述。
对内存查杀和CPU查杀安排优先级，可以使得相同的进程或系统资源不会被多次查杀，避免查杀流程变得冗余，且这样可以减少电子设备在运行时出现异常的概率。
可选的，在图7对应的实施例的基础上，电子设备提升内存空闲率之后，还可以包括：电子设备更新CPU资源空闲率；若第三值大于更新后的CPU资源空闲率，电子设备继续提升CPU资源空闲率。
本申请实施例中，若第三值大于更新后的CPU资源空闲率，说明电子设备提升内存空闲率之后，CPU仍然处于高负载状态，可以进行CPU查杀。具体电子设备进行CPU查杀的流程可以参照上述图6对应的实施例中步骤S609至步骤S611的相关描述，不再赘述。
若提升内存空闲率之后，CPU不处于高负载状态，则可以不进行CPU查杀；若提升内存空闲率之后，CPU处于高负载状态，则可以进行CPU查杀；这样，可以灵活控制查杀模块对进程或服务的查杀，使得电子设备不会过度查杀进程或服务，从而减少对用户的影响。
可选的，在图7对应的实施例的基础上，电子设备提升CPU资源空闲率之后，还可以包括：若提升后的CPU资源空闲率与第三值的差值大于或等于第一预设阈值，则减小第一值和/或增大第二值；若提升后的CPU资源空闲率与第三值的差值小于第二预设阈值，则增大第一值和/或减小第二值。
本申请实施例中，提升后的CPU资源空闲率与第三值的差值可以理解为上述图3对应的实施例中的回收的CPU资源占比与需要的CPU资源占比的差值；第一预设阈值可以理解为第一阈值；第二预设阈值可以理解为第二阈值；不再赘述。
电子设备中的CPU状态预留机制可以执行调整第一值和/或第二值的流程。这样，CPU状态预留机制可以根据CPU查杀后回收的CPU资源情况，更为准确的计算出需要的CPU资源。
可选的，在图7对应的实施例的基础上，方法还可以包括：响应于用户在第二应用的第一界面内滑动的操作，电子设备查询第一预设文件，得到第五值和第六值，其中，第五值为电子设备显示第一界面滑动后的界面需要的CPU资源利用率，第六值为电子设备退出显示第一界面滑动前的界面时的CPU资源回收率；电子设备基于第五值和第六值得到第七值，第七值为电子设备在第一界面内滑动时需要的CPU资源利用率；若第七值大于CPU资源空闲率，电子设备提升CPU资源空闲率。
本申请实施例中，在第二应用的第一界面内滑动的场景可以理解为应用内滑动的场景。可以理解的是，应用内滑动前后，所需要的CPU资源占比可以不同。
第五值可以理解为第二应用处于应用内滑动场景时，CPU预留资源表cpu_pre.xml中第一界面滑动后的界面需要的预留资源占比，第六值可以理解为第二应用处于应用内滑动场景时，CPU预留资源表cpu_pre.xml中退出显示第一界面滑动前的界面的回落资源占比。
第七值可以为第五值和第六值的差值，也可以为第五值和第六值的差值的倍数，还可以为第五值和第六值的差值的其他计算方式，本申请实施例不作限定。
第七值大于CPU资源空闲率可以理解为电子设备当前的CPU剩余资源不够充足；电子设备提升CPU资源空闲率可以包括电子设备执行CPU查杀。
响应于用户的触发操作，电子设备可以在应用界面滑动之前，提前预留出所需要的CPU资源，这样可以使得应用界面滑动时需要的CPU资源较为充足，从而减少电子设备的卡顿。
可选的，在图7对应的实施例的基础上，方法还可以包括：响应于用户从第一界面进入到第二应用的第二界面的操作，电子设备查询第一预设文件，得到第八值和第九值，其中，第八值为电子设备显示第二界面需要的CPU资源利用率，第九值为电子设备退出显示第一界面时的CPU资源回收率；电子设备基于第八值和第九值得到第十值，第十值为电子设备从第一界面进入到第二界面时需要的CPU资源利用率；若第十值大于CPU资源空闲率，电子设备提升CPU资源空闲率。
本申请实施例中，从第一界面进入到第二应用的第二界面的场景可以理解为应用内转场的场景。可以理解的是，应用内转场前后，所需要的CPU资源占比可以不同。
第八值可以理解为第二应用处于应用内转场场景时，CPU预留资源表cpu_pre.xml中显示第二界面需要的预留资源占比，第九值可以理解为第二应用处于应用内转场场景时，CPU预留资源表cpu_pre.xml中退出显示第一界面时的回落资源占比。
第十值可以为第八值和第九值的差值，也可以为第八值和第九值的差值的倍数，还可以为第八值和第九值的差值的其他计算方式，本申请实施例不作限定。
第十值大于CPU资源空闲率可以理解为电子设备当前的CPU剩余资源不够充足；电子设备提升CPU资源空闲率可以包括电子设备执行CPU查杀。
响应于用户的触发操作，电子设备可以在应用界面跳转之前，提前预留出所需要的CPU资源，这样可以使得应用界面跳转时所需要的CPU资源较为充足，从而减少电子设备的卡顿。
需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。
上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的方法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对实现该方法的装置进行功能模块的划分，例如可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
如图8示为本申请实施例提供的一种芯片的结构示意图。芯片800包括一个或两个以上(包括两个)处理器801、通信线路802、通信接口803和存储器804。
在一些实施方式中，存储器804存储了如下的元素：可执行模块或者数据结构，或者他们的子集，或者他们的扩展集。
上述本申请实施例描述的方法可以应用于处理器801中，或者由处理器801实现。处理器801可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器801中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器801可以是通用处理器(例如，微处理器或常规处理器)、数字信号处理器(digitalsignal processing，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field-programmable gate array，FPGA)或者其他可编程逻辑器件、分立门、晶体管逻辑器件或分立硬件组件，处理器801可以实现或者执行本申请实施例中的公开的各处理相关的方法、步骤及逻辑框图。
结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。其中，软件模块可以位于随机存储器、只读存储器、可编程只读存储器或带电可擦写可编程存储器(electricallyerasable programmable read only memory，EEPROM)等本领域成熟的存储介质中。该存储介质位于存储器804，处理器801读取存储器804中的信息，结合其硬件完成上述方法的步骤。
处理器801、存储器804以及通信接口803之间可以通过通信线路802进行通信。
在上述实施例中，存储器存储的供处理器执行的指令可以采用计算机程序产品的形式实现。其中，计算机程序产品可以是事先写入在存储器中，也可以是以软件形式下载并安装在存储器中。
本申请实施例还提供一种计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，计算机指令可以从一个网站的站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL)或无线(例如红外、无线、微波等)方式向另一个网站的站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。例如，可用介质可以包括磁性介质(例如，软盘、硬盘或磁带)、光介质(例如，数字通用光盘(digital versatiledisc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
本申请实施例还提供一种计算机可读存储介质。上述实施例中描述的方法可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。计算机可读介质可以包括计算机存储介质和通信介质，还可以包括任何可以将计算机程序从一个地方传送到另一个地方的介质。存储介质可以是可由计算机访问的任何目标介质。
作为一种可能的设计，计算机可读介质可以包括紧凑型光盘只读储存器(compactdisc read-only memory，CD-ROM)、RAM、ROM、EEPROM或其它光盘存储器；计算机可读介质可以包括磁盘存储器或其它磁盘存储设备。而且，任何连接线也可以被适当地称为计算机可读介质。例如，如果使用同轴电缆，光纤电缆，双绞线，DSL或无线技术(如红外，无线电和微波)从网站，服务器或其它远程源传输软件，则同轴电缆，光纤电缆，双绞线，DSL或诸如红外，无线电和微波之类的无线技术包括在介质的定义中。如本文所使用的磁盘和光盘包括光盘(CD)，激光盘，光盘，数字通用光盘(digital versatiledisc，DVD)，软盘和蓝光盘，其中磁盘通常以磁性方式再现数据，而光盘利用激光光学地再现数据。
本申请实施例是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理单元以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理单元执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

Claims (15)

1.一种CPU资源管理方法，其特征在于，所述方法包括：
电子设备显示第一应用的界面；
响应于用户从所述第一应用的界面进入第二应用的界面的操作，所述电子设备查询第一预设文件，得到第一值和第二值，其中，所述第一值为所述电子设备显示所述第二应用的界面需要的CPU资源利用率，所述第二值为所述第一应用退到后台时的CPU资源回收率；
所述电子设备基于所述第一值和所述第二值得到第三值，所述第三值为所述电子设备从所述第一应用的界面进入所述第二应用的界面时需要的CPU资源利用率；
若所述第三值大于CPU资源空闲率，所述电子设备提升所述CPU资源空闲率。
2.根据权利要求1所述的方法，其特征在于，所述电子设备的CPU包括n个内核，n为大于或等于1的整数，
所述第一值与下述值成正比：所述电子设备显示所述第二应用的界面时占用所述n个内核的时间，以及所述n个内核的权重；
所述第二值与所述第一应用的界面在前台显示时占用所述n个内核的时间成正比，与所述第一应用在后台运行时占用所述n个内核的时间成反比。
3.根据权利要求1或2所述的方法，其特征在于，所述第一值满足下述公式：
其中，sourcerate为所述第一值，m为预设时间段，n为CPU的内核个数，coreNi,j,time为所述电子设备显示所述第二应用的界面时占用第j个内核的时间，coreNi,j,weight为所述第j个内核的权重；
所述第二值满足下述公式：
其中，subsiderate为所述第二值，coreNi,j,fg为所述第一应用的界面在前台显示时占用第j个内核的时间，coreNi,j,bg为所述第一应用在后台运行时占用第j个内核的时间。
4.根据权利要求1-3任一项所述的方法，其特征在于，所述第三值为所述第一值和所述第二值的差值。
5.根据权利要求1-4任一项所述的方法，其特征在于，所述电子设备提升所述CPU资源空闲率，包括：
所述电子设备基于所述第三值和所述CPU资源空闲率的差值得到第四值，所述电子设备在第二预设文件中查询所述第四值所对应的提升所述CPU资源空闲率的策略；
所述电子设备执行所述第四值所对应的提升所述CPU资源空闲率的策略。
6.根据权利要求5所述的方法，其特征在于，所述第二预设文件中包括多个区间，
若所述第四值在第一区间，所述第四值所对应的提升所述CPU资源空闲率的策略包括所述电子设备清理下述的一项或多项：前台应用的进程、用户可见应用的进程、用户可感知后台应用的进程、备份任务的进程、不具有恢复能力的后台进程、运行时长未超过第二预设时间段的服务、所述第一应用启动之前所述电子设备中前台运行的应用的进程、运行时长超过第三预设时间段，且在所述第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；
若所述第四值在第二区间，所述第四值所对应的提升所述CPU资源空闲率的策略包括所述电子设备清理下述的一项或多项：不具有恢复能力的后台进程、运行时长未超过所述第二预设时间段的服务、所述第一应用启动之前所述电子设备中前台运行的应用的进程、运行时长超过所述第三预设时间段，且在所述第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；
若所述第四值在第三区间，所述第四值所对应的提升所述CPU资源空闲率的策略包括所述电子设备清理下述的一项或多项：运行时长超过所述第三预设时间段，且在所述第三预设时间段内的部分时间段未被使用的服务、缓存的后台应用的进程、空进程；
若所述第四值在第四区间，所述第四值所对应的提升所述CPU资源空闲率的策略包括所述电子设备清理下述的一项或多项：缓存的后台应用的进程、空进程；
若所述第四值在第五区间，所述第四值所对应的提升所述CPU资源空闲率的策略包括：所述电子设备清理空进程；
其中，所述第一区间中的值大于所述第二区间中的值，所述第二区间中的值大于所述第三区间中的值，所述第三区间中的值大于所述第四区间中的值，所述第四区间中的值大于所述第五区间中的值。
7.根据权利要求5或6所述的方法，其特征在于，
在所述电子设备执行所述第四值所对应的提升所述CPU资源空闲率的策略时，若所述策略中包括不允许清理的应用或服务，则不清理所述不允许清理的应用或服务；
其中，所述不允许清理的应用或服务包括：预设应用名单中的应用或服务、和/或所述电子设备加载的应用中用户使用频率高于阈值的应用或服务、和/或所述电子设备加载的应用中用户使用频率排名前Q名的应用或服务。
8.根据权利要求1-7任一项所述的方法，其特征在于，所述方法还包括：
若所述电子设备提升所述CPU资源空闲率时，还需要提升内存空闲率，则所述电子设备先提升所述内存空闲率。
9.根据权利要求8所述的方法，其特征在于，所述电子设备提升内存空闲率之后，还包括：
所述电子设备更新所述CPU资源空闲率；
若所述第三值大于更新后的所述CPU资源空闲率，所述电子设备继续提升所述CPU资源空闲率。
10.根据权利要求1-9任一项所述的方法，其特征在于，所述电子设备提升所述CPU资源空闲率之后，还包括：
若提升后的所述CPU资源空闲率与所述第三值的差值大于或等于第一预设阈值，则减小所述第一值和/或增大所述第二值；
若提升后的所述CPU资源空闲率与所述第三值的差值小于第二预设阈值，则增大所述第一值和/或减小所述第二值。
11.根据权利要求1-10任一项所述的方法，其特征在于，所述方法还包括：
响应于用户在所述第二应用的第一界面内滑动的操作，所述电子设备查询所述第一预设文件，得到第五值和第六值，其中，所述第五值为所述电子设备显示所述第一界面滑动后的界面需要的CPU资源利用率，所述第六值为所述电子设备退出显示所述第一界面滑动前的界面时的CPU资源回收率；
所述电子设备基于所述第五值和所述第六值得到第七值，所述第七值为所述电子设备在所述第一界面内滑动时需要的CPU资源利用率；
若所述第七值大于所述CPU资源空闲率，所述电子设备提升所述CPU资源空闲率。
12.根据权利要求11所述的方法，其特征在于，所述方法还包括：
响应于用户从所述第一界面进入到所述第二应用的第二界面的操作，所述电子设备查询所述第一预设文件，得到第八值和第九值，其中，所述第八值为所述电子设备显示所述第二界面需要的CPU资源利用率，所述第九值为所述电子设备退出显示所述第一界面时的CPU资源回收率；
所述电子设备基于所述第八值和所述第九值得到第十值，所述第十值为所述电子设备从所述第一界面进入到所述第二界面时需要的CPU资源利用率；
若所述第十值大于所述CPU资源空闲率，所述电子设备提升所述CPU资源空闲率。
13.一种电子设备，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机程序，所述处理器用于执行所述计算机程序，以执行如权利要求1-12任一项所述的方法。
14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有指令，当所述指令被执行时，使得计算机执行如权利要求1-12任一项所述的方法。
15.一种计算机程序产品，其特征在于，包括计算机程序，当所述计算机程序被运行时，使得电子设备执行如权利要求1-12任一项所述的方法。
CN202311194767.8A 2023-09-14 2023-09-14 Cpu资源管理方法及相关装置 Pending CN117349006A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311194767.8A CN117349006A (zh) 2023-09-14 2023-09-14 Cpu资源管理方法及相关装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311194767.8A CN117349006A (zh) 2023-09-14 2023-09-14 Cpu资源管理方法及相关装置

Publications (1)

Publication Number Publication Date
CN117349006A true CN117349006A (zh) 2024-01-05

Family

ID=89370119

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311194767.8A Pending CN117349006A (zh) 2023-09-14 2023-09-14 Cpu资源管理方法及相关装置

Country Status (1)

Country Link
CN (1) CN117349006A (zh)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080229127A1 (en) * 2007-03-15 2008-09-18 Felter Wesley M Method and System for Estimating Processor Utilization from Power Measurements
CN110018903A (zh) * 2018-01-10 2019-07-16 广东欧珀移动通信有限公司 资源管理方法、装置、移动终端及计算机可读存储介质
CN110045908A (zh) * 2019-03-18 2019-07-23 华为技术有限公司 一种控制方法和电子设备
WO2022127632A1 (zh) * 2020-12-14 2022-06-23 华为技术有限公司 一种资源管控方法及设备
CN116048648A (zh) * 2022-07-28 2023-05-02 荣耀终端有限公司 应用预加载方法、应用的启动方法及电子设备
CN116089096A (zh) * 2023-04-09 2023-05-09 荣耀终端有限公司 负载资源调度方法及电子设备
CN116126744A (zh) * 2023-04-04 2023-05-16 荣耀终端有限公司 一种内存回收方法、装置及终端设备
CN116700816A (zh) * 2022-10-31 2023-09-05 荣耀终端有限公司 一种资源管理方法及电子设备
CN116700915A (zh) * 2022-12-23 2023-09-05 荣耀终端有限公司 资源调度方法和装置

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080229127A1 (en) * 2007-03-15 2008-09-18 Felter Wesley M Method and System for Estimating Processor Utilization from Power Measurements
CN110018903A (zh) * 2018-01-10 2019-07-16 广东欧珀移动通信有限公司 资源管理方法、装置、移动终端及计算机可读存储介质
CN110045908A (zh) * 2019-03-18 2019-07-23 华为技术有限公司 一种控制方法和电子设备
WO2022127632A1 (zh) * 2020-12-14 2022-06-23 华为技术有限公司 一种资源管控方法及设备
CN116048648A (zh) * 2022-07-28 2023-05-02 荣耀终端有限公司 应用预加载方法、应用的启动方法及电子设备
CN116700816A (zh) * 2022-10-31 2023-09-05 荣耀终端有限公司 一种资源管理方法及电子设备
CN116700915A (zh) * 2022-12-23 2023-09-05 荣耀终端有限公司 资源调度方法和装置
CN116126744A (zh) * 2023-04-04 2023-05-16 荣耀终端有限公司 一种内存回收方法、装置及终端设备
CN116089096A (zh) * 2023-04-09 2023-05-09 荣耀终端有限公司 负载资源调度方法及电子设备

Similar Documents

Publication Publication Date Title
KR20190046995A (ko) 메모리 반환 방법 및 장치
CN105843650A (zh) 一种智能终端中的应用程序管理方法和装置
CN106201740A (zh) 一种广播消息管理方法、装置及设备
CN107483521A (zh) 一种信息展示方法、装置及系统
CN116680153B (zh) 应用帧率平滑方法、电子设备及存储介质
CN114546511A (zh) 插件管理方法、系统及装置
CN107870809B (zh) 应用关闭方法、装置、存储介质及电子设备
CN107670276B (zh) 游戏应用控制方法及设备
CN116700816B (zh) 一种资源管理方法及电子设备
CN117349006A (zh) Cpu资源管理方法及相关装置
CN116128571A (zh) 广告曝光量分析方法及相关装置
CN117632460A (zh) 一种负载调节方法及终端设备
CN117724937B (zh) 日志资源管理方法及相关装置
CN112732542A (zh) 信息处理方法、信息处理装置及终端设备
CN116661584B (zh) 一种资源调度方法及相关设备
CN115061702B (zh) 一种ide管理方法及电子设备
CN116028208B (zh) 系统负载确定方法、装置、设备和存储介质
CN118467146A (zh) 卡顿处理方法及相关装置
CN115016921B (zh) 资源调度方法、装置及存储介质
CN116737405B (zh) 一种快应用卡片的数据通信的方法及相关设备
CN117131497B (zh) 一种软件检测方法及电子设备
CN115291995B (zh) 一种消息显示方法及相关电子设备、可读存储介质
CN117707718A (zh) 进程管理的方法、电子设备及可读存储介质
WO2024159994A1 (zh) 一种搜索事件脉络显示方法、生成方法及电子设备
CN117149362A (zh) 进程管控方法及相关装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination