埋点数据的上报方法、装置、终端和存储介质
技术领域
本申请涉及代码埋点技术领域,尤其涉及一种埋点数据的上报方法、装置、终端和存储介质。
背景技术
目前,在页面埋点的配置过程中,需要为每个埋点的元素添加id(属性标识)和name(属性名称),才可以自动采集埋点,不同的页面可以使用相同的id和name,但是不同页面之间的埋点需求不同,使用相同的id和name,上报的数据也会是相同的,这样便无法区别不同页面的请求。
现有技术中,通过改变页面埋点中id和name涉及的函数和数据等进行区分,操作较为复杂,容易引起其他操作的冲突;并且其自定义的埋点需要h5调用它们的JS-SDK(软件开发工具包)频繁地发送请求,这样不仅会占用处理器和内存的资源,而且容易导致内容溢出,超出数据库最大连接数,影响数据的正常保存,甚至还会导致同步的请求之间也受到相互影响。
发明内容
本申请的目的旨在至少能解决上述的技术缺陷之一,特别是现有技术中自定义埋点频繁发送网络请求,导致占用过多内存的同时数据保存也会出现异常的技术缺陷。
本申请提供一种埋点数据的上报方法,包括如下步骤:
监测应用的运行状态,当所述应用开始运行时,开启对埋点控件的监测;
收集页面上各个埋点控件产生的埋点触发信息,统计所述埋点触发信息并存放至本地缓存;
当所述应用退出运行时,从所述本地缓存中提取各个埋点触发信息,根据所述埋点触发信息统计各个埋点控件被触发的次数,得到各个埋点控件的埋点数据;
将所述埋点数据上报至服务器。
在一个实施例中,所述监测应用的运行状态的步骤之前,还包括:
获取应用的各个页面上埋点对应的属性信息,根据所述属性信息对各个埋点重新进行埋点属性配置得到埋点控件。
在一个实施例中,所述根据所述属性信息对各个埋点重新进行埋点属性配置的步骤,包括:
根据所述属性信息中的属性名添加自定义属性,得到与所述属性信息对应的附加信息,其中,所述附加信息约定用于埋点;
根据所述附加信息对各个埋点重新进行埋点属性配置得到埋点控件。
在一个实施例中,所述开启对埋点控件的监测的步骤之前,还包括:
在所述应用的本地缓存中新建多个配置文件;其中,所述配置文件包括收集数据的脚本文件;
将各个配置文件与所述应用中各个页面的埋点代码相关联;
当所述埋点代码被执行时,调用与所述埋点代码对应的配置文件。
在一个实施例中,所述开启对埋点控件的监测的步骤,包括:
获取所述应用发送的埋点代码执行请求,并根据所述埋点代码执行请求响应与所述埋点代码对应的配置文件;
通过所述配置文件开启对所述页面的埋点控件的监测。
在一个实施例中,根据所述埋点触发信息统计各个埋点控件被触发的次数,得到各个埋点控件的埋点数据的步骤,包括:
通过所述埋点触发信息中的附加信息将所述本地缓存中的各个埋点触发信息重新进行排列,得到埋点列表;
统计所述埋点列表中同一个埋点触发信息对应的埋点控件被触发的次数,得到各个埋点控件的埋点数据。
在一个实施例中,统计所述埋点列表中同一个埋点触发信息对应的埋点控件被触发的次数的步骤之后,还包括:
根据统计结果确定所述埋点列表中同一个埋点触发信息对应的埋点控件被触发的次数是否超过设定的阈值;
当被触发的次数超过所述阈值时,以所述阈值作为对应的埋点控件被触发的次数。
本申请还提供了一种埋点数据的上报装置,其包括:
监测模块,用于监测应用的运行状态,当所述应用开始运行时,开启对埋点控件的监测;
信息采集模块,用于收集页面上各个埋点控件产生的埋点触发信息,统计所述埋点触发信息并存放至本地缓存;
信息处理模块,用于当所述应用退出运行时,从所述本地缓存中提取各个埋点触发信息,根据所述埋点触发信息统计各个埋点控件被触发的次数,得到各个埋点控件的埋点数据;
信息上传模块,用于将所述埋点数据上报至服务器。
本申请还提供了一种终端,其特征在于,包括存储器和处理器,所述存储器中存储有计算机可读指令,所述计算机可读指令被所述处理器执行时,使得所述处理器执行如上述实施例中任意一项所述埋点数据的上报方法中的步骤。
本申请还提供了一种存储介质,所述存储介质中存储有计算机可读指令,所述计算机可读指令被一个或多个处理器执行时,使得一个或多个处理器执行如上述实施例中任一项所述的埋点数据的上报方法的步骤。
上述埋点数据的上报方法、装置、终端和存储介质,监测应用的运行状态,当所述应用开始运行时,开启对埋点控件的监测;收集页面上各个埋点控件产生的埋点触发信息,统计所述埋点触发信息并存放至本地缓存;当所述应用退出运行时,从所述本地缓存中提取各个埋点触发信息,根据所述埋点触发信息统计各个埋点控件被触发的次数,得到各个埋点控件的埋点数据;将所述埋点数据上报至服务器。本方案中,通过监测应用的运行状态来判断是否开启对应用中的埋点控件的监测,以便在应用运行时,由各个埋点控件对应的页面埋点来收集埋点控件产生的埋点触发信息,当应用退出运行时,再通过收集到的埋点触发信息统计各个埋点控件的埋点数据;这种通过本地缓存将应用运行时产生的所有的埋点数据一并上报至服务器的过程,不仅会减少处理器的操作线程,以及内存的占用空间,而且还避免了同步的数据请求之间的相互影响,使得数据能够正常保存。
本申请附加的方面和优点将在下面的描述中部分给出,这些将从下面的描述中变得明显,或通过本申请的实践了解到。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
图1是本申请实施例提供的埋点数据的上报方法的应用环境图;
图2是一个实施例的埋点数据的上报方法流程图;
图3是一个实施例的埋点数据上报优化前后对比示意图;
图4是一个实施例的埋点数据的上报装置结构示意图;
图5是一个实施例提供的终端相关的手机的部分结构框图。
具体实施方式
下面详细描述本申请的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,仅用于解释本申请,而不能解释为对本申请的限制。
本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是,本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件,但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组合。
本技术领域技术人员可以理解,除非另外定义,这里使用的所有术语(包括技术术语和科学术语),具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是,诸如通用字典中定义的那些术语,应该被理解为具有与现有技术的上下文中的意义一致的意义,并且除非像本申请实施例中一样被特定定义,否则不会用理想化或过于正式的含义来解释。
本申请中的应用是基于Hybrid(混合开发)模式下的移动应用,该混合开发模式下的应用介于native-app(原生应用)与web-app(网页应用)两者之间,因此,使用时需要通过JsBridge进行原生应用与网页应用之间的交互。
需要说明的是,这里的native-app指的是IOS(苹果)或Android(安卓)的原生应用,Web-app应用中包括h5(html5)页面、js、css等。
参考图1所示,图1是本申请实施例的应用环境图;本实施例中,本申请的技术方案可以基于用户终端110上实现,如图1中,用户终端110中的某一混合开发的移动应用开始运行时,收集该应用中各个页面产生的埋点触发信息,并在该应用退出运行时,将统计到的埋点数据上报至服务器120中实现相关功能;
在本申请实施例中,用户终端110通过监测应用的运行状态来执行自动化埋点,并通过自动化埋点采集各个页面的埋点控件产生的埋点触发信息,将采集到的埋点触发信息保存在本地缓存中,最后统一上报至服务器120,从而实现移动应用中数据采集的功能;这里的服务器120指的是能够进行处理数据的一个或多个装置的组合。
在一个实施例中,如图2所示,图2为一个实施例的埋点数据的上报方法流程图,本实施例中提出了一种埋点数据的上报方法,具体可以包括以下步骤:
S110:监测应用的运行状态,当所述应用开始运行时,开启对埋点控件的监测;
本申请通过在h5页面中设置埋点,通过埋点采集用户在该页面中的行为数据,然后将该行为数据上报给TD(人才发展)或神策等统计平台统计自动化埋点,以对用户的行为进行分析。
因此,本步骤中,首先需要对混合开发模式下的应用的运行状态进行监测,以便在该应用开始运行时,开启对该应用中各个网页页面的埋点控件进行监测;当埋点控件被点击或页面加载等事件或状态发生变更时,自动上报给原生系统。
需要说明的是,这里的埋点控件指的是应用的各个网页页面中设置有页面埋点的元素;这里的原生系统指的是IOS(苹果)或Android(安卓)系统。
S120:收集页面上各个埋点控件产生的埋点触发信息,统计所述埋点触发信息并存放至本地缓存。
本步骤中,通过上述步骤S110中开启对埋点控件的监测后,通过页面埋点收集网页页面上各个埋点控件产生的埋点触发信息,该埋点触发信息包括有用户点击、浏览相关控件的信息。
由于将h5页面上报的内容通过原生系统保存时,无需频繁地向原生系统发送请求,因此,当统计收集到的埋点触发信息后,可将该埋点触发信息存放至原生系统的本地缓存下。
需要说明的是,这里的页面埋点指的是h5页面中,通过js等技术手段实现页面展示内容的信息爬取;页面埋点主要用于流量分析,而流量的意思包含有:页面浏览数(PV)、独立访问者数量(UV)、IP、页面停留时间、页面操作时间、页面访问次数、按钮点击次数、文件下载次数等。
S130:当所述应用退出运行时,从所述本地缓存中提取各个埋点触发信息,根据所述埋点触发信息统计各个埋点控件被触发的次数,得到各个埋点控件的埋点数据。
本步骤中,通过步骤S110中监测应用的运行状态后,当该应用退出运行时,将该应用运行过程中采集并保存在本地缓存下的各个埋点触发信息中埋点控件被触发的次数进行统计,以便得到各个埋点控件的埋点数据。
比如,埋点控件为按钮时,统计该按钮被点击的次数,得到的即是该按钮的埋点数据,该埋点数据还包括该按钮的页面标签中对应的属性信息,通过该属性信息即可统计不同埋点控件的埋点数据。
S140:将所述埋点数据上报至服务器。
本步骤中,通过步骤S130中得到各个埋点控件的埋点数据后,可直接将该埋点数据整理成埋点数据包后上报至服务器,或者将该埋点数据送入上报机制中,由该上报机制将埋点数据上报至服务器即可。
进一步地,该上报机制或本地缓存中均可设置上报时间,可以是在该应用退出运行时,也可以是该应用中采集埋点触发信息的页面关闭时,在此不做限制。
上述埋点数据的上报方法,监测应用的运行状态,当所述应用开始运行时,开启对埋点控件的监测;收集页面上各个埋点控件产生的埋点触发信息,统计所述埋点触发信息并存放至本地缓存;当所述应用退出运行时,从所述本地缓存中提取各个埋点触发信息,根据所述埋点触发信息统计各个埋点控件被触发的次数,得到各个埋点控件的埋点数据;将所述埋点数据上报至服务器。
如图3所示,图3为本实施例的埋点数据上报优化前后对比示意图,本方案中,通过监测应用的运行状态来判断是否开启对应用中的埋点控件的监测,以便在应用运行时,由各个埋点控件对应的页面埋点来收集埋点控件产生的埋点触发信息,当应用退出运行时,再通过收集到的埋点触发信息统计各个埋点控件的埋点数据;这种通过本地缓存将应用运行时产生的所有的埋点数据一并上报至服务器的过程,不仅会减少处理器的操作线程,以及内存的占用空间,而且还避免了同步的数据请求之间的相互影响,使得数据能够正常保存。
在一个实施例中,步骤S110中监测应用的运行状态的步骤之前,还可以包括:
获取应用的各个页面上埋点对应的属性信息,根据所述属性信息对各个埋点重新进行埋点属性配置得到埋点控件。
本申请中,每个页面埋点的元素中都添加有id(属性标识)和name(属性名称),有了这些属性名称和属性标识,才可以自动采集埋点。但是id和name是html标签的自带属性,频繁触发该埋点对应的埋点控件时,容易引起其他操作的冲突。如果在其自带属性中添加自定义埋点的话,又需要h5调用他们的JS-SDK(软件开发工具包)频繁的发送请求,这样会造成性能的浪费。
因此,本实施例中,对应用的各个页面上埋点对应的属性信息重新进行埋点属性配置,以得到新的埋点控件,该埋点控件被触发时,不需要h5调用JS-SDK频繁的发送请求,因而也不会引起其他操作冲突,同时也不会造成性能的浪费。如下所示:
Page A(页面A):
文本框:<input id=“cellphone”name=“cellphone”value=“”type=“text”/>
按钮:<input id=“submit”name=“”value=“确定”type=“button”/>
此时页面A中的id绑定了逻辑fun1;
Page B(页面B):
文本框:<input id=“cellphone”name=“cellphone”value=“”type=“text”/>
按钮:<input id=“submit”name=“”value=“立即申请”type=“button”/>
此时页面B中的id绑定了逻辑fun2;
由上述示例可知,对于页面A和页面B:1)文本框,id、name相同,实际与之关联的表单内容不同,实现效果不同;2)按钮,id、name相同,文字不同,绑定的函数也不同,即实际实现的逻辑不同,例如,fun1实现检查填手机号是否已存在,fun2实现用填写的手机号进行申请。
需要说明的是,这里的按钮和文本框都是指代本方案中的各个埋点对应的埋点控件的名称,id和name指的是埋点中包含的各个属性,其中id在h5页面的单页面中具有唯一性,不同页面可以使用相同的id,通常用来进行js操作和样式命名;name通常使用于表单元素(如:文本框input、文本域textarea、复选框checkbox等),当表单提交时,name与value形成对应关系,提交至后台,name可以相同;id=“submit”即表示该属性对应的值。
在一个实施例中,所述根据所述属性信息对各个埋点重新进行埋点属性配置的步骤,可以包括:
A1:根据所述属性信息中的属性名添加自定义属性,得到与所述属性信息对应的附加信息,其中,所述附加信息约定用于埋点;
A2:根据所述附加信息对各个埋点重新进行埋点属性配置得到埋点控件。
本申请中,由于应用中的不同页面的埋点元素中涉及到不同的逻辑,但不同逻辑下的id、name却是相同的,因此需要对各个埋点重新进行埋点属性配置。通过对埋点的属性信息中的属性名添加自定义属性,得到与该属性信息对应的附加信息,由于该附加信息为自定义属性,因而可根据该附加信息对各个埋点重新进行埋点属性配置得到埋点控件。
举例来说,当需要对属性信息添加附加信息时,即,自定义属性,首先需要声明一个类,并将Attribute Usage Attribute属性应用到该类中,类的名称即为新属性的名称,声明该类从System.Attribute继承,定义Private字段来存储属性值,需要时,为属性创建构造函数,并定义方法、字段和属性(Property)。
可以理解的是,html5规范里增加了一个自定义属性,目的是为前端开发者提供自定义的属性,这些属性集可以通过对象的dataset属性获取,不支持该属性的浏览器可以通过get Attribute方法获取,并且html5规范中还规定了自定义属性需要添加前缀data-,目的是提供与渲染无关的信息。
因而本申请中,在属性信息中根据id的属性名添加data-td-id=“具体埋点值”的预置属性,该预置属性为自定义属性,即附加信息,该附加信息继承自与其属性信息相同的类,即约定用于埋点,不可进行其他操作,因而也不会像id和name一样干扰其他逻辑。如下图所示:
添加附加信息后的Page A为:
按钮:<input id=“submit”name=“”value=“确定”type=“button”data-td-id=“id1”/>
添加附加信息后的Page B为:
按钮:<input id=“submit”name=“”value=“立即申请”type=“button”data-td-id=“id2”/>
由上述示例可知,通过在不同埋点元素中添加不同的附加信息,如data-td-id=“id1”和data-td-id=“id2”,即可将不同页面中显示的相同id和name对应的埋点区分开来,这样,为后续统计各个埋点控件的埋点数据提供了便利性。
在一个实施例中,步骤S110中开启对埋点控件的监测的步骤之前,还可以包括:
B1:在所述应用的本地缓存中新建多个配置文件;其中,所述配置文件包括收集数据的脚本文件;
B2:将各个配置文件与所述应用中各个页面的埋点代码相关联;
B3:当所述埋点代码被执行时,调用与所述埋点代码对应的配置文件。
本实施例中,通过将本地缓存下新建的配置文件与该配置文件对应的页面的埋点代码之间相关联后,即可在该埋点代码被执行时,调用与该埋点代码对应的配置文件,以便通过该配置文件的脚本文件收集页面埋点的数据信息。
进一步地,可通过该配置文件进行自动索引,得到各个埋点控件的埋点触发信息,该埋点触发信息中包含有埋点元素的属性信息以及附加信息等。通过对元素添加配置文件,可以在该文件中找到所有存在的埋点,也可以避免埋点id出现重复的情况。
更进一步地,可在该配置文件中添加备份字段,该备份字段为附加信息(如data-td-id)属性的值的具体映射,从而可以清晰的看到埋点的具体内容。
在一个实施例中,步骤S110中开启对埋点控件的监测的步骤,可以包括:
C1:获取所述应用发送的埋点代码执行请求,并根据所述埋点代码执行请求响应与所述埋点代码对应的配置文件;
C2:通过所述配置文件开启对所述页面的埋点控件的监测。
本实施例中,用户在应用中的操作行为会触发浏览器对被统计页面的一个http请求,即用户打开网页。
当网页被打开时,页面中埋点(javascript)的代码片段会被执行,该代码片段会动态创建一个script标签,并将src(源文件)指向一个单独的js文件,此时这个单独的js文件会被浏览器请求到并执行,这里的js文件就是真正的数据收集脚本,即本方案中的配置文件。
当该页面对应的配置文件被请求执行时,即可通过该配置文件开启对页面的埋点控件的监测。
在一个实施例中,步骤S130中根据所述埋点触发信息统计各个埋点控件被触发的次数,得到各个埋点控件的埋点数据的步骤,可以包括:
D1:通过所述埋点触发信息中的附加信息将所述本地缓存中的各个埋点触发信息重新进行排列,得到埋点列表;
D2:统计所述埋点列表中同一个埋点触发信息对应的埋点控件被触发的次数,得到各个埋点控件的埋点数据。
由于用户操作的不确定性,因而本地缓存中的埋点触发信息一般设置为根据用户触发埋点对象的触发时间进行排列,由此导致同一个的附加信息对应的埋点触发信息不一定会集中在一起。因此,需要对本地缓存中的各个埋点触发信息重新进行排列,将同一个的附加信息对应的埋点触发信息排列在一起,这样更有利于统计同一个埋点触发信息对应的埋点控件被触发的次数。
本实施例中,通过步骤A1和步骤A2可以得到埋点属性配置后的埋点控件,在该埋点控件的埋点触发信息中,由于附加信息是通过不同埋点元素添加得到的,如data-td-id=“id1”和data-td-id=“id2”,因而可将不同页面中显示的相同id和name对应的埋点区分开来。
综上,通过各个埋点触发信息中的附加信息,可将本地缓存中的各个埋点触发信息重新进行排列,得到埋点列表,如将data-td-id=“id1”这一附加信息对应的埋点触发信息排列在一个目录下,该目录名称可以是该附加信息对应的名称。
当通过上述手段得到埋点列表后,统计该埋点列表中同一个埋点触发信息对应的埋点控件被触发的次数,即该埋点触发信息出现的次数,并根据被触发的次数统计该埋点列表中各个埋点控件被触发的次数,即为各个埋点控件的埋点数据。
当然,该埋点数据中包含有各个埋点控件对应的埋点的属性信息、附加信息、该埋点触发信息被触发的次数等。通过该埋点数据即可判断用户在该应用中的操作行为对应的意图等。
在一个实施例中,步骤D2中统计所述埋点列表中同一个埋点触发信息对应的埋点控件被触发的次数的步骤之后,还可以包括:
E1:根据统计结果确定所述埋点列表中同一个埋点触发信息对应的埋点控件被触发的次数是否超过设定的阈值;
E2:当被触发的次数超过所述阈值时,以所述阈值作为对应的埋点控件被触发的次数。
本实施例中,还可以对上述埋点触发信息被触发的次数设定相应的阈值,当统计同一个埋点触发信息对应的埋点被触发的次数后,如果触发的次数超过设定的阈值时,以该阈值对应的埋点被触发的次数为该埋点最终被触发的次数。
如,设定埋点被触发的次数的阈值为10时,当该埋点被触发的次数统计超过10次后,即不再统计该埋点被触发的次数,取10次为该埋点被触发次数即可。这样不仅能够减少统计时间,还不会对最终结果的分析造成影响。
在一个实施例中,如图4所示,图4为一个实施例的埋点数据的上报装置结构示意图,本实施例中提供了一种埋点数据的上报装置,其包括:监测模块210、信息采集模块220、信息处理模块230和信息上传模块240,其中:
监测模块210,用于监测应用的运行状态,当所述应用开始运行时,开启对埋点控件的监测。
本申请通过在h5页面中设置埋点,通过埋点采集用户在该页面中的行为数据,然后将该行为数据上报给TD(人才发展)或神策等统计平台统计自动化埋点,以对用户的行为进行分析。
因此,本模块中,首先需要对混合开发模式下的应用的运行状态进行监测,以便在该应用开始运行时,开启对该应用中各个网页页面的埋点控件进行监测;当埋点控件被点击或页面加载等事件或状态发生变更时,自动上报给原生系统。
需要说明的是,这里的埋点控件指的是应用的各个网页页面中设置有页面埋点的元素;这里的原生系统指的是IOS(苹果)或Android(安卓)系统。
信息采集模块220,用于收集页面上各个埋点控件产生的埋点触发信息,统计所述埋点触发信息并存放至本地缓存。
本模块中,通过上述监测模块210中开启对埋点控件的监测后,通过页面埋点收集网页页面上各个埋点控件产生的埋点触发信息,该埋点触发信息包括有用户点击、浏览相关控件的信息。
由于将h5页面上报的内容通过原生系统保存时,无需频繁地向原生系统发送请求,因此,当统计收集到的埋点触发信息后,可将该埋点触发信息存放至原生系统的本地缓存下。
需要说明的是,这里的页面埋点指的是h5页面中,通过js等技术手段实现页面展示内容的信息爬取;页面埋点主要用于流量分析,而流量的意思包含有:页面浏览数(PV)、独立访问者数量(UV)、IP、页面停留时间、页面操作时间、页面访问次数、按钮点击次数、文件下载次数等。
信息处理模块230,用于当所述应用退出运行时,从所述本地缓存中提取各个埋点触发信息,根据所述埋点触发信息统计各个埋点控件被触发的次数,得到各个埋点控件的埋点数据。
本模块中,通过监测模块210中监测应用的运行状态后,当该应用退出运行时,将该应用运行过程中采集并保存在本地缓存下的各个埋点触发信息中埋点控件被触发的次数进行统计,以便得到各个埋点控件的埋点数据。
比如,埋点控件为按钮时,统计该按钮被点击的次数,得到的即是该按钮的埋点数据,该埋点数据还包括该按钮的页面标签中对应的属性信息,通过该属性信息即可统计不同埋点控件的埋点数据。
信息上传模块240,用于将所述埋点数据上报至服务器。
本模块中,通过信息处理模块230中得到各个埋点控件的埋点数据后,可直接将该埋点数据整理成埋点数据包后上报至服务器,或者将该埋点数据送入上报机制中,由该上报机制将埋点数据上报至服务器即可。
上述埋点数据的上报装置,监测应用的运行状态,当所述应用开始运行时,开启对埋点控件的监测;收集页面上各个埋点控件产生的埋点触发信息,统计所述埋点触发信息并存放至本地缓存;当所述应用退出运行时,从所述本地缓存中提取各个埋点触发信息,根据所述埋点触发信息统计各个埋点控件被触发的次数,得到各个埋点控件的埋点数据;将所述埋点数据上报至服务器。
本方案中,通过监测应用的运行状态来判断是否开启对应用中的埋点控件的监测,以便在应用运行时,由各个埋点控件对应的页面埋点来收集埋点控件产生的埋点触发信息,当应用退出运行时,再通过收集到的埋点触发信息统计各个埋点控件的埋点数据;这种通过本地缓存将应用运行时产生的所有的埋点数据一并上报至服务器的过程,不仅会减少处理器的操作线程,以及内存的占用空间,而且还避免了同步的数据请求之间的相互影响,使得数据能够正常保存。
关于埋点数据的上报装置的具体限定可以参见上文中对于埋点数据的上报方法的限定,在此不再赘述。上述埋点数据的上报装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于终端设备中的处理器中,也可以以软件形式存储于终端设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中,提出了一种终端,包括存储器320和处理器380,所述存储器320中存储有计算机可读指令,所述计算机可读指令被所述处理器380执行时,使得所述处理器380执行如上述实施例中任意一项所述埋点数据的上报方法中的步骤。
如图5所示,图5示出的是与本发明实施例提供的终端相关的手机的部分结构框图。参考图5,手机包括:射频(Radio Frequency,RF)电路310、存储器320、输入单元330、显示单元340、传感器350、音频电路360、无线保真(wireless fidelity,WiFi)模块370、处理器380、以及电源390等部件。本领域技术人员可以理解,图5中示出的手机结构并不构成对手机的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
下面结合图5对手机的各个构成部件进行具体的介绍:
RF电路310可用于收发信息或通话过程中,信号的接收和发送,特别地,将基站的下行信息接收后,给处理器380处理;另外,将设计上行的数据发送给基站。存储器320可用于存储计算机可读存储指令以及模块,处理器380通过运行存储在存储器320的计算机可读存储指令以及模块,从而执行手机的各种功能应用以及数据处理。输入单元330可用于接收输入的数字或字符信息,以及产生与手机的用户设置以及功能控制有关的键信号输入。显示单元340可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。
手机还可包括至少一种传感器350,比如光传感器、运动传感器以及其他传感器。音频电路360、扬声器361,传声器362可提供用户与手机之间的音频接口。WiFi属于短距离无线传输技术,手机通过WiFi模块370可以帮助用户收发电子邮件、浏览网页和访问流式媒体等,它为用户提供了无线的宽带互联网访问。处理器380是手机的控制中心,利用各种接口和线路连接整个手机的各个部分,通过运行或执行存储在存储器320内的计算机可读存储指令和/或模块,以及调用存储在存储器320内的数据,执行手机的各种功能和处理数据,从而对手机进行整体监控。
手机还包括给各个部件供电的电源390(比如电池),优选的,电源可以通过电源管理系统与处理器380逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
在一个实施例中,提出了一种存储介质,当存储在存储器320的计算机可读存储指令以及模块被处理器380执行时,可使得处理器380实现上述埋点数据的上报方法,以及实现图4所示实施例中的埋点数据的上报装置中的相应模块的功能。
应该理解的是,虽然附图的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,其可以以其他的顺序执行。而且,附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,其执行顺序也不必然是依次进行,而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上所述仅是本申请的部分实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。