CN105607953B - 在应用程序中进行进程回收处理的方法及装置 - Google Patents

在应用程序中进行进程回收处理的方法及装置 Download PDF

Info

Publication number
CN105607953B
CN105607953B CN201510967818.5A CN201510967818A CN105607953B CN 105607953 B CN105607953 B CN 105607953B CN 201510967818 A CN201510967818 A CN 201510967818A CN 105607953 B CN105607953 B CN 105607953B
Authority
CN
China
Prior art keywords
component
current process
run
current
attribute information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CN201510967818.5A
Other languages
English (en)
Other versions
CN105607953A (zh
Inventor
宋照春
张炅轩
姚彤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Qihoo Technology Co Ltd
Original Assignee
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Qihoo Technology Co Ltd, Qizhi Software Beijing Co Ltd filed Critical Beijing Qihoo Technology Co Ltd
Priority to CN201510967818.5A priority Critical patent/CN105607953B/zh
Publication of CN105607953A publication Critical patent/CN105607953A/zh
Application granted granted Critical
Publication of CN105607953B publication Critical patent/CN105607953B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022—Mechanisms to release resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/509—Offload

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明提供了一种在应用程序中进行进程回收处理的方法及装置。该方法包括：监听预设的进程回收事件；当监听到预设的进程回收事件时，反射调用活动管理接口，通过活动监控器对象获取当前进程各组件的Map引用关系，基于Map引用关系获取当前进程内运行的各组件的属性信息；将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理。本发明提供的技术方案能够实现对进程进行及时回收处理的目的，解决了现有技术中不能实现进程的及时回收，导致在回收之前进程仍然会长期占用内存资源的问题。

Description

在应用程序中进行进程回收处理的方法及装置
技术领域
本发明涉及计算机技术领域，特别是一种在应用程序中进行进程回收处理的方法及装置。
背景技术
在终端设备中，出于成本的考虑，系统内存非常有限，当系统在较大的负载下运行的时候，容易出现内存不足的情况。
目前，在Android(安卓)操作系统中，系统会在内存降低到系统设定的阈值的时候，根据进程的活跃度回收进程。虽然这从一定程度上缓解了内存不足的情况，然而现有的根据进程的活跃度回收进程的方法，有时候会造成操作系统应用的进程被回收掉，导致终端设备无法正常的运行的缺陷。此外，系统在内存降低到系统设定的阈值的时候，才会根据进程的活跃度回收进程，不能实现进程的及时回收，在回收之前进程仍然会长期占用内存资源。
发明内容
本发明提供了一种在应用程序中进行进程回收处理的方法及装置以克服上述问题或者至少部分地解决上述问题。
根据本发明的一个方面，提供了一种在应用程序中进行进程回收处理的方法，包括：
监听预设的进程回收事件；
当监听到所述预设的进程回收事件时，反射调用活动管理接口，通过活动监控器对象获取当前进程各组件的Map引用关系，基于所述Map引用关系获取当前进程内运行的各组件的属性信息；
将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理；
其中，所述方法还包括：
对应用程序中的各进程设置计数字段，用于对该进程中被恢复和/或被暂停的组件进行计数；
当接收到组件恢复事件时，对被恢复的组件所在进程的计数字段增加计数值；
当接收到组件暂停事件时，对被暂停的组件所在进程的计数字段减少计数值。
可选地，在所述监听预设的进程回收事件之前，所述方法还包括：
注册活动监控器对象，以在反射调用所述活动管理接口后传入所述活动监控器对象。
可选地，所述预设的进程回收事件包括：组件恢复事件。
可选地，所述方法还包括：在指定类中注册不能被回收的组件；
将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理，包括：
判断所述当前进程内运行的各组件是否注册到所述指定类中；
若所述当前进程内运行的各组件中存在至少一个组件注册到所述指定类中，则确定对所述当前进程不进行回收处理；
若所述当前进程内运行的各组件中不存在组件注册到所述指定类中，则确定对所述当前进程进行回收处理。
可选地，判断所述当前进程内运行的各组件是否注册到所述指定类中，包括：
调用所述指定类的判断方法，由所述判断方法查找所述当前进程内运行的各组件是否注册到所述指定类中；
接收所述判断方法返回的查找结果；
根据所述查找结果确定是否回收所述当前进程。
可选地，将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理，包括：
判断所述当前进程内运行的各组件中是否存在被恢复的组件；
若是，则确定对所述当前进程不进行回收处理；
若否，则确定对所述当前进程进行回收处理。
可选地，判断所述当前进程内运行的各组件中是否存在被恢复的组件，包括：
读取所述当前进程的计数字段；
判断所述计数字段的计数值是否大于指定阈值；
若是，则确定所述当前进程内运行的各组件中存在被恢复的组件；
若否，则确定所述当前进程内运行的各组件中不存在被恢复的组件。
可选地，将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理，包括：
判断所述当前进程是否为空进程或后台进程；
若是，则确定对所述当前进程进行回收处理。
可选地，将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理，包括：
判断所述当前进程中活动和服务的数量是否都为0；
若是，则确定对所述当前进程进行回收处理。
根据本发明的另一个方面，还提供了一种在应用程序中进行进程回收处理的装置，包括：
监听模块，适于监听预设的进程回收事件；
获取模块，适于当监听到所述预设的进程回收事件时，反射调用活动管理接口，通过活动监控器对象获取当前进程各组件的Map引用关系，基于所述Map引用关系获取当前进程内运行的各组件的属性信息；
确定模块，适于将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理；
其中，所述装置还包括：
计数模块，适于对应用程序中的各进程设置计数字段，用于对该进程中被恢复和/或被暂停的组件进行计数；当接收到组件恢复事件时，对被恢复的组件所在进程的计数字段增加计数值；当接收到组件暂停事件时，对被暂停的组件所在进程的计数字段减少计数值。
可选地，所述装置还包括：
对象注册模块，适于注册活动监控器对象，以在反射调用所述活动管理接口后传入所述活动监控器对象。
可选地，所述预设的进程回收事件包括：组件恢复事件。
可选地，所述装置还包括：
组件注册模块，适于在指定类中注册不能被回收的组件；
所述确定模块，还适于判断所述当前进程内运行的各组件是否注册到所述指定类中；若所述当前进程内运行的各组件中存在至少一个组件注册到所述指定类中，则确定对所述当前进程不进行回收处理；若所述当前进程内运行的各组件中不存在组件注册到所述指定类中，则确定对所述当前进程进行回收处理。
可选地，所述确定模块还适于：
调用所述指定类的判断方法，由所述判断方法查找所述当前进程内运行的各组件是否注册到所述指定类中；
接收所述判断方法返回的查找结果；
根据所述查找结果确定是否回收所述当前进程。
可选地，所述确定模块还适于：
判断所述当前进程内运行的各组件中是否存在被恢复的组件；
若是，则确定对所述当前进程不进行回收处理；
若否，则确定对所述当前进程进行回收处理。
可选地，所述确定模块还适于：
读取所述当前进程的计数字段；
判断所述计数字段的计数值是否大于指定阈值；
若是，则确定所述当前进程内运行的各组件中存在被恢复的组件；
若否，则确定所述当前进程内运行的各组件中不存在被恢复的组件。
可选地，所述确定模块还适于：
判断所述当前进程是否为空进程或后台进程；
若是，则确定对所述当前进程进行回收处理。
可选地，所述确定模块还适于：
判断所述当前进程中活动和服务的数量是否都为0；
若是，则确定对所述当前进程进行回收处理。
本发明提供的技术方案实现了对应用程序的进程的回收处理，首先设置了预设的进程回收事件，并对预设的进程回收事件进行主动监听，当监听到预设的进程回收事件时，每隔一预定时间段触发一次进程回收操作，即以轮询的方式触发进程回收操作，获取当前进程内运行的各组件的属性信息，进而将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理。本发明提供的技术方案实现了对进程进行及时回收处理的目的，解决了现有技术中不能实现进程的及时回收，导致在回收之前进程仍然会长期占用内存资源的问题。并且，本发明实施例是将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理，而不是仅仅根据进程的活跃度回收进程，从而使得操作系统应用的进程不会被回收掉，能够保证终端设备的正常运行。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了根据本发明一个实施例的在应用程序中进行进程回收处理的方法的流程图；
图2所示为Activity的状态转换示意图；
图3示出了根据本发明一个实施例的确定是否对当前进程进行回收处理的方法的流程图；
图4示出了根据本发明另一个实施例的确定是否对当前进程进行回收处理的方法的流程图；
图5示出了根据本发明再一个实施例的确定是否对当前进程进行回收处理的方法的流程图；
图6示出了根据本发明又一个实施例的在应用程序中进行进程回收处理的方法的流程图；
图7示出了根据本发明又一个实施例的在应用程序中进行进程回收处理的方法的流程图；
图8示出了根据本发明一个实施例的在应用程序中进行进程回收处理的装置的结构示意图；以及
图9示出了根据本发明另一个实施例的在应用程序中进行进程回收处理的装置的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。需要说明是，在不冲突的前提下，本发明实施例和实施例中的技术特征可以相互结合。
图1示出了根据本发明一个实施例的在应用程序中进行进程回收处理的方法的流程图。如图1所示，该方法包括：
步骤S102，监听预设的进程回收事件；
步骤S104，当监听到预设的进程回收事件时，获反射调用活动管理接口，通过活动监控器对象获取当前进程各组件的Map引用关系，基于Map引用关系获取当前进程内运行的各组件的属性信息；
步骤S106，将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理。
本实施例提供的方法实现了对应用程序的进程的回收处理，首先设置了预设的进程回收事件，并对预设的进程回收事件进行主动监听，当监听到预设的进程回收事件时，每隔一预定时间段触发一次进程回收操作，即以轮询的方式触发进程回收操作，获取当前进程内运行的各组件的属性信息，进而将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理。本实施例实现了对进程进行及时回收处理的目的，解决了现有技术中不能实现进程的及时回收，导致在回收之前进程仍然会长期占用内存资源的问题。并且，本实施例是将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理，而不是仅仅根据进程的活跃度回收进程，从而使得操作系统应用的进程不会被回收掉，能够保证终端设备的正常运行。
本实施例提供的方法主要适用于Android(安卓)系统。Android系统是一种处于不断演进状态的开源系统，其存在多个不同的版本，而不同的版本Android系统是处于并存的状态的。本实施例提供的方法主要适用于Android2.X的版本。
在上述方法中，为了通过IActivityWatcher对象(即活动监控器对象)获取当前进程内运行的各组件的属性信息，需要先注册IActivityWatcher对象。由于注册该对象的方法以及上层API(Application Programming Interface，应用程序编程接口)都是私有的，不允许被外界使用，必须通过反射的方式才可以使用，也就是说在上述方法中涉及的调用、获取等操作都是要通过反射的方式实现的，例如反射调用ActivityManagerNative.registerActivityWatcher的操作、反射获取ActivityThread.mActivities、反射获取ActivityThread.mServices等操作。
一般来说，Android系统都具备四大基本组件，分别是Activity(活动)、Service(服务)、ContentProvider(内容提供者)、BroadcastReceiver(广播接收器)，下面分别对这四个组件进行介绍。
首先，Activity是一个用户界面的概念，Activity通常表示应用程序中的一个屏幕。它通常包含一个或多个View(View是用户界面元素，是构成用户界面的基本构建块，View可以是一个按钮、标签、文本字段或者各种其他用户界面元素)，但也可以不包含View。Activity与它这个词本身的含义很相似：帮助用户完成某一操作，这一操作可能是查看数据、创建数据或编辑数据。大部分Android应用程序内都拥有多个Activity。
Android中的Service类似于Windows(窗口)或其他平台中的服务，它们都是可能长时间运行的后台进程。Android定义了两种类型的Service：本地Service和远程Service。本地Service是只能由承载该Service的应用程序访问的组件。而远程Service是供在设备上运行的其他应用程序远程访问的Service。电子邮件应用程序用于轮询新邮件的组件，就是一个Service示例。如果这种Service不能被在设备上运行的其他应用程序使用，那么它就是本地Service。如果有多个应用程序使用该Service，那么它就是远程Service。
Android为应用程序定义了一种标准机制来共享数据(比如联系人列表)，无需公开底层存储、结构和实现。通过ContentProvider可以公开数据，允许应用程序使用来自其他应用程序的数据。
Android应用程序可以使用BroadcastReceiver对外部事件进行过滤，只对感兴趣的外部事件(如，当电话呼入时或者数据网络可用时)进行接收并做出响应。BroadcastReceiver没有用户界面，然而，它们可以启动一个Activity或Serice来响应它们收到的信息，或者用NotificationManager(通知管理类)来通知用户。通知可以用很多种方式来吸引用户的注意力，如闪动背灯、震动、播放声音等，一般来说可以在状态栏上放一个持久的图标，用户可以打开它并获取消息。
四大基本组件都需要注册才能使用，每个Activity、Service、ContentProvider都需要在AndroidManifest文件中进行配置。AndroidManifest文件中未进行声明的Activity、Service以及ContentProvider将不为系统所见，从而也就不可用，而BroadcastReceiver的注册分静态注册(在AndroidManifest文件中进行配置)和通过代码动态创建并以调用Context.registerReceiver()的方式注册至系统。需要注意的是，在AndroidManifest文件中进行配置的BroadcastReceiver会随系统的启动而一直处于活跃状态，即使程序未运行，只要接收到感兴趣的广播就会触发。
运行Android应用程序及其组件的进程会经历各种生命周期事件(Android应用程序的生命周期是由Android框架进行管理，而不是由应用程序直接控制)，Android提供了回调，通过实现它们可以处理状态变化。
以一个Activity的各种生命周期回调为例，Activity的生命周期回调方法如下：onCreate()、onStart()、onRestart()、onResume()、onPause()、onStop()、onDestroy()。如图2所示为Activity的状态转换示意图。
系统可以根据发生的其他事件来启动和停止Activity。刚创建Activity时，Android调用onCreate()方法，然后总是会调用onStart()，但调用onStart()之前并不总是调用onCreate()，因为可以在应用程序停止(调用onStop()之后调用onStart())。当调用onStart()时，Activity对用户不可见，但稍后就会可见。在调用onStart()之后，在Activity处于前台且能供用户访问时调用onResume()，这时，用户就会与Activity交互。
当用户决定转到另一个Activity时，系统将调用当前Activity的onPause()方法，然后可能调用onResume()或onStop()。例如，如果用户将当前Activity调回前台，将调用onResume()。如果Activity变得对用户不可见，将调用onStop()。如果Activity调回了前台，那么在调用onStop()之后，将调用onRestart()。如果Activity位于Activity栈中，但对用户不可见，并且系统决定结束该Activity，那么将调用onDestroy()。
在上述方法中，预设的进程回收事件可以包括：组件恢复事件，即触发进程回收操作MESSAGE_TRY_KILL_PROCESS的时机可以选定为检测到发生了组件恢复事件，例如可以在收到IActivityWatcher.activityResuming()的回调后触发。
上述方法中提到的各组件的属性信息，主要是各组件的当前状态信息。下面进行详细的说明。
图3示出了根据本发明一个实施例的确定是否对当前进程进行回收处理的方法的流程图。如图3所示，该方法至少包括以下步骤S302至步骤S306。
步骤S302，判断当前进程内运行的各组件中是否存在被恢复的组件，若是，则继续执行步骤S304；否则，继续执行步骤S306。
在该步骤中，被恢复的组件为正处于前台运行的组件，也可以间接判断当前进程内运行的各组件中是否存在正处于前台运行的组件。
步骤S304，确定对当前进程不进行回收处理。
在该步骤中，被恢复的组件正处于前台运行的状态，则不对该组件所在的进程进行回收。
步骤S306，确定对当前进程进行回收处理。
在该步骤中，若当前进程内运行的各组件中不存在被恢复的组件，可以对当前进程进行回收处理，也可以采用后续提及的方法进一步判断。
在本发明一实施例中，可以对应用程序中的各进程设置计数字段(如当应用程序中的进程启动时，设置该进程的计数字段)，用于对该进程中被恢复组件和/或被暂停的组件进行计数。例如，当接收到组件恢复事件(即调用onResume()回调方法)时，对被恢复的组件所在进程的计数字段增加计数值；当接收到组件暂停事件(即调用onPause()回调方法)时，对被暂停的组件所在进程的计数字段减少计数值。
以Activity组件为例，当接收到Activity组件恢复事件时，对其所在进程的计数字段mResumedActivityCount增加计数值，如1或2等；当接收到Activity组件暂停事件时，对其所在进程的计数字段mResumedActivityCount减少计数值，如1或2等，本发明对此不做限制。
基于上文对应用程序中的各进程设置的计数字段，本发明实施例提供了一种实施上文步骤S302的可选方案，在该方案中，可以读取当前进程的计数字段，进而判断计数字段的计数值是否大于指定阈值，若是，则确定当前进程内运行的各组件中存在被恢复的组件；若否，则确定当前进程内运行的各组件中不存在被恢复的组件。
本发明实施例还提供了另一种可选地确定是否对当前进程进行回收处理的方案，图4示出了根据本发明另一个实施例的确定是否对当前进程进行回收处理的方法的流程图。如图4所示，该方法至少包括以下步骤S402至步骤S406。
步骤S402，判断当前进程是否为空进程或后台进程，若是，则继续执行步骤S404；否则，继续执行步骤S406。
在该步骤中，可以先获取当前进程的标识符，在系统中查找当前进程的标识符的RunningAppProcessInfo(该接口封装了正在运行的进程的信息)，调用其importance字段。如果该字段值为IMPORTANCE_EMPTY，则表示当前进程为空进程；如果该字段值为IMPORTANCE_BACKGROUND，则表示当前进程为后台进程。
步骤S404，确定对当前进程进行回收处理。
步骤S406，确定对当前进程不进行回收处理。
在该步骤中，若当前进程不为空进程或后台进程，可以对当前进程不进行回收处理，也可以采用前文图3所示的方法或者后续提及的方法进一步判断。
本发明实施例还提供了另一种可选地确定是否对当前进程进行回收处理的方案，图5示出了根据本发明再一个实施例的确定是否对当前进程进行回收处理的方法的流程图。如图5所示，该方法至少包括以下步骤S502至步骤S506。
步骤S502，判断当前进程中活动和服务的数量是否都为0，若是，则继续执行步骤S504；否则，继续执行步骤S506。
在该步骤中，在通过反射的方式注册、调用了IActivityManager.registerActivityWatcher之后，可以通过调用自定义类fetchActivitiesAndServices来获取私有的Activities和Services的Map引用。这样每次可直接通过读取该Map引用，来准确获取Activity和Service的各种信息了，包括它们的数量。
步骤S504，确定对当前进程进行回收处理。
步骤S506，确定对当前进程不进行回收处理。
在该步骤中，若前进程中Activity或Service的数量不为0，可以对当前进程不进行回收处理，也可以采用前文图3或图4所示的方法或者后续提及的方法进一步判断。
在本发明一实施例中，可以在指定类中注册不能被回收的组件。在一个应用程序内，通常拥有一个或多个Activity、Service、ContentProvider、BroadcastReceiver，在应用程序运行的过程中，对于不能被回收的组件，可以将其注册到指定类中。例如，自定义类IKillable，将不能被回收的组件注册到该自定义类中，它有一个方法isKillable()，在判断组件是否需要被回收时，可以调用该方法isKillable()，由该方法isKillable()查找组件是否注册到该自定义类中，若该方法返回false，则表示组件注册到该自定义类中，该组件不能被回收。若该方法返回true，则表示组件未注册到该自定义类中，可以回收该组件或者继续通过其他方法判断是否回收该组件。
基于上文的指定类，本发明实施例还提供了另一种可选地确定是否对当前进程进行回收的方案，图6示出了根据本发明又一个实施例的确定是否对当前进程进行回收处理的方法的流程图。如图6所示，该方法至少包括以下步骤S602至步骤S606。
步骤S602，判断当前进程内运行的各组件是否注册到指定类中，若当前进程内运行的各组件中存在至少一个组件注册到指定类中，则继续执行步骤S604；若当前进程内运行的各组件中不存在组件注册到指定类中，则继续执行步骤S606。
在该步骤中，可以调用指定类的判断方法，由判断方法查找当前进程内运行的各组件是否注册到指定类中，进而接收判断方法返回的查找结果，根据查找结果确定是否回收当前进程。
步骤S604，确定对当前进程不进行回收处理。
步骤S606，确定对当前进程进行回收处理。
在该步骤中，若当前进程内运行的各组件中不存在组件注册到指定类中，可以对当前进程机型回收处理，也可以采用保守的方案，即不回收处理，可以采用前文图3、图4或图5的方法进一步判断。
在实际应用中，可以采用图3、图4、图5或图6任一个所示的方法确定是否对当前进程进行回收处理，也可以结合图3、图4、图5和图6所示的方法确定是否对当前进程进行回收处理，例如，在当前进程内运行的各组件中不存在被恢复的组件，且当前进程内运行的各组件中不存在组件注册到指定类中时，确定对当前进程进行回收处理。
在当前进程为多个进程时，可以针对每个进程分别进行判断，以确定是否对其进行回收处理，此处不再赘述。
下面以一具体实施例详细介绍本发明的在应用程序中进行进程回收处理的方法的实现过程。
在该实施例中，涉及到的自定义的类如下：
1)IKillable
一个接口。它有一个方法，isKillable()
isKillable
查找Activity或Service等组件是否注册到IKillable中，若该方法返回false，则表示组件注册到IKillable中，该组件不能被回收。若该方法返回true，则表示组件未注册到IKillable中，可以回收该组件或者继续通过其他方法判断是否回收该组件。
2)KillableMonitor
用来管理所有IKillable接口的类，包括典型的List<IKillable>。
registerKillable(IKillable)
加入IKillable接口对象到List中(mKillableSet)。
unregisterKillable(IKillable)
删除IKillable接口对象到List中(mKillableSet)。
isAllKillable()
判断是否有IKillable.isKillable返回false。只要有任一个，就表示不能回收该进程。
3)KillerHandler
继承自Handler，用来处理事件：MESSAGE_TRY_KILL_PROCESS
MESSAGE_TRY_KILL_PROCESS
该方法用来调用tryKillProcess。这里MESSAGE_TRY_KILL_PROCESS的触发时机发通常应在收到来自IActivityWatcher.activityResuming()的回调后触发。
收到该消息后，会立即调用ProcessKiller.tryKillProcess方法来判断。
4)KillerWatcherImpl
核心类，实现了系统的IActivityWatcher.Stub()类。该类覆写了一个有用的方法：
activityResuming(activityId)
当系统任何的Activity即将调用onResume前调用。该方法只需发送MESSAGE_TRY_KILL_PROCESS即可，间隔7秒钟(可调整)。
无论用户做了有关页面切换的任何操作，系统都会回调这个方法来通知。比如：按Home键，这样Launcher界面就进入Resuming阶段，进而应用程序也能收到这个回调。
5)ProcessKiller
核心类，用来调度整个进程的生死。包括方法：
init()
注册IActivityWatcher对象，由于注册该对象的方法以及上层API都是私有的，不允许被外界使用，必须通过反射的方式才可以实现。
具体来说，我们需要做：
1、通过ActivityManager.getDefault()获取IActivityManager接口
通过反射直接获取这个接口
2、调用IActivityManager.registerActivityWatcher方法注册
通过反射调用该接口，将之前构造的IActivityWatcher(KillerWatcherImpl)对象传入即可。
3、调用fetchActivitiesAndServices(自定义的)方法
fetchActivitiesAndServices
init之后紧接着就调用该方法。主要用来获取私有的Activities和Services的Map引用。这样每次可直接通过读取该Map引用，来准确获取Activity和Service的各种信息了。具体为：
a、获取ActivityThread对象
通过反射获取这个对象即可。
b、获取ActivityThread.mActivities和ActivityThread.mServices
同样的，通过反射来获取这两个对象。注意：他们都是声明为Private，因此还得需要调用setAccessible即可。
addKillableService(ComponentName)
添加当前应用中已经实现了IKillable接口的Service类到mKillableService(自定义)列表。如果设置了保存所有没有实现IKillable接口的Service，那么在退出时只要发现有没有实现的IKillable的Service在当前进程中运行，那么就不会退出当前进程。
对于这里添加的已经实现了IKillable接口的Service类，会在当前进程中发现其还在运行时，会通过isKillable()来判断它是否可以强行退出。当其返回true时，该Service即使在当前进程中运行也不会再阻止进程的退出。
tryKillProcess
核心方法，在KillerHandler中被调用，该方法的判断流程参见上文图3、图4、图5以及图6，此处不再赘述。这里需要获取一遍IKillable接口，在mActivities和mServices中，可遍历并分别获取activity和service字段，进而判断IKillable接口是否符合杀掉的要求。获取操作仍然用反射来实现，这次要读取mActivities.get(i).activity对象。
图7示出了根据本发明另一个实施例的在应用程序中进行进程回收处理的方法的流程图。如图7所示，该方法至少包括以下步骤S702至步骤S716。
步骤S702，监听预设的进程回收事件。
在该步骤中，预设的进程回收事件可以是组件恢复事件。
本实施例中，对应用程序中的各进程设置计数字段(如当应用程序中的进程启动时，设置该进程的计数字段)，用于对该进程中被恢复组件和/或被暂停的组件进行计数。例如，当接收到组件恢复事件(即调用onResume()回调方法)时，对被恢复的组件所在进程的计数字段增加计数值；当接收到组件暂停事件(即调用onPause()回调方法)时，对被暂停的组件所在进程的计数字段减少计数值。
步骤S704，当监听到预设的进程回收事件时，反射调用活动管理接口，通过活动监控器对象获取当前进程各组件的Map引用关系，基于Map引用关系获取当前进程内运行的各组件的属性信息。
步骤S706，判断当前进程内运行的各组件中是否存在被恢复的组件，若是，则继续执行步骤S708；否则，继续执行步骤S710。
步骤S708，确定对当前进程不进行回收处理。
在该步骤中，被恢复的组件正处于前台运行的状态，则不对该组件所在的进程进行回收。
步骤S710，判断当前进程内运行的各组件是否注册到指定类中，若当前进程内运行的各组件中存在至少一个组件注册到指定类中，则继续执行步骤S708；若当前进程内运行的各组件中不存在组件注册到指定类中，则继续执行步骤S712。
步骤S712，判断当前进程是否为空进程或后台进程，若是，则继续执行步骤S714；否则，继续执行步骤S708。
步骤S714，判断当前进程中活动和服务的数量是否都为0，若是，则继续执行步骤S716；否则，继续执行步骤S708。
步骤S716，确定对当前进程进行回收处理。
本发明实施例是将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理，而不是仅仅根据进程的活跃度回收进程，从而使得操作系统应用的进程不会被回收掉，能够保证终端设备的正常运行。
基于上文各个实施例提供的在应用程序中进行进程回收处理的方法，基于同一发明构思，本发明实施例还提供了一种在应用程序中进行进程回收处理的装置。
图8示出了根据本发明一个实施例的在应用程序中进行进程回收处理的装置的结构示意图。如图8所示，该装置800至少可以包括监听模块810、获取模块820以及确定模块830，其中，
监听模块810，适于监听预设的进程回收事件；
获取模块820，与监听模块810相耦合，适于当监听到预设的进程回收事件时，反射调用活动管理接口，通过活动监控器对象获取当前进程各组件的Map引用关系，基于Map引用关系获取当前进程内运行的各组件的属性信息；
确定模块830，与获取模块820相耦合，适于将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理。
在本发明一实施例中，如图9所示，图8展示的装置还可以包括：
对象注册模块840，与获取模块820相耦合，适于注册活动监控器对象，以在反射调用活动管理接口后传入活动监控器对象。
在本发明一实施例中，预设的进程回收事件包括：组件恢复事件。
在本发明一实施例中，如图9所示，图8展示的装置还可以包括：
组件注册模块850，与确定模块830相耦合，适于在指定类中注册不能被回收的组件；
确定模块830还适于：判断当前进程内运行的各组件是否注册到指定类中；若当前进程内运行的各组件中存在至少一个组件注册到指定类中，则确定对当前进程不进行回收处理；若当前进程内运行的各组件中不存在组件注册到指定类中，则确定对当前进程进行回收处理。
在本发明一实施例中，确定模块830还适于：
调用指定类的判断方法，由判断方法查找当前进程内运行的各组件是否注册到指定类中；
接收判断方法返回的查找结果；
根据查找结果确定是否回收当前进程。
在本发明一实施例中，确定模块830还适于：
判断当前进程内运行的各组件中是否存在被恢复的组件；
若是，则确定对当前进程不进行回收处理；
若否，则确定对当前进程进行回收处理。
在本发明一实施例中，如图9所示，图8展示的装置还可以包括：
计数模块860，与确定模块830相耦合，适于对应用程序中的各进程设置计数字段，用于对该进程中被恢复和/或被暂停的组件进行计数；当接收到组件恢复事件时，对被恢复的组件所在进程的计数字段增加计数值；当接收到组件暂停事件时，对被暂停的组件所在进程的计数字段减少计数值。
在本发明一实施例中，确定模块830还适于：
读取当前进程的计数字段；
判断计数字段的计数值是否大于指定阈值；
若是，则确定当前进程内运行的各组件中存在被恢复的组件；
若否，则确定当前进程内运行的各组件中不存在被恢复的组件。
在本发明一实施例中，确定模块830还适于：
判断当前进程是否为空进程或后台进程；
若是，则确定对当前进程进行回收处理。
在本发明一实施例中，确定模块830还适于：
判断当前进程中活动和服务的数量是否都为0；
若是，则确定对当前进程进行回收处理。
本发明提供的技术方案实现了对应用程序的进程的回收处理，首先设置了预设的进程回收事件，并对预设的进程回收事件进行主动监听，当监听到预设的进程回收事件时，每隔一预定时间段触发一次进程回收操作，即以轮询的方式触发进程回收操作，获取当前进程内运行的各组件的属性信息，进而将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理。本发明提供的技术方案实现了对进程进行及时回收处理的目的，解决了现有技术中不能实现进程的及时回收，导致在回收之前进程仍然会长期占用内存资源的问题。并且，本发明实施例是将当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对当前进程进行回收处理，而不是仅仅根据进程的活跃度回收进程，从而使得操作系统应用的进程不会被回收掉，能够保证终端设备的正常运行。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的在应用程序中进行进程回收处理的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
至此，本领域技术人员应认识到，虽然本文已详尽示出和描述了本发明的多个示例性实施例，但是，在不脱离本发明精神和范围的情况下，仍可根据本发明公开的内容直接确定或推导出符合本发明原理的许多其他变型或修改。因此，本发明的范围应被理解和认定为覆盖了所有这些其他变型或修改。

Claims (18)

1.一种在应用程序中进行进程回收处理的方法，包括：
监听预设的进程回收事件；
当监听到所述预设的进程回收事件时，反射调用活动管理接口，通过活动监控器对象获取当前进程各组件的Map引用关系，基于所述Map引用关系获取当前进程内运行的各组件的属性信息；
将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理；
其中，所述方法还包括：
对应用程序中的各进程设置计数字段，用于对该进程中被恢复和/或被暂停的组件进行计数；
当接收到组件恢复事件时，对被恢复的组件所在进程的计数字段增加计数值；
当接收到组件暂停事件时，对被暂停的组件所在进程的计数字段减少计数值。
2.根据权利要求1所述的方法，其中，在所述监听预设的进程回收事件之前，所述方法还包括：
注册活动监控器对象，以在反射调用所述活动管理接口后传入所述活动监控器对象。
3.根据权利要求1或2所述的方法，其中，所述预设的进程回收事件包括：组件恢复事件。
4.根据权利要求1或2所述的方法，其中，
所述方法还包括：在指定类中注册不能被回收的组件；
将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理，包括：
判断所述当前进程内运行的各组件是否注册到所述指定类中；
若所述当前进程内运行的各组件中存在至少一个组件注册到所述指定类中，则确定对所述当前进程不进行回收处理；
若所述当前进程内运行的各组件中不存在组件注册到所述指定类中，则确定对所述当前进程进行回收处理。
5.根据权利要求4所述的方法，其中，判断所述当前进程内运行的各组件是否注册到所述指定类中，包括：
调用所述指定类的判断方法，由所述判断方法查找所述当前进程内运行的各组件是否注册到所述指定类中；
接收所述判断方法返回的查找结果；
根据所述查找结果确定是否回收所述当前进程。
6.根据权利要求1或2所述的方法，其中，将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理，包括：
判断所述当前进程内运行的各组件中是否存在被恢复的组件；
若是，则确定对所述当前进程不进行回收处理；
若否，则确定对所述当前进程进行回收处理。
7.根据权利要求6所述的方法，其中，判断所述当前进程内运行的各组件中是否存在被恢复的组件，包括：
读取所述当前进程的计数字段；
判断所述计数字段的计数值是否大于指定阈值；
若是，则确定所述当前进程内运行的各组件中存在被恢复的组件；
若否，则确定所述当前进程内运行的各组件中不存在被恢复的组件。
8.根据权利要求1或2所述的方法，其中，将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理，包括：
判断所述当前进程是否为空进程或后台进程；
若是，则确定对所述当前进程进行回收处理。
9.根据权利要求1或2所述的方法，其中，将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理，包括：
判断所述当前进程中活动和服务的数量是否都为0；
若是，则确定对所述当前进程进行回收处理。
10.一种在应用程序中进行进程回收处理的装置，包括：
监听模块，适于监听预设的进程回收事件；
获取模块，适于当监听到所述预设的进程回收事件时，反射调用活动管理接口，通过活动监控器对象获取当前进程各组件的Map引用关系，基于所述Map引用关系获取当前进程内运行的各组件的属性信息；
确定模块，适于将所述当前进程内运行的各组件的属性信息与进程回收规则对应的组件的属性信息进行比对，确定是否对所述当前进程进行回收处理；
其中，所述装置还包括：
计数模块，适于对应用程序中的各进程设置计数字段，用于对该进程中被恢复和/或被暂停的组件进行计数；当接收到组件恢复事件时，对被恢复的组件所在进程的计数字段增加计数值；当接收到组件暂停事件时，对被暂停的组件所在进程的计数字段减少计数值。
11.根据权利要求10所述的装置，其中，还包括：
对象注册模块，适于注册活动监控器对象，以在反射调用所述活动管理接口后传入所述活动监控器对象。
12.根据权利要求10或11所述的装置，其中，所述预设的进程回收事件包括：组件恢复事件。
13.根据权利要求10或11所述的装置，其中，还包括：
组件注册模块，适于在指定类中注册不能被回收的组件；
所述确定模块，还适于判断所述当前进程内运行的各组件是否注册到所述指定类中；若所述当前进程内运行的各组件中存在至少一个组件注册到所述指定类中，则确定对所述当前进程不进行回收处理；若所述当前进程内运行的各组件中不存在组件注册到所述指定类中，则确定对所述当前进程进行回收处理。
14.根据权利要求13所述的装置，其中，所述确定模块还适于：
调用所述指定类的判断方法，由所述判断方法查找所述当前进程内运行的各组件是否注册到所述指定类中；
接收所述判断方法返回的查找结果；
根据所述查找结果确定是否回收所述当前进程。
15.根据权利要求10或11所述的装置，其中，所述确定模块还适于：
判断所述当前进程内运行的各组件中是否存在被恢复的组件；
若是，则确定对所述当前进程不进行回收处理；
若否，则确定对所述当前进程进行回收处理。
16.根据权利要求15所述的装置，其中，所述确定模块还适于：
读取所述当前进程的计数字段；
判断所述计数字段的计数值是否大于指定阈值；
若是，则确定所述当前进程内运行的各组件中存在被恢复的组件；
若否，则确定所述当前进程内运行的各组件中不存在被恢复的组件。
17.根据权利要求10或11所述的装置，其中，所述确定模块还适于：判断所述当前进程是否为空进程或后台进程；
若是，则确定对所述当前进程进行回收处理。
18.根据权利要求10或11所述的装置，其中，所述确定模块还适于：判断所述当前进程中活动和服务的数量是否都为0；
若是，则确定对所述当前进程进行回收处理。
CN201510967818.5A 2015-12-21 2015-12-21 在应用程序中进行进程回收处理的方法及装置 Expired - Fee Related CN105607953B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510967818.5A CN105607953B (zh) 2015-12-21 2015-12-21 在应用程序中进行进程回收处理的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510967818.5A CN105607953B (zh) 2015-12-21 2015-12-21 在应用程序中进行进程回收处理的方法及装置

Publications (2)

Publication Number Publication Date
CN105607953A CN105607953A (zh) 2016-05-25
CN105607953B true CN105607953B (zh) 2018-10-09

Family

ID=55987907

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510967818.5A Expired - Fee Related CN105607953B (zh) 2015-12-21 2015-12-21 在应用程序中进行进程回收处理的方法及装置

Country Status (1)

Country Link
CN (1) CN105607953B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108108240B (zh) * 2018-01-03 2019-07-12 Oppo广东移动通信有限公司 进程管理方法、进程管理装置及移动终端
CN108279905B (zh) * 2018-01-04 2022-06-21 武汉斗鱼网络科技有限公司 一种组件中引入库文件的方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103544063A (zh) * 2013-09-30 2014-01-29 三星电子（中国）研发中心 应用于安卓平台的进程清除方法和装置
CN103677978A (zh) * 2013-12-30 2014-03-26 Tcl集团股份有限公司 一种对进程进行保护的方法和电子设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8161544B2 (en) * 2006-07-19 2012-04-17 Microsoft Corporation Trusted communications with child processes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103544063A (zh) * 2013-09-30 2014-01-29 三星电子（中国）研发中心 应用于安卓平台的进程清除方法和装置
CN103677978A (zh) * 2013-12-30 2014-03-26 Tcl集团股份有限公司 一种对进程进行保护的方法和电子设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Android进程线程管理机制与组件生命周期解析;heyetina;《https://blog.csdn.net/heyetina/article/details/8477434》;20130107;第1-2页 *
深入Android【五】——任务和进程;潜龙勿用;《http://blog.sina.com.cn/s/blog_495c8c720100uxiw.html》;20111012;第1-3页 *

Also Published As

Publication number Publication date
CN105607953A (zh) 2016-05-25

Similar Documents

Publication Publication Date Title
US7730479B2 (en) Cell-phone terminal, program management method and computer program of same
CN104992081B (zh) 一种Android应用程序第三方代码的安全增强方法
CN105354492B (zh) 移动通讯终端及其消息通知控制方法和装置
EP3200393A1 (en) Method and device for virtual network function management
CN109246220B (zh) 一种消息推送系统及方法
CN104967557A (zh) 通信消息发送方法及装置
CN105991408B (zh) 一种消息处理方法、装置及处理服务器
CN105094630B (zh) 应用程序推送消息的提示信息处理方法及装置
CN104780185A (zh) 信息分享控制方法及装置
CN109766172B (zh) 一种异步任务调度方法以及装置
CN105095749B (zh) 状态栏通知的接管方法及装置
CN108572898A (zh) 一种控制接口的方法、装置、设备、以及存储介质
CN106296135A (zh) 事件提醒方法、装置及终端
CN105468438B (zh) 在应用程序中进行进程回收处理的方法及装置
CN103064782A (zh) 一种获取控件的方法及装置
CN105573842B (zh) 在应用程序中进行进程回收处理的方法及装置
CN108363653A (zh) 监控系统的部署方法、装置、计算机设备及存储介质
CN107615250A (zh) 一种针对应用的处理方法、装置及智能终端
CN105933497B (zh) 一种多模式的来电拦截方法与装置
CN105607953B (zh) 在应用程序中进行进程回收处理的方法及装置
CN109543405A (zh) 一种隐私调用行为识别方法和电子设备
CN107957905A (zh) 限制应用自启动的方法、装置、存储介质及智能终端
CN113934331A (zh) 信息处理方法、装置及存储介质
JP2016220075A (ja) 通話履歴共有サーバ、通話履歴共有方法、及び、通話履歴共有プログラム
CN106708501A (zh) 活动监控方法及装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20220728

Address after: Room 801, 8th floor, No. 104, floors 1-19, building 2, yard 6, Jiuxianqiao Road, Chaoyang District, Beijing 100015

Patentee after: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Address before: 100088 room 112, block D, 28 new street, new street, Xicheng District, Beijing (Desheng Park)

Patentee before: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Patentee before: Qizhi software (Beijing) Co.,Ltd.

TR01 Transfer of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20181009