一种无埋点部署监测方法及相关装置与流程

本发明涉及计算机软件领域，尤其涉及一种无埋点部署检测方法及相关装置。

背景技术：

大数据分析是当前互联网技术的发展趋势，其中数据采集是核心问题。前端埋点技术作为一个比较成熟并且被广泛采用的数据接入手段，目前常见的前端埋点技术有三类：代码埋点即在某个控件操作发生时通过预先写好的代码来发数据的代码埋点；可视化埋点即通过可视化界面配置控件操作与事件发生关系的可视化埋点；无埋点即先收集所有数据再在后端筛选需要分析的对象的“无埋点”。

现有技术是将APP界面布局内的所有控件绑定辅助事件，并提取控件在布局内的顺序、唯一id、名称、类名等信息组合控件标识，生成了对应的配置文件，配置文件存放在服务器中。通过该控件标识来查询配置文件中对应控件并对控件配置进行修改从而对控件进行监测，实现无埋点部署监测。

在现有技术中，通过提取控件所在布局的上层所有控件的类名、控件id、控件标签等信息进行组合成控件标识，这就会导致当两个控件信息相同时，则会被默认为同一控件。当两个控件所在布局的上层类名均相同并且没有控件id和控件标签等信息时，则这两个控件触发相同的辅助事件，从而导致错误触发辅助事件现象出现。

技术实现要素：

本发明实施例提供了一种无埋点部署监测方法及相关装置，用于提高处理性能和处理效率从而更好的实现无埋点部署监测。

本发明实施例的第一方面提供了一种无埋点部署监测方法，包括：

服务器接收终端发送的本地配置文件，该本地配置文件由终端将控件信息以逻辑树的形式生成；

该服务器将该本地配置文件存储为服务器配置文件。

当该控件信息需要更新时，该服务器根据控件标识对目标控件信息进行更新，该控件标识与该服务器配置文件中该控件信息的存储位置一一对应。

从以上技术方案可以看出，本发明实施例具有以下优点：

本发明实施例中，服务器接收终端发送的配置文件，当该控件信息需要更新时，该服务器根据控件标识对目标控件信息进行更新，该控件标识与该控件信息在该配置文件中的存储位置一一对应。可以理解的是在以逻辑树形式生成的配置文件中，以控件信息的存储位置作为控件标识，因此该控件标识具有唯一性，当两个控件所在布局的上层类名均相同并且没有控件id和控件标签等信息时，服务器也能通过两个控件的存储位置即控件标识的不同将两控件区分开来，不会使得两个控件触发相同的辅助事件，从而避免错误触发辅助事件现象的发生。

结合本发明实施例的第一方面，在本发明实施例的第一方面的第一种可能的实现方式中，服务器根据控件标识对目标控件信息进行更新包括：

服务器通过控件标识来对服务器配置文件进行查询，当查询到目标控件信息之后，该服务器通过修改目标控件属性对该目标控件信息进行修改从而更新该目标控件信息，该目标控件信息包括该目标控件属性。

该实现方式中，服务器可以通过对目标控件属性的修改实现多目标控件信息的更新，从而使得服务器配置文件所对应的APP布局可以按照需要进行设计以及更改。

结合本发明实施例的第一方面的第一种可能的实现方式，在本发明实施例的第一方面的第二种可能的实现方式中，在服务器通过修改目标控件属性来对目标控件信息进行更新之后还包括：

当服务器对目标控件信息进行修改时，该服务器还同时会将服务器配置文件的版本号进行修改。

该实现方式中，服务器对更新后的服务器配置文件的版本号进行修改可以通过该版本号很清楚的知道与该版本号对应的配置文件有没有修改过。

本发明实施例的第二方面提供了一种无埋点部署监测方法，包括：

终端首次启动APP，该终端为安装有该APP的终端设备；

该终端通过Tracker读取APP界面布局内控件对应的控件信息，该Tracker为该APP内部的跟踪代码；

该终端将该控件信息以逻辑树的形式生成本地配置文件；

该终端将该本地配置文件发送至服务器。

从以上技术方案可以看出，本发明实施例具有以下优点：

终端将控件信息以逻辑树的形式生成本地配置文件，可以理解的是该逻辑树中包含了控件以及控件结构，另外该控件信息在该本地配置文件中的具有唯一的存储位置即逻辑树中的位置，该存储位置是唯一的因此本发明中的配置文件逻辑更加清楚和完善，由于是树形结构读取该配置文件的效率也会响应提高。

结合本发明实施例的第二方面，在本发明实施例的第二方面的第一种可能的实现方式中，该方法还包括：

当终端非首次启动APP时，若服务器配置文件的版本号与本地配置文件的版本号不相同，则说明该服务器配置文件已经更新过了，此时该终端便会将该配置文件下载到本地，利用更新后的该服务器配置文件替换现有的该本地配置文件。

该实现方式中，终端一旦启动就会检查本地配置文件的版本需不需要更新，若需要更新便会及时进行更新。这使得本地配置文件总是最新版本的。

本发明实施例的第三方面提供了一种服务器，包括：

接收单元，用于接收终端发送的本地配置文件，所述本地配置文件由终端将控件信息以逻辑树的形式生成；

存储管理单元，用于将所述本地配置文件存储为服务器配置文件；

更新单元，用于当所述控件信息需要更新时，根据控件标识对目标控件信息进行更新，所述控件标识与所述服务器配置文件中所述控件信息的存储位置一一对应。从以上技术方案可以看出，本发明实施例具有以下优点：

本发明实施例中，接收单元接收终端发送的配置文件，当该控件信息需要更新时，更新单元根据控件标识对目标控件信息进行更新，该控件标识与该控件信息在该配置文件中的存储位置一一对应。可以理解的是在以逻辑树形式生成的配置文件中，以控件信息的存储位置作为控件标识，因此该控件标识具有唯一性，当两个控件所在布局的上层类名均相同并且没有控件id和控件标签等信息时，服务器也能通过两个控件的存储位置即控件标识的不同将两控件区分开来，不会使得两个控件触发相同的辅助事件，从而避免错误触发辅助事件现象的发生。

结合本发明实施的第三方面，在本发明实施例的第三方面的第一种可能的实现方式中，更新单元包括：

查询模块，用于通过所述目标控件标识查询到所述服务器配置文件中对应的所述目标控件信息；

更新模块，用于通过修改目标控件属性来对所述目标控件信息进行更新，所述目标控件信息包括所述目标控件属性。

该实现方式中，更新模块可以通过对目标控件属性的修改实现多目标控件信息的更新，从而使得服务器配置文件所对应的APP布局可以按照需要进行设计以及更改。

结合本发明实施例的第三方面的第一种可能的实现方式，在本发明实施例的第三方面的第二种可能的实现方式中，服务器还包括：

修改单元，用于对所述服务器配置文件的版本号进行修改。

该实现方式中，服务器对更新后的服务器配置文件的版本号进行修改可以通过该版本号很清楚的知道与该版本号对应的配置文件有没有修改过。

本发明实施例的第四方面提供了一种终端，包括：

启动单元，用于首次启动APP，所述终端为安装有所述APP的终端设备；

读取单元，用于通过Tracker读取APP界面布局内控件对应的控件信息，所述Tracker为所述APP内部的跟踪代码；

生成单元，用于将所述控件信息以逻辑树的形式生成本地配置文件；

发送单元，用于将所述本地配置文件发送至服务器。

从以上技术方案可以看出，本发明实施例具有以下优点：

生成单元将控件信息以逻辑树的形式生成本地配置文件，可以理解的是该逻辑树中包含了控件以及控件结构，另外该控件信息在该本地配置文件中的具有唯一的存储位置即逻辑树中的位置，该存储位置是唯一的因此本发明中的配置文件逻辑更加清楚和完善，由于是树形结构读取该配置文件的效率也会响应提高。

结合本发明实施例的第四方面，在本发明实施例的第四方面的第一种可能的实现方式中，终端还包括：

下载单元，用于当所述终端非首次启动所述APP时，若若所述服务器配置文件的版本号与所述本地配置文件的版本号不相同，则下载所述服务器配置文件至本地，所述服务器配置文件为所述服务器中以逻辑树形式存储有所述控件信息的文件。

该实现方式中，终端一旦启动下载单元就会检查本地配置文件的版本需不需要更新，若需要更新便会及时进行更新。这使得本地配置文件总是最新版本的。

附图说明

图1为本发明实施例中无埋点部署监测方法的一个实施例示意图；

图2为本发明实施例中无埋点部署监测方法的另一个实施例示意图；

图3为本发明实施例中无埋点部署监测方法的另一个实施例示意图；

图4为本发明实施例中无埋点部署监测方法的另一个实施例示意图；

图5为本发明实施例中服务器的一个实施例示意图；

图6为本发明实施例中服务器的另一个实施例示意图；

图7为本发明实施例中终端的一个实施例示意图；

图8为本发明实施例中终端的另一个实施例示意图；

图9为本发明实施例中服务器的另一个实施例示意图；

图10为本发明实施例中终端的另一个实施例示意图。

具体实施方式

本发明实施例提供了一种无埋点部署监测方法及相关装置，用于提高处理性能和处理效率从而更好的实现无埋点部署监测。

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

目前对于一个典型的数据平台来说，数据采集显得尤为重要，数据采集是否丰富、采集的数据是否精确和采集是否及时等都会影响整个数据平台的应用效果。数据采集一般遵循两个基本原则：一、优先在后端采集数据；二、属性尽可能采集全面。当在分析前端界面设计是否合理，分析一些和后端没有交互的后端行为等都必须采用前端埋点技术进行分析设计，无埋点部署检测方案是一种比较常用的前端埋点技术手段。

为了便于理解本发明实施例，下面将分别从服务器侧和终端侧来对本发明实施例中无埋点部署监测方法进行说明。

一、服务器侧

请参阅图1对本发明实施例中无埋点部署监测方法中服务器侧的一种优选的实现方式进行详细说明，包括：

101、服务器接收终端发送的本地配置文件。

本实施例中，服务器接收终端发送的本地配置文件，该本地配置文件是将不同的控件信息置于逻辑树中不同的存储位置，该本地配置文件中的控件信息按照控件的内在逻辑生成树状结构因此该本地配置文件的存储结构为逻辑树结构。

此外，本实施例中，该本地配置文件可以为json格式文件，也可以是txt格式文件，还可以是其他格式文件对此此处不做限定。

102、服务器将本地配置文件存储为服务器配置文件。

本实施例中，当服务器接收到本地配置文件时，该服务器将该本地配置文件作为服务器配置文件保存至服务器中。

103、服务器根据控件标识对目标控件信息进行更新。

本实施例中，当开发人员需要实现对不同控件对应的不同辅助事件进行监测时，需要监测的控件对应的控件信息便需要进行更新，此时，服务器通过与服务器配置文件中控件信息的存储位置即控件标识对需要更新的控件信息进行修改，可以理解的是，该控件标识对应的是服务器配置文件中控件信息的存储位置，因此，该控件标识是唯一的。

本实施例中，服务器接收终端发送的本地配置文件并保存为服务器配置文件，当该控件信息需要更新时，该服务器根据控件标识对目标控件信息进行更新，该控件标识与该控件信息在该服务器配置文件中的存储位置一一对应。可以理解的是在以逻辑树形式生成的服务器配置文件中，以控件信息的存储位置作为控件标识，因此该控件标识具有唯一性，当两个控件所在布局的上层类名均相同并且没有控件id和控件标签等信息时，服务器也能通过两个控件的存储位置即控件标识的不同将两控件区分开来，不会使得两个控件触发相同的辅助事件，从而避免错误触发辅助事件现象的发生。

请参阅图2对本发明实施例中无埋点部署监测方法中服务器侧的另一种优先的实现方式进行详细说明，包括：

201、服务器接收终端发送的本地配置文件。

本实施例中，此步骤与上述步骤101类似，此处不再赘述。

202、服务器将本地配置文件存储为服务器配置文件。

本实施例中，此步骤与上述步骤102类似，此处不再赘述。

203、服务器通过目标控件标识查询到服务器配置文件中对应的目标控件信息。

本实施例中，当需要对目标控件信息进行更新时，服务器首先确定目标控件信息在配置文件中的存储位置即控件标识，然后根据该目标控件标识查询到对应的目标控件信息。

204、服务器通过修改目标控件属性来对目标控件信息进行更新。

本实施例中，当服务器查询到目标控件信息后，该服务器通过对该目标控件属性进行修改来更新目标控件信息，该目标控件信息包括该目标控件属性，例如：目标控件对应的目标控件属性对应不同的辅助事件如控制相应控件发送、点击、滚动、长按等事件，当需要将辅助事件由点击变更为发送时就需要对对应的目标控件属性进行修改，从而实现对目标控件信息的更新。当然，该目标控件信息中还包括其他有关控件的信息，对此此处不做限定，可以理解的是，该目标控件信息的更新不仅仅可以通过修改目标控件属性来实现，这只是一种优选的更新方式，还可以通过其他方式进行更新，对此此处也不再赘述。

205、服务器对服务器配置文件的版本号进行修改。

本实施例中，服务器对服务器配置文件中的控制信息进行修改的同时还会将服务器配置文件的版本号进行修改如由V1.1.0版本修改为V1.1.1版本。

本实施例中，服务器通过唯一的目标控件标识查询出目标控件信息，从而通过对目标控件属性进行修改实现对目标控件信息的更新操作，同时还对服务器配置文件的版本号进行更改，使得开发人员可以不停的更改APP布局即配置文件，最终使得APP布局变得越来越好。

二、终端侧

请参阅图3对本发明实施例中无埋点部署监测方法中终端侧的一种优选的实现方式进行详细说明，包括：

301、终端首次启动APP。

本实施例中，终端用户按下开机按钮将终端启动，然后在首次点击APP对应的图标打开该APP。

302、终端通过Tracker读取APP界面布局内控件对应的控件信息。

本实施例中，Tracker是安装在APP内部的跟踪代码，当该APP首次启动时用于读取APP界面布局内对应的控件信息包括控件类型和控件属性，每一个控件都会对应有相应的属性即控件属性，不同的控件属性用于指示不同的控件类型具有不同的功能、大小尺寸等，控件属性一般都会绑定有对应的辅助事件。如：按钮控件可以对应click控件属性，该click控件属性绑定的辅助事件为单击按钮事件。

303、终端将控件信息以逻辑树的形式生成本地配置文件。

本实施例中，当APP首次启动时，终端将APP界面布局内的控件信息生成本地配置文件，该本地配置文件中按照布局内控件的层次关系对应该本地配置文件的逻辑树结构的层次逻辑，每一个控件都有对应逻辑树中唯一的一个存储位置，该存储位置也是按照对应的层次逻辑来进行分配的。

此外，本实施例中，该本地配置文件可以为json格式文件，也可以是txt格式文件，还可以是其他格式文件对此此处不做限定。

304、终端将本地配置文件发送至服务器。

本实施例中，当APP首次启动时，在本地配置文件生成之后，终端便会将该本地配置文件发送至服务器。

本实施例中，终端将控件信息以逻辑树的形式生成本地配置文件，可以理解的是该逻辑树中包含了控件以及控件结构，另外该控件信息在该本地配置文件中的具有唯一的存储位置即逻辑树中的位置，该存储位置是唯一的因此本发明中的配置文件逻辑更加清楚和完善，由于是树形结构读取该配置文件的效率也会响应提高。

请参阅图4对本发明实施例中无埋点部署监测方法中终端侧的另一种优先的实现方式进行详细说明，包括：

401、终端首次启动APP。

402、终端通过Tracker读取APP界面布局内控件对应的控件信息。

403、终端将控件信息以逻辑树的形式生成本地配置文件。

404、终端将本地配置文件发送至服务器。

本实施例中，步骤401至步骤404分别与上述步骤301至步骤304类似，此处不再赘述。

405、终端下载服务器配置文件至本地。

本实施例中，当终端再次启动APP后，该APP会检测本地配置文件的版本号是否与服务器配置文件的版本号相同，若相同，则终端继续读取该本地配置文件对该APP界面进行布局；若不相同，则说明服务器配置文件有更新，该终端便会将服务器配置文件下载至本地将该本地配置文件覆盖掉，该终端重新使用更新后的本地配置文件对该APP界面进行布局。

此外，本实施例中，该服务器配置文件可以为json格式文件，也可以是txt格式文件，还可以是其他格式文件对此此处不做限定。

本实施例中，终端会在每次启动之后会检查本地配置文件的版本需不需要更新若需要更新，则终端便将本地配置文件更新。因此本发明实施例使得当开发人员需要对APP界面布局进行重新布局时操作更加方便，只需在后台将服务器配置文件进行修改并保存为不同的版本号即可。

上述实施例对本发明实施例中无埋点部署监测方法进行了说明，下面将从以下方面对本发明实施例中服务器和终端进行说明。

请参阅图5对本发明实施例中虚拟服务器的优选实施例进行说明，包括：

接收单元501，用于接收终端发送的本地配置文件，该本地配置文件由终端将控件信息以逻辑树的形式生成；

存储管理单元502，用于将该本地配置文件存储为服务器配置文件；

更新单元503，用于当该控件信息需要更新时，根据控件标识对目标控件信息进行更新，该控件标识与该服务器配置文件中该控件信息的存储位置一一对应。

本实施例中，接收单元501接收终端发送的本地配置文件并由存储管理单元502保存为服务器配置文件，当该控件信息需要更新时，更新单元503根据控件标识对目标控件信息进行更新，该控件标识与该控件信息在该服务器配置文件中的存储位置一一对应。可以理解的是在以逻辑树形式生成的服务器配置文件中，以控件信息的存储位置作为控件标识，因此该控件标识具有唯一性，当两个控件所在布局的上层类名均相同并且没有控件id和控件标签等信息时，服务器也能通过两个控件的存储位置即控件标识的不同将两控件区分开来，不会使得两个控件触发相同的辅助事件，从而避免错误触发辅助事件现象的发生。

其中，如图6所示，更新单元603还包括：

查询模块6031，用于通过该目标控件标识查询到该服务器配置文件中对应的该目标控件信息；

更新模块6032，用于通过修改目标控件属性来对该目标控件信息进行更新，该目标控件信息包括该目标控件属性。

另外，该虚拟服务器还包括：

修改单元604，用于对该服务器配置文件的版本号进行修改。

本实施例中，查询模块6031通过唯一的目标控件标识查询出目标控件信息，从而更新模块6032通过对目标控件属性进行修改实现对目标控件信息的更新操作，同时修改单元604还对服务器配置文件的版本号进行更改，使得开发人员可以不停的更改APP布局即配置文件，最终使得APP布局变得越来越好。

请参阅图7对本发明实施例中虚拟终端的优选实施例进行说明，包括：

启动单元701，用于首次启动APP，该终端为安装有该APP的终端设备；

读取单元702，用于通过Tracker读取APP界面布局内控件对应的控件信息，该Tracker为该APP内部的跟踪代码；

生成单元703，用于将该控件信息以逻辑树的形式生成本地配置文件；

发送单元704，用于将该本地配置文件发送至服务器。

本实施例中，生成单元703将控件信息以逻辑树的形式生成本地配置文件，可以理解的是该逻辑树中包含了控件以及控件结构，另外该控件信息在该本地配置文件中的具有唯一的存储位置即逻辑树中的位置，该存储位置是唯一的因此本发明中的配置文件逻辑更加清楚和完善，由于是树形结构读取该配置文件的效率也会响应提高。

另外，如图8所示，该虚拟终端还包括：

下载单元805，用于当该终端非首次启动该APP时，若该该若服务器配置文件的版本号与该本地配置文件的版本号不相同，则下载该服务器配置文件至本地，该服务器配置文件为该服务器中以逻辑树形式存储有该控件信息的文件。

本实施例中，下载单元805会在每次启动之后会检查本地配置文件的版本需不需要更新若需要更新，则终端便将本地配置文件更新。因此本发明实施例使得当开发人员需要对APP界面布局进行重新布局时操作更加方便，只需在后台将服务器配置文件进行修改并保存为不同的版本号即可。

上述实施例对虚拟服务器和虚拟终端进行了详细说明，下面将对实体服务器和实体终端分别进行说明。

请参阅图9对本发明实施例中实体服务器进行详细说明：

图9是本发明实施例提供的一种服务器结构示意图，该服务器900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)922(例如，一个或一个以上处理器)和存储器932，一个或一个以上存储应用程序942或数据944的存储介质930(例如一个或一个以上海量存储设备)。其中，存储器932和存储介质930可以是短暂存储或持久存储。存储在存储介质930的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器922可以设置为与存储介质930通信，在服务器900上执行存储介质930中的一系列指令操作。

通过调用存储介质930存储的一系列指令，中央处理器922执行以下步骤：

接收终端发送的本地配置文件，该本地配置文件由终端将控件信息以逻辑树的形式生成；

将该本地配置文件存储为服务器配置文件；

当该控件信息需要更新时，根据控件标识对目标控件信息进行更新，该控件标识与该服务器配置文件中该控件信息的存储位置一一对应。

服务器900还可以包括一个或一个以上电源926，一个或一个以上有线或无线网络接口950，一个或一个以上输入输出接口958，和/或，一个或一个以上操作系统941，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。

上述实施例中由服务器所执行的步骤可以基于该图9所示的服务器结构。

请参阅图10对本发明实施例中实体终端进行详细说明：

请参阅图10对本发明实施例中的终端进行描述，终端10包括：

输入设备110、输出设备120、处理器130、存储器140和总线150。

其中，存储器140可以包括只读存储器和随机存取存储器，并向处理器130提供指令和数据。存储器140的一部分还可以包括非易失性随机存取存储器(英文全称：Non-Volatile Random Access Memory，英文缩写：NVRAM)。

存储器140存储了如下的元素，可执行模块或者数据结构，或者它们的子集，或者它们的扩展集：

操作指令：包括各种操作指令，用于实现各种操作；

操作系统：包括各种系统程序，用于实现各种基础业务以及处理基于硬件的任务。

本发明实施例中处理器130用于：

首次启动APP，该终端为安装有该APP的终端设备；

通过Tracker读取APP界面布局内控件对应的控件信息，该Tracker为该APP内部的跟踪代码；

将该控件信息以逻辑树的形式生成本地配置文件；

将该本地配置文件发送至服务器。

处理器130控制第一终端10的操作，处理器130还可以称为中央处理单元(英文全称：Central Processing Unit，英文缩写：CPU)。存储器140可以包括只读存储器和随机存取存储器，并向处理器130提供指令和数据。存储器140的一部分还可以包括NVRAM。具体的应用中，第一终端10的各个组件通过总线系统150耦合在一起，其中总线系统150除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图中将各种总线都标为总线系统150。

上述本发明实施例揭示的方法可以应用于处理器130中，或者由处理器130实现。处理器130可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器130中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器130可以是通用处理器、数字信号处理器(英文全称：Digital Signal Processing，英文缩写：DSP)、专用集成电路(英文全称：Application Specific Integrated Circuit，英文缩写：ASIC)、现成可编程门阵列(英文全称：Field-Programmable Gate Array，英文缩写：FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器140，处理器130读取存储器140中的信息，结合其硬件完成上述方法的步骤。

图10的相关描述可以参阅图3和图4方法部分的相关描述和效果进行理解，此处不做过多赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。