CN109284102B - 信息采集方法及装置 - Google Patents

Abstract

本申请实施例公开了信息采集方法及装置，其中，所述方法包括：在目标应用程序中关联软件开发工具包SDK，所述目标应用程序中包括至少一个界面，在所述界面的代码中，为需要进行信息采集的视图添加采集标志信息；通过所述SDK执行以下操作：对所述界面内的事件进行检测；在检测到目标事件时，确定事件类型以及关联的目标视图；根据所述目标视图带有的采集标志信息，确定进行信息采集；根据所述事件类型信息以及所述目标视图的标识信息，生成信息采集结果。通过本申请实施例，能够在降低信息采集成本的前提下，提高稳定性。

Description

信息采集方法及装置

技术领域

本申请涉及信息采集技术领域，特别是涉及信息采集方法及装置。

背景技术

构建一个数据平台，大体上包括数据采集、数据上报、数据存储、数据计算以及数据可视化展示等几个重要的环节。其中，数据采集与上报是整个流程中重要的一环，只有确保前端数据生产的全面、准确、及时，最终产生的数据结果才是可靠的、有价值的。

为了达到上述目的，现有技术中主流的解决方案主要有两种，第一种是代码埋点，第二种是遍历所有的布局路径，将路径按树的方式存储，并上传所有节点的XPath路径，以此达到所有节点上传的目的。

其中，代码埋点的方式下，开发者需要手动在需要埋点的节点处(例如：点击事件的回调方法、列表元素的展示回调方法、页面的生命周期函数等等)插入埋点代码。虽然使用起来灵活，但是开发成本较高，并且一旦上线就很难修改，如果发生严重的数据问题，只能通过发热修复解决。另外，代码埋点是一种典型的命令式编程，因此埋点代码常常要侵入具体的业务逻辑，这使埋点代码变得很繁琐并且容易出错。

而如果采用第二种方案，数据量过大，由于并不是所有节点都需要上传，因此，大数据量的上传是没有意义的，只会导致浪费流量及存储空间。其次，对于处于树的同一层的复用节点，XPath路径无法正确区分。

因此，如何在降低信息采集成本的前提下，提高稳定性，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了信息采集方法及装置，能够在降低信息采集成本的前提下，提高稳定性。

本申请提供了如下方案：

一种信息采集方法，包括：

在目标应用程序中关联软件开发工具包SDK，所述目标应用程序中包括至少一个界面，在所述界面的代码中，为需要进行信息采集的视图添加采集标志信息；

通过所述SDK执行以下操作：

对所述界面内的事件进行检测；

在检测到目标事件时，确定事件类型以及关联的目标视图；

根据所述目标视图带有的采集标志信息，确定进行信息采集；

根据所述事件类型信息以及所述目标视图的标识信息，生成信息采集结果。

一种信息采集装置，包括：

SDK关联单元，用于在目标应用程序中关联软件开发工具包SDK，所述目标应用程序中包括至少一个界面，在所述界面的代码中，为需要进行信息采集的视图添加采集标志信息；

所述SDK包括：

事件检测单元，用于对所述界面内的事件进行检测；

确定单元，用于在检测到目标事件时，确定事件类型以及关联的目标视图；

信息采集确定单元，用于根据所述目标视图带有的采集标志信息，确定进行信息采集；

采集结果生成单元，用于根据所述事件类型信息以及所述目标视图的标识信息，生成信息采集结果。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以通过在应用程序中接入SDK，并在界面代码中对需要采集的视图进行标记的方式，实现更有针对性的信息采集及提交，避免造成过大的数据量，避免占用过大的流量计存储空间。并且，不需要业务方执行手动的代码埋点等操作，而只需要对视图执行标记操作，因此，开发成本比较低，这种标记信息也不会侵入具体的业务逻辑，不会由于标记信息的存在导致业务逻辑混乱。再者，由于是在检测到具体的事件后，可以采用视图的ID、名称等标识来表达一个具体的视图，而这些信息在应用程序改版等过程中，并不是像XPath那样具有多变性，因此，即使应用程序出现改版，也可以保证一定的稳定性。

其次，在界面代码中对需要进行信息采集的视图进行标记时，可以为视图定义名称，并且还可以是具有业务语义的名称，这样，可以直接将这种名称作为采集标志，在通过采集标志判断是否需要进行采集的同时，还可以获取到名称，并以此作为视图的标识，添加到信息采集结果中。这样的信息采集结果在提交后，具有更高的可读性，便于进行后续的数据分析处理。

另外，在优选的实现方式下，还可以允许业务方在界面代码中为视图标记出扩展信息，在生成信息采集结果时，还可以将扩展信息添加到信息采集结果中。例如，可以将视图内的内容描述信息作为扩展信息，这样，在同一视图在不同的时间点被不同的内容所复用时，可以根据这种扩展信息，更准确的确定出具体事件的作用对象。

再者，关于界面中各视图所共同具有的公共信息，还可以在界面代码中用同一行代码进行统一设置，而不需要为每个视图分别进行设置，在提交信息采集结果时，可以判断是否存在这种公共信息，如果存在，可以分别添加各条信息采集结果中。这样，可以提高开发效率，节省业务方的人力操作成本。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的实现方案的示意图；

图2是本申请实施例提供的方法的流程图；

图3是本申请实施例提供的装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，可以以界面中的视图(view)为出发点，通过白名单的方式对需要进行信息采集的视图进行标记，在事件发生时，通过视图在页面中的位置等信息来确定事件作用的视图，进而进行信息的采集以及提交。其中，参见图1，界面就可以是应用程序内的界面，一个应用程序内可以包括多个界面，可以是指首页或者其他页面。应用程序则可以是任意的具有信息采集需求的应用程序。视图是指界面中用于承载具体信息内容展示的对象，一个界面内可以包括多个视图，例如，对于无线端“天猫”这一应用程序，其首页中的视图可以包括横幅(banner)、坑位等，其中，banner区主要用于滚动展示一些图片等，具体的坑位则有多个，每个坑位中展示的内容通常可以由图片+标题等方式来组成，通过点击这种坑位，可以跳转到其他的界面，例如，某坑位内展示了某数据对象的链接，则点击该坑位后，可以跳转到该数据对象的详情页，等等。因此，这种banner就对应一个视图，每个坑位也分别对应一个视图。本申请实施例就是通过对这种视图进行标记的方式，来确定需要进行信息采集的视图，例如，如图1中所示，同一个界面内的多个视图，可以是有的进行了标记，有的则未标记。在进行采集时，可以根据视图的名称、ID等标识信息生成信息采集结果。这样，在应用程序发生改版等情况时，虽然视图的Xpath等信息有着极大的可能性会发生变化，但是，视图的名称、ID等标识信息则是相对稳定的，因此，即使发生改版，也可以使得信息采集得以继续进行。

另外，在具体实现时，本申请实施例可以通过SDK的方式向业务方提供支持，也就是说，业务方可以下载这种SDK，并将其接入到其需要进行信息采集的应用程序中。另一方面，业务方还可以对需要进行信息采集的界面代码进行一些配置，需要说明的是，在本申请实施例中，对界面代码的配置过程，并不是在进行代码埋点，而是对一些需要进行信息采集的视图进行标记，添加采集标志信息。

也就是说，为了配合本申请实施例提供的技术方案，业务方可以在界面代码中添加一些标记信息，这种标记信息可以用于区分，哪些视图是需要进行信息采集的，哪些不需要，从而避免将全部的视图都进行采集，造成传输以及存储资源的浪费。

具体实现时，这种采集标志信息可以简单的配置为标志符，这种标志符可以仅用于表达“是”或者“否”的含义，这样，SDK在运行过程中，就可以根据这种标志符，来确定是否对某个视图的事件信息进行采集。在这种情况下，对于需要进行采集的视图而言，可以将视图的ID等信息，作为视图的标识添加到信息采集结果中，并进行提交。

但是，由于提交的信息采集结果通常是用于进行大数据分析等，并且，分析的过程中会有人为参与的成分，因此，信息采集结果的可读性是比较重要的。如果信息采集结果中携带的是视图的ID等信息，则会造成可读性差等问题。因此，在优选的实施例中，可以将由业务方为各个需要进行信息采集的视图定义视图名称，在更为优选的实现方式下，这种视图名称还可以具有业务含义。例如，界面的横幅位置对应的视图的名称可以定义为banner，等等。在定义了视图名称的情况下，可以将视图名称作为信息采集标志，也就是说，不需要再另外配置标志符等信息，只要在界面代码中为视图添加视图名称，则可以代表该视图是需要进行信息采集的视图，并且，在检测出与这种视图相关的事件时，可以直接用视图名称作为视图的标识，添加到信息采集结果中。这样，通过以视图名称作为信息采集标志，不仅可以用于识别需要进行信息采集的视图，还可以同时获取到视图的标识信息，因此，可以提高效率。而在使视图名称具有业务含义的情况下，还可以提高信息采集结果的可读性，可以更方便的用于大数据分析等处理。

另外，在实际应用中，可能出现视图复用的情况，也就是说，对于同一界面中的同一视图，在不同的时间点，在视图的位置、名称等不变的情况下，视图内展示的内容却可能会发生变化，这种情况也可以称为：不同的内容复用同一视图。例如，某名称为icon1的视图，在某时刻展示的可能是某件衣服的链接，而在另一时刻则变成某鞋子的链接，等等。此时，在采集视图的信息时，如果仅携带视图名称信息，则可能会无法体现出实际被点击的是哪个链接，或者实际曝光的是哪个链接。针对这种情况，在某目标视图发生某事件时，除了需要提交视图的名称信息，业务方可能还会需要提交视图的其他信息，例如，可能还需要提交视图的内容等信息，以便利用这种内容信息，来更好的确定出事件的作用对象。

此时，为了满足这种需求，还可以允许业务方在界面代码中为视图添加扩展信息，或者称为补充信息。这样，业务方就可以针对有需要的视图，添加扩展信息，对于SDK而言，在检测到某目标视图发生某事件时，如果发现界面代码中还包括扩展信息，则也可以添加到信息采集结果中。这样，在将信息采集结果提交后，在进行数据分析时，就不仅可以确定出是哪个名称的视图发生了具体的事件，还可以确定出发生事件时，视图内具体的展示内容等扩展信息，使得信息更为全面、具体、准确。需要说明的是，在具体实现时，可以并不是对每个视图都定义扩展信息，也就是说，在以视图名称作为信息采集标志的情况下，业务方可以在界面代码中为每个具有信息采集需求的视图添加名称信息，而可以仅针对其中的部分视图添加扩展信息，或者，在不存在视图复用或视图内容变化不频繁的情况下，也可以全都不添加这种扩展信息，等等。当然，这种扩展信息除了可以是视图内展示的内容之外，还可以有其他的信息。

再者，在具体实现时，还可能存在同一个界面中的不同视图共用某部分信息的情况。例如，在直播业务场景下，界面中会在直播窗口下方或者其他位置设置一些视图(坑位等)，包括用于数据对象展示的视图，用于评论的视图，等等。这种直播界面中通常会用于承载多场不同的直播，每场直播的内容不同，不同的直播内容有不同的直播ID。对于每场不同的直播，界面内设置的视图的名称、位置等信息通常是不会变的，但是，每场不同的直播，在具体的视图内展示的内容可能会有变化，例如，主播A在进行直播时，视图内展示的数据对象可能是与该主播A的直播内容相关的一些数据对象，主播B进行直播时，可能会又会变为与该主播B的直播内容相关的一些数据对象，相应的，评论区的情况也会不同。也就是说，在这种情况下，当一个视图发生点击或者曝光等事件时，可能不仅与视图内展示的内容相关，还与当前界面中的直播内容有关，因此，业务方可能需要在进行信息采集时，不仅提交视图的名称，还需要提交视图内的内容信息，此外，还需要提交对应的直播ID信息，以用于区分具体是哪场直播带来的点击或曝光等事件。在这种情况下，可以将视图内的内容信息以及页面内的直播ID都作为扩展信息的方式，在界面代码中进行设置。但是，直播ID这一信息，对于界面内各视图而言都是相同的，如果对每个需要提交该信息的视图都在界面代码中进行一遍设置，则会造成大量的重复操作。

为此，在本申请的优选实施例中，还可以允许业务方为界面代码中需要进行信息采集的视图单独配置公共信息，这种公共信息可以仅配置一次即可，而不需要为每个视图都配置一遍。在SDK检测到某视图发生某事件时，如果该视图带有名称等采集标志信息，则确定出视图的名称、扩展信息等基础上，还可以判断界面中是否配置了公共信息，如果有，则还可以在视图的名称、扩展信息等基础上，添加上这种公共信息，将这些信息拼接在一起，作为信息采集结果进行提交。这样，可以更全面详细的提交信息采集结果，并且，还可以降低业务方的工作量。

通过以上所述，在优选的实现方式下，对于同一需要进行信息采集的视图而言，可以在界面代码中配置多种类型的标记信息，例如，可以包括名称信息，在需要的情况下，还可能标记扩展信息，甚至，还可能在界面中为各需要进行信息采集的视图配置公共信息，等等。为了便于对各种不同类型的标记信息进行区分，在具体实现时，可以采用“键值对”也即“key-value”的方式进行标记。其中，“key”可以是由SDK提供方定义的，“value”则可以由业务方来进行定义。例如，针对上述三种不同类型的标记信息，可以定义三种不同的“key”，分别为“-9001”，“-9002”和“-9003”。其中，“-9001”代表视图名称，“-9002”可以代表扩展信息，“-9003”则可以代表公共信息。例如，对于某视图，如果需要进行信息采集，则可以在界面代码中该视图所在的位置处添加一行代码：“-9001：banner1”，这样，SDK就可以获知，业务方为该视图定义的名称为“banner1”，该信息不仅可以作为确定该视图是否需要进行采集的标志，还可以作为视图的标识信息，添加到信息采集结果中。另外，如果业务方还希望为该视图提交其他的信息，则还可以在该视图所在的界面代码中添加另一行代码，“-9002：×××”，则SDK在确定出该视图发生某事件时，还可以将该扩展信息添加到信息采集结果中。再者，如果业务方还需要为界面中各个需要进行信息采集的视图配置公共信息，则可以在界面代码中添加一行代码，例如，“-9003：某直播的ID”，则在提交各视图的信息采集结果时，还可以将该公共信息添加到各视图的信息采集结果中。

业务方在其应用程序中引入SDK，并按照前述方案进行在界面代码中为视图添加了标记之后，在应用程序被启动并运行的过程中，SDK就可以在完成初始化之后，执行具体的事件检测以及信息采集等相关操作。具体的，可以通过这种SDK，对界面生命周期内的事件进行检测，具体的事件可以包括用户操作事件，或者系统执行的事件，等等。例如，用户执行的点击操作，或者在界面内的滑动操作等，都属于用户操作事件。在界面中存在“轮播”等内容(例如，banner部分通常可以以轮播的方式对多幅图片进行展示)时，在每次进行播放内容的切换时，还会触发系统的界面重绘事件，这种属于系统执行的事件。

具体的事件检测方式可以有多种，例如，在其中一种实现方式下，可以采用钩子(Hook)的方式进行检测，也即，通过Hook一些系统函数，实现对界面内的消息进行监控，并通过回调的方式，获得具体的事件信息。这种方式比较简单，但是在稳定性方面可能存在一些问题。

在本申请实施例的优选实施方式中，可以采用另一种事件检测方式。也即，可以在应用程序启动，并且界面内的各个视图都渲染完成后，创建一个虚拟的视图，其中，界面中各视图通常具有树形结构，在创建该虚拟视图时，可以是在树形结构的最顶层创建该虚拟视图，使得该虚拟视图成为界面内各视图组成的树形结构中根节点的根节点。这样，界面生命周期内的与视图相关的事件，就都可以由该虚拟视图接管，这样，可以通过这种虚拟视图抓取到界面生命周期内产生的与视图相关的事件信息。这种方式虽然会使得视图的层数增加，但是稳定性更强，也可以更方便快捷的进行事件检测。

在检测到具体的事件后，就可以确定出事件类型以及对应的目标视图。其中，在本申请实施例中，事件类型可以包括点击、曝光等类型。具体的，如果检测到的事件是用户执行的点击事件，则可以将事件类型确定为点击，如果检测到的是用户滑动屏幕的事件，或者系统自动触发的界面重绘事件，则可以将事件类型确定为曝光，等等。

在确定出事件类型之后，还可以确定出事件作用的目标视图。其中，对于点击类型的事件而言，由于一次点击的是一个视图，因此，确定目标视图的过程，就是确定出当前被用户点击的是哪个视图。具体实现时，可以通过以下方式实现：首先，系统可以给出点击事件发生的位置坐标信息，而界面中各视图在在当前显示屏中的坐标也是可以确定出来的，这样，就可以根据这种位置坐标信息，确定出点击事件对应的目标视图。

而对于用户的滑动屏幕事件，或者系统的重绘事件而言，由于一次滑动或者一次重绘可能会使得多个视图由不可见变为可见，因此，对应的目标视图通常可以为多个。当然，如果是由于banner等视图的轮播触发的系统重绘，则涉及的目标视图会仅有一个。总之，在检测到这种曝光事件时，为了确定出具体对哪个或者哪些视图进行了曝光，可以对界面中各个视图的可见/不可见属性进行遍历，如果某视图为可见属性，则属于在此次事件中被曝光的目标视图。当然，在实际应用中，由于界面具有连续性，用户的滑动操作也具有连续性，因此，可能存在以下情况：在用户滑动过程中，上一次滑动将一些视图由不可见变为可见，此次滑动时，将之前可见的视图中的一部分变为不可见，另一部分仍然可见，另外还有一部分视图由原来的不可见变为可见。因此，具体在确定此次曝光事件将哪些视图曝光时，可以结合上次滑动结束后，视图的可见/不可见属性进行对比，将此次事件中，由原来的不可见变为可见的部分视图，作为此次曝光事件的目标视图，等等。

当然，在实际应用中，对于曝光事件而言，一个视图具体被曝光的时间长度，可能也是业务方需要获知的信息，因此，还可以确定出一个视图的曝光时间长度信息，并添加到信息采集结果中。例如，可以记录一个视图从不可见变为可见时的第一时间点，以及由可见变为不可见时的第二时间点，这样就可以根据第二时间点与第一时间点的差值，确定出该视图的曝光时间长度信息。

另外，在具体实现时，有些曝光可能属于无效的曝光，例如，某视图的曝光时间长度很短，只有几毫秒，则证明该视图的内容可能并没有引起用户的注意，以至于用户的视线没有在该视图上停留，就继续向上或者向下滑动了。对于这种情况下，业务方可以将其设定为无效的信息，因此，不必将这种视图视为被曝光的视图。或者，某视图在某次滑动事件中，实际被曝光的面积比较小，例如，可能只有20％等，则证明用户的视线焦点可能也并不在此视图上，因此，也可以不必将这种视图视为被曝光的视图，等等。针对上述情况，可以预先进行配置，例如，关于具体多长的曝光时间长度可以作为有效的曝光，多大的曝光面积可以视为有效的曝光，等等。其中，系统中可以存在默认的配置信息，或者，在本申请实施例中，还可以为业务方提供相应的配置入口，由业务方根据自己的需求进行个性化的配置，等等。也就是说，对于不同的业务方而言，对于有效曝光的定义可以是不同的，SDK可以优先使用业务方自定义的信息进行确定，如果业务方未配置，则按照系统默认的配置信息进行确定。

在确定出具体的事件类型，以及事件中关联的目标视图后，就可以确定出目标视图的标识信息，例如，如果界面代码中以视图的名称作为采集标志，则可以通过获取视图的名称的方式，来确定目标视图的标识信息。具体的，可以通过Get tag等函数来进行获取。当然，在业务方还为目标视图定义了扩展信息的情况下，也可以一起获取出来，添加到信息采集结果中。另外，如果业务方还未界面中的各个视图定义了公共信息，则也可以获取出去，添加到信息采集结果中，等等。

在生成具体的信息采集结果后，就可以进行提交操作。其中，对于不同类型的事件，信息采集结果的提交时机也可以有所不同。例如，对于点击事件而言，由于通常仅涉及一个视图，并且，不同的点击事件之间通常具有独立性，因此，可以是在每次检测到点击事件，并确定出关联的信息采集结果后，就执行一次提交操作。而对于曝光事件而言，由于需要采集的信息可能比较多，并且，有些信息在多次曝光之间可能具有关联，因此，曝光事件的信息采集结果，可以在界面的生命周期结束时，再进行提交，等等。

以上所述对本申请实施例的具体实现方案进行了详细介绍，通过以上所述可见，本申请实施例主要提供了一种信息采集方法，参见图2，该方法具体可以包括：

S201：在目标应用程序中关联软件开发工具包SDK，所述目标应用程序中包括至少一个界面，在所述界面的代码中，为需要进行信息采集的视图添加采集标志信息；

其中，如前文所述，SDK可以是本申请实施例中为各个应用程序对应的业务方或者开发者提供的工具，业务方或者开发者可以下载这种SDK并接入到自己的应用程序中。并且，为了配合该SDK，还可以对界面中的视图进行一些标记工作。

具体实现时，所述采集标志信息可以包括为视图定义的名称信息；此时，如果所述界面代码中为目标视图配置了名称信息，则可以确定所述目标视图为需要进行信息采集的视图，并将所述名称信息确定为所述目标视图的标识信息。

为了提高信息采集结果的可读性，所述为视图定义的名称信息可以包括带有业务语义的名称信息，例如，banner，shop等等。

在可选的实施方式中，还可以在界面代码中为需要进行信息采集的视图添加附加信息，所述附加信息用于：在视图存在复用时，通过所述附加信息区分不同的视图。具体的，所述视图的附加信息包括：视图内展示的内容描述信息。或者，还可以是其他信息，这里不再详述。

另外，还可以在界面代码中为需要进行信息采集的视图添加公共信息，所述公共信息为所述界面内所具有的与各视图均相关的公共信息。这样，可以通过将所述目标视图的名称信息与所述公共信息进行拼接，再结合具体的事件类型信息，生成信息采集结果。

在一种具体的应用场景下，所述公共信息包括界面中的直播类信息的标识；所述需要进行信息采集的视图包括：所述界面中与所述直播类信息相关的视图，在直播类信息发生变化时，所述界面中与所述直播类信息相关的视图的名称不变。

在另一种实现方式下，也可以在界面代码中为需要进行信息采集的视图添加预置的标志符，这样，如果所述目标视图带有所述标志符，则确定所述目标视图为需要进行信息采集的视图，并所述目标视图的ID或路径等信息作为所述目标视图的标识信息。

需要说明的是，在实际应用中，还可能存在以下情况：对于某视图，业务方需要对其进行信息采集，但是，在界面代码中漏掉了对该视图名称等标志的配置，此时，本申请实施例还可以提供一种补救方案。也即，可以接收对未添加采集标志信息的视图进行信息采集的请求，然后，在检测到与所述未添加采集标志信息的视图相关的事件时，根据事件类型以及该视图的ID或路径等信息，提交信息采集结果。

在所述目标应用程序启动后，可以对所述SDK进行初始化处理。其中，对SDK的初始化主要包括对一些默认的开关进行初始化，或者对全局的上下文等进行赋值等操作。之后，就可以通过所述SDK执行以下操作：

S202：对所述界面内的事件进行检测；

界面内的事件具体就可以是指用户操作事件，或者系统触发的事件，等等。具体对事件检测的方式可以有多种。例如，在其中一种方式下，可以是在所述界面中的各视图被渲染完成后，在所述各视图组成的树形结构的最顶层，创建虚拟视图层，然后，通过所述虚拟视图层抓取所述界面生命周期内的事件。或者，也可以通过钩子Hook以及回调函数的方式，对界面内的事件进行检测。

S203：在检测到事件时，确定事件类型以及关联的目标视图；

检测到事件之后，可以根据具体事件信息，确定出事件类型。其中，事件类型可以是预先定义好的，例如，可以包括点击、曝光等多种类型。具体实现时，在检测到用户的点击操作事件时，可以确定事件类型为点击；并且，可以根据点击操作事件作用的坐标信息，确定位于该坐标处的视图为目标视图。

或者，在检测到系统的界面重绘事件，或者用户的滑动操作事件时，可以确定事件类型为曝光，然后，通过遍历界面内各视图的可见/不可见状态，确定从可见变为不可见的第一目标视图，以及从不可见变为可见的第二目标视图。其中，对于这种曝光事件中涉及到的视图，还可以确定出曝光时间长度等信息，添加到信息采集结果中。

S204：根据所述目标视图带有的采集标志信息，确定进行信息采集；

在确定出事件关联的目标视图后，就可以确定出是否需要对该视图进行事件信息的采集。具体的，就可以根据目标视图是否带有采集标志信息，确定是否需要进行信息采集。

S205：根据所述事件类型信息以及所述目标视图的标识信息，生成信息采集结果。

在确定出需要进行采集后，就可以根据所述事件类型信息以及所述目标视图的标识信息，生成信息采集结果。其中，关于目标视图的标识信息，可以是目标视图的ID，或者，在优选的实现方式下，在界面代码中为视图定义了具有业务语义的名称的情况下，还可以将这种名称作为目标视图的标识。

在确定出目标视图的标识后，可以根据事件类型信息以及视图标识信息，生成信息采集结果。其中，如果存在扩展信息或者公共信息，也都可以添加到信息采集结果中。另外，对于曝光事件而言，还可以确定出视图的曝光时间长度信息，然后，将所述曝光时间长度信息添加到所述信息采集结果中。

再者，对于曝光事件而言，还可以预先接收曝光有效性的配置信息，这样，在检测到所述曝光事件时，可以根据目标视图的曝光情况以及所述配置信息，确定是否为有效的曝光，仅对有效曝光的目标视图生成信息采集结果。

其中，所述配置信息可以包括曝光时间长度的配置信息，当目标视图的曝光时间长度大于预置阈值时，确定为有效曝光。或者，所述配置信息也可以包括曝光面积的配置信息，当目标视图的曝光面积大于预置阈值时，确定为有效曝光。

在生成信息采集结果后，就可以进行提交处理。其中，关于具体的提交时机，根据不同类型的事件，也可以是不同的。例如，可以每检测到一次点击操作事件，并生成信息采集结果后，执行一次信息采集结果的提交操作。而在每次检测到曝光事件并生成信息采集结果后，可以首先保存在本地缓存中，在界面生命周期结束时，再将所述缓存中保存的信息采集结果进行提交。

总之，通过本申请实施例，可以通过在应用程序中接入SDK，并在界面代码中对需要采集的视图进行标记的方式，实现更有针对性的信息采集及提交，避免造成过大的数据量，避免占用过大的流量计存储空间。并且，不需要业务方执行手动的代码埋点等操作，而只需要对视图执行标记操作，因此，开发成本比较低，这种标记信息也不会侵入具体的业务逻辑，不会由于标记信息的存在导致业务逻辑混乱。再者，由于是在检测到具体的事件后，可以采用视图的ID、名称等标识来表达一个具体的视图，而这些信息在应用程序改版等过程中，并不是像XPath那样具有多变性，因此，即使应用程序出现改版，也可以保证一定的稳定性。

其次，在界面代码中对需要进行信息采集的视图进行标记时，可以为视图定义名称，并且还可以是具有业务语义的名称，这样，可以直接将这种名称作为采集标志，在通过采集标志判断是否需要进行采集的同时，还可以获取到名称，并以此作为视图的标识，添加到信息采集结果中。这样的信息采集结果在提交后，具有更高的可读性，便于进行后续的数据分析处理。

另外，在优选的实现方式下，还可以允许业务方在界面代码中为视图标记出扩展信息，在生成信息采集结果时，还可以将扩展信息添加到信息采集结果中。例如，可以将视图内的内容描述信息作为扩展信息，这样，在同一视图在不同的时间点被不同的内容所复用时，可以根据这种扩展信息，更准确的确定出具体事件的作用对象。

再者，关于界面中各视图所共同具有的公共信息，还可以在界面代码中用同一行代码进行统一设置，而不需要为每个视图分别进行设置，在提交信息采集结果时，可以判断是否存在这种公共信息，如果存在，可以分别添加各条信息采集结果中。这样，可以提高开发效率，节省业务方的人力操作成本。

与前述信息采集方法相对应，本申请实施例还提供了一种信息采集装置，参见图3，该装置可以包括：

SDK关联单元301，用于在目标应用程序中关联软件开发工具包SDK，所述目标应用程序中包括至少一个界面，在所述界面的代码中，为需要进行信息采集的视图添加采集标志信息；

所述SDK包括：

事件检测单元302，用于对所述界面内的事件进行检测；

确定单元303，用于在检测到目标事件时，确定事件类型以及关联的目标视图；

信息采集确定单元304，用于根据所述目标视图带有的采集标志信息，确定进行信息采集；

采集结果生成单元305，用于根据所述事件类型信息以及所述目标视图的标识信息，生成信息采集结果。

其中，所述采集标志信息包括为视图定义的名称信息；

所述信息采集确定单元就具体用于：

如果所述界面代码中为目标视图配置了名称信息，则确定所述目标视图为需要进行信息采集的视图，并将所述名称信息确定为所述目标视图的标识信息。

其中，所述为视图定义的名称信息包括带有业务语义的名称信息。

在具体实现时，该装置还可以包括：

附加信息添加单元，用于在界面代码中为需要进行信息采集的视图添加附加信息，所述附加信息用于：在视图存在复用时，通过所述附加信息区分不同的视图。

其中，所述视图的附加信息包括：视图内展示的内容描述信息。

或者，该装置还可以包括：

公共信息添加单元，用于在界面代码中为需要进行信息采集的视图添加公共信息，所述公共信息为所述界面内所具有的与各视图均相关的公共信息；

所述采集结果生成单元包括：

信息拼接子单元，用于将所述目标视图的名称信息与所述公共信息进行拼接；

生成子单元，用于根据将所述事件类型以及拼接结果生成信息采集结果。

其中，所述公共信息包括界面中的直播类信息的标识；所述需要进行信息采集的视图包括：所述界面中与所述直播类信息相关的视图，在直播类信息发生变化时，所述界面中与所述直播类信息相关的视图的名称不变。

具体实现时，可以在所述界面的代码中，为需要进行信息采集的视图添加预置的标志符；

所述信息采集确定单元具体用于：如果所述目标视图带有所述标志符，则确定所述目标视图为需要进行信息采集的视图，并所述目标视图的ID信息作为所述目标视图的标识信息。

其中，该装置还可以包括：

请求接收单元，用于接收对未添加采集标志信息的视图进行信息采集的请求；

提交单元，用于在检测到与所述未添加采集标志信息的视图相关的事件时，根据事件类型以及该视图的ID信息，提交信息采集结果。

具体实现时，所述事件检测单元具体可以用于：

在所述界面中的各视图被渲染完成后，在所述各视图组成的树形结构的最顶层，创建虚拟视图层；通过所述虚拟视图层抓取所述界面生命周期内的事件。

或者，所述事件检测单元具体可以用于：

通过钩子Hook以及回调函数的方式，对界面内的事件进行检测。

在实际应用中，所述确定单元具体可以用于：在检测到用户的点击操作事件时，确定事件类型为点击；根据点击操作事件作用的坐标信息，确定位于该坐标处的目标视图。

另外，该装置还可以包括：

提交操作执行单元，用于每检测到一次点击操作事件，并生成信息采集结果后，执行一次信息采集结果的提交操作。

在一种实现方式下，所述确定单元具体可以用于：

在检测到系统的界面重绘事件，或者用户的滑动操作事件时，确定事件类型为曝光；通过遍历界面内各视图的可见/不可见状态，确定从可见变为不可见的第一目标视图，以及从不可见变为可见的第二目标视图。

其中，该装置还可以包括：

曝光时间信息确定单元，用于确定视图的曝光时间长度信息；

信息添加单元，用于将所述曝光时间长度信息添加到所述信息采集结果中。

配置信息接收单元，用于预先接收关于曝光有效性的配置信息；

有效曝光确定单元，用于在检测到所述曝光事件时，根据目标视图的曝光情况以及所述配置信息，确定是否为有效的曝光，仅对有效曝光的目标视图生成信息采集结果。

其中，所述配置信息包括曝光时间长度的配置信息，当目标视图的曝光时间长度大于预置阈值时，确定为有效曝光。

或者，所述配置信息包括曝光面积的配置信息，当目标视图的曝光面积大于预置阈值时，确定为有效曝光。

另外，该装置还可以包括：

保存单元，用于每次检测到曝光事件并生成信息采集结果后，保存在本地缓存中，在界面生命周期结束时，将所述缓存中保存的信息采集结果进行提交。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的信息采集方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (20)

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

在目标应用程序中关联软件开发工具包SDK，所述目标应用程序中包括至少一个界面，在所述界面的代码中，为需要进行信息采集的视图添加采集标志信息；

通过所述SDK执行以下操作：

对所述界面内的事件进行检测；

在检测到目标事件时，确定事件类型以及关联的目标视图；

根据所述目标视图带有的采集标志信息，确定进行信息采集；

根据所述事件类型信息以及所述目标视图的标识信息，生成信息采集结果；

所述采集标志信息包括为视图定义的名称信息；所述根据所述目标视图带有的采集标志信息，确定进行信息采集，包括：

判断界面代码中是否包含目标视图对应的采集标志信息，若是，则进行信息采集，否则不进行信息采集。

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标视图带有的采集标志信息，确定进行信息采集，包括：

如果所述界面代码中为目标视图配置了名称信息，则确定所述目标视图为需要进行信息采集的视图，并将所述名称信息确定为所述目标视图的标识信息。

3.根据权利要求2所述的方法，其特征在于，所述为视图定义的名称信息包括带有业务语义的名称信息。

4.根据权利要求2所述的方法，其特征在于，还包括：

在界面代码中为需要进行信息采集的视图添加附加信息，所述附加信息用于：在视图存在复用时，通过所述附加信息区分不同的视图。

5.根据权利要求4所述的方法，其特征在于，所述视图的附加信息包括：视图内展示的内容描述信息。

6.根据权利要求2所述的方法，其特征在于，还包括：

在界面代码中为需要进行信息采集的视图添加公共信息，所述公共信息为所述界面内所具有的与各视图均相关的公共信息；

所述根据所述事件类型信息以及所述目标视图的标识信息，生成信息采集结果，包括：

将所述目标视图的名称信息与所述公共信息进行拼接；

根据将所述事件类型以及拼接结果生成信息采集结果。

7.根据权利要求6所述的方法，其特征在于，所述公共信息包括界面中的直播类信息的标识；所述需要进行信息采集的视图包括：所述界面中与所述直播类信息相关的视图，在直播类信息发生变化时，所述界面中与所述直播类信息相关的视图的名称不变。

8.根据权利要求1所述的方法，其特征在于，所述在所述界面的代码中，为需要进行信息采集的视图添加采集标志信息，包括：

在所述界面的代码中，为需要进行信息采集的视图添加预置的标志符；

所述根据所述目标视图带有的采集标志信息，确定进行信息采集，包括：

如果所述目标视图带有所述标志符，则确定所述目标视图为需要进行信息采集的视图，并所述目标视图的ID信息作为所述目标视图的标识信息。

9.根据权利要求1所述的方法，其特征在于，还包括：

接收对未添加采集标志信息的视图进行信息采集的请求；

在检测到与所述未添加采集标志信息的视图相关的事件时，根据事件类型以及该视图的ID信息，提交信息采集结果。

10.根据权利要求1所述的方法，其特征在于，所述对所述界面内的事件进行检测，包括：

在所述界面中的各视图被渲染完成后，在所述各视图组成的树形结构的最顶层，创建虚拟视图层；

通过所述虚拟视图层抓取所述界面生命周期内的事件。

11.根据权利要求1所述的方法，其特征在于，所述对所述界面内的事件进行检测，包括：

通过钩子Hook以及回调函数的方式，对界面内的事件进行检测。

12.根据权利要求1所述的方法，其特征在于，所述在检测到目标事件时，确定事件类型以及关联的目标视图，包括：

在检测到用户的点击操作事件时，确定事件类型为点击；

根据点击操作事件作用的坐标信息，确定位于该坐标处的目标视图。

13.根据权利要求12所述的方法，其特征在于，还包括：

每检测到一次点击操作事件，并生成信息采集结果后，执行一次信息采集结果的提交操作。

14.根据权利要求1所述的方法，其特征在于，所述在检测到事件时，确定事件类型以及关联的目标视图，包括：

在检测到系统的界面重绘事件，或者用户的滑动操作事件时，确定事件类型为曝光；

通过遍历界面内各视图的可见/不可见状态，确定从可见变为不可见的第一目标视图，以及从不可见变为可见的第二目标视图。

15.根据权利要求14所述的方法，其特征在于，还包括：

确定视图的曝光时间长度信息；

将所述曝光时间长度信息添加到所述信息采集结果中。

16.根据权利要求14所述的方法，其特征在于，还包括：

预先接收关于曝光有效性的配置信息；

在检测到所述曝光事件时，根据目标视图的曝光情况以及所述配置信息，确定是否为有效的曝光，仅对有效曝光的目标视图生成信息采集结果。

17.根据权利要求16所述的方法，其特征在于，所述配置信息包括曝光时间长度的配置信息，当目标视图的曝光时间长度大于预置阈值时，确定为有效曝光。

18.根据权利要求16所述的方法，其特征在于，所述配置信息包括曝光面积的配置信息，当目标视图的曝光面积大于预置阈值时，确定为有效曝光。

19.根据权利要求14所述的方法，其特征在于，还包括：

每次检测到曝光事件并生成信息采集结果后，保存在本地缓存中，在界面生命周期结束时，将所述缓存中保存的信息采集结果进行提交。

20.一种信息采集装置，其特征在于，包括：

SDK关联单元，用于在目标应用程序中关联软件开发工具包SDK，所述目标应用程序中包括至少一个界面，在所述界面的代码中，为需要进行信息采集的视图添加采集标志信息；

所述SDK包括：

事件检测单元，用于对所述界面内的事件进行检测；

确定单元，用于在检测到目标事件时，确定事件类型以及关联的目标视图；

信息采集确定单元，用于根据所述目标视图带有的采集标志信息，确定进行信息采集；

采集结果生成单元，用于根据所述事件类型信息以及所述目标视图的标识信息，生成信息采集结果；

所述采集标志信息包括为视图定义的名称信息；所述信息采集确定单元，具体用于判断界面代码中是否包含目标视图对应的采集标志信息，若是，则进行信息采集，否则不进行信息采集。

Images