CN105302637A

CN105302637A - ***进程运行异常引起卡顿的恢复方法、装置及移动终端

Info

Publication number: CN105302637A
Application number: CN201510664846.XA
Authority: CN
Inventors: 王旭康
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2015-10-13
Filing date: 2015-10-13
Publication date: 2016-02-03
Anticipated expiration: 2035-10-13
Also published as: CN105302637B

Abstract

本发明公开了一种***进程运行异常引起***卡顿的恢复方法、装置及移动终端，其中所述方法具体为：统计并检测***进程，监测操作***是否发生卡顿阻塞；若检测到存在卡顿阻塞，则查找造成卡顿阻塞的***进程中内存占用率最多的一个或几个***进程，并标记为禁止进程；启动定时器T1，通知操作***在定时器T1内禁止调用所述禁止进程；降低造成卡顿阻塞的所述***进程的优先级。通过上述恢复方法可自动检测***卡顿并通过启动定时器T1通知操作***在定时器T1内禁止调用所述禁止进程以及降低造成卡顿阻塞的***进程的优先级，减少操作***的卡顿及不流畅现象，提升用户操作体验，享受移动终端的流畅操作。

Description

***进程运行异常引起卡顿的恢复方法、装置及移动终端

技术领域

本发明涉及移动终端的通信技术领域，特别涉及一种用于***进程运行异常引起卡顿的恢复方法、装置及移动终端。

背景技术

在使用Android操作***的移动终端平台中，***进程(logd进程，服务进程，camera进程，内存回收进程等)的合理调度使用，使得用户的移动终端可以协调流畅的运行。移动终端操作***可能由于***进程的频繁运行大量占用CPU会起卡顿，不流畅等异常。

移动终端操作***卡顿问题是工程技术人员在开发过程中以及移动终端用户在使用过程中经常遇到的性能问题，***进程(logd进程，服务进程，camera进程，内存回收进程等)频繁运行异常问题就是一个很典型的引起Android操作***卡顿的原因。移动终端操作***因为***进程(logd进程，服务进程，camera进程，内存回收进程等)频繁运行异常引起的移动终端UI(UserInterface)用户界面不流畅等现象，给用户带来不良的操作体验，并可能最终导致用户无法正常操作使用而需要退机重启。

发明内容

本发明的目的在于克服现有技术的缺点与不足，提供一种用于***进程运行异常引起卡顿的恢复方法、装置及移动终端

根据公开的实施例，本发明的第一方面提出了一种用于***进程运行异常引起***卡顿的恢复方法，包括下列步骤：

统计并检测***进程，监测操作***是否发生卡顿阻塞；

若检测到存在卡顿阻塞，则查找造成卡顿阻塞的***进程中内存占用率最多的一个或几个***进程，并标记为禁止进程；

启动定时器T1，通知操作***在定时器T1内禁止调用所述禁止进程。

进一步地，所述统计并检测***进程，监测操作***是否发生卡顿阻塞包括：

初始化阈值时间T、阀值比例m、统计周期时间TT、每次调用***进程的时间Tij，其中，i＝1，2，3，…，i表示第i个进程，j＝1,2，…，j表示第j次调用第i个进程；

分别计算所述***进程在所述统计周期时间TT内多次前后调用时间平均差值ΔTi，其中计算公式如下：

Δ T i = \frac{Σ_{j = 1}^{j - 1} (T_{i j + 1} - T_{i j})}{j - 1};

分别比较所述调用时间平均差值ΔTi是否小于所述阈值时间T，若小于，进入下一步骤；

获取所述***进程的内存占用率，并比较是否超过所述阀值比例m，若超过，则判断所述***进程为阻塞进程。

进一步地，所述启动定时器T1，通知操作***在定时器T1内禁止调用所述禁止进程之后，还包括：

降低造成卡顿阻塞的所述***进程的优先级。

进一步地，所述***进程的优先级由高到低依次包括前台进程、可见进程、次要服务、后台进程、内容供应节点、空进程。

进一步地，所述***进程的优先级通过变量“oom_adj”以数值表示出来，赋予各个进程，所述变量“oom_adj”的值越大，进程的优先级越低。

根据公开的实施例，本发明的第二方面提出了一种用于***进程运行异常引起***卡顿的恢复装置，包括下列模块：

监测模块，用于统计并检测***进程，监测操作***是否发生卡顿阻塞；

查找模块，用于若检测到存在卡顿阻塞，则查找造成卡顿阻塞的***进程中内存占用率最多的一个或几个***进程，并标记为禁止进程；

第一处理模块，用于启动定时器T1，通知操作***在定时器T1内禁止调用所述禁止进程。

进一步地，所述监测模块包括：

初始化单元，用于初始化阈值时间T、阀值比例m、统计周期时间TT、每次调用***进程的时间Tij，其中，i＝1，2，3，…，i表示第i个进程，j＝1,2，…，j表示第j次调用第i个进程；

计算单元，用于分别计算所述***进程在所述统计周期时间TT内多次前后调用时间平均差值ΔTi，其中计算公式如下：

Δ T i = \frac{Σ_{j = 1}^{j - 1} (T_{i j + 1} - T_{i j})}{j - 1};

第一判断单元，用于分别比较所述调用时间平均差值ΔTi是否小于所述阈值时间T，若小于，进入下一单元；

第二判断单元，用于获取所述***进程的内存占用率，并比较是否超过所述阀值比例m，若超过，则判断所述***进程为阻塞进程。

进一步地，还包括：

第二处理模块，用于降低造成卡顿阻塞的所述***进程的优先级。

根据公开的实施例，本发明第三方面提出了一种移动终端，所述移动终端包括权利要求6至8任一项所述的一种用于***进程运行异常引起***卡顿的恢复装置。

本发明相对于现有技术具有如下的优点及效果：

本发明公开的***进程运行异常引起***卡顿的恢复方法可以自动检测***卡顿阻塞并通过启动定时器T1通知操作***在定时器T1内禁止调用所述禁止进程以及降低造成卡顿阻塞的***进程的优先级，减少操作***的卡顿及不流畅现象，提升用户操作体验，享受移动终端的流畅操作，避免用户由于***卡顿而造成的开机重启现象发生。

附图说明

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

图1是本实施例一中公开的一种***进程运行异常引起卡顿的恢复方法的流程步骤图；

图2是本实施例一中公开的又一种***进程运行异常引起卡顿的恢复方法的流程步骤图；

图3是本实施例一中公开的另一种***进程运行异常引起卡顿的恢复方法的流程步骤图；

图4是本实施例二中公开的一种***进程运行异常引起卡顿的恢复装置的结构组成框图；

图5是本实施例二中公开的又一种***进程运行异常引起卡顿的恢复装置的结构组成框图；

图6是本实施例二中公开的另一种***进程运行异常引起卡顿的恢复装置的结构组成框图。

具体实施方式

为使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，以下参照附图并举实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

以下根据实施例分别进行详细说明。

实施例一

请参见图1，图1是本实施例一中一种***进程运行异常引起卡顿的恢复方法的流程步骤图。图1所示的一种***进程运行异常引起卡顿的恢复方法，应用于智能移动终端，所述智能移动终端包括但不限于手机、笔记本电脑、平板电脑和掌上上网设备、多媒体设备、流媒体设备、移动互联网设备(MID，mobileinternetdevice)、可穿戴设备或其他类型的终端设备。

本发明实施例中所述操作***为Android操作***，但是针对Android操作***的描述并不构成对本技术方案的限制，同样的解决技术方案可以类似延展到symbian、Linux、Palm、BlackBerry、WindowsMobile或iOS操作***。

该方法通过***自动检测判断***进程(logd进程，服务进程，camera进程，内存回收进程等)运行是否异常，当判断发生异常，通过在规定时间内禁止调用***进程以及降低***进程优先级的措施，保持移动终端操作***保持流畅。当发生异常时，移动终端通过自动启动定时器T，在时间段内禁止调用***进程。下面结合图1，具体说明一种Android操作******进程运行异常引起***卡顿的检测恢复方法的流程步骤：

步骤S101、统计并检测***进程，监测是否发生卡顿阻塞；

Android操作***将进程分为六大类：

1.前台进程(foreground)：目前正在屏幕上显示的进程和一些***进程。举例来说，DialerStorage，GoogleSearch等***进程就是前台进程；再举例来说，当移动终端运行一个程序，如浏览器，当浏览器界面在前台显示时，浏览器属于前台进程(foreground)，但一旦用户按home回到主界面，浏览器就变成了后台程序(background)。移动终端用户最不希望终止的进程就是前台进程。

2.可见进程(visible)：可见进程是一些不再前台，但用户依然可见的进程，举个例来说：widget、输入法等，都属于visible。这部分进程虽然不在前台，但与用户的使用也密切相关，移动终端用户也不希望它们被终止(用户肯定不希望时钟、天气，新闻等widget被终止，那它们将无法同步，用户也不希望输入法被终止，否则你每次输入时都需要重新启动输入法)

3.次要服务(secondaryserver)：目前正在运行的一些服务(主要服务，如拨号等，是不可能被进程管理终止的，故这里只谈次要服务)，举例来说：谷歌企业套件，Gmail内部存储，联系人内部存储等。这部分服务虽然属于次要服务，但很一些***功能依然息息相关，移动终端用户时常需要用到这些进程，所以也不希望这些进程被终止。

4.后台进程(hidden)：hidden实际即是后台进程(background)，就是通常意义上理解的启动后被切换到后台的进程，如浏览器，阅读器等。当程序显示在屏幕上时，它所运行的进程即为前台进程(foreground)，一旦用户按home返回主界面(注意是按home，不是按back)，程序就驻留在后台，成为后台进程(background)。后台进程的管理策略有多种：有较为积极的方式，一旦程序到达后台立即终止，这种方式会提高程序的运行速度，但无法加速程序的再次启动；也有较消极的方式，尽可能多的保留后台程序，虽然可能会影响到单个程序的运行速度，但在再次启动已启动的程序时，速度会有所提升。这里就需要用户根据自己的使用***衡点。

5.内容供应节点(contentprovider)：没有程序实体，进提供内容供别的程序去用的，比如日历供应节点，邮件供应节点等。在终止进程时，这类程序应该有较高的优先权。

6.空进程(empty)：没有任何东西在内运行的进程，有些程序，比如BTE，在程序退出后，依然会在进程中驻留一个空进程，这个进程里没有任何数据在运行，作用往往是提高该程序下次的启动速度或者记录程序的一些历史信息。这部分进程无疑是应该最先终止的。

因为造成阻塞的原因是统计周期时间TT内多次前后调用***进程时间差值ΔTi超过定时的阈值时间T并且该***进程运行占用CPU的比例大于阈值比例m(％)，此时默认该***进程将导致操作***的卡顿。步骤S101的具体细化如下，相关的流程图可以参照附图2：

步骤S1011、初始化阈值时间T，初始化阀值比例m，初始化统计周期时间TT，初始化每次调用***进程的时间Tij，其中，i＝1，2，3，…；i表示第i个进程，j＝1,2，…；j表示第j次调用第i个进程。

比如：针对统计记录中的第三种进程，i记为3，在统计周期时间TT内第4次调用第3种***进程的时间记为T34，类似情况以此类推。

步骤S1012、分别计算所述***进程在所述统计周期时间TT内多次前后调用时间平均差值ΔTi，其中计算公式如下：

Δ T i = \frac{Σ_{j = 1}^{j - 1} (T_{i j + 1} - T_{i j})}{j - 1};

该步骤用于分别计算各个***进程i在统计周期时间TT内多次前后调用时间的统计平均差值ΔTi，通过该平均差值ΔTi判断在统计周期时间TT内该第i个进程是否被过于频繁调用。

步骤S1013、分别比较所述调用时间平均差值ΔTi是否小于所述阈值时间T，若小于，进入下一步骤；

该步骤用于分别判断各种***进程i在统计周期时间TT内多次前后调用时间的统计平均差值ΔTi与所述阈值时间T的大小，如果小于阀值时间T，则判定该***进程被过于频繁调用，则可能引起***卡顿的诱因非常大，进入下一判断步骤；如果大于阀值时间T，则判断该***进程未被过于频繁调用，该***进程i不会成为引起***卡顿的因素。

步骤S1014、获取所述***进程的内存占用率，并比较是否超过阀值比例m，若超过，则判断所述***进程为阻塞进程。

该步骤在上述步骤S103的基础上，当比较某第i个进程在统计周期时间TT内多次前后调用时间的统计平均差值ΔTi小于所述阈值时间T，判断第i个***进程在统计周期时间TT内被频繁调用，继续判断所述***进程的内存占用率，首先获取所述***进程的内存占用率，然后比较所述***进程的内存占用率是否超过阀值比例m，其中，内存占用的阀值比例m是工程技术人员根据开发经验定义的一个阀值，若超过阀值比例m，则判断所述***进程为阻塞进程，若未超过阀值比例m，则判断所述***进程的运行和调用不会引起***的卡顿。

步骤S102、若检测到存在阻塞进程，则查找所述阻塞进程中内存占用率最多的一个或几个***进程，并标记为禁止进程；

本步骤中，当检测到存在某个或者某几个***进程在一个统计周期时间TT内多次前后调用时间的统计平均差值ΔTi小于所述阈值时间T，并且同时该个***进程的内存占用率超过阀值比例m，将上述一个或者几个***进程标注为禁止进程，确定其为造成***卡顿的问题进程。

步骤S103、启动定时器T1，通知操作***在定时器T1内禁止调用所述禁止进程。

一旦确定了引起***卡顿的问题进程，启动定时器T1，同时将禁止进程的进程名单列表发送给操作***，通知操作***在定时器T1内禁止调用进程名单列表上进程。

在另一优选的实施例中，本实施例公开的一种***进程运行异常引起卡顿的恢复方法在所述步骤S103、启动定时器T1，通知操作***在定时器T1内禁止调用所述禁止进程之后，还包括下列步骤，具体流程步骤图可参照附图3所示：

步骤S104、降低发生阻塞的***进程的优先级。

Android操作***会对***进程的重要性进行评估，并将重要性以“oom_adj”这个数值表示出来，赋予各个进程。操作***会根据“oom_adj”来判断需要优先结束哪些进程，一般来说，“oom_adj”的值越大，该进程***作***选中终止的可能就越高，前台程序的“oom_adj”值为0，这意味着它不会***作***终止。Android操作***将***进程分为6个等级，它们按优先级顺序由高到低依次是:foreground(前台进程)、visible(可见进程)、secondaryserver(次要服务)、hidden(后台进程)、contentprovider(内容供应节点)、empty(空进程)；同时，结束进程的顺序：Empty(空进程)>contentprovider(内容供应节点)>hidden(后台进程)>secondaryserver(次要服务)>visible(可见进程)>foreground(前台进程)。

Android操作***可根据“oom_adj”值的范围来决定进程管理策略，比如可以设定“当内存小于X时，结束“oom_adj”大于Y的进程”。

查看现在的设置可以:

shellandroid:/sys/module/lowmemorykiller/parameters$catminfree3599,4881,6164,8212,9495,11294相对应的Foreground>Visible>SecondaryServer>Hidden>ContentProvider>Empty显示出的应该是6个数字，以逗号隔开，例如:3599，4881，6164，8212，9495，11294注意这些数字的单位是page.1page＝4kb。上面的六个数字对应的就是(MB):14,19,24,32,37,44，这些数字也就是对应的内存阀值,一旦低于该值，Android操作***便开始按顺序关闭***进程。因此，当可用内存小于44MB(11294*4/1024)时，Android操作***开始结束优先级最低的EMPTY_APP。

综上所述，当移动终端开机正常工作后，操作***对***进程进行监测，检测出引起阻塞的***进程，然后操作***通过启动定时器在禁止时间周期T1内禁止调用该阻塞进程，同时通过降低调用异常频繁引起***卡顿的所述***进程的优先级，降低发生进程阻塞的***进程的优先级，实现卡顿自动检测和恢复功能，以避免操作***卡顿不流畅的问题出现。

实施例二

为了实现由于***进程运行异常引起卡顿的自动检测和恢复功能以避免操作***卡顿不流畅的问题出现的目的，本实施例公开了一种***进程运行异常引起卡顿的恢复装置及移动终端，该***进程运行异常引起卡顿的恢复装置可以是运行于各终端设备(例如手机、平板电脑、掌上上网设备)内的软件单元、硬件单元或者软硬件相结合的单元，也可以作为独立的挂件集成到所述终端设备中或者运行于所述终端设备的应用***中。

图4示出了本发明第二实施例提供的一种***进程运行异常引起卡顿的恢复装置的组成结构框图，为了便于描述，仅示出了与本发明实施例相关的部分。

如图4所示，本实施例二公开的一种***进程运行异常引起卡顿的恢复装置，包括下列模块：监测模块201、查找模块202、第一处理模块203。

其中，监测模块201，用于统计并检测***进程，监测操作***是否发生卡顿阻塞。

所述监测模块又具体包括下列单元：

初始化单元2011，用于初始化阈值时间T、阀值比例m、统计周期时间TT、每次调用***进程的时间Tij，其中，i＝1，2，3，…，i表示第i个进程，j＝1,2，…，j表示第j次调用第i个进程；

计算单元2012，用于分别计算所述***进程在所述统计周期时间TT内多次前后调用时间平均差值ΔTi，其中计算公式如下：

Δ T i = \frac{Σ_{j = 1}^{j - 1} (T_{i j + 1} - T_{i j})}{j - 1};

第一判断单元2013，用于分别比较所述调用时间平均差值ΔTi是否小于所述阈值时间T，若小于，进入下一单元；

第二判断单元2014，用于获取所述***进程的内存占用率，并比较是否超过所述阀值比例m，若超过，则判断所述***进程为阻塞进程。

所述监测模块具体组成结构的组成框图可参照附图5所示。

查找模块202，用于若检测到存在卡顿阻塞，则查找所述阻塞进程中内存占用率最多的一个或几个***进程，并标记为禁止进程。

第一处理模块203，用于启动定时器T1，通知操作***在定时器T1内禁止调用所述禁止进程。

在另一优选的实施方式中，本实施例公开的一种***进程运行异常引起***卡顿的恢复装置还包括：第二处理模块204，

其中，第二处理模块，用于降低发生阻塞的所述***进程的优先级。

包括上述第二处理模块的恢复装置的具体结构框图可以参照附图6所示。

基于同一发明构思，本发明实施例提供的一种***进程运行异常引起***卡顿的恢复装置及移动终端，在解决问题的原理与前述***进程运行异常引起***卡顿的恢复方法相似，因此该装置及移动终端的实施可以参见前述方法的实施，上述描述的模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

综上所述，本发明实施例二公开的***进程运行异常引起***卡顿的恢复装置及移动终端，该实现装置的各个模块、单元配合工作，自动检测***进程(logd进程，服务进程，camera进程，内存回收进程等)运行是否异常，当检测到***进程频繁运行发生异常时，自动的启动定时器T1，在时间段T1禁止调用***进程，同时降低***进程的优选级，通过本实施例公开的***进程运行异常引起***卡顿的恢复装置可以减少操作***的卡顿及不流畅现象，提升用户操作体验，享受移动终端的流畅操作，避免用户由于***卡顿而造成的开机重启现象发生。

值得注意的是，上述装置或终端实施例中，所包括的各个模块和单元只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各模块和单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的终端实施例仅仅是示意性的，例如，所述模块或者单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，模块或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本发明各个实施例中的各功能模块或单元可以集成在一个处理模块或者单元中，也可以是各个模块或者单元单独物理存在，也可以两个或两个以上模块或者单元集成在一个模块或者单元中。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims

1.一种***进程运行异常引起***卡顿的恢复方法，其特征在于，包括下列步骤：

统计并检测***进程，监测操作***是否发生卡顿阻塞；

2.根据权利要求1所述的一种***进程运行异常引起***卡顿的恢复方法，其特征在于，所述统计并检测***进程，监测操作***是否发生卡顿阻塞包括：

Δ T i = \frac{Σ_{j = 1}^{j - 1} (T_{i j + 1} - T_{i j})}{j - 1};

3.根据权利要求1所述的一种***进程运行异常引起***卡顿的恢复方法，其特征在于，

所述启动定时器T1，通知操作***在定时器T1内禁止调用所述禁止进程之后，还包括：

降低造成卡顿阻塞的所述***进程的优先级。

4.根据权利要求3所述的一种***进程运行异常引起***卡顿的恢复方法，其特征在于，

所述***进程的优先级由高到低依次包括前台进程、可见进程、次要服务、后台进程、内容供应节点、空进程。

5.根据权利要求3所述的一种***进程运行异常引起***卡顿的恢复方法，其特征在于，

所述***进程的优先级通过变量“oom_adj”以数值表示出来，赋予各个进程，所述变量“oom_adj”的值越大，进程的优先级越低。

6.一种***进程运行异常引起***卡顿的恢复装置，其特征在于，包括下列模块：

7.根据权利要求6所述的一种***进程运行异常引起***卡顿的恢复装置，其特征在于，所述监测模块包括：

Δ T i = \frac{Σ_{j = 1}^{j - 1} (T_{i j + 1} - T_{i j})}{j - 1};

8.根据权利要求6所述的一种***进程运行异常引起***卡顿的恢复装置，其特征在于，还包括：

9.一种移动终端，其特征在于，所述移动终端包括权利要求6至8任一项所述的一种***进程运行异常引起***卡顿的恢复装置。