CN107506291B - 一种基于数据采集的分析方法及装置 - Google Patents

Abstract

本发明公开了一种基于数据采集的分析方法，包括以下步骤：信息获取步骤：获取应用中用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；热力图绘制步骤：根据获取到的动作信息绘制热力图。本发明还公开了一种电子设备、计算机可读存储介质和基于数据采集的分析装置。本发明的基于数据采集的分析方法可以对用户行为数据进行自动的、无入侵式的采集，同时以热力图的形式进行更加清晰地展示。

Description

一种基于数据采集的分析方法及装置

技术领域

本发明涉及一种数据采集分析技术领域，尤其涉及一种基于数据采集的分析方法及装置。

背景技术

目前，对网站分析常用的数据采集方式是埋点分析；埋点技术如何采集数据，数据埋点分为初级、中级、高级三种方式，分别为：初级：在产品、服务转化关键点植入统计代码，据其独立ID确保数据采集不重复；中级：植入多段代码，追踪用户在平台每个界面上的系列行为，事件之间相互独立；高级：联合公司工程、ETL采集分析用户全量行为，建立用户画像，还原用户行为模型，作为产品分析、优化的基础。无疑，数据埋点是一种良好的私有化部署数据采集方式。数据采集准确，满足了企业去粗取精，实现产品、服务快速优化迭代的需求。但是因为手动埋点工程量极大，且一不小心容易出错，成为很多工程师的痛。

但是，现有的方案存在以下缺陷：

在手机端应用程序内，传统的方法一般通过埋点等手段来收集用户在应用内的行为数据，这个方法要求开发者在发布之前必须知道要在页面的特点位置进行埋点，且在发布之后开发者无法再对其他位置进行埋点；并且埋点开发周期长，耗时费力。

发明内容

为了克服现有技术的不足，本发明的目的之一在于提供一种基于数据采集的分析方法，其能解决数据采集以及热力图绘制的技术问题。

本发明的目的之二在于提供一种电子设备，其能解决数据采集以及热力图绘制的技术问题。

本发明的目的之三在于提供一种计算机可读存储介质，其能解决数据采集以及热力图绘制的技术问题。

本发明的目的之四在于提供一种基于数据采集的分析装置，其能解决数据采集以及热力图绘制的技术问题。

本发明的目的之一采用如下技术方案实现：

一种基于数据采集的分析方法，包括以下步骤：

信息获取步骤：获取应用中用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；

热力图绘制步骤：根据获取到的动作信息绘制热力图。

进一步地，所述信息获取步骤具体包括以下子步骤：

拦截步骤：通过Application拦截到UIEvent；

处理步骤：获取UIEvent中的UItouch并对其进行处理；

传递步骤：通过责任链的方式递归获取相应的构建块的构建标记；

结果获取步骤：获取到事件页面、事件位置和构建块标记。

进一步地，在信息获取步骤之前还包括包装布局步骤，所述包装布局步骤具体包括以下子步骤：

替换步骤：替换应用的上下文；

入口包装步骤：对应用的布局创建入口进行包装；

视图包装步骤：当进行应用视图创建时，对视图进行包装。

进一步地，所述信息获取步骤具体包括以下子步骤：

触摸获取步骤：获取到用户的触摸事件以得事件页面和事件位置；

递归寻找步骤：根据用户的触摸事件递归寻找构建块标记。

进一步地，所述热力图绘制步骤中具体包括以下子步骤：

事件记录获取步骤：获取事件页面内所有的事件记录；

标记生成步骤：根据事件记录对事件页面内所有可视的构建块进行构建块标记的生成，所述构建块标记的生成是按照获取事件记录时生成唯一标识码的逻辑进行；

标记匹配步骤：将事件页面内的构建块标记与事件位置对应的构建块标记进行数据匹配；

坐标还原步骤：当数据匹配成功时将该事件位置加入一坐标列表中；

绘图步骤：根据坐标列表进行绘制以得热力图。

本发明的目的之二采用如下技术方案实现：

一种电子设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现以下步骤：

信息获取步骤：获取应用中用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；

热力图绘制步骤：根据获取到的动作信息绘制热力图。

进一步地，进一步地，所述信息获取步骤具体包括以下子步骤：

拦截步骤：通过Application拦截到UIEvent；

处理步骤：获取UIEvent中的UItouch并对其进行处理；

传递步骤：通过责任链的方式递归获取相应的构建块的构建标记；

结果获取步骤：获取到事件页面、事件位置和构建块标记。

进一步地，在信息获取步骤之前还包括包装布局步骤，所述包装布局步骤具体包括以下子步骤：

替换步骤：替换应用的上下文；

入口包装步骤：对应用的布局创建入口进行包装；

视图包装步骤：当进行应用视图创建时，对视图进行包装。

本发明的目的之三采用如下技术方案实现：

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上任意一项所描述的方法。

本发明的目的之四采用如下技术方案实现：

一种基于数据采集的分析装置，其特征在于，包括以下模块：

信息获取模块：用于获取应用中用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；

热力图绘制模块：用于根据获取到的动作信息绘制热力图。

相比现有技术，本发明的有益效果在于：

本发明的基于数据采集的分析方法可以对用户行为数据进行自动的、无入侵式的采集，同时以热力图的形式进行更加清晰地展示。

附图说明

图1为本发明的基于数据采集的分析方法的流程图；

图2为本发明的基于数据采集的分析装置的结构图。

具体实施方式

下面，结合附图以及具体实施方式，对本发明做进一步描述，需要说明的是，在不相冲突的前提下，以下描述的各实施例之间或各技术特征之间可以任意组合形成新的实施例。

实施例一：

本发明的方法主要应用在移动终端上，移动终端当前主要有两大操作系统一种是IOS操作系统，一种是Andriod操作系统，本发明的方法对于以上两种系统均适用。

如图1所示，本发明提供了一种基于数据采集的分析方法，包括以下步骤：

步骤S0具体包括以下子步骤：

S01：替换应用的上下文；在Android SDK中，应用上下文都直接或者间接继承自ContextWrapper，我们只需要复写其attachBaseContext方法，就可以实现上下文的替换，将我们包装后的上下文返回给ContextWrapper，以便进行下一步的工作；

为了实现对LayoutInflator的替换，替换应用上下文已经能满足大部分场景了，但是Activity有一些特殊性，这里还需要对其进行额外的处理。目的也是为了完成对遗漏的LayoutInflator进行替换；

S02：对应用的布局创建入口进行包装；LayoutInflater及为应用中布局创建的入口，在完成应用上下文替换之后，我们相当于掌握了大部分入口，也就可以进行下一步对LayoutInflator的包装，替换系统原始的LayoutInflater返回封装后的LayoutInflater，以便进一步实现对创建的视图进行包装；

S03：当进行应用视图创建时，对视图进行包装。因为视图的创建都会通过LayoutInflater，现在已经把它替换成我们自己的LayoutInflater，也就是说掌握了这个入口。接下来就针对创建的视图，进行包装操作即可，在外面包装一层WrapperLayout，把包装后的视图返回给调用方。这样，在整个视图层级里面，就插入了WrapperLayout，也就具有接收、处理、分发触摸事件的能力，为后续采集工作打好了基础；因为Fragment使用相对灵活，可以将其插入到任意视图层级中，而且可以多Fragment之间进行切换。为了能够对其进行区分，在Fragment的场景，我们是直接对其创建的视图进行包装。同时需要修改其私有成员变量mView为包装后的View，以处理ViewPager场景可能出现的问题。

前面的准备工作奠定了采集工作的基础，当用户触摸界面上视图的时候，触摸事件会从Window开始按视图的层级进行分发，也就是会先发送到WrapperLayout，于是我们可以在dispatchTouchEvent方法中进行事件捕获和拦截。

S1：获取用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；需要展现用户的行为就需要记录用户的行为，在IOS以及Andriod上行为都可以分为Touch和手势，对于热力图展示来说所有这些用户的行为都可以处理成一串位置点；

所述步骤S1具体包括以下子步骤：

S101：获取到用户的触摸事件以得事件页面和事件位置；

S102：根据用户的触摸事件递归寻找构建块标记。

或者该步骤S1还可以由以下子步骤组成：S11：通过Application拦截到UIEvent；

S12：获取UIEvent中的UItouch并对其进行处理；

S13：通过责任链的方式递归获取相应的构建块的构建标记；

S14：获取到事件页面、事件位置和构建块标记。

UIApplication对象是iOS App在运行时创建的第一个对象，他为App运行时提供中心化控制与协调。UIApplication的一个主要功能就是处理app的用户事件，他将UIControl对象的事件通过sendEvent方法分发到目标对象进行处理。

在iOS中用户事件均由UIResponder对象进行处理，并通过响应链(The ResponderChain)进行传递与处理。首先是事件传递，UIApplication对象向目标分发事件，目标对象使用hitTest方法来寻找对事件作出响应的第一个对象，hitTest通过判断事件点是否在相关view内，若在则循环递归查找子view，直到找到最后一层。然后是事件的响应，由hitTest找到的响应对象如果不处理当前事件，则将事件向响应链后传递响应。

如此这般，我们可以在UIApplication中重写sendEvent方法来获取到当前app中所有的用户事件。在sendEvent方法中，我们获得了UIEvent对象，而UIEvent对象包含了event的类型、event的时间、event包含的touch。而这些touch即UITouch对象，在touch中包含了响应的view、touch的point、touch的类型(这里我们只需要这些属性)。但是UIEvent与UITouch并不支持直接持久化，也不支持使用初始化方法来创建对象(如果需要重新模拟操作则需要一些特殊处理，这里不展开)。一个Event事件可能包含多个Touch对象，每一个Touch对象都应该被保存。

pageID用来标注当前Touch属于的页面。iOS可以使用ViewController的ClassName作为唯一的id来标识。Touch对象有一个view属性，由上图响应链中可以看出ViewController是view的下一个响应者，所以可以通过touch的view来获得当前touch的ViewController，这样便可以获得pageID。

但是这里有一些特殊情况。例如在WebView和TableView上的滑动获得到的Touch对象中view是nil。对于这样的Touch我们通过获取keyWindow.rootViewController来获取当前显示的viewController。

最后，获得到的viewController可能是UINavigationController或UITabbarController如果将这些viewController作为pageID那么这个id就失去了作用，无法再还原对应的touch，所以如果获得的是这些viewController则需要向下取到实际的viewController。

由于iOS的有多种屏幕尺寸，切UI在设计开发的时候并不是按照屏幕尺寸等比例的缩放，所以position的记录是以点击的View为基准，并以相对于基准的百分比进行记录。

由于事件的位置是相对事件发生的View来记录的，那么如何在绘制时找到这个view就成了关键。在iOS中，UIView是没有一个"identifier"来唯一标记自身的。

虽然没有一个id可以来标识view，但是每一个view的层级位置是固定的，我以我们可以根据这个位置来标识一个view。到这里，我们已经获得了描述一个事件的关键信息：PageID、Position、ViewID，这样就可以使用这些信息来绘制热力图。以上三种也分别是事件页面、时间未知和构建块标记；

Andriod最开始技术选型的时候，没有采用AOP字节码插桩的方式，目前使用的是Hacker的方式，后期可以考虑与AOP的方式相结合，那样可做的事情更多，会更灵活；为了能够达到捕获大部分Touch事件的目的，需要对部分系统组件进行Hook，最终目的是替换原始的LayoutInflator，以便Wrap工作，方案如下：业务方需要继承MerApplication；在attachBaseContext方法中对原始Context进行包装，传入WrapperContext；在getBaseContext方法中进行判断处理，防止外部出现类型强转导致的问题；注册registerActivity Life cycle Callbacks用于监听Activity的生命周期，用于类型检查和热力图还原工作；业务方所有的Activity需要继承MerXXXActivity，比如MerCompatActivity；在attachBaseContext方法中对原始Context进行包装，传入WrapperContext；getSystemService的时候进行Hook逻辑，针对LAYOUT_INFLATER_SERVICE返回WrapperLayoutInflator；getLayoutInflater的时候进行Hook逻辑，返回WrapperLayoutInflator；onAttachFragment方法对Fragment进行类型检查(包括android.app.Fragment和android.support.v4.app.Fragment)；WrapperContext继承自ContextWrapper；getSystemService的时候进行Hook逻辑，针对LAYOUT_INFLATER_SERVICE返回WrapperLayoutInflator。其包括三部分，ClassPath/IndexPath/ResouceName，最后取MD5作为唯一标识，在Activity内基本是全局唯一的

1.ClassPath:当前View及其Parent的完整类名组成的路径

2.IndexPath:当前View及其Parent所在上一层View的索引

3.ResourceName:Resources.getResourceName

最初的方案是复写Activity的dispatchTouchEvent方法，然后通过ViewUtils来查找响应事件的View。然后后期开发过程中发现这种方式的局限性，包括如下几点

1.无法捕获到Dialog和PopupWindow以及其他通过WindowManager所添加的View；

2.无法有效的处理Fragment的逻辑，对Fragment进行区分标记

后面考虑从LayoutInflator入手，切入点是Android动态换肤方案来给View包装一层，考虑到性能问题，最后只是给inflate后的顶层View进行包装，还是继续使用ViewUtils来进行查找。方案初期可行，后续实施的过程中遇到了很多问题，由此在后续做了很多完善性的工作

1.外部inflate得到View之后，可能会对其进行类型强转。这个问题分两步进行，针对部分系统控件/组件的inflate动作后的类型强转，对其进行忽略不进行包装操作；针对外部其他View可能存在的强转问题进行适配，按照原始类型进行包装(原始顶层View是什么类型，外层再包装一层什么类型)，目前对常用布局完成了这项工作

2.提供一定的方式，以不同的粒度，允许外部声明当前布局文件/当前Activity不需要进行包装(以免影响正常的开发，待SDK适配后再将声明移除即可)。

Android的UI由View组成，所以在有了Wrapper方案之后，就不再需要考虑和区分Activity、Dialog、PopupWindow等不同窗口容器问题，只需要针对不同的ViewGroup来进行，其中包括如下场景

1.普通的布局

2.Fragment的场景

3.存在ListView的场景

4.存在ScrollView的场景

5.存在RecylcerView的场景

6.其他可滚动View的场景

针对以上场景，以下分点来说

普通的布局：记录的坐标为Touch事件位于当前View宽高的百分比：

xPercent＝LocationXInWidget/WidgetWidth；

yPercent＝LocationYInWidget/WidgetHeight；

这种情况对于捕获工作基本没困难，重点在于ViewUtils的逻辑，关于ViewUtils在后面会做讲解；另外一点是，一个Activity里面的View层级，可能是通过多次inflate后然后组合起来的，也就是说，绝大部分情况下，会出现一个View层级里面有多次Wrap的情况，不过这并不会影响到最后的采集，通用的，这也是前面所说可以针对部分'系统控件/组件的inflate工作进行忽略'的一个前提

Fragment的场景：关于Fragment，被Attach之后，就称为整个View层级的一部分，也无法辨认和识别，Fragment的使用也相当灵活，所以有如下几点需要考虑的场景：

1.一个Fragment的实例被Attach到Activity

2.多个Fragment类的实例被Attach到Activity，然后他们之间会存在切换动作

3.Fragment之间的嵌套情况

4.同一个Fragment类的实例被Attach到Activity，然后他们之间会存在切换动作

5.不同Fragment类的实例使用同一个布局文件，然后会在同一个Activity中存在切换动作

上面多次提到了切换动作，为什么要考虑到这点，主要是需要做到采集的事件能和对应的Fragment/View绑定起来，不然就无法完成热力图的还原工作。以上其实只有第四点和第五点比较麻烦，但是细想一下，是否真的有这样的使用场景，以及在这样的使用场景下，外部使用者又是怎么区分的呢？如此得到如下初步方案:

1.针对所有的Fragment的View，也进行一层Wrap动作，同时加入标记，用于和普通View的Wrap进行区分

2.UUID生成逻辑进行补充，添加Fragment的

UUID(ClassName+FragmentTag+BundleUUID)，这里的BundleUUID来自于Fragment的参数，也就是外部通过setArguments设置给Fragment的参数，它大部分情况下用于不同业务场景的区分，当然同理可以作为SDK区分Fragment的一条线索

可滚动View的场景：针对可滚动View的场景，最关键的就是需要能够获取到滚动距离，用于计算Touch位置的百分比，这里和普通View的记录逻辑稍稍不一样，计算百分比时是相对于上层可滚动View来进行计算的，记录的坐标为Touch事件位于当前ViewParent宽高的百分比：

xPercent＝LocationXInWidget/ScrollableParentWidth，

yPercent＝LocationYInWidget/ScrollableParentHeight；

针对AbsListView获取滚动距离，由于不能侵入业务方过多逻辑，所以通过getViewTreeObserver().addOnScrollChangedListener的方式来监听和计算滚动距离；

针对RecylcerView获取滚动距离，通过computeVerticalScrollOffset和computeHorizontalScrollOffset获取，针对其他可滚动View获取滚动距离，通过getScrollY和getScrollX获取。

S2：根据获取到的动作信息绘制热力图。在步骤S2中具体包括以下子步骤：

S21：获取事件页面内所有的事件记录；

S22：对事件页面内所有可是构建块标记按照采集时生成唯一标识码的逻辑进行构建块标记生成；

S23：将当前事件页面内的构建块标记与之前采集到的事件页面中的构建块标记进行匹配；

S24：当数据匹配成功时进行坐标还原，得到一个坐标列表；

S25：根据坐标列表传递至网页页面中进行绘制以得热力图。

为了能够统一安卓端与iOS端的绘制效果，这里采用了WebView的形式来绘制热力图。

区分同一页面当中的不同View，在绘制的过程中会遇到一个问题，即有一些弹层或浮层类的View盖在当前View之上，但是在代码结构上来说，这个View还是属于当前ViewController的，也就是说弹层View上的事件也是记录在了ViewController上。如果这里不对View进行区分，那么所有被标记在这个ViewController的事件都将被绘制到这个ViewController上，这样就会造成数据的不准确。

这里就要用到上面讲的ViewID。在绘制时通过判断事件对应的ViewID是否在当前页面上显示，如果不显示则忽略这个事件不进行绘制。

还原的工作相对于采集来说问题会少很多，只要采集准确，还原就能做得很好，不过也有一些问题需要考虑的，为了统一安卓端与iOS端的绘制效果，采用了WebView加载webgl-heatmap.js的方式来绘制热力图。

还原逻辑：

1.获取当前Activity(PageID)内所有的事件记录；

2.获取当前Activity所有可视的View，并按照采集时生成UUID的逻辑进行ID生成；

3.将当前Activity内的ViewID和之前采集的事件中ViewID进行匹配；

4.前一步当有数据匹配时，进行坐标还原，最得到一个坐标列表；

5.将坐标列表传递给WebView中的webgl-heatmap.js进行绘制。

需要考虑到的问题，最主要的是当前Activity的状态，以及是否有弹窗(Dialog/PopupWindow)，以及当前View是否可视，技术处理方案如下

1.通过Activity生命周期来管理Activity的状态

2.通过WrapperLayout的onAttachedToWindow和onDetachedFromWindow管理DecorView；

3.还原工作在Service中进行，避免使用Activity时影响到原有Activity状态管理；

4.针对不同场景下View所在区域覆盖情况进行事件的叠加和忽略

(PopupWindow叠加，Dialog忽略，依据是用户实际使用时，控件外的区域是否可操作)；

5.通过判断当前View所在的View层级的所有View是否可见来确定其可视

性，而不是当一当前View的可视性；

6.针对Fragment的场景，也需要判断其View的可视性。

限于Android事件分发系统的设计，触摸事件到达WrapperLayout的时候，以及WrapperLayout将事件分发下去，子视图处理完成之后，自己是不知道谁消费处理了这个事件，用户具体触摸了哪个控件。但是有一些基本原则，比如这个视图肯定是顶层可视的那个，基于这个基本原则，于是编写ViewUtils用于查找事件的消费者，其基本流程如下：

1.对于dispatchTouchEvent方法返回的结果进行不同处理，true则表示当前View或者其子View响应并处理了该事件(进入findActiveView流程)，false则表示当前View或者其子View消费但是未处理该事件(进入findConsumeView流程)；

2.两个流程的基本原理是一致的，当前Touch事件所在屏幕位置与View位于屏幕可视位置进行比对，查找最满足条件的那一个View(包括ViewGroup)；

3.如果当前View的Child是IViewWrapper的实例，则忽略该Child，让其Child自己去处理；

4.获取View位于屏幕可视位置时，需要考虑到Dialog的情况，对偏移进行计算；

5.INVISIBLE和GONE状态的View可直接忽略；

6.递归寻找，找不到的时候往上层寻找，其实也就是一个冒泡的过程。

然后得以绘制热力图。

实施例二：

实施例二公开了一种电子设备，该电子设备包括处理器、存储器以及程序，其中处理器和存储器均可采用一个或多个，程序被存储在存储器中，并且被配置成由处理器执行，处理器执行该程序时，实现实施例一的基于数据采集的分析方法。该电子设备可以是手机、电脑、平板电脑等等一系列的电子设备。

实施例三

实施例三公开了一种可读的计算机存储介质，该存储介质用于存储程序，并且该程序被处理器执行时，实现实施例一的基于数据采集的分析方法。

实施例四：

如图2所示，本发明提供了一种基于数据采集的分析装置，包括以下模块：

信息获取模块：用于获取应用中用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；

热力图绘制模块：用于根据获取到的动作信息绘制热力图。

上述实施方式仅为本发明的优选实施方式，不能以此来限定本发明保护的范围，本领域的技术人员在本发明的基础上所做的任何非实质性的变化及替换均属于本发明所要求保护的范围。

Claims (7)

1.一种基于数据采集的分析方法，其特征在于，包括以下步骤：

信息获取步骤：获取应用中用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；

热力图绘制步骤：根据获取到的动作信息绘制热力图；

所述信息获取步骤具体包括以下子步骤：

拦截步骤：通过Application拦截到UIEvent；

处理步骤：获取UIEvent中的UItouch并对其进行处理；

传递步骤：通过责任链的方式递归获取相应的构建块的构建标记；

结果获取步骤：获取到事件页面、事件位置和构建块标记；

所述热力图绘制步骤中具体包括以下子步骤：

事件记录获取步骤：获取事件页面内所有的事件记录；

标记生成步骤：根据事件记录对事件页面内所有可视的构建块进行构建块标记的生成，所述构建块标记的生成是按照获取事件记录时生成唯一标识码的逻辑进行；

标记匹配步骤：将事件页面内的构建块标记与事件位置对应的构建块标记进行数据匹配；

坐标还原步骤：当数据匹配成功时将该事件位置加入一坐标列表中；

绘图步骤：根据坐标列表进行绘制以得热力图。

2.如权利要求1所述的基于数据采集的分析方法，其特征在于，在信息获取步骤之前还包括包装布局步骤，所述包装布局步骤具体包括以下子步骤：

替换步骤：替换应用的上下文；

入口包装步骤：对应用的布局创建入口进行包装；

视图包装步骤：当进行应用视图创建时，对视图进行包装。

3.一种基于数据采集的分析方法，其特征在于，包括以下步骤：

信息获取步骤：获取应用中用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；

热力图绘制步骤：根据获取到的动作信息绘制热力图；

所述信息获取步骤具体包括以下子步骤：

触摸获取步骤：获取到用户的触摸事件以得事件页面和事件位置；

递归寻找步骤：根据用户的触摸事件递归寻找构建块标记；

所述热力图绘制步骤中具体包括以下子步骤：

事件记录获取步骤：获取事件页面内所有的事件记录；

标记生成步骤：根据事件记录对事件页面内所有可视的构建块进行构建块标记的生成，所述构建块标记的生成是按照获取事件记录时生成唯一标识码的逻辑进行；

标记匹配步骤：将事件页面内的构建块标记与事件位置对应的构建块标记进行数据匹配；

坐标还原步骤：当数据匹配成功时将该事件位置加入一坐标列表中；

绘图步骤：根据坐标列表进行绘制以得热力图。

4.一种电子设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现以下步骤：

信息获取步骤：获取应用中用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；

热力图绘制步骤：根据获取到的动作信息绘制热力图；

所述信息获取步骤具体包括以下子步骤：

拦截步骤：通过Application拦截到UIEvent；

处理步骤：获取UIEvent中的UItouch并对其进行处理；

传递步骤：通过责任链的方式递归获取相应的构建块的构建标记；

结果获取步骤：获取到事件页面、事件位置和构建块标记；

所述热力图绘制步骤中具体包括以下子步骤：

事件记录获取步骤：获取事件页面内所有的事件记录；

标记生成步骤：根据事件记录对事件页面内所有可视的构建块进行构建块标记的生成，所述构建块标记的生成是按照获取事件记录时生成唯一标识码的逻辑进行；

标记匹配步骤：将事件页面内的构建块标记与事件位置对应的构建块标记进行数据匹配；

坐标还原步骤：当数据匹配成功时将该事件位置加入一坐标列表中；

绘图步骤：根据坐标列表进行绘制以得热力图。

5.如权利要求4所述的电子设备，其特征在于，在信息获取步骤之前还包括包装布局步骤，所述包装布局步骤具体包括以下子步骤：

替换步骤：替换应用的上下文；

入口包装步骤：对应用的布局创建入口进行包装；

视图包装步骤：当进行应用视图创建时，对视图进行包装。

6.一种计算机可读存储介质，其上存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现如权利要求1-2或权利要求3任意一项所述的方法。

7.一种基于数据采集的分析装置，其特征在于，包括以下模块：

信息获取模块：用于获取应用中用户的动作信息，所述动作信息包括事件页面、事件位置和构建块标记；

热力图绘制模块：用于根据获取到的动作信息绘制热力图；

所述信息获取模块具体包括以下子模块：

拦截模块：通过Application拦截到UIEvent；

处理模块：获取UIEvent中的UItouch并对其进行处理；

传递模块：通过责任链的方式递归获取相应的构建块的构建标记；

结果获取模块：获取到事件页面、事件位置和构建块标记；

所述热力图绘制模块中具体包括以下子模块：

事件记录获取模块：获取事件页面内所有的事件记录；

标记生成模块：根据事件记录对事件页面内所有可视的构建块进行构建块标记的生成，所述构建块标记的生成是按照获取事件记录时生成唯一标识码的逻辑进行；

标记匹配模块：将事件页面内的构建块标记与事件位置对应的构建块标记进行数据匹配；

坐标还原模块：当数据匹配成功时将该事件位置加入一坐标列表中；

绘图模块：根据坐标列表进行绘制以得热力图。