数据传输的处理方法及装置与流程

本申请涉及移动通信技术领域，尤其涉及一种数据传输的处理方法及装置。

背景技术：

随着互联网技术的飞速发展，基于互联网的各种客户端或APP层出不穷。对于客户端或APP，通常会对其进行监测，采集获得监测数据，用于后续分析统计。而对监测数据的分析统计的及时性和准确性依赖于对客户端或APP的大量监测数据的实时准确的获取。

现有技术中，通常采用的技术方案是将监测数据按照一定时间间隔，经本地统计后重新组织数据结构，再上传给服务器。现有技术的方案，因监测数据需要本地重组之后才能上传到服务器，服务器接收到监测数据之后还需要进行反解析，对于需要采集大量数据维度的业务，会增加客户端和服务器的工作量，并导致数据传输不及时，无法满足产品业务要求。

因此，如何有效提高监测数据传输的及时性及准确性，成为亟需解决的技术问题。

技术实现要素：

本申请提供一种数据传输的处理方法及装置，以解决现有技术应用程序监测数据上传服务器及时性和准确性较低等缺陷。

本申请第一个方面提供一种数据传输的处理方法，包括：

在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据；

根据预配置的第一发送规则，对各所述监测数据进行发送处理，以将各所述监测数据上传给服务器；其中，对于每条所述监测数据，若发送失败，则将所述监测数据从所述第一数据存储区域移动到第二数据存储区域。

本申请的另一个方面提供一种数据传输的处理装置，包括：

第一获取模块，用于在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据；

第一发送模块，用于根据预配置的第一发送规则，对各所述监测数据进行发送处理，以将各所述监测数据上传给服务器；

第一移动模块，用于对于每条所述监测数据，若发送失败，则将所述监测数据从所述第一数据存储区域移动到第二数据存储区域。

本申请提供的数据传输的处理方法及装置，通过在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据；根据预配置的第一发送规则，对各所述监测数据进行发送处理，以将各所述监测数据上传给服务器，无需对监测数据进行本地重组，从而服务器接收到监测数据后不需要进行反解析，提高了监测数据上传效率。并且通过对于每条所述监测数据，若发送失败，则将所述监测数据从所述第一数据存储区域移动到第二数据存储区域，可以保证正常的监测数据发送的及时性，同时不受之前积累的大量发送失败的监测数据的影响。

附图说明

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

图1为本申请一实施例提供的数据传输的处理方法的流程示意图；

图2为本申请另一实施例提供的数据传输的处理方法的流程示意图；

图3为本申请再一实施例提供的数据传输的处理方法的流程示意图；

图4为本申请一实施例提供的数据传输的处理装置的结构示意图；

图5为本申请另一实施例提供的数据传输的处理装置的结构示意图。

具体实施方式

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

实施例一

本实施例提供一种数据传输的处理方法，用于将对应的应用程序的监测数据上传给服务器。本实施例的执行主体为数据传输的处理装置(以下简称装置)，该装置可以设置在终端中。具体可以与对应的应用程序关联以实现对应的应用程序的监测数据的上传。该方法可以用于不同的应用程序的监测数据的上传。

如图1所示，为本实施例提供的数据传输的处理方法的流程示意图，该方法包括：

步骤101，在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据。

具体的，当用户开启应用程序时，比如用户打开微博，该装置则开始判断是否满足第一预设发送条件。当满足第一预设发送条件时，则从第一数据存储区域中获取待发送的一条或多条监测数据。

其中，第一预设发送条件可以是第一定时器到达第一间隔时间，比如预先设置好第一间隔时间为5分钟，则每间隔5分钟，就触发向服务器上传一次监测数据。则当用户开启应用程序时，第一定时器也开启，当到达第一间隔时间，该装置则从第一数据存储区域中获取待发送的一条或多条监测数据。

可选地，第一数据存储区域中的一条或多条监测数据为对应用程序的监测过程中采集获取后存储到第一数据存储区域中的。监测数据可以为用户使用该应用程序的行为数据、该应用程序展示的内容数据等，只要是该应用程序相关的可以采集到的数据都可以，可以理解地，也可以是根据需要设置好要采集的类型，比如需要采集用户的操作行为数据，可以采集用户的点击操作、点击操作对应的功能、点击时间、进入的页面、页面内容等等。监测数据可以采用数据库字段的形式进行存储。采集的监测数据存储到第一存储区域中。

可选地，第一存储区域可以是缓存池、数据库等任意可实施的存储方式。

可选地，第一预设发送条件还可以是其他条件，比如，可以根据采集的监测数据向第一存储区域存放的次数触发上传操作，比如，存储50次后则进行上传操作；还可以根据第一存储区域中当前存储的数据的大小触发上传操作等等，任意可实施的触发上传操作的条件都可以，本实施例中不做限定。

步骤102，根据预配置的第一发送规则，对各监测数据进行发送处理，以将各监测数据发送到服务器，其中，对于每条监测数据，若发送失败，则将监测数据从第一数据存储区域移动到第二数据存储区域。

具体的，在获取到待发送的一条或多条监测数据后，则可以根据预配置的第一发送规则，对各监测数据进行发送处理，以将各监测数据上传给服务器。预配置的第一发送规则可以是预先设置的监测数据的发送优先级，比如先采集的先发送、或者哪种监测数据优先发送等。具体的发送过程可以为一条一条地发送，根据预配置的第一发送规则一条一条地发送。

其中，对于每条监测数据，若发送失败，则将监测数据从第一数据存储区域移动到第二数据存储区域。移动之后，第一数据存储区域中不再存储有该条监测数据。

第二数据存储区域的类型可以与第一数据存储区域相同，比如为缓存池、数据库等。

如上过程，每当满足第一预设发送条件时，则将第一数据存储区域中，在上一次上传至当前的这段时间内存储的监测数据上传至服务器。

可选地，对上述上传过程可以进行记录。

可选地，在装置获取第一数据存储区域中待发送的监测数据时，还可以判断是否为未发送的监测数据。根据判断结果，只获取未发送的监测数据，进行上传操作。比如根据存储时间进行判断，只获取第一时间间隔内存储的监测数据。还可以在发送后记录发送次数，以便下次获取数据时进行识别待发送的监测数据，还可以在发送成功后将已发送的监测数据从第一数据存储区域中清除等。本实施例不做限定。

本实施例提供的数据传输的处理方法，通过在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据；根据预配置的第一发送规则，对各监测数据进行发送处理，以将各监测数据上传给服务器，无需对监测数据进行本地重组，从而服务器接收到监测数据后不需要进行反解析，提高了监测数据上传效率。并且通过对于每条监测数据，若发送失败，则将监测数据从第一数据存储区域移动到第二数据存储区域，可以保证正常的监测数据发送的及时性，同时不受之前积累的大量发送失败的监测数据的影响。

实施例二

本实施例对实施例一提供的数据传输的处理方法做进一步补充说明。

如图2所示，为本实施例提供的数据传输的处理方法的流程示意图。

作为一种可实施的方式，在上述实施例一的基础上，可选地，对于每条监测数据，若发送成功，则将监测数据从第一数据存储区域中清除。

作为另一种可实施的方式，在上述实施例一的基础上，可选地，上述根据预配置的第一发送规则，对各监测数据进行发送处理，包括：

步骤1021，根据预配置的第一发送规则，将各监测数据加入第一发送队列。

具体的，根据预配置的第一发送规则，将各条监测数据按顺序加入第一发送队列，等待发送。

步骤1022，根据第一发送队列，对各监测数据进行发送处理，以将各监测数据上传给服务器；其中，对于每条监测数据，若发送失败，则将监测数据从第一数据存储区域移动到第二数据存储区域。

具体的，按照第一发送队列进行监测数据的发送，将第一发送队列中的监测数据一条一条地上传到服务器。若某一条监测数据发送失败，则将该条监测数据从第一数据存储区域移动到第二数据存储区域，并继续进行下一条监测数据的发送。

如图3所示，为本实施例提供的作为再一种可实施的方式，在上述实施例一的基础上，可选地，该方法还包括：

步骤2011，在满足第二预设发送条件时，从第二数据存储区域获取发送失败的各监测数据。

具体的，为发送失败的那些监测数据设置第二预设发送条件，该第二预设发送条件的类型可以与第一预设发送条件的类型相同，但具体值可以根据实际情况进行设置，比如若第二预设发送条件为第二定时器，则第二定时器的具体时间间隔可以与第一预设发送条件的第一定时器不同，并且第二定时器可以单独控制，甚至可以关闭第二定时器。第二定时器单独控制功能，可以保证失败的监测数据根据业务需要，灵活配置发送时间，甚至可以关闭第二定时器，以便将失败的监测数据直接扔掉，避免影响数据发送的及时性。比如可以将多次发送失败的监测数据清除不再进行循环地发送等。

步骤2012，根据预配置的第二发送规则，将发送失败的各监测数据加入第二发送队列

具体的，由预配置的第二发送规则，触发第二发送队列，比如第二定时器，实现了失败监测数据的第二发送队列单独维护功能，可以保证失败的监测数据根据业务需要，灵活配置发送时间，甚至可以关闭第二定时器，以便将失败的监测数据直接扔掉，避免影响数据发送的及时性。比如可以将多次发送失败的监测数据清除不再加入第二发送队列进行循环地发送等。

步骤2013，根据第二发送队列，对发送失败的各监测数据进行发送处理。

该步骤的具体操作与第一发送队列的具体操作一致，在此不再赘述。

可选地，对于发送失败的每一条监测数据，若再次发送失败，则将该监测数据的发送次数加1，当再次满足第二预设发送条件时，对该监测数据再次进行发送处理，重复此步骤，直至发送成功。

具体的，若在第二数据存储区域中的某条监测数据在加入第二发送队列，并进行发送处理，结果再次发送失败时，可将该监测数据仍存储在第二数据存储区域，以便再次发送。

可选地，还可以对第二数据存储区域中的监测数据设置发送次数阈值，当发送次数超过发送次数阈值时就不再发送。

可选地，对于第一数据存储区域中的监测数据是否清除可以根据实际需求进行设置，本实施例不做限定。比如可以设置发送成功的监测数据清除，也可以不清除，而标记其已发送或发送次数。

可选地，对于发送失败的每一条监测数据，若再次发送成功，则将监测数据从第二数据存储区域中清除。

作为又一种可实施的方式，在上述实施例一的基础上，可选地，该方法还包括：

步骤2021，根据预配置的采集规则，采集获取监测数据。

具体的，可以根据实际的业务需求预配置采集规则，根据预配置的采集规则，采集获取需要的监测数据。监测数据的具体情况已在上述实施例中进行了详细阐述，在此不再赘述。

步骤2022，将监测数据存储到第一数据存储区域中。

该步骤的具体操作已在上述实施例中进行了详细阐述，在此不再赘述。

需要说明的是，本实施例中各可实施的方式，可以单独实施，也可以在不冲突的情况下，以任意组合方式结合实施，本实施例不做限定。

需要说明的是，步骤2021-2022为监测数据采集存储过程，步骤101、1021和1022为监测数据正常发送的过程，步骤2011-2013为发送失败的监测数据的补偿性发送过程，三个过程为相互独立的过程，没有必然的先后顺序。监测数据的采集可以是实时的，只要应用程序开启，便可实时采集用户的操作行为数据、应用程序向用户展示的界面内容等等，或者根据业务需求采集需要的数据，并将采集获得的监测数据存储到第一数据存储区域。监测数据正常发送的过程可以按照预配置的第一发送规则，从第一数据存储区域获取一条或多条监测数据，并进行发送处理，其过程完全不受采集过程的影响。可以理解地，若满足第一预设发送条件时，第一数据存储区域没有待发送的监测数据，则可以不进行本次发送过程，而等待再一次发送时刻的到来，如此循环处理。监测数据的补偿性发送过程同样可以独立地根据第二预设发送条件及预配置的第二发送规则对第二数据存储区域中的监测数据进行发送处理，而不受采集过程和正常发送过程的影响。三者之间的仅存在监测数据的转移，采集过程实时将监测数据存储到第一数据存储区域，正常发送过程将发送失败的监测数据移动到第二数据存储区域。

本实施例提供的数据传输的处理方法，通过在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据；根据预配置的第一发送规则，对各监测数据进行发送处理，以将各监测数据上传给服务器，无需对监测数据进行本地重组，从而服务器接收到监测数据后不需要进行反解析，提高了监测数据上传效率。并且通过对于每条监测数据，若发送失败，则将监测数据从第一数据存储区域移动到第二数据存储区域，可以保证正常的监测数据发送的及时性，同时不受之前积累的大量发送失败的监测数据的影响。通过采用双队列机制，实现正常监测数据的及时发送以及发送失败的监测数据的补偿性发送，既保证了新的监测数据发送的及时性，又避免了发送失败的监测数据的丢失，提高了监测数据的准确性。还可以通过预配置的第一发送规则和第一数据存储区域将监测数据的采集和发送逻辑解耦，当采集监测数据事件发生时，将相关数据存放到第一数据存储区域中，发送过程可以根据独立的发送规则从第一数据存储区域中获取监测数据进行发送处理，最大限度地保证了程序的稳定性，避免因为数据传输采集集中爆发影响当前应用程序的正常使用。

实施例三

本实施例以缓存池和定时器为例，对上述任一实施例提供的数据传输的处理方法做进一步补充说明。

如图3所示，为本实施例提供的数据传输的处理方法的流程示意图。前提是应用程序处于开启状态，并且，当应用程序开启时，第一定时器开启，第二定时器根据业务需要开启。其中，表示第一数据缓存池和第二数据缓存池的方框并非步骤，而是为说明各步骤之间的关系，将存储监测数据的第一数据缓存池和第二数据缓存池显示在图3中。该方法可以包括：

步骤301，根据预配置的采集规则，采集获取监测数据。

步骤302，将监测数据存储到第一数据缓存池中。

步骤303，判断第一定时器是否到达发送时间，若是转步骤304。

步骤304，从第一数据缓存池中获取待发送的一条或多条监测数据。

步骤305，将根据预配置的第一发送规则，将各监测数据加入第一发送队列。

步骤306，根据第一发送队列进行发送处理。

步骤307，判断当前监测数据是否发送成功。若是转步骤308；若否转步骤311。

步骤308，从第一数据缓存池中清除当前一条监测数据。转步骤309。

步骤309，判断第一发送队列中的监测数据是否发送完。若是转步骤310，若否转步骤306发送下一条监测数据。

步骤310，结束。

步骤311，将当前监测数据从第一数据缓存池移动到第二数据缓存池。转步骤306发送下一条监测数据。

步骤312，判断第二定时器是否到达发送时间，若是转步骤313。

步骤313，从第二数据缓存池中获取一条或多条监测数据。

步骤314，将根据预配置的第二发送规则，将各监测数据加入第二发送队列。

步骤315，根据第二发送队列进行发送处理。

步骤316，判断当前监测数据是否发送成功。若是转步骤317，若否转步骤315。

步骤317，从第二数据缓存池中清除当前监测数据。转步骤315。

其中，步骤301-302为监测数据采集存储过程，其与后续步骤没有必然先后顺序。监测数据采集存储过程为实时过程。后续发送过程可以为实时也可以为间隔发生。步骤303-310为第一定时器及第一发送队列进行正常监测数据发送的过程，步骤311-317为第二定时器及第二发送队列进行发送失败的监测数据的补偿性发送的过程。两个过程没有必然的先后顺序。第一定时器和第二定时器是相对对立控制的，除了将第一数据缓存池中发送失败的监测数据移动到第二数据缓存池之外，两个过程互不干扰。且对于步骤311-317，可以根据实际业务需要选择进行或不进行，以及如何进行。步骤311-317只给出了一次队列上传的过程，在本次结束后，当第二定时器再次到达发送时间时，第二缓存池中可能既有新增的监测数据，又有再次发送失败或多次发送失败的监测数据，可以根据实际需求设置相应的条件，用于确定各种状态的监测数据是否继续发送、或者是否清除等。在此不做限定。

本实施例中各步骤的具体操作与上述实施例中一致，在此不再赘述。

需要说明的是，本实施例只是示例性的说明，并非对本申请的限定。在实际实施过程中，也可以是其他可实施的过程。

本实施例提供的数据传输的处理方法，通过在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据；根据预配置的第一发送规则，对各监测数据进行发送处理，以将各监测数据上传给服务器，无需对监测数据进行本地重组，从而服务器接收到监测数据后不需要进行反解析，提高了监测数据上传效率。并且通过对于每条监测数据，若发送失败，则将监测数据从第一数据存储区域移动到第二数据存储区域，可以保证正常的监测数据发送的及时性，同时不受之前积累的大量发送失败的监测数据的影响。通过采用双队列机制，实现正常监测数据的及时发送以及发送失败的监测数据的补偿性发送，既保证了新的监测数据发送的及时性，又避免了发送失败的监测数据的丢失，提高了监测数据的准确性。还可以通过预配置的第一发送规则和第一数据存储区域将监测数据的采集和发送逻辑解耦，当采集监测数据事件发生时，将相关数据存放到第一数据存储区域中，发送过程可以根据独立的发送规则从第一数据存储区域中获取监测数据进行发送处理，最大限度地保证了程序的稳定性，避免因为数据传输采集集中爆发影响当前应用程序的正常使用。

实施例四

本实施例提供一种数据传输的处理装置，用于执行上述实施例一的数据传输的处理方法。

如图4所示，为本实施例提供的数据传输的处理装置的结构示意图。该数据传输的处理装置40包括第一获取模块41、第一发送模块42和第一移动模块43。

其中，第一获取模块41用于在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据；第一发送模块42用于根据预配置的第一发送规则，对各监测数据进行发送处理，以将各监测数据上传给服务器；第一移动模块43用于对于每条监测数据，若发送失败，则将监测数据从第一数据存储区域移动到第二数据存储区域。

关于本实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

根据本实施例提供的数据传输的处理装置，通过在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据；根据预配置的第一发送规则，对各监测数据进行发送处理，以将各监测数据上传给服务器，无需对监测数据进行本地重组，从而服务器接收到监测数据后不需要进行反解析，提高了监测数据上传效率。并且通过对于每条监测数据，若发送失败，则将监测数据从第一数据存储区域移动到第二数据存储区域，可以保证正常的监测数据发送的及时性，同时不受之前积累的大量发送失败的监测数据的影响。

实施例五

本实施例对上述实施例四提供的数据传输的处理装置做进一步补充说明。

如图5所示，为本实施例提供的数据传输的处理装置的结构示意图。

作为一种可实施的方式，在上述实施例四的基础上，可选地，该装置40还可以包括第一清除模块46。

其中，第一清除模块46用于对于每条监测数据，若发送成功，则将监测数据从第一数据存储区域中清除。

可选地，该装置40可以包括第一数据存储区域44和第二数据存储区域45，也可以不包括第一数据存储区域44和第二数据存储区域45，即第一数据存储区域44和第二数据存储区域45可以为该装置40之外的存储区域。

作为另一种可实施的方式，在上述实施例四的基础上，可选地，第一发送模块42具体可以用于：根据预配置的第一发送规则，将各监测数据加入第一发送队列；根据第一发送队列，对各监测数据进行发送处理。

作为再一种可实施的方式，在上述实施例四的基础上，可选地，该装置40还可以包括第二获取模块47、第二发送模块48和第二清除模块49。

其中，第二获取模块47用于在满足第二预设发送条件时，从第二数据存储区域获取发送失败的各监测数据；第二发送模块48用于根据预配置的第二发送规则，将发送失败的各监测数据加入第二发送队列；根据第二发送队列，对发送失败的各监测数据进行发送处理。

可选地，第二清除模块49用于对于发送失败的每一条监测数据，若再次发送成功，则将监测数据从第二数据存储区域中清除。

作为又一种可实施的方式，在上述实施例四的基础上，可选地，该装置40还可以包括采集模块50和存储模块51。

其中，采集模块50用于根据预配置的采集规则，采集获取监测数据；存储模块51用于将监测数据存储到第一数据存储区域44中。

关于本实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

需要说明的是，本实施例中各可实施的方式，可以单独实施，也可以在不冲突的情况下，以任意组合方式结合实施，本实施例不做限定。

根据本实施例的数据传输的处理装置，通过在应用程序处于开启状态，且满足第一预设发送条件时，从第一数据存储区域中获取待发送的一条或多条监测数据；根据预配置的第一发送规则，对各监测数据进行发送处理，以将各监测数据上传给服务器，无需对监测数据进行本地重组，从而服务器接收到监测数据后不需要进行反解析，提高了监测数据上传效率。并且通过对于每条监测数据，若发送失败，则将监测数据从第一数据存储区域移动到第二数据存储区域，可以保证正常的监测数据发送的及时性，同时不受之前积累的大量发送失败的监测数据的影响。通过采用双队列机制，实现正常监测数据的及时发送以及发送失败的监测数据的补偿性发送，既保证了新的监测数据发送的及时性，又避免了发送失败的监测数据的丢失，提高了监测数据的准确性。还可以通过预配置的第一发送规则和第一数据存储区域将监测数据的采集和发送逻辑解耦，当采集监测数据事件发生时，将相关数据存放到第一数据存储区域中，发送过程可以根据独立的发送规则从第一数据存储区域中获取监测数据进行发送处理，最大限度地保证了程序的稳定性，避免因为数据传输采集集中爆发影响当前应用程序的正常使用。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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