CN111831434A - 资源分配方法、装置、存储介质及电子设备 - Google Patents

Abstract

本申请实施例公开了一种资源分配方法、装置、存储介质及电子设备，其中，本申请实施例当接收到线程发送的资源分配请求时，判断线程是否为第一类线程；当线程为第一类线程时，将线程添加至第一处理单元的任务队列，以基于第一处理单元执行线程对应的任务；当线程不为第一类线程时，将线程添加至第二处理单元的任务队列中。本方案通过为执行用户交互事件中相关任务的线程设置独立的处理单元，其他的线程在运行时不会抢占这些线程的资源，同时，当这种类型的线程请求处理器资源时，可以快速、及时地被分配到资源，进而使得该类型的线程得到及时的运行，提高了交互场景下相关线程的执行的流畅度，避免出现系统卡顿。

Description

资源分配方法、装置、存储介质及电子设备

技术领域

本申请涉及电子设备技术领域，具体涉及一种资源分配方法、装置、存储介质及电子设备。

背景技术

随着技术的发展，电子设备中安装的各类应用程序越来越多，例如视频类应用、游戏类应用以及即时通讯类应用等。这使得电子设备经常需要在前台和后台运行很多个应用程序，容易在用户交互场景中出现卡顿现象。

发明内容

本申请实施例提供一种资源分配方法、装置、存储介质及电子设备，能够减少系统卡顿的产生。

第一方面，本申请实施例提供一种资源分配方法，包括：

当接收到线程发送的资源分配请求时，判断所述线程是否为第一类线程，其中，第一类线程为执行用户交互事件中相关任务的线程；

当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，以基于所述第一处理单元执行所述线程对应的任务，其中，将处理器的多个处理单元划分为第一处理单元和第二处理单元；

当所述线程不为第一类线程时，将所述线程添加至第二处理单元的任务队列中。

第二方面，本申请实施例还提供一种资源分配装置，包括：

线程识别模块，用于当接收到线程发送的资源分配请求时，判断所述线程是否为第一类线程，其中，第一类线程为执行用户交互事件中相关任务的线程；

第一分配模块，用于当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，以基于所述第一处理单元执行所述线程对应的任务，其中，将处理器的多个处理单元划分为第一处理单元和第二处理单元；

第二分配模块，用于当所述线程不为第一类线程时，将所述线程添加至第二处理单元的任务队列中。

第三方面，本申请实施例还提供一种存储介质，其上存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如本申请任一实施例提供的资源分配方法。

第四方面，本申请实施例还提供一种电子设备，包括处理器和存储器，所述存储器有计算机程序，所述处理器通过调用所述计算机程序，用于执行如本申请任一实施例提供的资源分配方法。

本申请实施例提供的技术方案，将处理器的多个处理单元划分为第一处理单元和第二处理单元，在为线程分配处理单元时，先判断该线程是否为第一类线程，其中，执行用户交互事件中相关任务的线程为第一类线程，如果是，则将该线程添加至第一处理单元的任务队列，反之，则将该线程添加至第二处理单元的任务队列。由于执行用户交互事件中相关任务的线程是否能够即使得到资源执行对应任务，会影响到交互场景下是否会产生卡顿，本方案通过为执行用户交互事件中相关任务的线程设置独立的处理单元，其他的线程在运行时不会抢占这些线程的资源，同时，当这种类型的线程请求处理器资源时，可以快速、及时地被分配到资源，进而使得该类型的线程得到及时的运行，提高了交互场景下相关线程的执行的流畅度，避免出现系统卡顿。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的资源分配方法的第一种流程示意图。

图2为本申请实施例提供的资源分配方法的处理单元分配方式示意图。

图3为本申请实施例提供的资源分配装置的结构示意图。

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

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

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本申请的保护范围。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本申请实施例提供一种资源分配方法，该资源分配方法的执行主体可以是本申请实施例提供的资源分配装置，或者集成了该资源分配装置的电子设备，其中该资源分配装置可以采用硬件或者软件的方式实现。其中，电子设备可以是智能手机、平板电脑、掌上电脑、笔记本电脑、或者台式电脑等设备。

请参阅图1，图1为本申请实施例提供的资源分配方法的第一种流程示意图。本申请实施例提供的资源分配方法的具体流程可以如下：

在101中，当接收到线程发送的资源分配请求时，判断所述线程是否为第一类线程，其中，第一类线程为执行用户交互事件中相关任务的线程。

本申请实施例中，电子设备的操作系统可以是基于linux内核的系统，例如，安卓操作系统等。电子设备上运行着系统进程和应用程序的进程，线程是进程的一条执行路径，是程序执行时的最小单位。一个进程可以有多个线程，但至少有一个线程。

如果电子设备的处理器是多核心处理器，则每一个处理器核心可以当作一个独立的处理单元。比如，如果电子设备为八核处理器，则每一个核心为一个独立的处理单元。每个处理单元有各自对应的任务队列，该任务队列中包含分配给该处理单元的任务，每一个任务由对应的线程去执行。

电子设备中可能有一个或者多个程序在同时运行，每个程序至少有一个对应的进程，而一个进程又有至少一个线程在执行任务。因此，电子设备会有多个线程需要执行，需要为这些线程的执行分配CPU资源。

电子设备会按照一定的调度规则，所有运行在处理器核心上的线程都会接收系统的整体调度。例如，在一般的ARM(Advanced RISC Machine，进阶精简指令集机器)架构的电子设备中，CPU的核心都是以组的形式进行调度，所有运行在CPU组内的CPU核心上的线程都会接受系统的整体调度。在ARM标准的架构中，CPU核心的算力是存在差异的，一般会将算力较强的核心称为大核，算力较弱的核心称为小核。比如，对于八核心处理器来说，一般具有四个大核，四个小核。需要说明的是，上述核心数量仅为举例说明，本申请实施例对于处理器的核心数量并不做具体限制，当至少有两个核心时，都可以使用本申请实施例的方案。

以具备多核心处理器的智能手机为例，在用户的日常使用过程中，全部CPU满载运行的情况非常少，很多情况下，都只有部分CPU核心在运行。但是，在CPU整体负载很高的情况下，每一处理器核心上都有较多的线程等待运行，这种情况下，即使多个处理器核心满载运行，也有可能出现交互场景下的核心线程，例如执行界面绘制、界面渲染等界面处理任务的线程，竞争不过其他的线程，而被分配至小核心处理器运行。由于执行用户交互事件中相关任务的线程与用户体验直接相关，这些线程是否能够及时得到资源执行对应任务，会影响到交互场景下是否会产生系统卡顿，即如果交互场景下的核心线程得不到及时运行，就会产生用户可感知的卡顿，影响用户体验。

对于内核来说，在进行资源调度时，比如CPU调度，都是具体到某个线程的。进程内有一个主线程，它也会创建出很多子线程来协助工作。比如一个内容交互应用程序的进程，它会创建一个主线程来执行代码，执行途中也会创建其它子线程来协助运行各部分的任务代码。

本申请实施例中，从线程的运行情况是否会影响到用户体验的角度出发，将那些直接或者间接地影响到用户体验的线程标记出来。

执行用户交互事件中相关任务的线程是否能够流畅运行决定着是否会在用户交互事件中产生用户可感知的卡顿，故本申请实施例中，确定出执行用户交互事件中相关任务的线程，并将这些与用户体验紧密相关的线程记为ux(user experience，用户体验)线程，即第一类线程。本申请实施例中，将除ux线程之外的线程记为第二类线程。第二类线程的运行情况一般不会影响用户体验，或者对用户体验影响较小。这里的影响用户体验是指：在用户交互场景下，如果这些线程因为不能及时的分配到系统资源而长时间的处于等待资源分配的状态，会导致响应速度慢，使用户感知到系统卡顿，例如，界面切换卡顿、界面绘制速度慢、界面动画显示延迟等等。

为了改善上述系统卡顿的现象，本申请实施例从多个处理器核心中独立出来一个处理器核心，该处理器核心只运行ux线程，而那些非ux线程则运行在除了该独立的处理器核心之外的其他处理器核心上，不会抢占ux线程的资源，以使ux线程能够快速、及时的运行。

并且，低负载的场景下，将一个处理器核心关闭，不仅不会影响到电子设备的运行，还可以节省功耗。而在高负载的场景下，ux线程一般占比较高，把预留的处理器核心专门用于ux线程的运行，可以改善交互场景的手机卡顿，提升用户体验。

例如，在一实施例中，该方法还包括：

当检测到系统启动时，获取处理器信息；

根据所述处理器信息从所述处理器的多个处理单元中确定出第一处理单元，并将所述第一处理单元关闭；

将除所述第一处理单元之外的其他处理单元作为第二处理单元，其中，所述第一处理单元的频率大于或等于所述第二处理单元的频率。

当电子设备启动后，系统先读取处理器信息，例如CPU的拓扑结构信息，以确定CPU包含的核心数量，以及各个处理器核心的算力，以从多核处理器核心中确定一个处理器核心并将其独立出来，例如，将一个大核独立出其所属CPU组的调度策略，不参与日常CPU运算，并将其关闭。其中，由于一个处理核心为一个处理单元，因此，将独立出来的处理器核心记为第一处理单元，将除了第一处理单元之外的其他处理单元作为第二处理单元。其中，第二处理单元仍然按照其原本所属CPU组的调度策略进行调度。

本申请实施例中，电子设备的系统架构至少包括应用框架(framework)层和内核(kernel)层，本申请实施例，从应用框架层和内核层的角度对ux线程进行识别和标记，例如，应用框架层为一些直接执行用户交互事件中相关任务的线程添加第一预设标签，以将这些线程标记为静态ux线程，内核层将一些间接地影响到用户交互事件中相关任务执行的线程标记为动态ux线程。

本申请实施例中的进程包括系统级进程和应用级进程。由于产生用户可感知的界面的卡顿的场景多是相对于运行在前台的进程来说的。因此，本申请实施例的方案中，“确定出执行用户交互事件中相关任务的线程”包括：在检测到有进程切换到前台运行时，确定前台进程；从该前台进程的线程中确定出用于执行用户交互事件中相关任务的线程，作为目标线程。

例如，在一实施例中，“从前台进程的线程中确定出用于执行用户交互事件中相关任务的目标线程，并将目标线程标记为第一类线程”包括：从前台进程的线程中识别出用于执行用户交互事件中相关任务的第一预设线程，作为目标线程；为目标线程添加第一预设标签，以将线程标记为第一类线程。

例如，上述第一预设线程包括进程运行时创建的一些用于直接执行用户交互事件的相关任务的线程，如UI(user interface，用户界面)线程，Render(渲染)线程，GL线程，用户输入事件的分发线程，用户输入事件的检测线程等，其中，GL线程为OGL(Open GraphicsLibrary，开放图形库)的渲染线程。这些线程是否能够流畅运行决定着是否会在用户与该进程的交互界面中产生用户可感知的卡顿。

比如，用户使用聊天软件与某一好友聊天，用户在对话框输入文字，电子设备通过服务器将用户输入的文字发送至该好友的电子设备。在这次交互事件中，需要UI线程、Render线程、用户输入事件的分发线程、用户输入事件的检测线程等线程共同工作，以完成本次用户交互事件，其中，每一个线程的运行都需要系统为其分配资源。因此，在检测到该聊天软件在前台运行时，识别出这些线程，将其标记为ux线程。

其中，第一预设线程一般是应用级线程，这些线程可以是通过对实际的卡顿场景进行分析来确定。比如，在测试中，如果某一用户交互场景下发生了应用卡顿，通过对该场景分析发现卡顿现象是某个线程处理任务太慢导致的，则可以认为该线程是用于执行用户交互事件中相关任务的，该线程的运行与用户体验紧密相关，可以将该线程作为第一预设线程。

基于此，可以通过对各种可能的卡顿场景进行测试，记录这些导致卡顿出现的线程。电子设备中存储这些第一预设线程的相关信息，当进程切换到前台运行时，将该进程下的属于预先记录的第一预设线程的线程都标记为ux线程。

可以理解的是，对于电子设备来说，存储的第一预设线程的相关信息并不是不可修改的，当进行系统升级时，可以对第一预设线程的相关信息进行更新。

此外，在另一实施例中，该方法还包括：当检测到有第二预设线程创建时，将创建的第二预设线程标记为第一类线程，其中，第二预设线程为系统级线程。

由于在执行用户交互事件的过程中，除了应用级线程之外，可能还涉及到一些系统级的线程来完成任务，系统框架层也需要将这些系统级线程标记为ux线程。一般这些线程在系统启动时就会创建，因此，可以在检测到系统启动时，识别出这些线程并进行标记，比如，Surfaceflinger线程(图层合成线程)、系统动画线程等。或者，在系统运行过程中，如果检测到有新的系统进程的线程创建并用来执行用户交互事件中相关任务，系统框架层也将这些线程标记为ux线程。比如，SystemUI(系统界面)线程。其中，第二预设线程也可以通过对实际的卡顿场景进行分析来确定。比如，在测试中，如果某一用户交互场景下发生了应用卡顿，通过对该场景分析发现卡顿现象是某个系统级线程处理任务太慢导致的，则可以认为该系统级线程是用于执行用户交互事件中相关任务的，该系统级线程的运行与用户体验紧密相关，可以将该系统级线程作为第二预设线程。电子设备中存储这些第二预设线程的相关信息，如果检测到系统创建了这些线程，则将其标记为ux线程。

其中，第一预设标签可以为ux标签，其添加方式如下：Linux使用task_struct结构体描述和记录线程，每个线程都有对应的task_struct结构体。task_struct中记录了线程的名称、标识符、状态、优先级、内存指针、上下文数据等属性信息。因此，应用框架层可以在task_struct结构体中增加对应的ux flag成员，以将前台进程的UI线程、Render线程、GL线程等执行用户交互事件中相关任务的线程，通过标记ux flag位(ux标志位)，使内核层能够识别该线程的任务属性。

需要说明的是，上述几种静态ux线程仅为举例说明，并不局限于此，只要是直接地执行用户交互事件中相关任务的线程，使得其运行情况直接地影响到用户体验的线程，都可以将其标记为静态ux线程。对于应用框架层来说，在检测到新创建的线程是用来执行用户交互事件，或者检测到某些常驻系统级线程是用以处理用户交互事件时，为这些线程添加ux标签，以将其标记为静态ux线程。

在另一实施例中，“从前台进程的线程中确定出用于执行用户交互事件中相关任务的目标线程，并将目标线程标记为第一类线程”还包括：在前台进程的运行过程中，当检测到有新线程创建时，确定新创建的线程是否用于执行用户交互事件中的相关任务；当新创建的线程用于执行用户交互事件中的相关任务时，将新创建的线程标记为第一类线程。

前台进程在运行过程中，如果有用户交互事件发生，除了上述应用级的第一预设线程和系统级的第二预设线程之外，还可能会有一些临时创建的任务线程，这些任务线程的运行也会直接影响到是否会在用户与该进程的交互界面中产生用户可感知的卡顿。因此，应用框架层会将这些线程也标记为ux线程。

其中，电子设备根据检测到的用户指令确定发生的用户交互事件。用户交互事件一般是指用户触发了某指令后，电子设备需要即时的对该指令进行响应，进行某种处理并将处理结果显示在界面上的情况。例如，用户使用电子设备观看视频、编辑短信、使用聊天软件、使用游戏软件、控制电子设备界面的切换、使用浏览浏览网页等，都属于用户交互事件。比如，用户使用聊天软件与某一好友聊天，用户在对话框输入文字，电子设备通过服务器将用户输入的文字发送至该好友的电子设备。在这个过程中，电子设备需要调度多个线程以完成本次用户交互事件，从该用户交互事件的开始到完成的整个过程中，进程创建的用来完成这次用户交互事件的线程都可以认为是与用户体验相关的线程。

在另一实施例中，为目标线程添加第一预设标签之后，该方法还包括：若前台进程为应用进程，则在检测到前台进程切换至后台运行时，删除第一预设线程的第一预设标签。当前台进程切换到后台运行时，该进程的运行情况已经与用户体验无关，其线程的重要程度也有所下降，因此，可以将该进程对应的第一预设线程的ux标记删除，将这些ux线程恢复为普通线程。

此外，对于那些在用户交互事件中临时创建的任务线程来说，在执行完对应的任务后就会被销毁，其自然会丢失掉ux标签。而对于系统级的第二预设线程来说，即使发生了进程的前后台切换，这些线程始终与用户体验相关，所以始终保有ux标签。

通过上述实施例，框架层识别出那些直接影响到用户体验的线程并为其添加标记。而线程的运行，需要内核为之分配系统资源。因此，线程在执行任务前，会向内核请求资源。内核在基于该请求为其分配资源时，可以先判断该线程是否为ux线程，对于ux线程和非ux线程采用不同的资源分配方式。

需要说明的是，这里的第一类线程和第二类线程中的“第一类”和“第二类”，仅仅是为了区分线程是否具有ux标签，而不是说将系统中的线程只划分为这两种类别。本申请的资源分配优化方案是从线程是否具有ux标签这一角度出发的，如果线程同时还具有其他属性，则在资源分配时，考虑了是否具有ux标签这一属性后，仍然会考虑其他属性。

上述实施例介绍了静态ux线程的识别。还有一些线程虽然并没有直接地执行用户交互事件的相关任务，但是这些线程的运行情况也会影响到静态ux线程的运行情况，进而间接地影响到用户交互事件的相关任务的执行。也就是说，这些线程并不是总是与用户体验相关，但是这些线程在执行过程的某段时间内，可能通过资源约束与静态ux线程产生关联，因此，在一些实施例中，为了进一步地减少交互场景下的卡顿现象，内核层将这些与静态ux线程之间有约束关系的线程也标记为ux线程。而一旦这种约束关系结束，就会将该线程恢复至非ux线程。本申请实施例中将这类线程定义为动态ux线程。其中，具体的约束关系包括但不限于进程间通信、线程间通信或者持有临界资源等。比如，静态ux线程通过进程间通信请求的普通线程，静态ux线程通过某种线程间通信方式请求的普通线程，持有静态ux线程需要的等待信号量、读写信号量、互斥锁等临界资源的普通线程等，本申请实施例中将这类线程标记为动态ux线程。

基于此，在一些实施例中，该方法还包括：对第一类线程的运行状态进行检测；当检测到有第一类线程进入阻塞状态，则确定与进入阻塞状态的第一类线程之间有约束关系的关联线程；为关联线程添加第一预设标签，以将关联线程标记为第一类线程。

在一些实施例中，将关联线程标记为第一类线程之后，还包括：当检测到约束关系解除时，删除关联线程的第一预设标签。

其中，关于线程的阻塞状态，在内核层面一般会区分为D状态(Uninterruptablesleep状态，不可中断的睡眠状态)和S状态(interruptable sleep状态，可中断的睡眠状态)，比如，线程发起IO请求但得不到满足，就进入D状态；线程发起同步Binder(一种进程间通信机制)请求，就会进入S状态。线程进入这些状态一般都是因为这些都是线程任务执行途中因为某些原因或者逻辑，需要主动或者被动地放弃CPU资源。

该实施例中，内核层对静态ux线程的状态进行检测，当检测到ux线程进入到堵塞状态时，确定出与进入堵塞状态的ux线程之间具有约束关系的关联线程，如果这些关联线程没有及时分配到资源，比如IO资源，而导致运行受阻，则由于关联线程的运行缓慢又会导致该ux线程长时间处于阻塞状态，因此，为了避免该ux线程长时间处于阻塞状态，内核层会将识别出的关联线程也标记为ux线程，以提高其IO处理效率，保证其及时执行，进而快速解除该ux线程的阻塞状态。

上文中介绍了应用框架层和内核层识别并标记ux线程的方式。通过上述多个实施例中的任意一种或者多种识别出线程中那些影响到用户体验的线程，并将其标记为ux线程。

在102中，当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，以基于所述第一处理单元执行所述线程对应的任务，其中，将处理器的多个处理单元划分为第一处理单元和第二处理单元。

在103中，当所述线程不为第一类线程时，将所述线程添加至第二处理单元的任务队列中

系统在接收到线程发送的资源分配请求时，先判断该线程是否为ux线程，若内核判定该线程属于ux线程，则将该ux线程添加至第一处理单元的任务队列，以基于所述第一处理单元执行所述线程对应的任务。通过这种方式，该线程无需参与CPU整体调度，不用去和其他线程进行竞争，保证Ux线程能顺利运行在第一处理单元上。

其中，在一实施例中，第一处理单元独立出所属CPU组的调度策略，不参与日常CPU运算，但是也可以始终处于开启状态。只要有ux线程，都可以将ux线程运行在第一处理单元上。

或者，在另一实施例中，所述当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，包括：

当所述线程为第一类线程时，判断所述第一处理单元是否开启，其中，当系统负载大于第一预设负载时，开启所述第一处理单元；

当所述第一处理单元开启时，将所述线程添加至所述第一处理单元的任务队列。

该实施例中，只有在系统负载大于第一预设负载时，才会开启所述第一处理单元。其中，第一预设负载可以是一个经验值，当系统负载大于第一预设负载时，系统处于高负载状态。而在低负载时，即使将ux线程运行在第二处理单元上，按照第二处理单元所属CPU组的调度策略进行调度，ux线程仍然能够以较快的速度获取处理器资源。在102中，当系统检测到线程为第一类线程时，先判断所述第一处理单元是否开启，如果第一处理单元已开启，则将所述线程添加至所述第一处理单元的任务队列；如果第一处理单元未开启，则说明当前处于低负载状态，可以将所述线程添加至所述第二处理单元的任务队列。

此外，当所述线程不为第一类线程时，可以直接将线程添加至第二处理单元的任务队列中。

请参阅图2，图2为本申请实施例提供的资源分配方法的处理单元分配方式示意图。假设电子设备的处理器有四个核心，其中，CPU0、CPU1为小核，CPU2、CPU3为大核，即CPU2和CPU3的算力大于CPU0和CPU1的算力，或者，即CPU2和CPU3的频率大于CPU0和CPU1的频率，将其中一个大核CPU3作为预留给ux线程使用的独立核心。其中，ux1、ux2、ux3均为ux线程，分配到CPU3上运行，而task1至task9不是ux线程，则按照CPU调度策略将其分配到CPU0、CPU1或CPU2上运行。基于此，将ux线程放到指定CPU的大核上运行，无需参与CPU整体调度，不用去和其他线程进行竞争，保证ux线程能顺利运行在大核上，使其能顺利流畅地运行，避免出现系统卡顿，提升用户体验。

其中，在一实施例中，在第一处理单元开启后，继续对系统负载进行检测，当检测到系统负载小于第二预设负载时，关闭所述第一处理单元，其中，所述第二预设负载小于或等于所述第一预设负载；第二预设负载可以是一个经验值，当系统负载小于第二预设负载时，系统处于低负载状态。或者，在另一实施例中，当检测到所述第一处理单元的任务队列执行完毕时，关闭所述第一处理单元。

具体实施时，本申请不受所描述的各个步骤的执行顺序的限制，在不产生冲突的情况下，某些步骤还可以采用其它顺序进行或者同时进行。

由上可知，本申请实施例提供的资源分配方法，将处理器的多个处理单元划分为第一处理单元和第二处理单元，在为线程分配处理单元时，先判断该线程是否为第一类线程，其中，执行用户交互事件中相关任务的线程为第一类线程，如果是，则将该线程添加至第一处理单元的任务队列，反之，则将该线程添加至第二处理单元的任务队列。由于执行用户交互事件中相关任务的线程是否能够即使得到资源执行对应任务，会影响到交互场景下是否会产生卡顿，本方案通过为执行用户交互事件中相关任务的线程设置独立的处理单元，其他的线程在运行时不会抢占这些线程的资源，同时，当这种类型的线程请求处理器资源时，可以快速、及时地被分配到资源，进而使得该类型的线程得到及时的运行，提高了交互场景下相关线程的执行的流畅度，避免出现系统卡顿。

在一实施例中还提供一种资源分配装置。请参阅图3，图3为本申请实施例提供的资源分配装置300的结构示意图。其中该资源分配装置300应用于电子设备，该资源分配装置300包括线程识别模块301、第一分配模块302以及第二分配模块303，如下：

线程识别模块301，用于当接收到线程发送的资源分配请求时，判断所述线程是否为第一类线程，其中，第一类线程为执行用户交互事件中相关任务的线程；

第一分配模块302，用于当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，以基于所述第一处理单元执行所述线程对应的任务，其中，将处理器的多个处理单元划分为第一处理单元和第二处理单元；

第二分配模块303，用于当所述线程不为第一类线程时，将所述线程添加至第二处理单元的任务队列中。

在一些实施例中，第一分配模块302还用于：当所述线程为第一类线程时，判断所述第一处理单元是否开启，其中，当系统负载大于第一预设负载时，开启所述第一处理单元；

当所述第一处理单元开启时，将所述线程添加至所述第一处理单元的任务队列。

在一些实施例中，第二分配模块303还用于：当所述第一处理单元未开启时，将所述线程添加至所述第二处理单元的任务队列。

在一些实施例中，该资源分配装置300还包括处理器管理模块，该处理器管理模块用于：当检测到系统启动时，获取处理器信息；

根据所述处理器信息从所述处理器的多个处理单元中确定出第一处理单元，并将所述第一处理单元关闭；

将除所述第一处理单元之外的其他处理单元作为第二处理单元，其中，所述第一处理单元的频率大于或等于所述第二处理单元的频率。

在一些实施例中，处理器管理模块还用于：对系统负载进行检测，在检测到系统负载小于第二预设负载时，关闭所述第一处理单元，其中，所述第二预设负载小于或等于所述第一预设负载；

或者，当检测到所述第一处理单元的任务队列执行完毕时，关闭所述第一处理单元。

在一些实施例中，该资源分配装置300还包括线程标记模块，该线程标记模块用于：确定出用于执行交互事件中相关任务的目标线程，并将所述目标线程标记为第一类线程。

在一些实施例中，线程标记模块还用于：当检测到有进程切换至前台运行时，确定前台进程；

从所述前台进程的线程中确定出用于执行用户交互事件中相关任务的目标线程，并将所述目标线程标记为第一类线程。

应当说明的是，本申请实施例提供的资源分配装置与上文实施例中的资源分配方法属于同一构思，通过该资源分配装置可以实现资源分配方法实施例中提供的任一方法，其具体实现过程详见资源分配方法实施例，此处不再赘述。

由上可知，本申请实施例提出的资源分配装置，该资源分配装置300包括线程识别模块301、第一分配模块302以及第二分配模块303，其中，将处理器的多个处理单元划分为第一处理单元和第二处理单元，在为线程分配处理单元时，线程识别模块301先判断该线程是否为第一类线程，其中，执行用户交互事件中相关任务的线程为第一类线程，如果是，则第一分配模块302将该线程添加至第一处理单元的任务队列，反之，则第二分配模块303将该线程添加至第二处理单元的任务队列。由于执行用户交互事件中相关任务的线程是否能够即使得到资源执行对应任务，会影响到交互场景下是否会产生卡顿，本方案通过为执行用户交互事件中相关任务的线程设置独立的处理单元，其他的线程在运行时不会抢占这些线程的资源，同时，当这种类型的线程请求处理器资源时，可以快速、及时地被分配到资源，进而使得该类型的线程得到及时的运行，提高了交互场景下相关线程的执行的流畅度，避免出现系统卡顿。

本申请实施例还提供一种电子设备。所述电子设备可以是智能手机、平板电脑等设备。请参阅图4，图4为本申请实施例提供的电子设备的第一种结构示意图。电子设备400包括处理器401和存储器402。其中，处理器401与存储器402电性连接。

处理器401是电子设备400的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或调用存储在存储器402内的计算机程序，以及调用存储在存储器402内的数据，执行电子设备的各种功能和处理数据，从而对电子设备进行整体监控。

存储器402可用于存储计算机程序和数据。存储器402存储的计算机程序中包含有可在处理器中执行的指令。计算机程序可以组成各种功能模块。处理器401通过调用存储在存储器402的计算机程序，从而执行各种功能应用以及数据处理。

在本实施例中，电子设备400中的处理器401会按照如下的步骤，将一个或一个以上的计算机程序的进程对应的指令加载到存储器402中，并由处理器401来运行存储在存储器402中的计算机程序，从而实现各种功能：

当接收到线程发送的资源分配请求时，判断所述线程是否为第一类线程，其中，第一类线程为执行用户交互事件中相关任务的线程；

当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，以基于所述第一处理单元执行所述线程对应的任务，其中，将处理器的多个处理单元划分为第一处理单元和第二处理单元；

当所述线程不为第一类线程时，将所述线程添加至第二处理单元的任务队列中。

在一些实施例中，请参阅图5，图5为本申请实施例提供的电子设备的第二种结构示意图。电子设备400还包括：射频电路403、显示屏404、控制电路405、输入单元406、音频电路407、传感器408以及电源409。其中，处理器401分别与射频电路403、显示屏404、控制电路405、输入单元406、音频电路407、传感器408以及电源409电性连接。

射频电路403用于收发射频信号，以通过无线通信与网络设备或其他电子设备进行通信。

显示屏404可用于显示由用户输入的信息或提供给用户的信息以及电子设备的各种图形用户接口，这些图形用户接口可以由图像、文本、图标、视频和其任意组合来构成。

控制电路405与显示屏404电性连接，用于控制显示屏404显示信息。

输入单元406可用于接收输入的数字、字符信息或用户特征信息(例如指纹)，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。其中，输入单元406可以包括指纹识别模组。

音频电路407可通过扬声器、传声器提供用户与电子设备之间的音频接口。其中，音频电路407包括麦克风。所述麦克风与所述处理器401电性连接。所述麦克风用于接收用户输入的语音信息。

传感器408用于采集外部环境信息。传感器408可以包括环境亮度传感器、加速度传感器、陀螺仪等传感器中的一种或多种。

电源409用于给电子设备400的各个部件供电。在一些实施例中，电源409可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

虽然图中未示出，电子设备400还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本实施例中，电子设备400中的处理器401会按照如下的步骤，将一个或一个以上的计算机程序的进程对应的指令加载到存储器402中，并由处理器401来运行存储在存储器402中的计算机程序，从而实现各种功能：

当接收到线程发送的资源分配请求时，判断所述线程是否为第一类线程，其中，第一类线程为执行用户交互事件中相关任务的线程；

当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，以基于所述第一处理单元执行所述线程对应的任务，其中，将处理器的多个处理单元划分为第一处理单元和第二处理单元；

当所述线程不为第一类线程时，将所述线程添加至第二处理单元的任务队列中。

由上可知，本申请实施例提供了一种电子设备，所述电子设备将处理器的多个处理单元划分为第一处理单元和第二处理单元，在为线程分配处理单元时，先判断该线程是否为第一类线程，其中，执行用户交互事件中相关任务的线程为第一类线程，如果是，则将该线程添加至第一处理单元的任务队列，反之，则将该线程添加至第二处理单元的任务队列。由于执行用户交互事件中相关任务的线程是否能够即使得到资源执行对应任务，会影响到交互场景下是否会产生卡顿，本方案通过为执行用户交互事件中相关任务的线程设置独立的处理单元，其他的线程在运行时不会抢占这些线程的资源，同时，当这种类型的线程请求处理器资源时，可以快速、及时地被分配到资源，进而使得该类型的线程得到及时的运行，提高了交互场景下相关线程的执行的流畅度，避免出现系统卡顿。

本申请实施例还提供一种存储介质，所述存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，所述计算机执行上述任一实施例所述的资源分配方法。

需要说明的是，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过计算机程序来指令相关的硬件来完成，所述计算机程序可以存储于计算机可读存储介质中，所述存储介质可以包括但不限于：只读存储器(ROM，Read OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁盘或光盘等。

此外，本申请中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或模块的过程、方法、系统、产品或设备没有限定于已列出的步骤或模块，而是某些实施例还包括没有列出的步骤或模块，或某些实施例还包括对于这些过程、方法、产品或设备固有的其它步骤或模块。

以上对本申请实施例所提供的资源分配方法、装置、存储介质及电子设备进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种资源分配方法，其特征在于，包括：

当接收到线程发送的资源分配请求时，判断所述线程是否为第一类线程，其中，第一类线程为执行用户交互事件中相关任务的线程；

当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，以基于所述第一处理单元执行所述线程对应的任务，其中，将处理器的多个处理单元划分为第一处理单元和第二处理单元；

当所述线程不为第一类线程时，将所述线程添加至第二处理单元的任务队列中。

2.如权利要求1所述的资源分配方法，其特征在于，所述当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，包括：

当所述线程为第一类线程时，判断所述第一处理单元是否开启，其中，当系统负载大于第一预设负载时，开启所述第一处理单元；

当所述第一处理单元开启时，将所述线程添加至所述第一处理单元的任务队列。

3.如权利要求2所述的资源分配方法，其特征在于，所述判断第一处理单元是否开启之后，还包括：

当所述第一处理单元未开启时，将所述线程添加至所述第二处理单元的任务队列。

4.如权利要求1至3任一项所述的资源分配方法，其特征在于，还包括：

当检测到系统启动时，获取处理器信息；

根据所述处理器信息从所述处理器的多个处理单元中确定出第一处理单元，并将所述第一处理单元关闭；

将除所述第一处理单元之外的其他处理单元作为第二处理单元，其中，所述第一处理单元的频率大于或等于所述第二处理单元的频率。

5.如权利要求4所述的资源分配方法，其特征在于，所述当所述第一处理单元开启时，将所述线程添加至第一处理单元的任务队列之后，还包括：

对系统负载进行检测，在检测到系统负载小于第二预设负载时，关闭所述第一处理单元，其中，所述第二预设负载小于或等于所述第一预设负载；

或者，当检测到所述第一处理单元的任务队列执行完毕时，关闭所述第一处理单元。

6.如权利要求1所述的资源分配方法，其特征在于，所述方法还包括：

确定出用于执行交互事件中相关任务的目标线程，并将所述目标线程标记为第一类线程。

7.如权利要求6所述的资源分配方法，其特征在于，所述确定出用于执行用户交互事件中相关任务的目标线程，并将所述目标线程标记为第一类线程，包括：

当检测到有进程切换至前台运行时，确定前台进程；

从所述前台进程的线程中确定出用于执行用户交互事件中相关任务的目标线程，并将所述目标线程标记为第一类线程。

8.一种资源分配装置，其特征在于，包括：

线程识别模块，用于当接收到线程发送的资源分配请求时，判断所述线程是否为第一类线程，其中，第一类线程为执行用户交互事件中相关任务的线程；

第一分配模块，用于当所述线程为第一类线程时，将所述线程添加至第一处理单元的任务队列，以基于所述第一处理单元执行所述线程对应的任务，其中，将处理器的多个处理单元划分为第一处理单元和第二处理单元；

第二分配模块，用于当所述线程不为第一类线程时，将所述线程添加至第二处理单元的任务队列中。

9.一种存储介质，其上存储有计算机程序，其特征在于，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1至7任一项所述的资源分配方法。

10.一种电子设备，包括处理器和存储器，所述存储器存储有计算机程序，其特征在于，所述处理器通过调用所述计算机程序，用于执行如权利要求1至7任一项所述的资源分配方法。

Images