CN107066270A

CN107066270A - 一种信息采集方法及终端

Info

Publication number: CN107066270A
Application number: CN201710203089.5A
Authority: CN
Inventors: 周龙
Original assignee: Nubia Technology Co Ltd
Current assignee: Chengdu Hai Ruien Network Technology Co., Ltd
Priority date: 2017-03-30
Filing date: 2017-03-30
Publication date: 2017-08-18
Anticipated expiration: 2037-03-30
Also published as: CN107066270B

Abstract

本发明提供一种信息采集方法及终端，先获取对采集被监测活动窗口的窗口参数起位置指引作用的采集指引信息，然后调用终端系统的意图询问功能，根据该采集指引信息按照预设采集策略对当前处于运行状态的应用程序的活动窗口进行窗口参数的采集，并将采集到的窗口参数存储到终端本地的数据库中。通过系统意图询问功能，使得应用程序信息采集过程不受终端系统权限的限制，从而能够触及并采集到应用程序中被监测活动窗口的窗口参数。由于采集到的窗口参数相对于应用程序的基础信息，表征了终端中应用程序的更多细节，能够向信息需求对象提供更多的信息。相应的，也就为应用程序信息需求对象的后续分析利用提供了更厚实的基础和更广阔的平台。

Description

一种信息采集方法及终端

技术领域

本发明涉及终端技术领域，更具体地说，涉及一种信息采集方法及终端。

背景技术

相对于传统功能终端，智能终端更受广大用户的欢迎，这主要的原因就是智能终端通过APP(Application，应用程序)的形式为用户提供了更多功能，而且相对于传统终端的功能只能由厂商决定的现状，智能终端在这一方面为用户提供了更多选择，用户可以根据自己的个人需求“定制”功能独特的专属终端，并且随时随地、随心所欲地对自己终端的功能进行调整、更改。

对于各个APP厂商而言，如何令自己研发设计的APP拥有更多的下载率已经成为了其决定研发设计方向时主要考虑的因素之一。为了更好地分析用户喜好，总结市场趋向。而且，现在需要了解APP信息的远不止各个APP厂商，例如也有不少用户期望对自己终端中APP的信息进行了解。另外，若用户主动参与了某些平台的APP信息采集活动，则这些活动的发起者，即平台也是APP信息的需求对象之一。

以APP信息需求对象为APP厂商为例，现有各个APP厂商均会让自己研发设计的APP具备采集用户终端中其他APP信息的功能，但是通过这种方式所采集到的终端APP信息是比较浅显的，其只能采集到用户终端中已安装APP的名称、类别以及各APP被分配权限等基础信息，由于这类基础信息能够反映的信息单一有限，所以其能够提供给APP厂商的信息也是相对浅显与粗略的，基本无法给APP厂商带来真正有用的信息。

对于APP信息的需求对象为用户自身和其他平台的情况也基本一样，由于现有技术中信息采集太过浅显、基础的缘故，所以导致采集结果不尽人意，无法满足信息需求对象的需求。所以现在亟需提出一种能够采集APP内的活动窗口信息的信息采集方案。

发明内容

本发明要解决的技术问题在于提供一种能够采集APP活动窗口信息的信息采集方案，以解决现有技术中APP信息采集无法满足APP信息需求对象需求的问题。

为解决上述技术问题，本发明提供一种信息采集方法，包括：

基于预先获取到的采集指引信息调用终端系统的意图询问功能，按照预设采集策略采集被监测活动窗口的窗口参数；所述采集指引信息用于指示采集被监测活动窗口的窗口参数的位置；所述被监测活动窗口为所述终端当前处于运行状态的应用程序的活动窗口；

将采集到的所述窗口参数存储到所述终端的本地数据库。

进一步地，将采集到的所述窗口参数存储到所述终端的本地数据库包括：

将采集到的所述窗口参数存储到临时关系数据结构中；

当所述终端中存在应用程序的运行状态由运行状态变为非运行状态时，从所述临时关系数据结构中提取出所述窗口参数并进行解析处理；

将经过处理的所述窗口参数存储到所述终端的本地数据库中。

进一步地，将经过处理的所述窗口参数存储到所述终端的本地数据库中包括：

根据预设分类策略将所述窗口参数分类写入到所述本地数据库的各分类存储表中。

进一步地，所述按照预设采集策略采集被监测活动窗口的窗口参数包括：

根据所述采集指引信息到所述终端的活动窗口堆栈、活动窗口线程及活动窗口记录的相应位置采集所述被监测活动窗口的窗口参数。

进一步地，所述按照预设采集策略采集被监测活动窗口的窗口参数之前还包括：

调用所述终端系统的程序管理服务扫描所述终端中当前已安装应用程序；

根据扫描结果到所述终端的进程列表中查询当前处于运行状态的各应用程序的进程信息；

基于查询到的所述进程信息确定针对当前处于运行状态的各所述应用程序活动窗口的采集指引信息，并存储记录所述采集指引信息。

进一步地，所述基于查询到的所述进程信息确定针对当前处于运行状态的各所述应用程序活动窗口的采集指引信息之后还包括：直接根据所述采集指引信息完成对所述被监测活动窗口之窗口参数的初次采集。

进一步地，基于查询到的所述进程信息确定针对当前处于运行状态的各所述应用程序活动窗口的采集指引信息包括：

从所述终端的活动窗口管理服务中获取所述应用程序中各活动窗口间的映射关系；

根据查询到的所述进程信息确定终端为所述进程分配的存储位置；

结合所述存储位置和所述映射关系确定针对当前处于运行状态的各所述应用程序活动窗口的采集指引信息。

进一步地，还包括：

接收系统的新增通知，所述新增通知用以指示终端中存在状态由非运行状态变为运行状态的新增应用程序；

判断是否已经记录有针对所述新增应用程序各活动窗口的采集指引信息；

若是，直接根据已记录的采集指引信息采集针对所述新增应用程序各活动窗口的窗口参数；

若否，进入所述终端的进程列表中确定所述新增应用程序的新增进程信息，基于所述新增进程信息确定针对所述新增应用程序各活动窗口的采集指引信息，并根据确定出的所述采集指引信息采集针对所述新增应用程序各活动窗口的窗口参数。

进一步地，本发明提供了一种终端，包括：

获取模块，用于获取采集指引信息，所述采集指引信息用于指示采集被监测活动窗口的窗口参数的位置；所述被监测活动窗口为所述终端当前处于运行状态的应用程序的活动窗口；

采集模块，用于基于预先获取到的所述采集指引信息调用终端系统的意图询问功能，按照预设采集策略采集被监测活动窗口的窗口参数；

存储模块，用于将采集到的所述窗口参数存储到所述终端的本地数据库。

进一步地，获取模块用于调用所述终端系统的程序管理服务扫描所述终端中当前已安装应用程序；根据扫描结果到所述终端的进程列表中查询当前处于运行状态的各应用程序的进程信息；基于查询到的所述进程信息确定针对当前处于运行状态的各所述应用程序活动窗口的采集指引信息，并存储记录所述采集指引信息。

有益效果

本发明提供一种信息采集方法及终端，终端先获取对采集被监测活动窗口的窗口参数起位置指引作用的采集指引信息，然后调用终端系统的意图询问功能，根据该采集指引信息按照预设采集策略对当前处于运行状态的应用程序的活动窗口进行窗口参数的采集，并将采集到的窗口参数存储到终端本地的数据库中。本发明中的应用程序采集方案，通过系统意图询问功能，使得应用程序信息采集过程不受终端系统权限的限制，从而能够触及并采集到应用程序中被监测活动窗口的窗口参数，并将采集到的窗口参数存储到终端本地的数据库中，以供后续的分析使用。由于采集到的窗口参数相对于应用程序的基础信息，表征了终端中应用程序的更多细节，能够向信息需求对象提供更多的信息。相应的，也就为应用程序信息需求对象的后续分析利用提供了更厚实的基础和更广阔的平台。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1为本发明第一实施例中提供的信息采集方法的一种流程图；

图2为本发明第一实施例中终端获取被监测活动窗口的采集指引信息的一种流程图；

图3为本发明第二实施例中所示出的安卓系统中APP的一种架构图；

图4为本发明第二实施例中提供的信息采集方法的一种流程图；

图5为本发明第三实施例中提供的终端一种结构示意图；

图6为本发明第三实施例中提供的终端另一种结构示意图；

图7为本发明第四实施例中提供的终端一种结构示意图；

图8为图7中存储模块的一种结构示意图；

图9为本发明第五实施例中提供的移动终端一种硬件结构示意图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。

第一实施例：

本实施例提供一种信息采集方法，该方法可以针对终端上运行的APP进行信息采集，并将采集到的数据存储到终端本地的本地数据库，下面结合附图1所示出的流程图对信息采集方法进行详细阐述：

S102、终端基于预先获取到的采集指引信息调用系统的意图询问功能，按照预设采集策略采集被监测活动窗口的窗口参数。

这里所说的采集指引信息是对一个APP中Activity的窗口参数采集起指引作用的信息，可以理解的是采集指引信息中至少包含对应Activity窗口参数的采集位置，例如针对某一个被监测活动窗口的窗口参数，应当分别到终端活动窗口记录(Activity Record)、活动窗口线程(Activity Thread)以及活动窗口堆栈(Activity Stack)的哪个位置进行数据采集。同时，由于到对应采集位置中采集到的窗口参数之前必须明确采集对象是哪一个，所以在采集指引信息中当然会包含被采集对象的名称等基础信息，被采集对象实际就是被监测活动窗口。

终端获取采集指引信息的方式有这样两种：若终端之前已经存储记录了该被监测活动窗口的采集指引信息，也即，在本次信息采集之前，终端可能已经对被监测活动窗口进行过信息采集了，则终端可以直接提取之前存储记录的采集指引信息实现对窗口参数的采集。若终端初次对某一个APP的Activity进行窗口参数采集，在这之前并没有存储记录针对对应Activity的采集指引信息，则终端需要通过查询自身的进程列表(Process List)，基于查询到的进程列表信息确定出该APP之Activity的采集指引信息。

下面结合一个具体的情景示例对终端通过第二种方式获取采集指引信息的过程进行介绍：

假定终端之前没有对自身的任何一个APP进行过信息采集，也即之前没有存储过任何一个Activity的采集指引信息，则在首次进行信息采集之前，终端需要按照图2所示出的流程获取到各被监测活动窗口的采集指引信息：

S202、终端调用系统的程序管理服务扫描自身当前已安装应用程序。

在本实施例中，系统的PMS在启动的时候会扫描终端中所有已安装的APP，其能够获取到已安装APP的名称、厂家等基本信息。值得注意的是，在PMS的扫描结果中并没有区分哪些APP是当前正在运行的，哪些是处于关闭状态的。为了获得关于那些当前处于运行状态的APP的进一步信息，终端需要访问进程列表。

S204、终端根据扫描结果到进程列表中查询当前处于运行状态的各应用程序的进程信息。

一个APP可以具有一个或者多个进程，而终端的进程列表中包含有当前正在运行的所有进程。进程是一个具有一定独立功能的应用程序关于某个数据集合的一次运行活动。它是操作系统动态执行的基本单元，在操作系统中，进程既是基本的分配单元，也是基本的执行单元。

S206、终端基于查询到的进程信息确定针对当前处于运行状态的各应用程序活动窗口的采集指引信息。

根据上述介绍，根据进程列表就可以确定出终端中哪些APP当前处于运行状态。另一方面，由于进程是基本的资源分配单位，所以在终端内存当中，针对一个进程所存储的数据在逻辑上是在一起的，根据进程信息也就能够确定终端系统为该进程分配的存储位置。在此基础上，基于查询到的进程信息就可以确定出针对当前处于运行状态的各应用程序活动窗口的采集指引信息。

具体的，终端在基于查询到的进程信息查询确定采集指引信息时，可以结合从AM(Activity Manage，活动窗口管理)和AMS(Activity Manager Service，活动窗口管理服务)中获取到信息进行，在AM和AMS中记录了一个APP中各Activity间的映射关系等。将从进程信息中确定出的存储位置和从AM和AMS中获取到的映射关系结合就能够确定出针对每一个活动窗口的数据存储位置，也即能够确定出详细的采集指引信息。

S208、终端存储记录采集指引信息。

当确定出针对某个APP采集指引信息之后，终端会把该采集指引信息进行存储记录，以便后续对再次对这些APP中的Activity进行信息采集时直接使用，节省信息采集时间。

另外，在终端基于查询到的进程信息确定出采集指引信息后，可以直接根据该采集指引信息完成对被监测窗口之窗口参数的初次采集。在初次采集的过程当中，不需要调用系统的意图询问功能。为了便于理解，我们可以将初次信息采集的过程和后续再次信息采集的过程形象化为这样一个过程：

假定一本传记合集当中记录了三个人物A、B、C的生平，在书本的第1页是三个人物传记的索引(总索引目录)，例如，第1页上记录了这样的信息：对于A的介绍从第2页开始；对于人物B的介绍从第41页开始；对于人物C的介绍从第66页开始。另外，假定每个人物的生平均是按照童年、青年、中年、老年的顺序进行介绍，而且对在书本的第2页、第41页以及第66中分别是这三个人物生平大事件索引(次级索引目录)。

若一个研究B人物青年时期的学者将此书当作参考资料，则其可以先翻至其第1页查询一下对于人物B的介绍从何处开始，然后根据第一页的索引将书翻至第41页，然后从第41页所示出的大事件索引中查询到B青年时期的介绍从何处开始，假定该学者查询后发现B的青年事迹从第50页开始介绍。则学者可以记录“50”这个页码，若以后有查询需要，可以直接翻至第50页，进行阅读，而不用再从总索引目录、次级索引目录依次进行查询，节省了该学者的查询时间。同时，可以理解的是，当学者初次查询到B人物的青年时期介绍从第50页开始时，其也可以根据该页码直接翻至第50页完成初次阅读。

由于本实施例中终端进行信息采集仅针对那些当前正在运行的APP，所以，被监测活动窗口一定是终端中当前处于运行状态的APP中的活动窗口。但是本实施例中信息采集时，并不区分系统自带APP和用户自行安装的APP，对于这两种类型的APP，终端都会一视同仁。

例如，一部智能手机中安装有三个APP，其中包括一款系统自带的媒体播放APP，如音乐播放器；一款用户自行安装的即使即时通讯APP，假定为微信；以及一个用户自行安装的地图导航APP。如果当前用户一边使用音乐播放器播放着音乐，一边使用微信与自己的好友进行视频通话。但是由于用户当前不需要导航，所以导航APP并没有被开启，仍处于关闭状态。针对该情况，若终端进行信息采集，则微信与音乐播放器中的Activity可以作为被监测活动窗口，但是地图导航APP中的Activity却不可能是当前信息采集的对象，也即当前不可能是被监测活动窗口。

终端在进行信息的采集的时候，可以通过调用终端系统的意图询问功能。以Android(安卓)系统为例，Intent(意图)功能主要是解决Android应用的各项组件之间的通讯。Intent负责对应用中一次操作的动作、动作涉及数据、附加数据进行描述，Android则根据此Intent的描述，负责找到对应的组件，将Intent传递给调用的组件，并完成组件的调用。在Android系统中包括PMS(Package Manager Service，程序管理服务)，而在PMS下就包括query Intent Activities(活动窗口意图询问功能)。query Intent Activities是隶属于终端系统的功能，因此，其具备访问终端内存的能力，所以，能够完成对被监测活动窗口的窗口参数的采集。终端调用query Intent Activities对被监测活动窗口实施信息采集时，只需要将采集指引信息中表征采集位置的信息传递给query Intent Activities，query Intent Activities就能根据该采集指引信息返回对应被监测活动窗口的窗口参数。

终端采集被监测窗口的窗口参数时，可以根据预设采集策略进行。预设采集策略可由终端设计人员预先设置完成。若需要窗口参数的人是终端用户本人，则预设采集策略也可由用户自己设置。具体的，若预设策略要求终端采集被监测活动窗口的所有窗口参数，则终端可以控制意图询问功能返回被监测活动窗口的所有窗口参数。而如果终端用户或者终端设计人员仅对APP中活动窗口的部分数据感兴趣，则意图询问功能可以仅对用户或者终端设计人员感兴趣的窗口参数进行采集，或者对所有的窗口参数进行采集，但是在返回数据之前先对采集到的窗口参数进行筛选。

S104、终端将采集到的窗口参数存储到本地数据库。

当终端采集到窗口参数之后可以将这些窗口参数存储到本地数据库中，以供用户自身分析使用。当然若需要窗口参数的是终端厂家或者是其他第三方平台，则终端也可以在适当的时候将这些窗口参数从本地数据库中提取出来并传输到对应的服务器。适当的时候指的是终端相对空闲的时候，因为传输这些窗口参数必然要占用终端部分处理资源与网络资源，所以为了不影响用户正常的体验，则可以选择终端任务较少或者完全空闲的时候传输窗口参数到服务器。

本实施例提供的信息采集方法，终端预先通过调用程序管理服务扫描终端中已安装的APP，然后通过查询进程列表查询能够表征当前正在运行的各APP的进程信息，并基于进程信息确定出针对终端当前正在运行的各APP值活动窗口的采集指引信息。在信息采集过程中，终端调用系统的意图询问功能根据预先获取到的采集指引信息到对应位置采集每一个被监测活动窗口的窗口参数，然后存储到本地数据库中，相对于现有技术中只能采集到APP名称、设计厂家等基础信息的信息采集方案而言，本发明提供的信息采集方案，通过意图询问功能和采集指引信息，能够获得APP等细节的信息，能够为需要了解APP信息的用户、终端厂家或者是其他第三方平台提供更多信息。

第二实施例：

目前，针对智能终端比较主流的系统中包括安卓系统、塞班系统、iOS系统等，相对于其他两种系统而言，安卓系统的应用更为广泛，所以本实施例中以安卓系统中的信息采集为例对本发明的信息采集方法做进一步介绍：

为了使本领域技术人员能够了解安卓系统中的信息采集细节，所以在介绍信息采集方法之前，先对安卓系统中的而一些基础概念进行简单介绍：

安卓APP是事件驱动的，且安卓系统具有独特的线程机制、回调方法和多入口等特性。安卓系统为开发人员提供4大组件：

活动，Activity，其为用户提供了可以与之进行交互的界面，每一个用户交互的界面都是一个Activity并且整个应用程序中有一个main Activity，即最初用户启动时候所进入的界面；

服务，Service，在后台执行长时间运行的任务，其他的组件可以开启并且绑定一个Service；

内容提供者，Content Providers，提供了在安卓系统中的一种数据存储管理机制，其它组件可以把必要的数据存取在Content Providers中用于和用户之间信息的交流；

广播，Broadcast，用来监听安卓系统所产生的一些活动，比如接受信息、接受电话等，App会通过Broadcast Receiver接受此类活动，并通过它可以做出相应处理。

从图3所示出的安卓系统中APP的架构图可以看出，在安卓系统当中，各APP的运行也是以进程31为基本单位进行的，同时对于资源的分配，同样以进程为单位。PM(PackageManager，程序管理)32和AM(Activity Manager，活动窗口管理)33分别从APP的整体和局部对其进行管理。程序管理32对APP的管理是从“宏观”的角度进行的，所以通过调用程序管理服务321能够了解到终端中所有已安装APP的基础信息。在程序管理服务321下具有queryIntent Activities(活动窗口询问功能)3211，在本实施例中，活动窗口询问功能3211能够直接根据采集指引信息实现首次信息采集以外的其他信息采集。而活动窗口管理33则管理着APP活动窗口的相关细节，例如各个活动窗口的窗口参数相对于程序管理32的管理，活动窗口管理33更像是从“微观”上对APP进行管理。在活动窗口管理33下包括活动窗口管理服务331，而活动窗口管理服务331下又通过活动窗口堆栈3311、活动窗口线程3312及活动窗口记录3313分别管理着APP活动窗口各个方面的参数。

下面请结合图4所示出的信息采集方法：

S402、终端对当前处于运行状态的APP的活动窗口进行首次活动窗口参数采集。

终端调用程序管理服务对自身已安装的所有APP进行扫描，然后查询进程列表，根据进程信息和扫描结果确定出当前处于运行状态的APP有哪些。同时，还可以通过进程列表中查询到的进程信息，结合活动窗口管理服务中的存储的各个活动窗口之间的映射关系确定出处于运行状态的APP的各活动窗口中的窗口参数的存储位置，生成采集指引信息，同时对采集指引信息进行存储记录。

由于第一实施例中已经介绍了终端在首次信息采集时确定采集指引信息的过程，这里不再做详细介绍。

不过在本实施例中，终端根据进程信息和映射关系确定出应当到活动窗口堆栈、活动窗口线程及活动窗口记录的哪些位置去采集各被监测活动窗口的窗口参数后，终端可以直接到相应位置进行首次信息采集。首次信息采集过程不需要调用query IntentActivities，因为首次信息采集就像是一个从APP“宏观”到“微观”的完整采集过程，不需要通过query Intent Activities根据窗口参数的采集位置实现“跳跃”采集。

S404、终端将采集到的窗口参数存储到临时关系数据结构中。

在针对当前处于运行状态的APP进行信息采集的过程当中，完整的信息采集过程至少会包含一个首次信息采集过程，而绝大多数信息采集过程，可能还会包括一个及以上的再次采集过程。在本实施例中，一次完整的信息采集过程采集到的信息会在经过处理之后再存储到终端本地数据库中。所以，针对每一次单独的信息采集的采集结果，终端会把它们存储到临时关系数据结构中。

临时关系数据结构相当于一个存放窗口参数的临时数据库，终端在采集到窗口参数后，之所以没有直接通过通用数据接口把采集结果存储到本地数据库中，这主要是由于采集到的窗口参数需要经过解析及冗余处理等流程后才能存储到本地数据库，以便保证终端本地数据库中存储的窗口参数都是有意义的，提升终端本地数据库容纳有用信息的能力。在本实施例的一种示例当中，临时关系数据结构可以为Hash Map(基于哈希表的Map接口的实现)。

S406、终端判断当前是否存在应用程序的运行状态由运行状态到非运行状态的变化。

若判断结果为是，则说明原本的处于运行状态的部分APP已经不再运行了，也就是说有部分被监测活动窗口已经无法采集到数据了。在这种情况下，可以认为当前一个完整的信息采集过程已经结束了，因此可以转至S410。若判断结果为否，则应当继续执行再次采集过程，即应当继续通过调用query Intent Activities来进行信息采集，执行S408。

S408、终端调用query Intent Activities根据采集信息指引信息对被监测活动窗口的窗口参数进行信息采集。

终端调用query Intent Activities进行信息采集时，可以采集被监测活动窗口的全部窗口参数，也可以仅对其中部分信息进行采集并返回，或者也可以采集全部信息，但在返回之前先进行一定的筛选。query Intent Activities返回的信息是针对某一个被监测活动窗口的，返回的信息相当于该被监测活动窗口的“档案”。

再次信息采集过程完成后，终端会又一次执行S406。

S410、终端从临时关系数据结构中提取存储窗口参数并进行解析处理。

终端提取临时关系数据结构中的窗口参数时，可以通过迭代器(iterator)进行。迭代器是一种对象，它能够用来遍历标准模板库容器中的部分或全部元素，每个迭代器对象代表容器中的确定的地址。

终端先对提取出的窗口参数进行信息解析，从这些窗口参数中可以解析出当前在运行的APP进程名称、UID(APP的唯一识别信息)、NICE值、进程状态、ADJ值等进程相关信息以及用户当前切到前台的APP信息，包括APP名称、类型、top Activity(顶级活动窗口信息)相关信息，top Activity相关信息包括用户停留在该APP的top Activity的时长、开始访问时间、离开访问时间、用户访问时是否联网、网络类型、用户位置、用户状态等信息。

S412、终端对解析处理后的窗口参数进行冗余处理。

冗余处理过程主要是为了剔除采集结果中的无用部分例如，针对第一活动窗口的状态信息，在1:00到5:00中的每个整点时分，终端进行信息采集。最终采集结果表明，第一活动窗口在1:00到4:00这段时间内的状态均为“状态1”，而4:00采集到的状态则变为“状态0”。若要将这5次采集结果均进行保存，则需要进行类似于表1的存储：

表1

采集时间	1:00	2:00	3:00	4:00	5:00
						采集结果	状态1	状态1	状态1	状态1	状态0

若不经处理，直接对采集到的窗口参数进行存储，则需要使用较大容量的空间来存储这5小时之间第一活动窗口的参数。但是，如果对这些窗口参数进行冗余处理之后，可以采用表2的形式进行存储：

表2

采集时间	1:00～4:00	5:00
			采集结果	状态1	状态0

经过冗余处理之后，针对相同的信息量，可以通过更少的存储空间来容纳存储，反言之，即提升了原存储空间的利用率。

S414、终端将处理后的窗口参数分类写入到本地数据库的各分类存储表中。

在终端本地数据库当中，可以包含多个分类存储表，这些分类存储表用于存储不同的窗口参数。例如，可以通过“用户状态表”来对用户状态进行定义；通过“APP活动窗口统计信息表”来收纳某一个APP活动窗口的相关信息；通过“APP时间段表”来记录用户在不同时间段在各APP活动窗口的停留情况与操作情况等。由此可见，这些分类存储表决定了窗口参数在本地数据库中的存储类别。可以理解的是，窗口参数在本地数据库中的存储类别是可以由信息需求对象决定的，所以，分类存储表可以由信息需求对象设置，例如用户自定义设置、第三方平台设置后由用户下载导入等。

另外，终端可以自动地将窗口参数分类存储到本地数据库中，而在本实施例的而一种示例当中，用户可以通过终端的输入单元控制通用数据读写接口实现对本地数据库中存储数据的管理。例如，控制窗口参数的写入，具体的包括写入时间、写入位置等，或者控制窗口参数的修改、删除等。

在本实施例的一种示例当中，终端在进行信息采集和/或将采集结果存储到本地数据库的过程当中，还会接收系统的新增通知，新增通知用以告知终端当前存在APP的状态由非运行状态变为了运行状态，也即，终端当前进行信息采集的对象有了增加。这时候，终端需要判断针对该APP的活动窗口是否已经记录了采集指引信息，如果已经记录了，则可以直接调用query Intent Activities按照再次信息采集过程实现窗口数据采集。如果之前并没有记录该APP互动窗口的采集指引信息，则终端需要通过自身的进程列表确定该新增APP的新增进程信息，并基于新增进程信息确定针对该新增APP各活动窗口的采集指引信息，根据确定出的采集指引信息实现窗口参数采集。

本实施例提供的信息采集方法，不仅可以根据采集指引信息调用query IntentActivities实现对活动窗口之窗口参数的采集，能够为用户以及其他需要了解APP信息的其他对象提供更加详细的采集结果。而且终端在将采集到的窗口参数存储到本地数据库之前，会先对采集结果进行解析处理、冗余处理等，而且在本地数据库中以分类存储表的形式存储窗口参数，使得采集结果更加明晰、更直观，让需要了解APP信息的对象能够在以更简单的方式了解到更多详细的信息。

第三实施例：

本实施例提供一种终端，请参见图5：

终端50包括获取模块502、采集模块504和存储模块506，其中获取模块502用于获取采集指引信息，采集模块504用于基于该采集指引信息调用系统的意图询问功能对被监测活动窗口的数据进行采集，而存储模块506则用于将采集到的窗口参数存储到终端50的本地数据库中。

在本实施例中，获取模块502获取到的采集指引信息是对一个APP中Activity的窗口参数采集起指引作用的信息，可以理解的是采集指引信息中至少包含对应Activity窗口参数的采集位置，例如针对某一个被监测活动窗口的窗口参数，应当分别到终端50活动窗口记录、活动窗口线程以及活动窗口堆栈的哪个位置进行数据采集。同时，由于到对应采集位置中采集到的窗口参数之前必须明确采集对象是哪一个，所以在采集指引信息中当然会包含被采集对象的名称等基础信息，被采集对象实际就是被监测活动窗口。

获取模块502获取采集指引信息的方式有这样两种：若终端50之前已经存储记录了该被监测活动窗口的采集指引信息，也即，在本次信息采集之前，采集模块504可能已经对被监测活动窗口进行过信息采集了，则获取模块502可以直接提取之前存储记录的采集指引信息实现对窗口参数的采集。若采集模块504初次对某一个APP的Activity进行窗口参数采集，在这之前并没有存储记录针对对应Activity的采集指引信息，则获取模块502需要通过查询终端50的进程列表，基于查询到的进程列表信息确定出该APP之Activity的采集指引信息。

下面结合一个具体的情景示例对获取模块502通过第二种方式获取采集指引信息的过程进行介绍：

假定采集模块504之前没有对自身的任何一个APP进行过信息采集，也即之前没有存储过任何一个Activity的采集指引信息，则在首次进行信息采集之前，获取模块502需要先调用系统的程序管理服务扫描自身当前已安装应用程序。

在本实施例中，系统的PMS在启动的时候会扫描终端50中所有已安装的APP，其能够获取到已安装APP的名称、厂家等基本信息。值得注意的是，在PMS的扫描结果中并没有区分哪些APP是当前正在运行的，哪些是处于关闭状态的。为了获得关于那些当前处于运行状态的APP的进一步信息，获取模块502需要访问进程列表。

获取模块502根据扫描结果到进程列表中查询当前处于运行状态的各应用程序的进程信息。一个APP可以具有一个或者多个进程，而终端50的进程列表中包含有当前正在运行的所有进程。进程是一个具有一定独立功能的应用程序关于某个数据集合的一次运行活动。它是操作系统动态执行的基本单元，在操作系统中，进程既是基本的分配单元，也是基本的执行单元。

根据上述介绍，获取模块502根据进程列表就可以确定出终端50中哪些APP当前处于运行状态。另一方面，由于进程是基本的资源分配单位，所以在终端50内存当中，针对一个进程所存储的数据在逻辑上是在一起的，根据进程信息也就能够确定终端50系统为该进程分配的存储位置。在此基础上，获取模块502基于查询到的进程信息就可以确定出针对当前处于运行状态的各应用程序活动窗口的采集指引信息。

具体的，获取模块502在基于查询到的进程信息查询确定采集指引信息时，可以结合从AM和AMS中获取到信息进行，在AM和AMS中记录了一个APP中各Activity间的映射关系等。将从进程信息中确定出的存储位置和从AM和AMS中获取到的映射关系结合就能够确定出针对每一个活动窗口的数据存储位置，也即能够确定出详细的采集指引信息。

当确定出针对某个APP采集指引信息之后，获取模块502会把该采集指引信息进行存储记录，以便后续对再次对这些APP中的Activity进行信息采集时直接使用，节省信息采集时间。

另外，在获取模块502基于查询到的进程信息确定出采集指引信息后，采集模块504可以直接根据该采集指引信息完成对被监测窗口之窗口参数的初次采集。在初次采集的过程当中，不需要调用系统的意图询问功能。为了便于理解，我们可以将初次信息采集的过程和后续再次信息采集的过程形象化为这样一个过程：

由于本实施例中采集模块504进行信息采集仅针对那些当前正在运行的APP，所以，被监测活动窗口一定是终端50中当前处于运行状态的APP中的活动窗口。但是本实施例中信息采集时，采集模块504并不区分系统自带APP和用户自行安装的APP，对于这两种类型的APP，采集模块504都会一视同仁。

例如，一部智能手机中安装有三个APP，其中包括一款系统自带的媒体播放APP，如音乐播放器；一款用户自行安装的即使即时通讯APP，假定为微信；以及一个用户自行安装的地图导航APP。如果当前用户一边使用音乐播放器播放着音乐，一边使用微信与自己的好友进行视频通话。但是由于用户当前不需要导航，所以导航APP并没有被开启，仍处于关闭状态。针对该情况，若采集模块504进行信息采集，则微信与音乐播放器中的Activity可以作为被监测活动窗口，但是地图导航APP中的Activity却不可能是当前信息采集的对象，也即当前不可能是被监测活动窗口。

采集模块504在进行信息的采集的时候，可以通过调用终端50系统的意图询问功能。以Android系统为例，Intent功能主要是解决Android应用的各项组件之间的通讯。Intent负责对应用中一次操作的动作、动作涉及数据、附加数据进行描述，Android则根据此Intent的描述，负责找到对应的组件，将Intent传递给调用的组件，并完成组件的调用。在Android系统中包括PMS，而在PMS下就包括query Intent Activities。query IntentActivities是隶属于终端50系统的功能，因此，其具备访问终端50内存的能力，所以，能够完成对被监测活动窗口的窗口参数的采集。采集模块504调用query Intent Activities对被监测活动窗口实施信息采集时，只需要将采集指引信息中表征采集位置的信息传递给query Intent Activities，query Intent Activities就能根据该采集指引信息返回对应被监测活动窗口的窗口参数。

采集模块504采集被监测窗口的窗口参数时，可以根据预设采集策略进行。预设采集策略可由终端设计人员预先设置完成。若需要窗口参数的人是终端用户本人，则预设采集策略也可由用户自己设置。具体的，若预设策略要求采集模块504采集被监测活动窗口的所有窗口参数，则采集模块504可以控制意图询问功能返回被监测活动窗口的所有窗口参数。而如果终端用户或者终端设计人员仅对APP中活动窗口的部分数据感兴趣，则采集模块504可以通过意图询问功能对用户或者终端设计人员感兴趣的窗口参数进行采集，或者对所有的窗口参数进行采集，但是在返回数据之前先对采集到的窗口参数进行筛选。

当采集模块504采集到窗口参数之后，存储模块506可以将这些窗口参数存储到本地数据库中，以供用户自身分析使用。当然若需要窗口参数的是终端厂家或者是其他第三方平台，则终端50也可以在适当的时候将这些窗口参数从本地数据库中提取出来并传输到对应的服务器。如图6所示，终端50还包括传输模块508，传输模块508在适当的时候将这些窗口参数从本地数据库中提取出来并传输到对应的服务器。适当的时候指的是终端50相对空闲的时候，因为传输这些窗口参数必然要占用终端50部分处理资源与网络资源，所以为了不影响用户正常的体验，则传输模块508可以选择终端50任务较少或者完全空闲的时候传输窗口参数到服务器。

本实施例提供的终端，通过预先调用程序管理服务扫描终端中已安装的APP，然后通过查询进程列表查询能够表征当前正在运行的各APP的进程信息，并基于进程信息确定出针对终端当前正在运行的各APP值活动窗口的采集指引信息。在信息采集过程中，终端调用系统的意图询问功能根据预先获取到的采集指引信息到对应位置采集每一个被监测活动窗口的窗口参数，然后存储到本地数据库中，相对于现有技术中只能采集到APP名称、设计厂家等基础信息的信息采集方案而言，本发明提供的信息采集方案，通过意图询问功能和采集指引信息，能够获得APP等细节的信息，能够为需要了解APP信息的用户、终端厂家或者是其他第三方平台提供更多信息。

第四实施例：

目前，针对智能终端比较主流的系统中包括安卓系统、塞班系统、iOS系统等，相对于其他两种系统而言，安卓系统的应用更为广泛，所以本实施例中以安卓系统中的信息采集为例对本发明的终端做进一步介绍：

从图3所示出的安卓系统中APP的架构图可以看出，在安卓系统当中，各APP的运行也是以进程31为基本单位进行的，同时对于资源的分配，同样以进程为单位。程序管理32和活动窗口管理33分别从APP的整体和局部对其进行管理。程序管理32对APP的管理是从“宏观”的角度进行的，所以通过调用程序管理服务321能够了解到终端中所有已安装APP的基础信息。在程序管理服务321下具有活动窗口询问功能3211，在本实施例中，活动窗口询问功能3211能够直接根据采集指引信息实现首次信息采集以外的其他信息采集。而活动窗口管理33则管理着APP活动窗口的相关细节，例如各个活动窗口的窗口参数相对于程序管理32的管理，活动窗口管理33更像是从“微观”上对APP进行管理。在活动窗口管理33下包括活动窗口管理服务331，而活动窗口管理服务331下又通过活动窗口堆栈3311、活动窗口线程3312及活动窗口记录3313分别管理着APP活动窗口各个方面的参数。

下面请图7所示出的终端：终端70包括获取模块702、采集模块704、存储模块706。

获取模块702调用程序管理服务对自身已安装的所有APP进行扫面，然后查询进程列表，根据进程信息和扫描结果确定出当前处于运行状态的APP有哪些。同时，还可以通过进程列表中查询到的进程信息，结合活动窗口管理服务中的存储的各个活动窗口之间的映射关系确定出处于运行状态的APP的各活动窗口中的窗口参数的存储位置，生成采集指引信息，同时对采集指引信息进行存储记录。

由于第一实施例中已经介绍了获取模块702在采集模块704首次信息采集时确定采集指引信息的过程，这里不再做详细介绍。

不过在本实施例中，获取模块702根据进程信息和映射关系确定出应当到活动窗口堆栈、活动窗口线程及活动窗口记录的哪些位置去采集各被监测活动窗口的窗口参数后，采集模块704可以直接到相应位置进行首次信息采集。首次信息采集过程不需要调用query Intent Activities，因为首次信息采集就像是一个从APP“宏观”到“微观”的完整采集过程，不需要通过query Intent Activities根据窗口参数的采集位置实现“跳跃”采集。

在针对当前处于运行状态的APP进行信息采集的过程当中，完整的信息采集过程至少会包含一个首次信息采集过程，而绝大多数信息采集过程，可能还会包括一个及以上的再次采集过程。在本实施例中，存储模块706会在对一个完整的信息采集过程中所采集到的所有信息进行处理之后再存储到终端70本地数据库中。所以，针对每一次单独的信息采集的采集结果，采集模块704会把它们存储到临时关系数据结构中。

临时关系数据结构相当于一个存放窗口参数的临时数据库，采集模块704在采集到窗口参数后，之所以没有直接通过通用数据接口把采集结果存储到本地数据库中，这主要是由于采集到的窗口参数需要经过解析及冗余处理等流程后才能存储到本地数据库，以便保证终端70本地数据库中存储的窗口参数都是有意义的，提升终端70本地数据库容纳有用信息的能力。在本实施例的一种示例当中，临时关系数据结构可以为Hash Map。

采集模块704每次采集完窗口参数之后，都会判断当前是否存在应用程序的运行状态由运行状态到非运行状态的变化。若判断结果为是，则说明原本的处于运行状态的部分APP已经不再运行了，也就是说有部分被监测活动窗口已经无法采集到数据了。在这种情况下，可以认为当前一个完整的信息采集过程已经结束了，因此可以通知存储模块706将临时关系数据结构中存储的窗口参数提取到本地数据库中。若判断结果为否，则采集模块704应当继续执行再次采集过程，即应当继续通过调用query Intent Activities来进行信息采集。

在再次信息采集过程当中，采集模块704调用query Intent Activities根据采集信息指引信息对被监测活动窗口的窗口参数进行信息采集。采集模块704可以采集被监测活动窗口的全部窗口参数，也可以仅对其中部分信息进行采集并返回，或者也可以采集全部信息，但在返回之前先进行一定的筛选。query Intent Activities返回的信息是针对某一个被监测活动窗口的，返回的信息相当于该被监测活动窗口的“档案”。再次信息采集过程完成后，采集模块704会又一次判断当前是否存在应用程序的运行状态由运行状态到非运行状态的变化。

若采集模块704确定当前存在应用程序的运行状态由运行状态到非运行状态的变化，则存储模块706可以通过迭代器提取临时关系数据结构中的窗口参数。迭代器是一种对象，它能够用来遍历标准模板库容器中的部分或全部元素，每个迭代器对象代表容器中的确定的地址。如图8所示，存储模块706当中包括解析处理模块7061、冗余处理模块7062和数据写入模块7063。

存储模块706用于对提取出的窗口参数进行信息解析，从这些窗口参数中可以解析出当前在运行的APP进程名称、UID、NICE值、进程状态、ADJ值等进程相关信息以及用户当前切到前台的APP信息，包括APP名称、类型、top Activity相关信息，top Activity相关信息包括用户停留在该APP的top Activity的时长、开始访问时间、离开访问时间、用户访问时是否联网、网络类型、用户位置、用户状态等信息。

冗余处理模块7062可对解析处理后的窗口参数进行冗余处理。冗余处理过程主要是为了剔除采集结果中的无用部分例如，针对第一活动窗口的状态信息，在1:00到5:00中的每个整点时分，采集模块704进行信息采集。最终采集结果表明，第一活动窗口在1:00到4:00这段时间内的状态均为“状态1”，而4:00采集到的状态则变为“状态0”。若要将这5次采集结果均进行保存，则需要进行类似于表1的存储。表1中这种不经处理，直接对采集到的窗口参数进行存储的方案，必然需要使用较大容量的空间来存储这5小时之间第一活动窗口的参数。但是，如果对这些窗口参数进行冗余处理之后，则可以采用如表2的形式进行存储。经过冗余处理之后，针对相同的信息量，可以通过更少的存储空间来容纳存储，反言之，即提升了原存储空间的利用率。

数据写入模块7063用于将处理后的窗口参数分类写入到本地数据库的各分类存储表中。在终端70的本地数据库当中，可以包含多个分类存储表，这些分类存储表用于存储不同的窗口参数。例如，可以通过“用户状态表”来对用户状态进行定义；通过“APP活动窗口统计信息表”来收纳某一个APP活动窗口的相关信息；通过“APP时间段表”来记录用户在不同时间段在各APP活动窗口的停留情况与操作情况等。由此可见，这些分类存储表决定了窗口参数在本地数据库中的存储类别。可以理解的是，窗口参数在本地数据库中的存储类别是可以由信息需求对象决定的，所以，分类存储表可以由信息需求对象设置，例如用户自定义设置、第三方平台设置后由用户下载导入等。

另外，数据写入模块7063可以自动地将窗口参数分类存储到本地数据库中，而在本实施例的而一种示例当中，用户可以通过终端70的输入单元控制数据写入模块7063通过通用数据读写接口实现对本地数据库的管理。例如，控制窗口参数的写入，具体的包括写入时间、写入位置等，或者控制窗口参数的修改、删除等。

在本实施例中，终端70还包括监测模块708，采集模块704在进行信息采集和/或存储模块706将采集结果存储到本地数据库的过程当中，监测模块708还会接收系统的新增通知，新增通知用以告知终端70中当前存在APP的状态由非运行状态变为了运行状态，也即，采集模块704当前进行信息采集的对象有了增加。这时候，获取模块702需要判断针对该APP的活动窗口是否已经记录了采集指引信息，如果已经记录了，则采集模块704可以直接调用query Intent Activities按照再次信息采集过程实现窗口数据采集。如果之前并没有记录该APP互动窗口的采集指引信息，则获取模块702需要通过自身的进程列表确定该新增APP的新增进程信息，并基于新增进程信息确定针对该新增APP各活动窗口的采集指引信息，由采集模块704根据确定出的采集指引信息实现窗口参数采集。

本实施例提供的终端，不仅可以根据采集指引信息调用query IntentActivities实现对活动窗口之窗口参数的采集，能够为用户以及其他需要了解APP信息的其他对象提供更加详细的采集结果。而且终端在将采集到的窗口参数存储到本地数据库之前，会先对采集结果进行解析处理、冗余处理等，而且在本地数据库中以分类存储表的形式存储窗口参数，使得采集结果更加明晰、更直观，让需要了解APP信息的对象能够在以更简单的方式了解到更多详细的信息。

第五实施例：

本实施例在第三实施例与第四实施例的基础上对本发明中终端的硬件结构进行阐述，本实施例中的终端可以以各种形式来实施，诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的移动终端。应当明白的是，固定终端也可作为本实施例终端的一种实施形式。下面，假设终端是移动终端，请参考图9所示出的一个可选的移动终端的硬件结构示意图：

移动终端900可以包括无线通信单元910、感测单元920、存储器930、控制器940等等。图9示出了移动终端的部分组件，但是应理解的是，并不要求实施所有示出的组件，可以替代地实施更多或更少的组件，将在下面详细描述移动终端的元件。

无线通信单元910通常包括一个或多个组件，其允许移动终端900与无线通信系统或网络之间的无线电通信。例如，无线通信单元910可以包括移动通信模块911、无线互联网模块912等。移动通信模块911将无线电信号发送到基站(例如，接入点等等)、外部终端以及服务器中的至少一个和/或从其接收无线电信号。这样的无线电信号可以包括语音通话信号、视频通话信号、或者根据文本和/或多媒体消息发送和/或接收的各种类型的数据。无线互联网模块912支持移动终端的无线互联网接入。该模块可以内部或外部地耦接到终端。该模块所涉及的无线互联网接入技术可以包括WLAN(无线LAN)(Wi-Fi)、Wibro(无线宽带)、Wimax(全球微波互联接入)、HSDPA(高速下行链路分组接入)等等。

在本实施例中，若移动终端中采集到的窗口参数需要被传输到第三方平台或移动终端厂商所提供的服务器时，无线通信单元910可在控制器940的控制下，选择移动终端900较为空闲时段完成窗口参数的传输，以供第三方平台或移动终端厂商对接收到的窗口参数进行统计分析，并在此基础上实现其他应用功能的设计开发。由于移动运营商提供的数据流量基本都收费昂贵，所以为了避免窗口参数的传输给用户带来较重的经济负担，本实施例中可以由无线互联网模块912在移动终端处于WiFi环境下时进行数据传输。

感测单元920检测移动终端900的当前状态，(例如，移动终端900的打开或关闭状态)、移动终端900的位置、用户对于移动终端900的接触(即，触摸输入)的有无、移动终端900的取向、移动终端900的加速或减速移动和方向等等，并且生成用于控制移动终端900的操作的命令或信号。例如，当移动终端900实施为滑动型移动电话时，感测单元920可以感测该滑动型电话是打开还是关闭。

在本实施例中，若要求采集的窗口参数不仅包括活动窗口的各项具体参数，还包括用户停留在该活动窗口的运动状态时，移动终端900可以通过感测单元920来检测用户的运动状态，并由控制器940根据预先确定的划分规则确定用户是处于“慢走状态”、“快走状态”还是“静止状态”。

存储器930可以存储由控制器940执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器930可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。存储器930可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，移动终端900可以与通过网络连接执行存储器930的存储功能的网络存储装置协作。

本实施例中用于存储窗口参数的本地数据库和临时关系数据结构均可以设置在存储器930上，具体的，控制器940可以为本地数据库和临时关系数据结构分配不同的存储位置和存储空间大小。

控制器940通常用于控制移动终端100的总体操作。本发明第三实施例及第四实施例中的获取模块、采集模块、监测模块的功能均可以通过控制器940来实现，而存储模块的功能则可以由控制器940控制存储器930实现。而第三实施例中的传输模块的功能可由无线通信单元910在控制器940的控制下实现。

具体地，在移动终端900初次对自身的APP进行信息采集时，控制器940调用程序管理服务对已安装的所有APP进行扫描，然后查询进程列表，通过进程列表中查询到的进程信息，结合活动窗口管理服务中的存储的各个活动窗口之间的映射关系确定出处于运行状态的APP的各活动窗口中的窗口参数的存储位置，生成采集指引信息，同时将采集指引信息存储记录到存储器930中。在此之后，移动终端900的控制器可以直接调用query IntentActivities根据存储器930中的采集指引信息返回窗口参数。控制器940采集到窗口参数之后，会将窗口参数存储到设置在存储器930里的临时关系数据结构中。当一个完整的信息采集过程结束后，控制器940从临时关系数据结构中提取出采集到的信息，进行解析处理及冗余处理之后，再将窗口参数写入到存储器930中的本地数据库，并且在本地数据库中，窗口参数是被记录到分类存储表上的。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器940中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器930中并且由控制器940执行。

至此，己经按照其功能描述了移动终端。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型移动终端等等的各种类型的移动终端中的滑动型移动终端作为示例。因此，本发明能够应用于任何类型的移动终端，并且不限于滑动型移动终端。

本实施例中提供的移动终端，由控制器先获取对采集被监测活动窗口的窗口参数起位置指引作用的采集指引信息，然后调用终端系统的意图询问功能，根据该采集指引信息按照预设采集策略对当前处于运行状态的APP的活动窗口进行窗口参数的采集，并将采集到的窗口参数存储到存储器中。通过系统意图询问功能，使得APP信息采集过程不受系统权限的限制，从而能够触及并采集到APP中被监测活动窗口的窗口参数。另外，由于采集到的窗口参数相对于APP的基础信息，表征了移动终端中APP的更多细节，能够向信息需求对象提供更多的信息。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。

Claims

1.一种信息采集方法，其特征在于，包括：

将采集到的所述窗口参数存储到所述终端的本地数据库。

2.如权利要求1所述的信息采集方法，其特征在于，将采集到的所述窗口参数存储到所述终端的本地数据库包括：

将采集到的所述窗口参数存储到临时关系数据结构中；

3.如权利要求2所述的信息采集方法，其特征在于，将经过处理的所述窗口参数存储到所述终端的本地数据库中包括：

4.如权利要求1所述的信息采集方法，其特征在于，所述按照预设采集策略采集被监测活动窗口的窗口参数包括：

5.如权利要求1-4任一项所述的信息采集方法，其特征在于，所述按照预设采集策略采集被监测活动窗口的窗口参数之前还包括：

6.如权利要求5所述的信息采集方法，其特征在于，所述基于查询到的所述进程信息确定针对当前处于运行状态的各所述应用程序活动窗口的采集指引信息之后还包括：直接根据所述采集指引信息完成对所述被监测活动窗口之窗口参数的初次采集。

7.如权利要求5所述的信息采集方法，其特征在于，基于查询到的所述进程信息确定针对当前处于运行状态的各所述应用程序活动窗口的采集指引信息包括：

8.如权利要求5所述的信息采集方法，其特征在于，还包括：

9.一种终端，其特征在于，包括：

10.如权利要求9所述的终端，其特征在于，所述获取模块，用于调用所述终端系统的程序管理服务扫描所述终端中当前已安装应用程序；根据扫描结果到所述终端的进程列表中查询当前处于运行状态的各应用程序的进程信息；基于查询到的所述进程信息确定针对当前处于运行状态的各所述应用程序活动窗口的采集指引信息，并存储记录所述采集指引信息。