线程调度方法、装置、存储介质及电子设备与流程

文档序号:22626626发布日期:2020-10-23 19:35阅读:97来源:国知局
本申请涉及电子设备
技术领域
:,特别涉及一种线程调度方法、装置、存储介质及电子设备。
背景技术
::随着技术的发展,电子设备中安装的各类应用程序越来越多,例如视频类应用、游戏类应用以及即时通讯类应用等。这使得电子设备经常需要在前台和后台运行多个应用程序,容易在用户交互场景中出现卡顿现象。技术实现要素:本申请实施例提供一种线程调度方法、装置、存储介质及电子设备,可以减少交互场景下的卡顿现象。第一方面,本申请实施例提供一种线程调度方法,所述方法包括:按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表;检测所述目标任务链表中是否有第一类线程,所述第一类线程为执行用户交互事件中相关任务的线程;当所述目标任务链表中有所述第一类线程时,从所述目标任务链表中确定出等待时间最长的所述第一类线程,作为第一目标线程;基于所述目标处理器单元执行所述第一目标线程。第二方面,本申请实施例提供一种的线程调度装置,所述装置包括:获取模块,用于按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表;检测模块,用于检测所述目标任务链表中是否有第一类线程,所述第一类线程为执行用户交互事件中相关任务的线程;确定模块,用于当所述目标任务链表中有所述第一类线程时,从所述目标任务链表中确定出等待时间最长的所述第一类线程,作为第一目标线程;处理模块,用于基于所述目标处理器单元执行所述第一目标线程。第三方面,本申请实施例提供一种存储介质,其上存储有计算机程序,当所述计算机程序在计算机上执行时,使得所述计算机执行本申请实施例提供的方法。第四方面,本申请实施例还提供一种电子设备,包括存储器,处理器,所述处理器通过调用所述存储器中存储的计算机程序,用于执行本申请实施例提供的方法。本申请实施例中按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表;检测所述目标任务链表中是否有第一类线程,所述第一类线程为执行用户交互事件中相关任务的线程;当所述目标任务链表中有所述第一类线程时,从所述目标任务链表中确定出等待时间最长的第一类线程,作为目标线程;基于所述目标处理器单元执行所述目标线程。因此当目标处理器单元在选择将要执行的线程时,按照优先级由高至低的顺序,查找到线程数量不为零、且优先级最高的目标任务链表,如果目标任务链表上具有第一类线程,则目标处理器单元将优先处理第一类线程,使得执行用户交互事件相关任务的第一类线程能够及时执行,从而减少了用户交互场景下的卡顿现象,提升了用户体验。附图说明下面结合附图,通过对本申请的具体实施方式详细描述,将使本申请的技术方案及其有益效果显而易见。图1是本申请实施例提供的线程调度方法的流程示意图。图2是本申请实施例提供的线程调度方法的另一流程示意图。图3是本申请实施例提供的线程调度方法的场景示意图。图4是本申请实施例提供的线程调度的装置的结构示意图。图5是本申请实施例提供的电子设备的结构示意图。图6是本申请实施例提供的电子设备的另一结构示意图。具体实施方式请参照图示,其中相同的组件符号代表相同的组件,本申请的原理是以实施在一适当的运算环境中来举例说明。以下的说明是基于所例示的本申请具体实施例,其不应被视为限制本申请未在此详述的其它具体实施例。可以理解的是,本申请实施例的执行主体可以是诸如智能手机或平板电脑等的电子设备。请参阅图1,图1是本申请实施例提供的线程调度方法的流程示意图。该线程调度方法可以应用于电子设备。该线程调度方法的流程可以包括:在101中,按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表。随着技术的发展,电子设备中安装的各类应用程序越来越多,例如视频类应用、游戏类应用以及即时通讯类应用等。这使得电子设备经常需要在前台和后台运行多个应用程序,容易在用户交互场景中出现卡顿现象。本申请实施例中,电子设备的操作系统可以是基于linux内核的系统,例如,安卓操作系统等。电子设备上运行着系统进程和应用程序的进程,线程是进程的一条执行路径,是程序执行时的最小单位。一个进程可以有多个线程,但至少有一个线程。对于内核来说,在进行资源调度时,比如cpu调度,都是具体到某个线程的。进程内有一个主线程,它也会创建出很多子线程来协助工作。比如一个内容交互应用程序的进程,它会创建一个主线程来执行代码,执行途中也会创建其它子线程来协助运行各部分的任务代码。一般情况下,内核中的线程是有区分调度类的。内核中的线程最常见的是cfs(completefairschedule,完全公平调度)调度类线程(比如ui线程、render线程以及很多比较常见的线程都是cfs的)、rt(realtimescheduler,实时调度)调度类线程(比如surfaceflinger线程以及一些其他核心线程)。不同调度类的优先级不一样(这里的优先级是指某一调度类线程整体上相对于另一调度类线程具有的优先级)。比如,调度类的优先级体现在:多核cpu进行调度时,会先通过rt调度类的任务调度方法中选择rt线程运行,如果没有rt线程,才会从cfs调度类的调度方法中选择cfs线程,也就是说,rt调度类的优先级高于cfs调度类的优先级。当然,这两种调度类各自的调度方法中,会区分各自处理的线程的优先级(这里的优先级是指某一调度类内部各线程的优先级),如rt调度类内的rt线程,会区分线程的rt优先级。本申请实施例的方案适用于rt线程或者cfs线程的调度。接下来,以rt线程的调度为例对本申请实施例的方案进行说明,rt线程采用了基于优先级的调度策略,常用的调度策略包括fifo(firstinfirstout,先到先服务),rr(roundrobin,时间片轮转)等。无论fifo调度策略还是rr调度策略,当线程优先级不同的时候,都是根据线程的优先级由高到低的顺序进行调度,最高优先级的线程将优先得到处理。当线程具有相同优先级时,fifo调度策略,最先到达的线程将首先得到处理器资源,并且一直占用该资源,直到该线程进入睡眠状态。而对于rr调度器,具有相同优先级的线程将以轮流执行的方式共享处理器资源,当一个线程开始运行后,如果该线程不会阻塞,那么该线程将一直运行,直到分配给该线程的时间片到期。当时间片用完,将把该线程放在任务链表的末端。此外,本申请实施例可以应用于多核心处理器。在arm标准的架构中,cpu核心的算力是存在差异的,一般会将算力较强的核心称为大核,算力较弱的核心称为小核。比如,对于八核心处理器来说,一般具有四个大核,四个小核。需要说明的是,上述核心数量仅为举例说明,本申请实施例对于处理器的核心数量并不做具体限制,当至少有两个核心时,都可以使用本申请实施例的方案。如果电子设备的处理器是多核心处理器,则每一个处理器核心可以当作一个独立的处理单元。比如,如果电子设备为八核处理器,则每一个核心为一个独立的处理单元。其中,每一个处理器单元会维持一个运行队列,当线程准备就绪需要被执行时,会挂载到对应的目标处理器单元的运行队列上。该运行队列通过任务链表的结构来维护这些待执行的线程,运行队列包括多个的任务链表,不同的任务链表对应不同的优先级,相同优先级的线程挂载在同一个任务链表,不同优先级的线程挂载在不同的任务链表,新创建的线程也会根据其优先级挂载在对应优先级的任务链表上。对于某处理器单元的运行队列来说,运行队列中的线程共同使用该处理器单元资源,在每个时刻,只有一个线程在运行,线程采用了基于优先级的调度策略,因此当目标处理器单元在选择将要执行的线程时,会按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表。也就是说,目标处理器单元按照任务链表的优先级由高到低的顺序,依次查找到线程数量不为零的任务链表,作为目标任务链表,该目标任务链表是当前所有任务链表中线程数量不为空、且优先级最高的任务链表。其中,当一处理器单元的运行队列中有线程待调度执行时,将该处理器单元作为目标处理器单元,按照本申请实施例提出的方案对其运行队列中的线程进行调度执行。比如,当前不同优先级任务链表为5个:表1、表2、表3、表4、表5,且任务链表的优先级由高到低的顺序是:表1、表2、表3、表4、表5,则目标处理器在选择将要执行的线程时,将从表1开始判断线程数量是否不为零,若表1有线程,则表1作为目标任务链表,不再继续查找表2、表3、表4、表5,即表1是当前线程数量不为零、且优先级最高的任务链表。若表1当前没有线程,则继续查找表2,若当前表2有线程,则表2作为目标任务链表,不再继续查找表3、表4、表5了,即表2是当前线程数量不为零、且优先级最高的任务链表。在102中,检测目标任务链表中是否有第一类线程,其中,第一类线程为执行用户交互事件中相关任务的线程。本申请实施例中,目标处理器单元在调度线程时,首先,获取到当前线程数量不为零、且优先级最高的目标任务链表;然后,检测目标任务链表中是否有第一类线程,其中,第一类线程为执行用户交互事件中相关任务的线程。其中,执行用户交互事件中相关任务的线程是否能够流畅运行决定着是否会在用户交互事件中产生用户可感知的卡顿,故本申请实施例中,确定出执行用户交互事件中相关任务的线程,并将这些与用户体验紧密相关的线程记为ux(userexperience,用户体验)线程,作为第一类线程。由于产生用户可感知的界面的卡顿的场景多是相对于运行在前台的进程来说的。因此,在一种实施方式中,在检测到有进程切换到前台运行时,确定前台进程;从前台进程的线程中识别出用于执行用户交互事件中相关任务的线程,将这些线程作为第一类线程。在一种实施方式中,第一类线程包括进程运行时创建的一些用于直接执行用户交互事件的相关任务的线程,如ui(userinterface,用户界面)线程,render(渲染)线程,gl线程,用户输入事件的分发线程,用户输入事件的检测线程等。这些线程是否能够流畅运行决定着是否会在用户与该进程的交互界面中产生用户可感知的卡顿。其中,第一类线程一般是应用级线程,这些线程可以是通过对实际的卡顿场景进行分析来确定。比如,在测试中,如果某一用户交互场景下发生了应用卡顿,通过对该场景分析发现卡顿现象是某个线程处理任务太慢导致的,则可以认为该线程是用于执行用户交互事件中相关任务的,该线程的运行与用户体验紧密相关,可以将该线程作为第一类线程。由于在执行用户交互事件的过程中,除了应用级线程之外,可能还涉及到一些系统级的线程来完成任务,系统框架层也需要将这些系统级线程标记为第一类线程。一般这些线程在系统启动时就会创建,因此,可以在检测到系统启动时,识别出这些线程并进行标记,比如,surfaceflinger线程、系统动画线程等。或者,在系统运行过程中,如果检测到有新的系统进程的线程创建并用来执行用户交互事件中相关任务,系统框架层也将这些线程标记为第一类线程。此外,在一种实施方式中,还有一些线程虽然并没有直接地执行用户交互事件的相关任务,但是这些线程的运行情况也会影响到第一类线程的运行情况,进而间接地影响到用户交互事件的相关任务的执行。也就是说,这些线程并不是总是与用户体验相关,但是这些线程在执行过程的某段时间内,可能通过资源约束与第一类线程产生关联,因此,在一些实施例中,为了进一步地减少交互场景下的卡顿现象,内核层将这些与第一类线程之间有约束关系的线程也标记为第一类线程。而一旦这种约束关系结束,就会将该线程恢复至非第一类线程。其中,具体的约束关系包括但不限于进程间通信、线程间通信或者持有临界资源等。比如,第一类线程通过进程间通信请求的普通线程,持有第一类线程需要的等待信号量、读写信号量、互斥锁等临界资源的普通线程等,本申请实施例中将这类线程也标记为第一类线程。在103中,当目标任务链表中有第一类线程时,从目标任务链表中确定出等待时间最长的第一类线程,作为第一目标线程。目标任务链表中的线程都具有相同的优先级,也就是目标任务链表中第一类线程和第二类线程都具有相同的优先级。其中,第一类线程与用户体验紧密相关,第一类线程是否能够流畅运行决定是否会在用户交互事件中产生用户可感知的卡顿。将除第一类线程之外的线程记为第二类线程,第二类线程的运行情况一般不会影响用户体验,或者对用户体验影响较小。因此本申请实施例中,从线程的运行情况是否会影响到用户体验的角度出发,目标处理器单元在选择将要执行的线程时,目标处理器单元会优先调度那些直接或者间接地影响到用户体验的第一类线程。也就是说,当目标任务链表中同时有第一类线程和第二类线程时,目标处理器单元将优先调度第一类线程,其中,目标处理器单元在调度第一类线程时,会确定出等待时间最长的第一类线程,也就是确定出最先挂载到目标任务链表的第一类线程,作为第一目标线程将优先被调度。其中,当目标任务链表中的线程按照先入先出的顺序排列时,越靠近目标任务链表表头位置的线程等待时长越长。因此,可以从目标任务链表的表头位置开始依次检测目标任务链表中的线程是否为第一类线程,直至检测到第一类线程,从而从目标任务链表中确定出等待时长最长的第一类线程,并将其作为第一目标线程。当目标任务链表中的线程按照其他方式排列时,可以遍历目标任务链表中所有的线程,从而得到目标任务链表中所有的第一类线程,以及每一个第一类线程的等待时长,然后比较所有第一类线程的等待时长,确定出等待时长最长的第一类线程,并将其作为第一目标线程。在104中,基于目标处理器单元执行第一目标线程。目标处理器单元从目标任务链表中确定出等待时间最长的第一类线程后,执行第一目标线程。本申请实施例提供的线程调度方法,当目标处理器单元在选择将要执行的线程时,按照优先级由高至低的顺序,查找到线程数量不为零、且优先级最高的目标任务链表,如果目标任务链表上具有第一类线程,则目标处理器单元将优先处理第一类线程。也可以理解为,虽然目标任务链表中第一类线程和第二类线程具有相同的优先级,但目标处理器单元的资源会优先分配给第一类线程,使得执行用户交互事件相关任务的第一类线程能够及时执行,缩短其等待时间,减少了用户交互场景下的卡顿现象,提升了用户体验。请参阅图2,图2为本申请实施例提供的线程调度方法的另一流程示意图,流程可以包括:在201中,确定出用于执行用户交互事件中相关任务的第二目标线程。本申请实施例中,电子设备的操作系统可以是基于linux内核的系统,例如,安卓操作系统等。电子设备上运行着系统进程和应用程序的进程,线程是进程的一条执行路径,是程序执行时的最小单位。一个进程可以有多个线程,但至少有一个线程。对于内核来说,在进行资源调度时,比如cpu调度,都是具体到某个线程的。进程内有一个主线程,它也会创建出很多子线程来协助工作。比如一个内容交互应用程序的进程,它会创建一个主线程来执行代码,执行途中也会创建其它子线程来协助运行各部分的任务代码。其中,执行用户交互事件中相关任务的线程是否能够流畅运行决定着是否会在用户交互事件中产生用户可感知的卡顿,故本申请实施例中,确定出执行用户交互事件中相关任务的线程,并将这些与用户体验紧密相关的线程记为ux线程(userexperience,用户体验),也即第二目标线程。在202中,为第二目标线程添加预设标签,以将第二目标线程标记为第一类线程。由于第二目标线程是否能够流畅运行决定着是否会在用户交互事件中产生用户可感知的卡顿,故本申请实施例中,确定出执行用户交互事件中相关任务的第二目标线程,为第二目标线程添加预设标签,以将第二目标线程标记为第一类线程。其中,电子设备的系统架构至少包括应用框架(framework)层和内核(kernel)层,本申请实施例,从应用框架层和内核层的角度对ux线程进行识别和标记,例如,应用框架层为一些直接执行用户交互事件中相关任务的线程添加预设标签,以将这些线程标记为静态ux线程,内核层将一些间接地影响到用户交互事件中相关任务执行的线程标记为动态ux线程。可以理解的,预设标签可以为ux标签,其添加方式如下:linux使用task_struct结构体描述和记录线程,每个线程都有对应的task_struct结构体。task_struct中记录了线程的名称、标识符、状态、优先级、内存指针、上下文数据等属性信息。因此,应用框架层可以在task_struct结构体中增加对应的uxflag成员,以将前台进程的ui线程、render线程、gl线程等执行用户交互事件中相关任务的线程,通过标记uxflag位,使内核层能够识别该线程的任务属性。本申请实施例中的进程包括系统级进程和应用级进程。由于产生用户可感知的界面的卡顿的场景多是相对于运行在前台的进程来说的。因此,本申请实施例的方案中,“确定出用于执行用户交互事件中相关任务的第二目标线程”包括:在检测到有进程切换到前台运行时,确定前台进程;从前台进程的线程中识别出用于执行用户交互事件中相关任务的第一预设线程,将第一预设线程作为第二目标线程。在一种实施方式中,第一预设线程包括进程运行时创建的一些用于直接执行用户交互事件的相关任务的线程,如ui(userinterface,用户界面)线程,render(渲染)线程,gl线程,用户输入事件的分发线程,用户输入事件的检测线程等。这些线程是否能够流畅运行决定着是否会在用户与该进程的交互界面中产生用户可感知的卡顿。比如,用户使用聊天软件与某一好友聊天,用户在对话框输入文字,电子设备通过服务器将用户输入的文字发送至该好友的电子设备。在这次交互事件中,需要ui线程、render线程、用户输入事件的分发线程、用户输入事件的检测线程等线程共同工作,以完成本次用户交互事件,其中,每一个线程的运行都需要系统为其分配资源。因此,在检测到该聊天软件在前台运行时,识别出这些线程,将这些线程作为第一预设线程,并标记为ux线程。其中,第一预设线程一般是应用级线程,这些线程可以是通过对实际的卡顿场景进行分析来确定。比如,在测试中,如果某一用户交互场景下发生了应用卡顿,通过对该场景分析发现卡顿现象是某个线程处理任务太慢导致的,则可以认为该线程是用于执行用户交互事件中相关任务的,该线程的运行与用户体验紧密相关,可以将该线程作为第一预设线程。基于此,可以通过对各种可能的卡顿场景进行测试,记录这些导致卡顿出现的线程。电子设备中存储这些第一预设线程的相关信息,当进程切换到前台运行时,将该进程下的属于预先记录的第一预设线程的线程都标记为ux线程。可以理解的是,对于电子设备来说,存储的第一预设线程的相关信息并不是不可修改的,当进行系统升级时,可以对第一预设线程的相关信息进行更新。在一种实施例中,为第二目标线程添加预设标签之后,该方法还包括:若前台进程为应用进程,则在检测到前台进程切换至后台运行时,删除第一预设线程的预设标签。当前台进程切换到后台运行时,该进程的运行情况已经与用户体验无关,其线程的重要程度也有所下降,因此,可以将该进程对应的第一预设线程的ux标记删除,将这些ux线程恢复为普通线程。此外,在另一实施例中,该方法还包括:当检测到有第二预设线程创建时,将创建的第二预设线程作为第二目标线程,其中,第二预设线程为系统级线程。由于在执行用户交互事件的过程中,除了应用级线程之外,可能还涉及到一些系统级的线程来完成任务,系统框架层也需要将这些系统级线程标记为ux线程。一般这些线程在系统启动时就会创建,因此,可以在检测到系统启动时,识别出这些线程并进行标记,比如,surfaceflinger线程、系统动画线程等。或者,在系统运行过程中,如果检测到有新的系统进程的线程创建并用来执行用户交互事件中相关任务,系统框架层也将这些线程标记为ux线程。比如,systemui线程。其中,第二预设线程也可以通过对实际的卡顿场景进行分析来确定。比如,在测试中,如果某一用户交互场景下发生了应用卡顿,通过对该场景分析发现卡顿现象是某个系统级线程处理任务太慢导致的,则可以认为该系统级线程是用于执行用户交互事件中相关任务的,该系统级线程的运行与用户体验紧密相关,可以将该系统级线程作为第二预设线程。电子设备中存储这些第二预设线程的相关信息,如果检测到系统创建了这些线程,则将其标记为ux线程。对于系统级的第二预设线程来说,即使发生了进程的前后台切换,这些线程始终与用户体验相关,所以始终保有ux标签。在另一实施例中,在前台进程的运行过程中,当检测到有新线程创建时,确定新创建的线程是否用于执行用户交互事件中的相关任务;当新创建的线程用于执行用户交互事件中的相关任务时,将新创建的线程标记为ux线程。前台进程在运行过程中,如果有用户交互事件发生,除了上述应用级的第一预设线程和系统级的第二预设线程之外,还可能会有一些临时创建的任务线程,这些任务线程的运行也会直接影响到是否会在用户与该进程的交互界面中产生用户可感知的卡顿。因此,应用框架层会将这些线程也标记为ux线程,以优化系统对该线程的资源分配。其中,电子设备根据检测到的用户指令确定发生的用户交互事件。用户交互事件一般是指用户触发了某指令后,电子设备需要即时的对该指令进行响应,进行某种处理并将处理结果显示在界面上的情况。例如,用户使用电子设备观看视频、编辑短信、使用聊天软件、使用游戏软件、控制电子设备界面的切换、使用浏览浏览网页等,都属于用户交互事件。比如,用户使用聊天软件与某一好友聊天,用户在对话框输入文字,电子设备通过服务器将用户输入的文字发送至该好友的电子设备。在这个过程中,电子设备需要调度多个线程以完成本次用户交互事件,从该用户交互事件的开始到完成的整个过程中,进程创建的用来完成这次用户交互事件的线程都可以认为是与用户体验相关的线程。在用户交互事件中临时创建的任务线程在执行完对应的任务后就会被销毁,其自然会丢失掉ux标签。需要说明的是,上述几种ux线程仅为举例说明,并不局限于此,只要是直接地执行用户交互事件中相关任务的线程,使得其运行情况直接地影响到用户体验的线程,都可以将其标记为ux线程。对于应用框架层来说,在检测到新创建的线程是用来执行用户交互事件,或者检测到某些常驻系统级线程是用以处理用户交互事件时,为这些线程添加ux标签,以将其标记为ux线程。还有一些线程虽然并没有直接地执行用户交互事件的相关任务,但是这些线程的运行情况也会影响到ux线程的运行情况,进而间接地影响到用户交互事件的相关任务的执行。也就是说,这些线程并不是总是与用户体验相关,但是这些线程在执行过程的某段时间内,可能通过资源约束与ux线程产生关联,因此,在一些实施例中,为了进一步地减少交互场景下的卡顿现象,内核层将这些与ux线程之间有约束关系的线程也标记为ux线程。而一旦这种约束关系结束,就会将该线程恢复至非ux线程。其中,具体的约束关系包括但不限于进程间通信、线程间通信或者持有临界资源等。比如,ux线程通过进程间通信请求的普通线程,持有ux线程需要的等待信号量、读写信号量、互斥锁等临界资源的普通线程等,本申请实施例中将这类线程也标记为ux线程。基于此,在一些实施例中,该方法还包括:对第一类线程的运行状态进行检测;当检测到有第一类线程进入阻塞状态时,确定与进入阻塞状态的第一类线程之间有约束关系的关联线程;为关联线程添加预设标签,以将关联线程标记为第一类线程。在一些实施例中,将关联线程标记为第一类线程之后,还包括:当检测到约束关系解除时,删除关联线程的预设标签。其中,关于线程的阻塞状态,在内核层面一般会区分为d状态(uninterruptablesleep状态,不可中断的睡眠状态)和s状态(interruptablesleep状态,可中断的睡眠状态),比如,线程发起io请求但得不到满足,就进入d状态;线程发起同步binder请求,就会进入s状态。线程进入这些状态一般都是因为这些都是线程任务执行途中因为某些原因或者逻辑,需要主动或者被动地放弃cpu资源。该实施例中,内核层对ux线程的状态进行检测,当检测到ux线程进入到堵塞状态时,确定出与进入堵塞状态的ux线程之间具有约束关系的关联线程,如果这些关联线程没有及时分配到资源,比如io资源,而导致运行受阻,则由于关联线程的运行缓慢又会导致该ux线程长时间处于阻塞状态,因此,为了避免该ux线程长时间处于阻塞状态,内核层会将识别出的关联线程也标记为ux线程,以提高其io处理效率,保证其及时执行,进而快速解除该ux线程的阻塞状态。在203中,按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表。本申请实施例的方案以rt线程的调度为例进行说明,rt线程采用了基于优先级的调度策略,常用的调度策略包括fifo(firstinfirstout,先到先服务),rr(roundrobin,时间片轮转)等。无论fifo调度策略还是rr调度策略,当线程优先级不同的时候,都是根据线程的优先级由高到低的顺序进行调度,最高优先级的线程将优先得到处理。当线程具有相同优先级时,fifo调度策略,最先到达的线程将首先得到处理器资源,并且一直占用该资源,直到该线程进入睡眠状态。而对于rr调度器,具有相同优先级的线程将以轮流执行的方式共享处理器资源,当一个线程开始运行后,如果该线程不会阻塞,那么该线程将一直运行,直到分配给该线程的时间片到期。当时间片用完,将把该线程放在任务链表的末端。此外,本申请实施例可以应用于多核心处理器。本申请实施例对于处理器的核心数量并不做具体限制,如果电子设备的处理器是多核心处理器,则每一个处理器核心可以当作一个独立的处理单元。比如,如果电子设备为八核处理器,则每一个核心为一个独立的处理单元。其中,每一个处理器单元会维持一个运行队列,当线程准备就绪需要被执行时,会挂载到对应的目标处理器单元的运行队列上。该运行队列通过任务链表的结构来维护这些待执行的线程,运行队列包括多个的任务链表,不同的任务链表对应不同的优先级,相同优先级的线程挂载在同一个任务链表,不同优先级的线程挂载在不同的任务链表,新创建的线程也会根据其优先级挂载在对应优先级的任务链表上。对于某处理器单元的运行队列来说,运行队列中的线程共同使用该处理器单元资源,在每个时刻,只有一个线程在运行,线程采用了基于优先级的调度策略,因此当目标处理器单元在选择将要执行的线程时,会按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表。也就是说,目标处理器单元按照任务链表的优先级由高到低的顺序,依次查找到线程数量不为零的任务链表,作为目标任务链表,该目标任务链表是当前所有任务链表中线程数量不为空、且优先级最高的任务链表。其中,当一处理器单元的运行队列中有线程待调度执行时,将该处理器单元作为目标处理器单元,按照本申请实施例提出的方案对其运行队列中的线程进行调度执行。比如,当前不同优先级任务链表为5个:表1、表2、表3、表4、表5,且任务链表的优先级由高到低的顺序是:表1、表2、表3、表4、表5,则目标处理器在选择将要执行的线程时,将从表1开始判断线程数量是否不为零,若表1有线程,则表1作为目标任务链表,不再继续查找表2、表3、表4、表5,即表1是当前线程数量不为零、且优先级最高的任务链表。若表1当前没有线程,则继续查找表2,若当前表2有线程,则表2作为目标任务链表,不再继续查找表3、表4、表5了,即表2是当前线程数量不为零、且优先级最高的任务链表。在204中,检测目标任务链表中是否有第一类线程。本申请实施例中,目标处理器单元在调度线程时,首先,获取到当前线程数量不为零且优先级最高的目标任务链表;然后,检测目标任务链表中是否有第一类线程。本申请实施例中已确定出执行用户交互事件中相关任务的第二目标线程,且为第二目标线程添加预设标签,以将第二目标线程标记为第一类线程。因此检测目标任务链表中是否有第一类线程,可以通过检测目标任务链表上每一个线程是否具有预设标签,以确定目标任务链表中是否具有第一类线程,其中,将具有预设标签的线程确定为第一类线程。若目标任务链表中至少有一个线程具有预设标签,则目标任务链表中具有第一类线程;若目标任务链表中的全部线程都没有预设标签,则目标任务链表中没有第一类线程。在205中,当目标任务链表中有第一类线程时,从目标任务链表中确定出等待时间最长的第一类线程,作为第一目标线程。目标任务链表中的线程都具有相同的优先级,也就是目标任务链表中第一类线程和第二类线程都具有相同的优先级,第一类线程与用户体验紧密相关,第一类线程是否能够流畅运行决定是否会在用户交互事件中产生用户可感知的卡顿。本申请实施例中,将除第一类线程之外的线程记为第二类线程。第二类线程的运行情况一般不会影响用户体验,或者对用户体验影响较小。因此本申请实施例中,从线程的运行情况是否会影响到用户体验的角度出发,目标处理器单元在选择将要执行的线程时,目标处理器单元会优先调度那些直接或者间接地影响到用户体验的第一类线程。也就是说,当目标任务链表中同时有第一类线程和第二类线程时,目标处理器单元将确定出等待时间最长的第一类线程,也就是确定出最先挂载到目标任务链表的第一类线程,作为第一目标线程将优先被调度。其中,当目标任务链表中的线程按照先入先出的顺序排列时,越靠近目标任务链表表头位置的线程等待时长越长。因此,可以为从目标任务链表的表头位置开始依次检测目标任务链表中的线程是否为第一类线程,直至检测到第一类线程,从而从目标任务链表中确定出等待时长最长的第一类线程,并将其作为第一目标线程。当目标任务链表中的线程按照其他方式排列时,可以遍历目标任务链表中所有的线程,从而得到目标任务链表中所有的第一类线程,以及每一个第一类线程的等待时长,然后比较所有第一类线程的等待时长,确定出等待时长最长的第一类线程,并将其作为第一目标线程。此外,在一种实施方式中,从目标任务链表中确定出等待时间最长的第一类线程之前,还可以获取目标任务链表中每一个第一类线程的类型信息;根据类型信息调整多个第一类线程在目标任务链表上的排列顺序。例如,若目标任务链表上具有相同优先级的ui(userinterface,用户界面)线程和render(渲染)线程,ui线程和render线程都属于第一类线程,但是具有不同的类型信息。根据系统运行需要,若ui线程比render线程更需要被快速执行,使得用户在交互过程中更不容易感知到卡顿,那么,当新生成的ui线程挂载到目标任务链表时,可以调整ui线程的排列顺序,比如,插入在等待时间最长的render线程之前,使得ui线程更接近目标任务链表的表头位置,或者调整ui线程的等待时间,使得ui线程的等待时间变长,从而更快得到执行。在206中,当目标任务链表中没有第一类线程时,从目标任务链表中确定出等待时间最长的第二类线程,作为第一目标线程,其中,将目标任务链表中除第一类线程以外的线程作为第二类线程。本申请实施例中,将除第一类线程之外的线程作为为第二类线程。第二类线程的运行情况一般不会影响用户体验,或者对用户体验影响较小。若目标任务链表中的全部线程都没有预设标签,则目标任务链表中没有第一类线程,目标任务链表中只有第二类线程。目标任务链表中的线程都具有相同的优先级,也就是目标任务链表中第一类线程和第二类线程都具有相同的优先级,虽然第二类线程对用户体验影响较小,但是目标任务链表的第二类线程也是当前优先级最高的重要线程。目标处理器单元基于优先级的调度策略,将从目标任务链表中确定出等待时间最长的第二类线程,也就是确定出最先挂载到目标任务链表的第二类线程,作为第一目标线程将优先被调度。当目标任务链表中的线程按照先入先出的顺序排列时,越靠近目标任务链表表头位置的线程等待时长越长。因此,可以确定目标任务链表的表头位置的第二类线程为第一目标线程。当目标任务链表中的线程按照其他方式排列时,可以遍历目标任务链表中所有的第二类线程,以及每一个第二类线程的等待时长,然后比较所有第二类线程的等待时长,确定出等待时长最长的第二类线程,并将其作为第一目标线程。在207中,基于目标处理器单元执行第一目标线程。当目标任务链表中具有与用户体验紧密相关的第一类线程时,则从目标任务链表中确定出等待时间最长的第一类线程,作为第一目标线程;当目标任务链表中没有第一类线程,只有第二类线程时,则从目标任务链表中确定出等待时间最长的第二类线程,作为第一目标线程。目标处理器单元从目标任务链表中确定出第一目标线程,执行第一目标线程。本申请实施例提供的线程调度方法,确定出用于执行用户交互事件中相关任务的第二目标线程,并为第二目标线程添加预设标签,以将第二目标线程标记为第一类线程。当目标处理器单元在选择将要执行的线程时,按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零、且优先级最高的目标任务链表。通过检测目标任务链表的每一个线程是否具有预设标签确定目标任务链表中是否有第一类线程。本申请实施例中,如果目标任务链表上具有第一类线程,则目标处理器单元将优先处理第一类线程,使得执行用户交互事件相关任务的第一类线程能够及时执行,缩短其等待时间,从而减少了用户交互场景下的卡顿现象,提升了用户体验。此外,在一种实施方式中,在检测目标任务链表中是否有第一类线程之前,还包括:获取目标任务链表中每一个第二类线程的等待时长;若至少一个第二类线程的等待时长超过预设时长,则将等待时长最长的第二类进程作为第一目标进程。目标任务链表中目标任务链表中第一类线程和第二类线程都具有相同的优先级,虽然第二类线程对用户体验影响较小,但是目标任务链表的第二类线程也是当前优先级最高的重要线程,如果第二类线程长时间不能得到执行,也可能会对系统的性能或者系统运行造成影响,因此可以根据具体系统性能或者系统运行的需要设定预设时长,如果第二类线程的等待时长超过预设时长,也可以优先执行等待时长超过预设时长的第二类线程。需要说明的是,这里的第一类线程和第二类线程中的“第一类”和“第二类”,仅仅是为了区分线程是否具有ux标签,而不是说将系统中的线程只划分为这两种类别。请参阅图3,图3是本申请实施例提供的线程调度方法的场景示意图。执行用户交互事件中相关任务的线程是否能够流畅运行决定着是否会在用户交互事件中产生用户可感知的卡顿,故本申请实施例,确定出执行用户交互事件中相关任务的线程,并将这些与用户体验紧密相关的线程记为ux线程(userexperience,用户体验),也即第二目标线程。具体的第二目标线程请参考上述实施例,在此不在赘述。为第二目标线程添加预设标签,以将第二目标线程标记为第一类线程。如图3所示,例如,与用户体验紧密相关的第一类线程为:a1、a2、a3。本申请实施例中,将除第一类线程之外的线程作为为第二类线程。第二类线程的运行情况一般不会影响用户体验,或者对用户体验影响较小。如图3所示,例如,第二类线程为:b1、b2、b3、b4、b5。每一个处理器单元会维持一个运行队列,当线程准备就绪需要被执行时,会挂载到对应的目标处理器单元的运行队列上,该运行队列通过任务链表的结构来维护这些待执行的线程,运行队列包括多个的任务链表,不同的任务链表对应不同的优先级,相同优先级的线程挂载在同一个任务链表。如图3所示,例如,运行队列中包括第一优先级任务链表、第二优先级任务链表等任务链表,其中,第一优先级任务链表的优先级最高。当目标处理器单元在选择将要执行的线程时,按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零、且优先级最高的目标任务链表。如图3所示,例如,第一优先级任务链表的优先级最高,且第一优先级任务链表的线程数量不为零,则第一优先级任务链表为目标任务链表,不再继续查找其他任务链表。检测目标任务链表中是否有第一类线程,由于本申请实施例中已确定出执行用户交互事件中相关任务的第二目标线程,且为第二目标线程添加预设标签,以将第二目标线程标记为第一类线程。其中,预设标签可以为ux标签。因此检测目标任务链表中是否有第一类线程,可以通过检测目标任务链表上每一个线程是否具有预设标签,以确定目标任务链表中是否具有第一类线程。其中,将具有预设标签的线程确定为第一类线程。若目标任务链表中至少有一个线程具有预设标签,则目标任务链表中具有第一类线程;若目标任务链表中的全部线程都没有预设标签,则目标任务链表中没有第一类线程。如图3所示,例如,第一优先级任务链表为目标任务链表,且第一优先级任务链表上的线程a1、a2具有预设标签,因此,第一优先级任务链表具有第一类线程:a1、a2。当目标任务链表中有第一类线程时,从目标任务链表中确定出等待时间最长的第一类线程,作为第一目标线程;当目标任务链表中的线程按照先入先出的顺序排列时,最接近目标任务链表表头位置的线程等待时长越长,因此将最接近目标任务链表表头位置的第一类线程作为第一目标线程。图3所示,例如,第一优先级任务链表中第一类线程a1最接近目标任务链表表头位置,也就是等待时间最长的第一类线程,因此将第一类线程a1作为第一目标线程。需要说明的是,当目标任务链表中没有第一类线程时,则从目标任务链表中确定出等待时间最长的第二类线程,作为第一目标线程。基于目标处理器单元执行第一目标线程。本申请实施例中,如果目标任务链表上具有第一类线程,则目标处理器单元将优先处理第一类线程,使得执行用户交互事件相关任务的第一类线程能够及时执行,缩短了其等待时间,从而减少了用户交互场景下的卡顿现象,提升了用户体验。请参阅图4,图4为本申请实施例提供的线程调度装置的结构示意图。该线程调度装置可以应用于电子设备。线程调度装置300可以包括:获取模块301,检测模块302,确定模块303、处理模块304。获取模块301用于:按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表;检测模块302用于:检测所述目标任务链表中是否有第一类线程,其中,所述第一类线程为执行用户交互事件中相关任务的线程;确定模块303用于:当所述目标任务链表中有所述第一类线程时,从所述目标任务链表中确定出等待时间最长的所述第一类线程,作为第一目标线程;处理模块304用于:基于所述目标处理器单元执行所述第一目标线程。在一种实施方式中,所述检测所述目标任务链表中是否有第一类线程之后,所述确定模块303可以用于:当所述目标任务链表中没有所述第一类线程时,从所述目标任务链表中确定出等待时间最长的第二类线程,作为第一目标线程,其中,将除所述第一类线程以外的线程作为所述第二类线程。在一种实施方式中,所述检测模块302可以用于:检测所述目标任务链表上每一个线程是否具有预设标签,以确定所述目标任务链表中是否具有所述第一类线程,其中,将具有所述预设标签的线程确定为所述第一类线程。在一种实施方式中,所述检测模块302可以用于:确定出用于执行用户交互事件中相关任务的第二目标线程;为所述第二目标线程添加所述预设标签,以将所述第二目标线程标记为所述第一类线程。在一种实施方式中,所述检测模块302可以用于:在检测到有进程切换到前台运行时,确定前台进程;从所述前台进程的线程中识别出用于执行用户交互事件中相关任务的第一预设线程,将所述第一预设线程作为所述第二目标线程。在一种实施方式中,所述检测模块302可以用于:当检测到有第二预设线程创建时,将创建的第二预设线程作为所述第二目标线程,其中,所述第二预设线程为系统级线程。在一种实施方式中,所述将所述第二目标线程标记为第一类线程之后,所述检测模块302可以用于:对所述第一类线程的运行状态进行检测;当检测到有所述第一类线程进入阻塞状态时,确定与进入阻塞状态的所述第一类线程之间有约束关系的关联线程;为所述关联线程添加所述预设标签,以将所述关联线程标记为所述第一类线程。申请实施例提供一种计算机可读的存储介质,其上存储有计算机程序,当所述计算机程序在计算机上执行时,使得所述计算机执行如本实施例提供的线程调度方法中的流程。本申请实施例还提供一种电子设备,包括存储器,处理器,所述处理器通过调用所述存储器中存储的计算机程序,用于执行本实施例提供的线程调度方法中的流程。例如,上述电子设备可以是诸如平板电脑或者智能手机等移动终端。请参阅图5,图5为本申请实施例提供的电子设备的结构示意图。该电子设备400可以包括存储器402、处理器401等部件。本领域技术人员可以理解,图5中示出的电子设备结构并不构成对电子设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。存储器402可用于存储应用程序和数据。存储器402存储的应用程序中包含有可执行代码。应用程序可以组成各种功能模块。处理器401通过运行存储在存储器402的应用程序,从而执行各种功能应用以及数据处理。其中,处理器401与存储器402电性连接。处理器401是电子设备的控制中心,利用各种接口和线路连接整个电子设备的各个部分,通过运行或执行存储在存储器402内的应用程序,以及调用存储在存储器402内的数据,执行电子设备的各种功能和处理数据,从而对电子设备进行整体监控。在本实施例中,电子设备中的处理器401按照如下的指令,将一个或一个以上的应用程序的进程对应的可执行代码加载到存储器402中,并由处理器401来运行存储在存储器402中的应用程序,从而执行:按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表;检测所述目标任务链表中是否有第一类线程,其中,所述第一类线程为执行用户交互事件中相关任务的线程;当所述目标任务链表中有所述第一类线程时,从所述目标任务链表中确定出等待时间最长的所述第一类线程,作为第一目标线程;基于所述目标处理器单元执行所述第一目标线程。请参阅图6,图6为本申请实施例提供的电子设备的第二种结构示意图。电子设备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中的应用程序,从而执行:按照优先级由高至低的顺序遍历目标处理器单元的多个任务链表,直至获取到线程数量不为零的任务链表,作为目标任务链表;检测所述目标任务链表中是否有第一类线程,其中,所述第一类线程为执行用户交互事件中相关任务的线程;当所述目标任务链表中有所述第一类线程时,从所述目标任务链表中确定出等待时间最长的第一类线程,作为第一目标线程;基于所述目标处理器单元执行所述第一目标线程。在一种实施方式中,在所述检测所述目标任务链表中是否有第一类线程之后,处理器401执行当所述目标任务链表中没有所述第一类线程时,从所述目标任务链表中确定出等待时间最长的第二类线程,作为第一目标线程,其中,将除所述第一类线程以外的线程作为所述第二类线程;基于所述目标处理器单元执行所述第一目标线程。在一种实施方式中,在所述检测所述目标任务链表中是否有第一类线程中,处理器401执行检测所述目标任务链表上每一个线程是否具有预设标签,以确定所述目标任务链表中是否具有所述第一类线程,其中,将具有所述预设标签的线程确定为所述第一类线程。在一种实施方式中,处理器401执行确定出用于执行用户交互事件中相关任务的第二目标线程;为所述第二目标线程添加所述预设标签,以将所述第二目标线程标记为所述第一类线程。在一种实施方式中,在所述确定出用于执行用户交互事件中相关任务的第二目标线程中,处理器401执行在检测到有进程切换到前台运行时,确定前台进程;从所述前台进程的线程中识别出用于执行用户交互事件中相关任务的第一预设线程,将所述第一预设线程作为所述第二目标线程。在一种实施方式中,在所述确定出用于执行用户交互事件中相关任务的第二目标线程中,处理器401执行当检测到有第二预设线程创建时,将创建的第二预设线程作为所述第二目标线程,其中,第二预设线程为系统级线程。在一种实施方式中,在所述将所述第二目标线程标记为第一类线程之后,处理器401执行对所述第一类线程的运行状态进行检测;当检测到有所述第一类线程进入阻塞状态时,确定与进入阻塞状态的所述第一类线程之间有约束关系的关联线程;为所述关联线程添加所述预设标签,以将所述关联线程标记为所述第一类线程。在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见上文针对线程调度方法的详细描述,此处不再赘述。本申请实施例提供的所述线程调度装置与上文实施例中的线程调度方法属于同一构思,在所述线程调度装置上可以运行所述线程调度方法实施例中提供的任一方法,其具体实现过程详见所述线程调度方法实施例,此处不再赘述。需要说明的是,对本申请实施例所述线程调度方法而言,本领域普通技术人员可以理解实现本申请实施例所述线程调度方法的全部或部分流程,是可以通过计算机程序来控制相关的硬件来完成,所述计算机程序可存储于一计算机可读取存储介质中,如存储在存储器中,并被至少一个处理器执行,在执行过程中可包括如所述线程调度方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储器(rom,readonlymemory)、随机存取记忆体(ram,randomaccessmemory)等。对本申请实施例的所述线程调度装置而言,其各功能模块可以集成在一个处理芯片中,也可以是各个模块单独物理存在,也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中,所述存储介质譬如为只读存储器,磁盘或光盘等。以上对本申请实施例所提供的线程调度方法、装置、存储介质以及电子设备进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。当前第1页12当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1