件暂停事件(即调用onPause()回调方法)时，对被暂停的组件所在进程的计数字段减少计数值。
[0118]以Activity组件为例，当接收到Activity组件恢复事件时，对其所在进程的计数字段mResumedActivityCount增加计数值，如I或2等；当接收到Activity组件暂停事件时，对其所在进程的计数字段mResumedActivityCount减少计数值，如I或2等，本发明对此不做限制。
[0119]基于上文对应用程序中的各进程设置的计数字段，本发明实施例提供了一种实施上文步骤S302的可选方案，在该方案中，可以读取当前进程的计数字段，进而判断计数字段的计数值是否大于指定阈值，若是，则确定当前进程内运行的各组件中存在被恢复的组件；若否，则确定当前进程内运行的各组件中不存在被恢复的组件。
[0120]本发明实施例还提供了另一种可选地确定是否对当前进程进行回收处理的方案，图4示出了根据本发明另一个实施例的确定是否对当前进程进行回收处理的方法的流程图。如图3所示，该方法至少包括以下步骤S302至步骤S306。
[0121]步骤S402，判断当前进程是否为空进程或后台进程，若是，则继续执行步骤S404;否则，继续执行步骤S406。
[0122]在该步骤中，可以先获取当前进程的标识符，在系统中查找当前进程的标识符的RunningAppProcessInfo(该接口封装了正在运行的进程的信息)，调用其importance字段。如果该字段值为IMP0RTANCE_EMPTY，则表示当前进程为空进程；如果该字段值为importance_background，则表示当前进程为后台进程。
[0123]步骤S404，确定对当前进程进行回收处理。
[0124]步骤S406，确定对当前进程不进行回收处理。
[0125]在该步骤中，若当前进程不为空进程或后台进程，可以对当前进程不进行回收处理，也可以采用前文图3所示的方法或者后续提及的方法进一步判断。
[0126]在本发明一实施例中，可以在指定类中注册不能被回收的组件。在一个应用程序内，通常拥有一个或多个Activity、Service、ContentProVider、BroadcastReceiver，在应用程序运行的过程中，对于不能被回收的组件，可以将其注册到指定类中。例如，自定义类IKiliable，将不能被回收的组件注册到该自定义类中，它有一个方法isKillable()，在判断组件是否需要被回收时，可以调用该方法isKillableO，由该方法isKillable()查找组件是否注册到该自定义类中，若该方法返回false，则表示组件注册到该自定义类中，该组件不能被回收。若该方法返回true，则表示组件未注册到该自定义类中，可以回收该组件或者继续通过其他方法判断是否回收该组件。
[0127]基于上文的指定类，本发明实施例还提供了另一种可选地确定是否对当前进程进行回收的方案，图5示出了根据本发明又一个实施例的确定是否对当前进程进行回收处理的方法的流程图。如图5所示，该方法至少包括以下步骤S502至步骤S506。
[0128]步骤S502，判断当前进程内运行的各组件是否注册到指定类中，若当前进程内运行的各组件中存在至少一个组件注册到指定类中，则继续执行步骤S504;若当前进程内运行的各组件中不存在组件注册到指定类中，则继续执行步骤S506。
[0129]在该步骤中，可以调用指定类的判断方法，由判断方法查找当前进程内运行的各组件是否注册到指定类中，进而接收判断方法返回的查找结果，根据查找结果确定是否回收当前进程。
[0130]步骤S504，确定对当前进程不进行回收处理。
[0131]步骤S506，确定对当前进程进行回收处理。
[0132]在该步骤中，若当前进程内运行的各组件中不存在组件注册到指定类中，可以对当前进程进行回收处理，也可以采用保守的方案，即不回收处理，可以采用前文图3或图4的方法进一步判断。
[0133]在实际应用中，可以采用图3、图4或图5任一个所示的方法确定是否对当前进程进行回收处理，也可以结合图3、图4和图5所示的方法确定是否对当前进程进行回收处理，例如，在当前进程内运行的各组件中不存在被恢复的组件，且当前进程内运行的各组件中不存在组件注册到指定类中时，确定对当前进程进行回收处理。
[0134]在当前进程为多个进程时，可以针对每个进程分别进行判断，以确定是否对其进行回收处理，此处不再赘述。
[0135]下面以一具体实施例详细介绍本发明的在应用程序中进行进程回收处理的方法的实现过程。
[0136]在该实施例中，涉及到的自定义的类如下:
[0137]DIKillable
[0138]—个接口。它有一个方法，isKiIIableO
[0139]isKillable
[0140]查找Activity或Service等组件是否注册到IKiIIable中，若该方法返回false，则表示组件注册到IKillable中，该组件不能被回收。若该方法返回true，则表示组件未注册至IjIKillable中，可以回收该组件或者继续通过其他方法判断是否回收该组件。
[0141]2)KiIlabIeMonitor
[0142]用来管理所有IKillable接口的类，即上述的回收处理接口管理类，包括典型的List<IKillable>0
[0143]registerKiIlabIe(IKillable)
[0144]加入IKiIIable接口对象到List中(mKiIIableSet)。
[0145]unregisterKiIlabIe(IKi liable)
[0146]删除IKillable接口对象到List中(mKillableSet)。为了尽可能触发轮询，每次反注册时都会立即发起一次MESSAGE_TRY_KILL_PROCESS(—种进程回收操作)，这样可及时退出UI进程。
[0147]isAllKillableQ
[0148]判断是否有IKi I lable.1sKi I Iable返回false。只要有任一个，就表示不能回收该进程。
[0149]3)KillerHandler
[0150]继承自Handler，用来处理事件:MESSAGE_TRY_KILL_PROCESS
[0151]MESSAGE_TRY_KILL_PROCESS
[ΟΙ52] 该方法用来调用tryKiIIProcess。由于Handler使用轮询的方式，每隔设定时间间隔(如I分钟)走一次，直到该事件被终止。
[0153]4)ProcessKiller
[0154]核心类，用来调度整个进程的生死。包括方法:
[0155]onUpdate
[0156]仅发起MESSAGE_TRY_KILL_PROCESS事件即可，一旦发起就自动进入轮询。
[0157]然而，在触发场景上，需在下列场景中调用该方法:
[0158]Activity.0nDestroy (每个)
[0159]应用程序启动时
[0160]其它可能的情况
[0161]InitQ
[ΟΙ62] 注册onUpdate方法并做好准备。
[0163]addKiIIableService(ComponentName)
[0164]添加当前应用中已经实现了 IKi I Iable接口的自定义)列表。如果设置了保存所有没有实现IKillable接口的Service，那么在退出时只要发现有没有实现的IKillable的Service在当前进程中运行，那么就不会退出当前进程。
[0165]对于这里添加的已经实现了 IKillable接口的Service类，会在当前进程中发现其还在运行时，会通过isKi llable()来判断它是否可以强行退出。当其返回true时，该Service即使在当前进程中运行也不会再阻止进程的退出。
[0166]tryKiI!Process
[0?67]核心方法，在Ki I IerHandler中被调用，根据设定时间间隔被调用一次，该方法的判断流程参见上文图2、图3以及图4，此处不再赘述。
[0168]图6示出了根据本发明另一个实施例的在应用程序中进行进程回收处理的方法的流程图。如图6所示，该方法至少包括以下步骤S602至步骤S614。
[0169]步骤S602，监听预设的进程回收事件。
[0170]在该步骤中，预设的进程回收事件可以是应用程序启动事件、系统组件启动事件、系统组件退出事件、组件销毁事件、反注册进程回收接口管理类事件等。
[0171]本实施例中，对应用程序中的各进程设置计数字段(如当应用程序中的进程启动时，设置该进程的计数字段)，用于对该进程中被恢复组件和/或被暂停的组件进行计数。例如，当接收到组件恢复事件时，对被恢复的组件所在进程的计数字段增加计数值；当接收到组件暂停事件时，对被暂停的组件所在进程的计数字段减少计数值。
[0172]步骤S604，当监听到预设的进程回收事件时，每隔一预定时间段获取一次当前进程内运行的各组件的属性信息。
[0173]步骤S606，判断当前进程内运行的各组件中是否存在被恢复的组件，若是，则继续执行步骤S608 ；否则，继续执行步骤S610。
[0174]步骤S608，确定对当前进程不进行回收处理。
[0175]在该步骤中，被恢复的组件正处于前台运行的状态，则不对该组件所在的进程进行回收。
[0176]步骤S610，判断当前进程内运行的各组件是否注册到指定类中，若当前进程内运行的各组件中存在至少一个组件注册到指定类中，则继续执行步骤S608;若当前进程内运行的各组件中不存在组件注册到指定类