进程管理方法和装置、电子设备与流程

文档序号:25543381发布日期:2021-06-18 20:40阅读:65来源:国知局
进程管理方法和装置、电子设备与流程

本申请涉及计算机技术领域,特别涉及一种进程管理方法和装置、电子设备。



背景技术:

ipc(inter-processcommunication,进程间通信)是指在不同进程之间传播或交换信息的一种通信方式。基于ipc的不同应用之间通常存在进程间的调用,当前,对于处于挂起(休眠)状态的进程,当有其他进程调用该处于挂起状态的进程时,该处于挂起状态的进程存在直接被唤醒的情况,当进程被频繁唤醒,内存和功耗资源也将相应被频繁地消耗。



技术实现要素:

本申请的目的在于解决现有技术中处于挂起状态的进程在被调用时直接被唤醒,存在进程被频繁唤醒,导致内存和功耗资源的消耗的问题。本申请提供了一种进程管理方法,可以有效地减少处于挂起状态的进程被唤醒,以减少内存和功耗资源的消耗的问题。

为解决上述技术问题,第一方面,本申请的实施方式公开了一种进程管理方法,包括:在进行binder进程间调用时,确定该binder进程间调用中的被调用进程是否为处于挂起状态的进程;若被调用进程为处于挂起状态的进程,则根据预设的基于binder进程间调用的通信类型的唤醒策略确定是否唤醒被调用进程,以用于进程调用;若被调用进程为处于非挂起状态的进程,则执行进程调用。

在binder进程间调用中,对于处于挂起状态的被调用进程,当该被调用进程被调用进程调用时,可以根据预设的基于binder进程间调用的通信类型的唤醒策略确定是否需要唤醒该被调用进程,即对于不同的binder进程间调用的通信类型,在需要唤醒时唤醒该被调用进程以用于进程调用,在不需要唤醒时,则可以不用唤醒该被调用进程,由此,可以有效地减少进程被唤醒,即可以有效地减少调用进程基于binder进程间调用唤醒被调用进程,以避免进程被频繁唤醒,导致内存和功耗资源的消耗的问题,即可以有效地降低内存占用和功耗资源的消耗。

在上述第一方面的一种可能的实现中,根据预设的基于binder进程间调用的通信类型的唤醒策略确定是否唤醒被调用进程以用于进程调用,包括:确定binder进程间调用的通信类型;通信类型包括binder同步调用和binder异步调用;若binder进程间调用的通信类型为binder同步调用,则根据预设的binder进程间调用优先类型确定是否唤醒被调用进程以用于进程调用;若binder进程间调用的通信类型为binder异步调用,则缓存binder进程间调用,并基于缓存的针对被调用进程的累积程度是否达到预设的累积程度标准或被调用进程的状态是否发生变化,以确定是否唤醒被调用进程以用于进程调用。

在binder进程间调用中,对于binder同步调用和binder异步调用两种通信类型,分别进行不同的关于进程唤醒的管理方法,由此对于不同的binder进程间调用的通信类型,可以进行针对性地进程唤醒管理,且可以满足不同通信类型的情况下对被调用进程的调用需求。

在上述第一方面的一种可能的实现中,优先类型包括易用性优先,且若binder进程间调用的优先类型为易用性优先,则唤醒被调用进程以用于进程调用。

易用性优先则为优先考虑进程的使用便捷性,若binder进程间调用的优先类型为易用性优先,则唤醒被调用进程以用于进程调用,由此可以保证对该被调用进程的使用需求。

在上述第一方面的一种可能的实现中,满足以下任一条件的binder进程间调用的优先类型为易用性优先:被调用进程或调用被调用进程的调用进程对应的应用为通过用户界面被选择为允许后台活动的应用;被调用进程或调用被调用进程的调用进程对应的应用为通过用户界面被选择为忽略功耗影响的应用;被调用进程或调用被调用进程的调用进程对应的应用为通过用户界面被选择为忽略内存影响的应用。

在上述第一方面的一种可能的实现中,优先类型包括功耗优先,且若binder进程间调用的优先类型为功耗优先,则判断调用被调用进程的调用进程是否为核心进程,若调用进程为核心进程,则唤醒被调用进程;若调用进程为非核心进程,则不唤醒被调用进程。

功耗优先则为优先考虑进程尽量占用少的功耗,并且在判断binder进程间调用的优先类型为功耗优先时,出于对基于该binder进程间调用相关功能的正常使用的考虑,可以通过判断该调用进程是否为核心进程,由此决定是否唤醒被调用进程,若该调用进程为核心进程,为保证该binder进程间调用相关功能的正常使用,则唤醒该被调用进程用于进程调用,若该调用进程为非核心进程,则即使不唤醒该被调用进程,也不影响用户的使用,因此,可以不唤醒该被调用进程。

在上述第一方面的一种可能的实现中,满足以下任一条件的调用进程为核心进程:调用进程对应的应用为通过应用白名单配置的应用;调用进程为前台进程,且被用户正在前台使用;操作系统中调用进程的adj值小于前台进程的adj值;操作系统中调用进程为不在后台进程调度分组中的进程;调用进程对应的应用的uid小于预设的uid;调用进程为操作系统中前台服务的进程;调用进程为当前进行后台可感知业务的进程。

在上述第一方面的一种可能的实现中,若调用进程为非核心进程,则不唤醒被调用进程,并进一步还包括:将调用进程的状态标识为挂起状态,和/或将调用进程对应的应用的状态标识为挂起状态。

若调用进程为非核心进程,则即使不执行该binder进程间调用,也不影响用户的当前使用,在不唤醒该被调用进程的基础上,还可以将调用进程将调用进程的状态标识为挂起状态,和/或将调用进程对应的应用的状态标识为挂起状态,以进一步减少内存和功耗资源的消耗。

在上述第一方面的一种可能的实现中,缓存binder进程间调用,包括:缓存针对被调用进程的调用关系至异步调用缓存器中。

在上述第一方面的一种可能的实现中,若缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准,或被调用进程的状态由挂起状态转换为活跃状态,则唤醒被调用进程。

在上述第一方面的一种可能的实现中,缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准,包括:针对被调用进程的异步调用缓存器的存储总量超过预设的存储阈值;或针对被调用进程的异步调用缓存器的可用存储空间小于预设的存储空间阈值;或针对被调用进程的缓存调用次数达到预设的缓存调用次数阈值;或针对被调用进程的缓存调用时间达到预设的缓存调用时间阈值。

对于通信类型为binder异步调用方式的binder进程间调用,为避免进程被频繁唤醒,则可以暂时缓存针对被调用进程的调用,在达到一定的唤醒条件时,再唤醒该被调用进程。进一步地,当该被调用进程被唤醒时,可以执行该缓存的binder进程间调用。

在上述第一方面的一种可能的实现中,被调用进程被唤醒后,还包括:将被调用进程的状态由挂起状态转换为活跃状态,且将被调用进程对应的应用的状态由挂起状态转换为活跃状态。在被调用进程被唤醒后,将被调用进程的状态由挂起状态转换为活跃状态,且将被调用进程对应的应用的状态由挂起状态转换为活跃状态,即使得进程和进程对应的应用处于活跃状态,以便于进程及应用处于的正常使用。

在上述第一方面的一种可能的实现中,确定被调用进程是否为处于挂起状态的进程,包括:判断被调用进程的进程标识信息是否位于预设的管理进程列表中;管理进程列表包括与处于挂起状态的应用对应的进程的进程标识信息;若被调用进程的进程标识信息位于管理进程列表中,则被调用进程为处于挂起状态的进程;若被调用进程的进程标识信息未位于管理进程列表中,则被调用进程为处于非挂起状态的进程。

预先设置管理进程列表,并将处于挂起状态的进程的进程标识信息添加至该管理进程列表中,在判断被调用进程是否为挂起进程时,只需要判断该被调用进程的进程标识信息是否位于该管理进程列表中,即可以方便地确定该被调用进程是否为挂起进程。

在上述第一方面的一种可能的实现中,进程标识信息包括进程id和/或与进程对应的应用的uid。

在上述第一方面的一种可能的实现中,处于挂起状态的应用,包括:进入后台后,在预设时间内无可感知业务的应用。

对于进入后台后,在预设时间内无可感知业务的应用,为避免该应用继续占用内存及产生功耗,可以将该应用的状态转换为挂起状态,并将该应用对应的进程的状态转换为挂起状态,由此可以避免内存及功耗资源的消耗。

在上述第一方面的一种可能的实现中,进一步包括,处于挂起状态的进程的状态转换为活跃状态后,将进程的进程标识信息从管理进程列表中移除;或处于挂起状态的应用的状态转换为活跃状态后,将应用对应的进程的进程标识信息从管理进程列表中移除。

为避免进程/应用的正常使用,在进程的状态由挂起状态转换为活跃状态后,将该进程的进程标识信息从管理进程列表中移除,以使在该进程被调用时,可以直接执行进程调用。

第二方面,本申请的实施方式提供了一种进程管理装置,包括:binder进程间调用管理模块,binder进程间调用管理模块在进行binder进程间调用时,确定binder进程间调用中的被调用进程是否为进入后台处于挂起状态的进程;并在确定被调用进程为处于挂起状态的进程时,根据预设的基于binder进程间调用的通信类型的唤醒策略确定是否唤醒被调用进程以用于进程调用;在确定被调用进程为处于非挂起状态的进程时,执行进程调用。

在上述第二方面的一种可能的实现中,还包括:应用模块和应用管理模块;应用管理模块用于确定应用模块中进入后台的应用在预设时间内是否无可感知业务,若无,则将应用的状态标识为挂起状态;若有,则将应用的状态标识为活跃状态;针对标识为挂起状态的应用,应用管理模块还用于将应用对应的进程的状态标识为挂起状态,并通知binder进程间调用管理模块将处于挂起状态的进程的进程标识信息加入binder进程间调用管理模块中预设的管理进程列表中。

在上述第二方面的一种可能的实现中,应用管理模块还用于:当被调用进程被唤醒后,通知binder进程间调用管理模块将被调用进程的进程标识信息从管理进程列表中删除。

在上述第二方面的一种可能的实现中,应用管理模块还用于:当被调用进程被唤醒后,将被调用进程的状态由挂起状态转换为活跃状态,和/或将被调用进程对应的应用的状态由挂起状态转换为活跃状态。

在上述第二方面的一种可能的实现中,应用管理模块还用于:当调用被调用进程的调用进程的状态被标识为挂起状态时,将调用进程对应的应用的状态标识为挂起状态。

本申请提供的进程管理装置,包括用于执行上述第一方面和/或第一方面的任意一种可能的实现方式所提供的进程管理方法的模块,因此也能实现第一方面提供的进程管理方法所具备的有益效果(或优点)。

第三方面,本申请的实施方式提供了一种电子设备,包括:存储器,用于存储计算机程序,计算机程序包括程序指令;处理器,用于执行程序指令,以使电子设备执行如上述第一方面和/或第一方面的任意一种可能的实现方式所提供的进程管理方法。

第四方面,本申请的实施方式提供了一种计算机可读取存储介质,计算机可读取存储介质存储有计算机程序,计算机程序包括程序指令,程序指令被计算机运行以使计算机执行如第一方面和/或第一方面的任意一种可能的实现方式所提供的进程管理方法。

附图说明

为了更清楚地说明本申请实施例的技术方案,下面将对实施例描述中所使用的附图作简单介绍。

图1是根据本申请的一些实施例,示出了一种ipc机制原理图;

图2是根据本申请的一些实施例,示出了一种binder进程间调用场景图;

图3是根据本申请的一些实施例,示出了一种binder进程间调用中的进程管理方法流程图;

图4是根据本申请的一些实施例,示出了一种基于binder进程间调用的通信类型的唤醒策略确定是否唤醒被调用进程的方法流程图;

图5是根据本申请的一些实施例,示出了一种binder进程间调用在异步调用缓存器中的缓存状态示意图;

图6是根据本申请的一些实施例,示出了一种应用及进程的管理方法流程图;

图7是根据本申请的一些实施例,示出了一种进程管理装置的模块示意图;

图8是根据本申请的一些实施例,示出了一种binder进程间调用中的进程管理方法流程图;

图9是根据本申请的一些实施例,示出了一种电子设备的结构示意图;

图10是根据本申请的一些实施例,示出了一种片上系统(soc)的结构示意图。

具体实施方式

以下由特定的具体实施例说明本申请的实施方式,本领域技术人员可由本说明书所揭示的内容轻易地了解本申请的其他优点及功效。虽然本申请的描述将结合较佳实施例一起介绍,但这并不代表此申请的特征仅限于该实施方式。恰恰相反,结合实施方式作申请介绍的目的是为了覆盖基于本申请的权利要求而有可能延伸出的其它选择或改造。为了提供对本申请的深度了解,以下描述中将包含许多具体的细节。本申请也可以不使用这些细节实施。此外,为了避免混乱或模糊本申请的重点,有些具体细节将在描述中被省略。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。

应注意的是,在本说明书中,相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。

为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请的实施方式作进一步地详细描述。

电子设备中通常设置有多个应用(application),各应用通常会对应一个或多个进程,每个进程通常都有自己的一部分独立的系统资源,且彼此是隔离的,为了能使不同的进程互相访问资源并进行协调工作,才有了进程间通信。

该电子设备具体可以是手机、平板电脑、个人数字助理(personaldigitalassistant,pda)或台式电脑等终端设备。

请参见图1,图1示出了进程间通信的一种机制原理图,其中进程a和进程b分别具有独立的用户空间,进程的用户空间是互相独立的,且用户空间之间信息不可直接共享。内核空间是所有进程的共享空间,进程间可以通过内核空间实现彼此的用户空间之间的信息传播或交换,比如通过系统调用可以将进程a的用户空间内的信息通过内核空间复制到进程b的用户空间内。

进一步地,使用进程间通信的两个应用通常可以被分类为客户端和服务端,客户端进程请求数据,服务端进程回复客户端进程的数据请求。

具体的,请参见图2,图2示出了一种应用间进行进程间通信的一种场景。该场景下包括应用模块和安卓框架(androidframework)模块,其中应用模块包括第一应用10,第二应用20和第三应用30,且该第一应用10,第二应用20和第三应用30都通过sdk(softwaredevelopmentkit,软件开发工具包)集成,具体的都集成在sdk1和sdk2,且各sdk之间通过进程间通信通信。另外,安卓框架中包括蓝牙服务40、gps服务50、sensor服务60等模块,且该蓝牙服务40、gps服务50、sensor服务60等模块具体也可以与前述第一应用10,第二应用20和第三应用30之间通过进程间通信通信。

针对sdk1,可以选择第三应用30进程作为服务端,第一应用10和第二应用20作为客户端;针对sdk2:可以选择第二应用20进程作为服务端,第一应用10和第三应用30作为客户端。该第一应用10、第二应用20和第三应用30之间互相保活,其中一个应用死掉(或处于挂起状态),另一个应用会将死掉应用拉起(或唤醒)。具体的,应用之间的拉起会使得应用中处于挂起状态的进程被唤醒,进程被唤醒过多,会导致内存和功耗资源消耗。

进一步地,前述各sdk之间通过进程间通信通信,及蓝牙服务、gps服务、sensor服务等模块具体也可以与前述第一应用10,第二应用20和第三应用30之间通过进程间通信通信具体可以是进行binder进程间通信机制。具体的,android系统中,每个应用程序是由activity,service,broadcast,provider这四大组件组成,这四大组件所涉及的进程间通信底层都是依赖于binder进程间通信机制。

需要说明的是,binder进程间调用的通信类型包括binder同步调用和binder异步调用,其中binder同步调用中调用进程调用被调用进程,需要等待被调用进程返回结果才能结束此次调用;异步binder调用为调用进程调用被调用进程,不需要等待被调用进程返回结果,类似通知机制。

进一步地,图2中,带箭头的实线所示的为binder同步调用,带箭头的虚线所示的为binder异步调用。

由此,应用对应的进程之间基于binder进程间通信机制的binder进程间调用会存在进程唤醒,而进程被唤醒过多,会导致内存和功耗资源消耗。

基于上述技术问题,本申请的实施方式公开了一种进程管理方法,请参见图3,图3示出了一种进程管理方法,其具体包括:

s100:在进行binder进程间调用时,确定被调用进程是否为处于挂起状态的进程;若被调用进程为处于挂起状态的进程,则执行s200;若被调用进程为处于非挂起状态的进程,则执行s300。

s200:根据预设的基于binder进程间调用的通信类型的唤醒策略确定是否唤醒被调用进程,以用于进程调用。

s300:执行进程调用。

具体的,在binder进程间调用中,通常包括调用进程和被调用进程,其中,调用进程为binder进程间调用的发起者(调用者),被调用进程为在binder进程间调用中被调用进程调用的进程(被调用者)。本申请提供的进程管理方法中,在binder进程间调用中,对于处于挂起状态的被调用进程,当该被调用进程被调用时,可以根据预设的基于binder进程间调用的通信类型的唤醒策略确定是否需要唤醒该进程,即对于不同的binder进程间调用的通信类型,在需要唤醒时唤醒该被调用进程以用于进程调用,在不需要唤醒时,则可以不用唤醒该被调用进程,可以有效地减少被调用进程被唤醒,即可以有效地减少调用进程基于binder进程间调用唤醒被调用进程,以避免进程被频繁唤醒,引起内存和功耗资源的消耗的问题,由此,可以减少内存及功耗资源的消耗。

示例性的,请参见图4,基于binder进程间调用的通信类型的唤醒策略确定是否唤醒被调用进程,具体包括:

s210:确定binder进程间调用的通信类型。

具体的,binder进程间调用的通信类型包括binder同步调用和binder异步调用;若binder进程间调用的通信类型为binder同步调用,则执行s220:若binder进程间调用的通信类型为binder异步调用,则执行s230。

s220:根据预设的binder进程间调用优先类型确定是否唤醒被调用进程以用于进程调用。

s230:缓存binder进程间调用,并基于缓存的针对被调用进程的累积程度是否达到预设的累积程度标准或被调用进程的状态是否发生变化,以确定是否唤醒被调用进程以用于进程调用。

具体的,binder进程间调用的通信类型包括binder同步调用和binder异步调用,其中binder同步调用中调用进程调用被调用进程,需要等待被调用进程返回结果才能结束此次调用;异步binder调用为调用进程调用被调用进程,不需要等待被调用进程返回结果,类似通知机制。本申请基于不同的binder进程间调用的通信类型设定不同的唤醒策略,对于binder同步调用,可以根据预设的binder进程间调用优先类型确定是否唤醒被调用进程以用于进程调用;对于binder异步调用,可以缓存binder进程间调用,并基于缓存的针对被调用进程的累积程度是否达到预设的累积程度标准或被调用进程的状态是否发生变化,以确定是否唤醒被调用进程以用于进程调用。由此,可以针对不同的binder进程间调用的通信类型,制定不同的进程的唤醒策略,可以在满足不同的binder进程间调用的通信类型的需求的基础上,可以有效地减少进程的唤醒。

示例性的,本申请的一种实现方式中,优先类型包括易用性优先,且若binder进程间调用的优先类型为易用性优先,则唤醒被调用进程以用于进程调用。具体的,易用性优先则为优先考虑进程的使用便捷性,若binder进程间调用的优先类型为易用性优先,则唤醒被调用进程以用于进程调用,由此可以保证对该被调用进程的使用需求。

示例性的,在本申请的一种可能的实现中,满足以下任一条件的binder进程间调用的优先类型为易用性优先:被调用进程或调用被调用进程的调用进程对应的应用为通过用户界面被选择为允许后台活动的应用;被调用进程或调用被调用进程的调用进程对应的应用为通过用户界面被选择为忽略功耗影响的应用;被调用进程或调用被调用进程的调用进程对应的应用为通过用户界面被选择为忽略内存影响的应用。

具体的,在一次binder进程间调用中,若调用进程和被调用进程中的至少一个进程对应的应用为允许后台活动的应用,则认为本次binder进程间调用的优先类型为易用性优先,需要唤醒被调用进程以用于进程调用。

同样的,在一次binder进程间调用中,若调用进程和被调用进程中的至少一个进程对应的应用为通过用户界面被选择为忽略功耗影响的应用,或为通过用户界面被选择为忽略内存影响的应用,则认为本次binder进程间调用的优先类型为易用性优先,需要唤醒被调用进程以用于进程调用。

具体的,前述忽略功耗影响的应用具体可以是指android系统中的忽略电池优化的应用。

需要说明的是,在binder进程间调用中,用户可以通过用户界面对应用进行设置,例如对于一些高频使用应用,或者对于用户重要的应用,用户可以将其选择为允许后台活动/忽略功耗影响/忽略内存影响的应用,则在判断调用进程和被调用进程中的至少一个进程对应的应用,为允许后台活动/忽略功耗影响/忽略内存影响的应用时,为方便用户的使用,可以确定此次binder进程间调用的类型为易用性优先,并唤醒被调用进程,以进行进程调用。

示例性的,本申请的一种实现方式中,优先类型包括功耗优先,且若binder进程间调用的优先类型为功耗优先,则判断调用被调用进程的调用进程是否为核心进程,若调用进程为核心进程,则唤醒被调用进程;若调用进程为非核心进程,则不唤醒被调用进程。

具体的,功耗优先则为优先考虑进程尽量占用少的功耗,并且在判断binder进程间调用的优先类型为功耗优先时,出于对基于该binder进程间调用相关功能的正常使用的考虑,可以通过判断该调用进程是否为核心进程,由此决定是否唤醒被调用进程,若该调用进程为核心进程,为保证该binder进程间调用相关功能的正常使用,则唤醒该被调用进程用于进程调用,若该调用进程为非核心进程,则即使不唤醒该被调用进程,也不影响用户的使用,因此,可以不唤醒该被调用进程。

需要说明的是,本申请中,binder进程间调用的优先类型可以只包括前述易用性优先和功耗优先两种类型,在判断binder进程间调用的优先类型时,可以只判断其是否为易用性优先类型,若否,则认为其是功耗优先类型,或者可以只判断其是否为功耗优先类型,若否,则认为其是易用性优先类型。当然,也可以分别判断binder进程间调用的优先类型是否为易用性优先类型和功耗优先类型,其可以根据需要具体选择和设置。

示例性的,本申请的一种实现方式中,满足以下任一条件的调用进程为核心进程:

调用进程对应的应用为通过应用白名单配置的应用。具体的,通过判断调用进程对应的应用是否为通过操作系统中的应用白名单(applicationwhitelisting)配置的应用,可以确定调用进程是否为核心进程,若调用进程对应的应用为通过系统中的应用白名单配置的应用,则认为该调用进程为核心进程。

调用进程为前台进程,且被用户正在前台使用。具体的,通过判断调用进程是否为被用户正在前台使用的前台进程可以确定调用进程是否为核心进程,若调用进程为前台进程,且被用户正在前台使用的进程,则认为该调用进程为核心进程。

操作系统中调用进程的adj值小于前台进程的adj值。具体的,可以将操作系统中调用进程的adj值于前台进程的adj值进行比较,若调用进程的adj值小于前台进程的adj值,则认为该调用进程为核心进程。

操作系统中调用进程为不在后台进程调度分组(sched_group_background)中的进程。具体的,处于后台进程调度分组中的进程未非核心进程,则通过判断调用进程是否处于后台进程调度分组中,可以确定调用进程是否为核心进程,若调用进程位于该后台进程调度分组中,则认为调用进程为非核心进程,若调用进程非处于该后台进程调度分组中,则该调用进程为核心进程。

调用进程对应的应用的uid小于预设的uid。具体的,该预设的uid的具体可以是操作系统中的第一应用分配uid(first_application_uid),具体的,若操作系统为android系统,则该first_application_uid为10000。当然,该预设的uid的具体值可以根据具体的选择和设置。

调用进程为操作系统中前台服务的进程。具体的,可以通过判断调用进程是否为操作系统中前台服务的进程,以判断该调用进程是否为核心进程,若调用进程为操作系统中的前台服务的进程,则认为该调用进程为核心进程。

调用进程为当前进行后台可感知业务的进程。具体的,可以通过判断调用进程是否为当前进行后台可感知业务的进程,以判断该调用进程是否为核心进程,若调用进程为当前进行后台可感知业务的进程,则认为该调用进程为核心进程。当前进行后台可感知业务的进程通常包括音乐播放、录音、下载、导航等应用对应的进程。

需要说明的是,判断调用进程是否是核心进程,具体可以判断调用进程是否满足前述任意一项,且只要满足其中任意一项,则认为调用进程为核心进程。若调用进程不满足前述任意一项,则认为调用进程为非核心进程。

前述操作系统具体可以是androidos,也可以是ios,或者其他类型的操作系统。

进一步地,也可以根据需要设置其他用于判断调用进程是否为核心进程的条件。

示例性的,本申请的一种实现方式中,若调用进程为核心进程,则唤醒被调用进程,以用于进程调用;若调用进程为非核心进程,则不唤醒被调用进程,并进一步还包括:将调用进程的状态标识为挂起状态,和/或将调用进程对应的应用的状态标识为挂起状态。

具体的,本申请中,若调用进程为非核心进程,则即使不执行该binder进程间调用,也不影响用户的当前使用,出于节省内存和/或降低功耗的考虑,在不唤醒被调用进程的基础上,可以将调用该被调用进程的调用进程的状态标识为挂起状态,并且将调用进程对应的应用的状态标识为挂起状态,或者也可以只将调用进程的状态标识为挂起状态,或者只将调用进程对应的应用的状态标识为挂起状态,其可以根据需要具体选择设置。

进一步地,对于通信类型为binder异步调用方式的binder进程间调用,为避免进程被频繁唤醒,则可以暂时缓存针对被调用进程的调用,在达到一定的唤醒条件时,再唤醒该被调用进程。进一步地,当该被调用进程被唤醒时,可以执行该缓存的binder进程间调用。

示例性的,本申请的一种实现方式中,若binder进程间调用的通信类型为binder异步调用,则缓存该binder进程间调用,并且缓存binder进程间调用,包括:缓存针对被调用进程的调用关系至异步调用缓存器中。具体的,电子设备中通常设置有异步调用缓存器,缓存针对binder异步调用方式的binder进程间调用,具体可以是将该binder进程间调用缓存至异步调用缓存器中。

示例性的,binder进程间调用在异步调用缓存器中的缓存状态具体可以如图5所示。其中,b为被调用进程,a、c皆为调用该被调用进程b的调用进程,缓存针对该被调用进程b的调用关系至异步调用缓存器中,具体为缓存“acallb”、“ccallb”等调用关系至该异步缓存器中。

进一步地,该异步调用缓存器具体为fifo(firstinputfirstoutput,先进先出)缓存器。

需要说明的是,当存在需要缓存多个不同的调用进程对被调用进程的binder进程间调用时,依次将各binder进程间调用缓存至该异步调用缓存器。

示例性的,本申请的一种实现方式中,若缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准,或被调用进程的状态由挂起状态转换为活跃状态,则唤醒被调用进程。

示例性的,本申请的一种实现方式中,缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准可以是针对被调用进程的异步调用缓存器的存储总量超过预设的存储阈值。具体的,如果针对被调用进程的异步调用缓存器的存储总量超过预设的存储阈值,则认为缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准。该预定阈值具体可以是针对被调用进程的异步调用缓存器的存储容量的四分之三,当然其可以根据需要具体设置。更为详细的,异步调用缓存器的存储容量为512k,该预设的存储阈值具体可以是384k,若异步调用缓存器的当前的存储总量为300k,则可以继续缓存针对被调用进程的binder进程间调用,若异步调用缓存器的当前的存储总量为384k,则不能继续缓存针对被调用进程的binder进程间调用,此时唤醒该被调用进程。

本申请的一种实现方式中,缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准,也可以是针对被调用进程的异步调用缓存器的可用存储空间小于预设的存储空间阈值。具体的,如果针对被调用进程的异步调用缓存器的可用存储空间小于预设的存储空间阈值,则认为缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准。该预设的存储空间阈值具体可以是针对被调用进程的异步调用缓存器的存储总量的四分之一,当然其可以根据需要具体设置。更为详细的,异步调用缓存器的存储容量为512k,该预设的存储空间阈值具体可以是128k,若异步调用缓存器的当前的可用存储空间为200k,则可以继续缓存针对被调用进程的binder进程间调用,若异步调用缓存器的当前的可用存储空间为128k,则不能继续缓存针对被调用进程的binder进程间调用,此时唤醒该被调用进程。

本申请的一种实现方式中,缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准,还可以是针对被调用进程的缓存调用次数达到预设的缓存调用次数阈值。具体的,预设的缓存调用次数阈值具体可以是100次,当缓存的针对被调用进程的调用次数达到100次时,认为缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准,此时唤醒被调用进程,进一步地,该唤醒的被调用进程可以用于进程调用。需要说明的是,预设的缓存调用次数阈值可以是100次,其也可以是根据需要设置的其他数值。

本申请的一种实现方式中,缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准,还可以是针对被调用进程的缓存调用时间达到预设的缓存调用时间阈值。具体的,预设的缓存调用时间阈值具体可以是30min,当缓存的针对被调用进程的缓存调用时间达到30min时,认为缓存的针对被调用进程的缓存的累积程度达到预设的累积程度标准,此时唤醒被调用进程,进一步地,该唤醒的被调用进程可以用于进程调用。需要说明的是,预设的缓存调用时间阈值可以是30min,当然其也可以是根据需要设置的其他数值。

示例性的,本申请的一种实现方式中,被调用进程被唤醒后,还包括:将被调用进程的状态由挂起状态转换为活跃状态,且将被调用进程对应的应用的状态由挂起状态转换为活跃状态。具体的,当被调用进程被唤醒后,将被调用进程的状态由挂起状态转换为活跃状态,且将被调用进程对应的应用的状态由挂起状态转换为活跃状态,以使被调用进程可以用于进程调用。

具体的,对于缓存在异步调用缓存器中的binder进程间调用,在满足上述被调用进程唤醒条件时,还需要从该异步调用缓存器中的缓存的binder进程间调用的列表中将针对该被调用进程的缓存删除。

示例性的,本申请的一种实现方式中,确定被调用进程是否为处于挂起状态的进程,包括:判断被调用进程的进程标识信息是否位于预设的管理进程列表中;管理进程列表包括与处于挂起状态的应用对应的进程的进程标识信息;若被调用进程的进程标识信息位于管理进程列表中,则被调用进程为处于挂起状态的进程;若被调用进程的进程标识信息未位于管理进程列表中,则被调用进程为处于非挂起状态的进程。

具体的,可以预先设置管理进程列表,将处于挂起状态的进程的进程标识信息加入该管理进程列表中,即管理进程列表中包括处于挂起状态的进程的进程标识信息。在判断被调用进程是否为处于挂起状态的进程时,通过判断该被调用进程的进程标识是否位于该管理进程列表中,则可以方便地确定该调用进程是否为处于挂起状态的进程。

示例性的,本申请的一种实现方式中,进程标识信息可以只包括进程id,比如“进程a—id”、“进程b—id”、“进程c—id”等。或者进程标识信息也可以只包括与处于挂起状态的进程对应的处于挂起状态的应用的uid,比如“应用1—uid”、“应用2—uid”、“应用3—uid”等。或者该进程标识信息可以同时包括进程id和与进程对应的应用的uid,比如“应用1—uid+进程a—id”、“应用2—uid+进程b—id”、“应用3—uid+进程c—id&进程d—id”以及“应用4—uid+进程c—id&进程a—id&进程e—id”等。其可以根据需要具体选择设置。

示例性的,本申请的一种实现方式中,处于挂起状态的应用,包括:进入后台后,在预设时间内无可感知业务的应用。对于进入后台后,在预设时间内无可感知业务的应用,为避免该应用继续占用内存及产生功耗,可以将该应用的状态转换为挂起状态,并将该应用对应的进程的状态转换为挂起状态,由此可以避免内存及功耗资源的消耗。当然,该处于挂起状态的应用具体也可以是系统未激活的应用等其他处于挂起状态的应用。

具体的,请参见图6,本申请中对应用及进程的状态进行管理具体包括:

s610:应用退后台,且处于活跃状态。

s620:在预设时间内是否无感知业务,若无,则执行步骤s630;如有,则继续执行步骤s620。

s630:将应用的状态标识为挂起状态。执行步骤s640。

s640:将应用对应的进程的状态标识为挂起状态,且将该应用对应的进程的进程id加入管理进程列表中。

具体的,应用退后台后,先进入活跃状态,检测预设时间t内应用是否无可感知业务,若检测到应用在预设时间t内无可感知业务,则将应用的状态标识为挂起状态,应用进程处于挂起状态后将该应用对应的进程的进程id加入预先设置的管理进程列表中。

需要说明的是,该预设时间可以根据需要具体设置,比如具体可以是5min,10min等。

进一步地,本申请中对应用及进程的状态进行管理还包括:判断处于挂起状态的进程或应用的状态是否转换为活跃状态,若处于挂起状态的进程的状态转换为活跃状态后,将进程的进程标识信息从管理进程列表中移除;和/或处于挂起状态的应用的状态转换为活跃状态后,将应用对应的进程的进程标识信息从管理进程列表中移除。

具体的,当处于挂起状态的进程的状态转换为活跃状态后,为保证进程的正常调用,可以将进程的进程标识信息从管理进程列表中移除。或者处于挂起状态的应用的状态转换为活跃状态后,为保证与该应用对应的进程的正常调用,可以将应用对应的进程的进程标识信息从管理进程列表中移除。由此,可以实时得对进程和/或应用的状态进行管理,以方便用户的使用。

进一步地,对于前述进入后台后,处于挂起状态的进程,若该应用被启动到前台,则将该应用的状态标识为活跃状态,且将该应用对应的进程的状态标识为活跃状态。或者进程被进行了binder调用时,将切换到活跃状态。

请参见图7,图7示出了本申请提供的一种进程管理装置的模块示意图。

本申请的一种实现方式中,进程管理装置包括:binder进程间调用管理模块710,binder进程间调用管理模块710用于在进行binder进程间调用时,确定binder进程间调用中的被调用进程是否为进入后台处于挂起状态的进程;并在确定被调用进程为处于挂起状态的进程时,根据预设的基于binder进程间调用的通信类型的唤醒策略确定是否唤醒被调用进程以用于进程调用;在确定被调用进程为处于非挂起状态的进程时,执行进程调用。即binder进程间调用管理模块710可以用于执行前述步骤s100~s300对应的进程管理方法。

本申请的另一种实现方式中,进程管理装置还包括:应用模块720和应用管理模块730;应用管理模块730用于对应用模块720中的应用的状态和应用对应的进程的状态进行管理,具体的,应用管理模块730用于确定应用模块720中进入后台的应用在预设时间内是否无可感知业务,若无,则将应用的状态标识为挂起状态;若有,则将应用的状态标识为活跃状态;针对标识为挂起状态的应用,应用管理模块730还用于将应用对应的进程的状态标识为挂起状态,并通知binder进程间调用管理模块710将进程的进程标识信息加入binder进程间调用管理模块710中预设的管理进程列表中。

本申请的一种实现方式中,应用管理模块730还用于:当被调用进程被唤醒后,通知binder进程间调用管理模块710将被调用进程的进程标识信息从管理进程列表中删除。

本申请的一种实现方式中,应用管理模块730还用于:当被调用进程被唤醒后,将被调用进程的状态由挂起状态转换为活跃状态,和/或将被调用进程对应的应用的状态由挂起状态转换为活跃状态。

本申请的一种实现方式中,应用管理模块730还用于:当调用被调用进程的调用进程的状态被标识为挂起状态时,将调用进程对应的应用的状态标识为挂起状态。

进一步地本申请提供的进程管理装置中,还可以包括binder驱动模块,binder驱动模块是实现binder进程间调用的核心模块,用于执行binder进程间调用等相关binder进程间调用处理。

需要说明的是,本申请提供的进程管理装置包括用于分别执行前述进程管理方法中的各步骤的binder进程间调用管理模块710、应用模块720和应用管理模块730,该binder进程间调用管理模块710、应用模块720和应用管理模块730分别用于执行对应的步骤,因此,对于相同部分,此处不再赘述。

进一步地,请参见图8,图8示出了一种进程管理方法,其具体包括:

s810:a进程binder进程间调用b进程。

s820:判断b进程是否为处于挂起状态的进程。若是,则执行s830;若否,则执行s890。

具体的,判断b进程是否为处于挂起状态的进程,具体可以是前述的binder进程间调用管理模块710通过前述的用于确定被调用进程是否为处于挂起状态的进程的方式确定,此处不再赘述。

s830:判断通信类型。

具体的,binder进程间调用管理模块710判断a进程binder进程间调用b进程的通信类型,若通信类型为binder同步调用,则执行s840;若通信类型为binder异步调用则执行s850。

s840:判断优先类型。

具体的,若通信类型为binder同步调用,则binder进程间调用管理模块710判断a进程binder进程间调用b进程的优先类型,若优先类型为易用性优先,则binder进程间调用管理模块710执行s870;若优先类型为功耗优先,则binder进程间调用管理模块710执行s860。

s850:缓存进行调用。

具体的,若通信类型为binder异步调用,binder进程间调用管理模块710缓存a进程对b进程的binder进程间调用。其缓存具体可以是缓存至如图5所示的异步缓存器中。

进一步地,缓存a进程对b进程的binder进程间调用之后,还包括,在满足预设条件时binder进程间调用管理模块710执行s870,以唤醒进程b。该预设条件具体可以是前述的针对被调用进程b的累积程度是否达到预设的累积程度标准或被调用进程b的状态是否发生变化,以确定是否唤醒被调用进程b以用于进程调用的条件,此处不再赘述。

s860:判断a进程是否为核心进程。若是,执行s870;若否,执行s880。

s870:唤醒b进程。

s880:不唤醒b进程,且挂起a进程。

s890:执行进程调用。

本实现方式提供的进程管理方法,在binder进程间调用中,对于被调用进程b进程,先判断b进程是否为挂起状态的进程,若b进程为挂起状态的进程,则根据预设的唤醒策略判断是否唤醒该b进程,若b进程为非挂起状态(活跃状态)的进程,则执行进程调用。具体的,该唤醒策略包括先判断本次binder进程间调用的通信类型为binder同步调用还是binder异步调用。

若本次binder进程间调用的通信类型为binder同步调用,则进一步判断本次binder进程间调用的优先类型,根据确定的优先类型确定是否唤醒b进程。具体的,若优先类型为易用性优先,则立即唤醒b进程,处理binder进程间调用。若优先类型为功耗优先,则进一步判断a进程是否为核心进程,如果a进程不是核心进程,则不唤醒b进程,且同时将a进程挂起(休眠),暂停本次binder进程间调用;若a进程是核心进程,则唤醒b进程,处理binder进程间调用。

若本次binder进程间调用的通信类型为binder异步调用,则缓存本次binder进程间调用至针对b进程的异步缓存器中,待满足预设的唤醒条件时,唤醒b进程以用于进程调用。

进一步地,唤醒b进程后,应用管理模块730将b进程的状态从挂起状态转换为活跃状态。进一步地,该应用管理模块730还可以将b进程对应的应用的状态从挂起状态转换为活跃状态。

进一步地,将a进程挂起后,应用管理模块730将a进程的状态从活跃状态转换为挂起状态。进一步地,应用管理模块730还可以将a进程对应的应用的状态从活跃状态转换为挂起状态。

若缓存了多个针对该b进程的binder进程间调用,则在唤醒b进程后,由b进程依次处理缓存的所有针对b进程的binder进程间调用。

本实现方式提供的进程管理方法,在binder进程间调用中,通过设置的前述基于binder进程间调用的通信类型的唤醒策略确定是否唤醒被调用进程,相比于现有技术中,在发生binder进程间调用时直接唤醒被调用进程以用于进程调用的方法,可以有效地减少进程被唤醒的次数,以减少内存占用和功耗资源的损耗,而且还能满足用户的正常使用需求。

参见图9,图9所示为根据本申请的一实施方式提供的电子设备900的结构示意图。电子设备900可以包括耦合到控制器中枢904的一个或多个处理器901。对于至少一个实施例,控制器中枢904经由诸如前端总线(fsb)之类的多分支总线、诸如快速通道互连(qpi)之类的点对点接口、或者类似的连接与处理器901进行通信。处理器901执行控制一般类型的数据处理操作的指令。在一实施例中,控制器中枢904包括,但不局限于,图形存储器控制器中枢(gmch)(图中未示出)和输入/输出中枢(ioh)(其可以在分开的芯片上)(图中未示出),其中gmch包括存储器和图形控制器并与ioh耦合。

电子设备900还可包括耦合到控制器中枢904的协处理器906和存储器902。或者,存储器902和gmch中的一个或两者可以被集成在处理器901内(如本申请中所描述的),存储器902和协处理器906直接耦合到处理器901以及控制器中枢904,控制器中枢904与ioh处于单个芯片中。

存储器902可以是例如动态随机存取存储器(dram)、相变存储器(pcm)或这两者的组合。

在一个实施例中,协处理器906是专用处理器,诸如例如高吞吐量mic处理器、网络或通信处理器、压缩引擎、图形处理器、gpgpu、或嵌入式处理器等等。协处理器906的任选性质用虚线表示在图9中。

在一个实施例中,电子设备900可以进一步包括网络接口(nic)903。网络接口903可以包括收发器,用于为电子设备900提供无线电接口,进而与任何其他合适的设备(如前端模块,天线等)进行通信。在各种实施例中,网络接口903可以与电子设备900的其他组件集成。网络接口903可以实现上述实施例中的通信单元的功能。

电子设备900可以进一步包括输入/输出(i/o)设备905。输入/输出(i/o)设备905可以包括:用户界面,该设计使得用户能够与电子设备900进行交互;外围组件接口的设计使得外围组件也能够与电子设备900交互;和/或传感器设计用于确定与电子设备900相关的环境条件和/或位置信息。

值得注意的是,图9仅是示例性的。即虽然图9中示出了电子设备900包括处理器901、控制器中枢904、存储器902等多个器件,但是,在实际的应用中,使用本申请各方法的设备,可以仅包括电子设备900各器件中的一部分器件,例如,可以仅包含处理器901和nic903。图9中可选器件的性质用虚线示出。

在该电子设备900的存储器中可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性计算机可读介质。计算机可读存储介质中存储有指令,具体而言,存储有该指令的暂时和永久副本。

本申请中,该电子设备900具体可以是前述的手机、平板电脑、个人数字助理(personaldigitalassistant,pda)或台式电脑等终端设备。该电子设备的存储器中存储的指令可以包括:由处理器中的至少一个单元执行时导致电子设备实施如前述提到的进程管理方法的指令。

参见图10,图10所示为根据本申请的一实施方式提供的soc(systemonchip,片上系统)1000的结构示意图。在图10中,相似的部件具有同样的附图标记。另外,虚线框是更先进的soc1000的可选特征。该soc1000可以被用于根据本申请的任一电子设备,根据其所在的设备不同以及其内所存储的指令的不同,可以实现相应的功能。

在图10中,soc1000包括:互连单元1002,其被耦合至处理器1001;系统代理单元1006;总线控制器单元1005;集成存储器控制器单元1003;一组或一个或多个协处理器1007,其可包括集成图形逻辑、图像处理器、音频处理器和视频处理器;sram(静态随机存取存储器)单元1008;dma(直接存储器存取)单元1004。在一个实施例中,协处理器1007包括专用处理器,诸如例如网络或通信处理器、压缩引擎、gpgpu、高吞吐量mic处理器、或嵌入式处理器等等。

sram单元1008中可以包括用于存储数据和/或指令的一个或多个计算机可读介质。计算机可读存储介质中可以存储有指令,具体而言,存储有该指令的暂时和永久副本。该指令可以包括:由处理器中的至少一个单元执行时导致电子设备实施如前述所提到的进程管理方法的指令。

本申请公开的机制的各实施例均可以以软件、硬件、固件或这些实现方法的组合等方式实现。本申请的实施例可实现为在可编程系统上执行的计算机程序或程序代码,该可编程程序包括至少一个处理器、存储器(或存储系统,包括易失性和非易失性存储器和/或存储单元)。

可将程序代码应用于输入指令,以执行文本描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。可以理解,在本申请的实施例中,处理系统可以是微处理器、数字信号处理器(dsp)、微控制器、专用集成电路(asic)等,和/或其任何组合。根据另一方面,处理器可以是单核处理器、多核处理器等,和/或其任何组合。

程序代码可以用高级程序化语言或面向对象的编程语言来实现,以便与处理器通信。在需要时,也可用汇编语言或机器语言来实现程序代码。事实上,文本中描述的机制不限于任何特定编程语言的范围。在任一情形下,该语言可以是编译语言或解释语言。

在一些情况下,所公开的实施例可以以硬件、固件、软件或其他任何组合来实现。所公开的实施例可以被实现为一个或多个暂时或非暂时性及其可读(例如,计算机可读)存储介质承载或存储在其上的指令,其可以由一个多个处理器读取和执行。例如,指令通过网络或气压计算机可读取介质分发。因此,机器可读取介质可以包括用于机器(例如,计算机)可读的形式存储或传输信息的任何机制,包括但不限于,软盘、光盘、光碟、只读存储器(cd-roms)、磁光盘、只读存储器(rom)、随机存取存储器(ram)、可擦除可编程只读存储器(eprom)、电可擦除可编程只读存储器(eeprom)、磁卡或光卡、闪卡、或用于利用因特网以电、光、声或其他形式的传播信号来传输信息(例如,载波、红外信号数字等)的有形的机器可读取存储器。因此,机器可读取介质包括适合于以机器可读的形式存储或传输电子指令或信息的任何类型的机器可读介质。

至少一个实施例的一个或多个方面可以由存储在计算机可读取存储介质上的表示性指令来实现,指令表示处理器中的各种逻辑,指令在被机器读取时使得该机制作用于执行文本所述的技术的逻辑。被称为“ip核”的这些表示可以被存储在有形的计算机可读取存储介质上,并被提供给多个客户或生产设备实施以加载到实际制造该逻辑或处理器的制造机器中。

在一些情况下,指令转换器可用来将指令从源指令集转移至目标指令集。例如,指令转换器可以变换(例如使用静态二进制变换、包括动态编译的动态二进制变换)、变形、仿真或以其他方式将指令转换成由核来处理的一个或多个其他指令。指令转换器可以用软件、硬件、固件、或其他组合实现。指令转换器可以在处理器上、在处理器外、或者部分在处理器上且部分在处理器外。

需要说明的是,如本文所使用的,术语“模块”可以指代或者专用集成电路(asic)、电子电路、执行一个或多个软件或固件程序的处理器(共享、专用或群组)和/或存储器、组合逻辑电路、和/或提供所描述的功能的其他适当硬件组件,或者可以作为这些硬件组合的一部分。即本申请各设备实施例中的各模块都是逻辑模块,在物理上,一个逻辑模块可以是一个物理单元,也可以是一个物理单元的一部分,还可以是多个物理单元的组合实现。另外,本申请上述各设备实施例并没有将于解决本申请所提出的技术问题关系不太密切的模块引入,这并不表明上述设备实施例并不存在其他的模块。

需要说明的是,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。

需要说明的是,在附图中,可以以特定布置和/或顺序示出一些结构或方法特征。然而,应该理解,可能不需要这样的特定布置和/或排序。而是,在一些实施例中,这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外,在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征,并且在一些实施例中,可以不包括这些特征或者可以与其他特征组合。

虽然通过参照本申请的某些优选实施方式,已经对本申请进行了图示和描述,但本领域的普通技术人员应该明白,以上内容是结合具体的实施方式对本申请所作的进一步详细说明,不能认定本申请的具体实施只局限于这些说明。本领域技术人员可以在形式上和细节上对其作各种改变,包括做出若干简单推演或替换,而不偏离本申请的精神和范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1