一种界面卡顿监测方法及装置与流程

本发明涉及终端
技术领域：
，具体而言，涉及一种界面卡顿监测方法及装置。
背景技术：
：当用户在使用手机、平板电脑及电脑等终端设备时，经常会出现界面卡顿现象，比如说，当用户在玩游戏的时候，或者听歌的时候经常会出现画面滞帧，这就是卡顿现象，卡顿现象也就是人们通常所述的“卡”。而引起界面卡顿的原因有很多，现有技术中，为了分析出现界面卡顿的原因，通常采用的方法就是由测试人员对终端设备进行多次测试，当测试人员在测试过程中发现卡顿现象时，由开发人员对问题进行复现，以获取出现卡顿时终端的日志信息，进而分析出现卡顿的原因。但是，采用现有技术中的方法进行界面卡顿的测试，需要投入大量的测试人员对终端设备进行反复测试，导致人力资源的浪费，并且，当出现卡顿时，为了获取出现卡顿时的日志信息，还得由开发人员对问题进行复现，耗费大量的时间。技术实现要素：有鉴于此，本发明实施例的目的在于提供一种界面卡顿监测方法及装置，以试图解决或者缓解上述出现的问题。第一方面，本发明实施例提供了一种界面卡顿监测方法，其中，所述方法包括：根据待监测终端的中央处理器和内存的性能指标，确定所述待监测终端的界面卡顿阈值；实时或定期发送监测消息给界面线程对应的消息队列，并记录所述监测消息的发送时间，所述监测消息携带有消息标识；对所述消息队列中的消息按序进行处理，当接收到携带有所述消息标识的所述监测消息的处理请求时，记录所述监测消息对应的处理请求的接收时间；根据所述发送时间、所述接收时间和所述界面卡顿阈值,判断所述待监测终端是否出现界面卡顿；当确定所述待监测终端出现界面卡顿时，获取所述待监测终端在所述发送时间和所述接收时间之间的时间段内的日志信息，所述日志信息包括所述中央处理器占用信息、所述内存占用信息及当前运行程序的调试信息。结合第一方面，本发明实施例提供了上述第一方面的第一种可能的实现方式，其中，所述根据所述发送时间、所述接收时间和所述界面卡顿阈值,判断所述待监测终端是否出现界面卡顿，包括：确定所述发送时间和所述接收时间之间的时间差值；将所述时间差值与所述界面卡顿阈值进行比较；当所述时间差值大于或等于所述界面卡顿阈值时，确定所述待监测终端出现界面卡顿。结合第一方面，本发明实施例提供了上述第一方面的第二种可能的实现方式，其中，所述方法还包括：将获取的所述日志信息生成待监测终端的日志文件；将所述日志文件发送给服务器。结合第一方面的第二种可能的实现方式，本发明实施例提供了上述第一方面的第三种可能的实现方式，其中，所述将所述日志文件发送给服务器，包括：将所述日志文件的大小与预设阈值进行比较；当所述日志文件大于或等于所述预设阈值时，将所述日志文件发送给服务器；当所述日志文件小于所述预设阈值时，将所述日志文件保存在所述待监测终端。结合第一方面，本发明实施例提供了上述第一方面的第四种可能的实现方式，其中，所述根据待监测终端的中央处理器和内存的性能指标，确定所述待监测终端的界面卡顿阈值，包括：根据所述中央处理器和所述内存的性能指标，确定所述待监测终端的硬件评分；根据所述硬件评分，确定所述待监测终端的界面卡顿阈值。结合第一方面的第四种可能的实现方式，本发明实施例提供了上述第一方面的第五种可能的实现方式，其中，所述根据所述中央处理器和所述内存的性能指标，确定所述待监测终端的硬件评分，包括：分别确定所述中央处理器和所述内存的评分规则；根据所述中央处理器的性能指标和所述中央处理器的评分规则，确定所述中央处理器的评分；根据所述内存的性能指标和所述内存的评分规则，确定所述内存的评分；根据所述中央处理器的评分和所述内存的评分，确定所述待监测终端的硬件评分。结合第一方面的第五种可能的实现方式，本发明实施例提供了上述第一方面的第六种可能的实现方式，其中，所述根据所述中央处理器的评分和所述内存的评分，确定所述待监测终端的硬件评分，包括：分别确定所述中央处理器和所述内存的权重；根据所述中央处理器的评分、所述中央处理器的权重、所述内存的评分和所述内存的权重，确定所述待监测终端的硬件评分。结合第一方面，本发明实施例提供了上述第一方面的第七种可能的实现方式，其中，通过所述界面线程的消息发送者Handler发送监测消息给所述界面线程对应的消息队列。第二方面，本发明实施例提供了一种界面卡顿监测装置，其中，所述装置包括：确定模块，用于根据待监测终端的中央处理器和内存的性能指标，确定所述待监测终端的界面卡顿阈值；第一发送模块，用于实时或定期发送监测消息给界面线程对应的消息队列，并记录所述监测消息的发送时间，所述监测消息携带有消息标识；处理模块，用于对所述消息队列中的消息按序进行处理，当接收到携带有所述消息标识的所述监测消息的处理请求时，记录所述监测消息对应的处理请求的接收时间；判断模块，用于根据所述发送时间、所述接收时间和所述界面卡顿阈值,判断所述待监测终端是否出现界面卡顿；获取模块，用于当确定所述待监测终端出现界面卡顿时，获取所述待监测终端在所述发送时间和所述接收时间之间的时间段内的日志信息，所述日志信息包括所述中央处理器占用信息、所述内存占用信息及当前运行程序的调试信息。结合第二方面，本发明实施例提供了上述第二方面的第一种可能的实现方式，其中，所述判断模块，包括：第一确定单元，用于确定所述发送时间与所述接收时间之间的时间差值；比较单元，用于将所述时间差值与所述界面卡顿阈值进行比较；第二确定单元，用于当所述时间差值大于或等于所述界面卡顿阈值时，确定所述待监测终端出现界面卡顿。本发明实施例提供了一种界面卡顿监测方法及装置，该方法实现了界面卡顿的自动监测，并且，在监测到出现界面卡顿时，会获取卡顿期间的日志信息，方便开发人员对引起卡顿的原因进行分析，避免了通过问题复现来获取卡顿期间的日志信息，节省了大量的人力和时间。为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。附图说明为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。图1示出了本发明实施例1所提供的一种界面卡顿监测方法的流程图；图2示出了本发明实施例1所提供的一种界面卡顿监测方法中判断是否出现界面卡顿的流程图；图3示出了本发明实施例1所提供的一种界面卡顿监测方法中确定待监测终端的硬件得分的流程图；图4示出了本发明实施例2所提供的一种界面卡顿监测装置的结构示意图。具体实施方式为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。考虑到现有技术中，在检测终端是否出现界面卡顿时，通常采用的方法就是由测试人员对终端设备进行多次测试，当测试人员在测试过程中发现卡顿现象时，由开发人员对问题进行复现，以获取出现卡顿时终端的日志信息，进而分析出现卡顿的原因，但是，这样需要投入大量的测试人员，导致人力资源的浪费，并且，当出现卡顿时，为了获取出现卡顿时的日志信息，还得由开发人员对问题进行复现，耗费大量的时间。基于此，本发明实施例提供了一种界面卡顿监测方法及装置，下面通过实施例进行描述。实施例1本发明实施例提供了一种界面卡顿监测方法，如图1所示，采用该方法进行界面卡顿监测时，包括步骤S110-S150，具体如下。S110，根据待监测终端的中央处理器和内存的性能指标，确定待监测终端的界面卡顿阈值。上述待监测终端可以时手机、平板电脑、计算机等。引起终端卡顿的原因很多，主要还是受终端硬件性能高低的影响，当终端需要处理的任务量相同时，如果终端的硬件性能很高，则终端可以在很短的时间内完成该任务量，如果终端的硬件性能很低，则终端需要较长的时间才能完成上述任务量。而终端界面出现卡顿，主要还是由终端上的中央处理器(CentralProcessingUnit，CPU)和内存来决定的，因此，在本发明实施例中，主要考虑中央处理器和内存对界面卡顿的影响，根据中央处理器和内存的性能指标，确定待监测终端的界面卡顿阈值。其中，根据中央处理器和内存的性能指标，确定待监测终端的界面卡顿阈值，具体包括：根据中央处理器和内存的性能指标，确定待监测终端的硬件评分；根据上述硬件评分，确定待监测终端的界面卡顿阈值。由于终端设备中，对卡顿影响最大的就是中央处理器和内存，因此，本发明中，根据中央处理器和内存的性能指标，确定待监测终端的硬件评分。其中，作为一个实施例，如图2所示，根据中央处理器和内存的性能指标，确定待监测终端的硬件评分，包括步骤S210-S240，具体如下。S210，分别确定中央处理器和内存的评分规则；S220，根据中央处理器的性能指标和中央处理器的评分规则，确定中央处理器的评分；S230，根据内存的性能指标和内存的评分规则，确定内存的评分；S240，根据中央处理器的评分和内存的评分，确定待监测终端的硬件评分。其中，对于中央处理器而言，最重要的两个因素就是中央处理器的主频和内核数量，因此，在本发明实施例中，在对中央处理器进行评分时，主要考虑中央处理器的主频和内核数量。当中央处理器的主频越高时，引起界面卡顿的概率越小，即中央处理器的硬件评分越高，当中央处理器的内核数量越多时，引起界面卡顿的概率越小，即中央处理器的硬件评分越高。因此，可以按照引起界面卡顿的概率，设定中央处理器的评分规则，即主频越大，中央处理器的得分越高，在某个具体实施例中，不同主频的中央处理器对应的分数，如表1所示。表1主频0-1G1-2G2G+分数20分30分50分在上述表1中，当主频小于或等于1G时，对应的分数为20分，当主频大于1G且小于或等于2G时，中央处理器对应的得分为30分，当主频大于或等于2G时，中央处理器对应的得分为50分。当然，上述表1中只是给出了一种主频的评分规则，并没有对各个频段对应的分数进行限定，上述各个频段对应的分数还可以是其它值，只要满足主频越大，分数越高的原则即可。在某些具体实施例中，不同内核数量的中央处理器对应的评分规则，如表2所示。表2内核数量1核心2核心4核心8核心分数20分30分40分50分其中，在上述表2中，当中央处理器的内核数量小于或等于1个时，中央处理器对应的得分为20分，当内核数量大于1且小于或等于2个时，中央处理器对应的得分为30分，当内核数量大于2且小于或等于4时，中央处理器对应的得分为40分，当内核数量大于4且小于或等于8时，中央处理器对应的得分为50分。当然，上述表2中只是给出了一种内核数量对应的评分规则，并没有对各个核心对应的分数进行限定，上述不同数量的内核对应的分数还可以是其它数值，只要满足内核数量越多，分数越高的原则即可。上述表1和表2给出了一种可能的评分规则，如果待监测终端的中央处理器的主频为2.51G，内核的数量为8核，从上述表1中可以得出待监测终端的中央处理器的主频的得分为50分，内核的得分为50分，因此，待监测终端的中央处理器的评分为50+50＝100分，即中央处理器的评分为主频得分和内核得分之和。待监测终端内存直接影响的是待监测终端的容量，而待监测终端的容量越大，引起界面卡顿的概率越低，待监测终端的容量越小，引起界面卡顿的概率越高，即待监测终端的内存越大，引起界面卡顿的概率越低，内存的评分越高，待监测终端的内存越小，引起界面卡顿的概率越高，内存的评分越低。因此，在确定内存的评分规则时，需要满足内存的容量越大，内存的评分越高的原则即可，在某个具体实施例中，内存对应的评分规则如表3所示。表3内存容量512M512M-1G1G-2G2G-4G6G+分数20分40分60分80分100分其中，在上述表3中，当终端设备的内容容量小于或等于512M时，终端设备的内存得分为20分，当内存容量大于512M且小于或等于1G时，内存对应的得分为40分，当内存容量大于1G且小于或等于2G时，内存对应的得分为60分，当内存容量大于2G且小于或等于4G时，内存对应的得分为80分，当内存容量大于6G时，内存对应的得分为100分。当然，上述表3只是给出了其中一种可能的内存的评分规则，并没有对每个阶段内存对应的具体的分数进行限定，上述每个阶段对应的内存的得分还可以是其它数值，内存的评分规则只要满足内存越大，内存得分越高即可。通过上述过程，可以分别确定的待监测终端的中央处理器和内存的单项评分，之后，则根据中央处理器的评分和内存的评分，确定待监测终端的硬件评分，具体包括：分别确定中央处理器和内存的权重；根据上述中央处理器的评分、中央处理器的权重、内存的评分和内存的权重，确定待监测终端的硬件评分。其中，与内存相比较，中央处理器对引起界面卡顿的影响更大，因此，中央处理器的权重大于内存的权重。当确定了中央处理器和内存的权重后，可以通过如下公式计算待监测终端的硬件评分，M＝a×b％+c×d％其中，在上述公式中，M为待监测终端的硬件评分，a为中央处理器的评分，b％为中央处理器的权重，c为内存的评分，d％为内存的权重。比如说，在某个实施例中，如果中央处理器的评分为90，内存的评分为80，中央处理器的权重为80％，内存的权重为20％，则根据上式可以计算出待监测终端的硬件评分为88。当确定了待监测终端的硬件评分后，根据待监测终端的硬件评分确定待监测终端的界面卡顿阈值。待监测终端的响应速度随着硬件性能的高低而有所不同，对于相同的任务量，如果终端的硬件性能较高，则可以在较短时间内完成该任务量，如果终端的硬件性能较低，则需要较长的时间才能完成上述任务量，因此，在对待监测终端进行界面卡顿监测时，需要根据待监测终端硬件性能设定界面卡顿阈值，即根据待监测终端的硬件评分，确定待监测终端的界面卡顿阈值。如果终端的硬件评分较高，可以将终端的界面卡顿阈值设小一些，如果终端的硬件评分较低，可以将界面卡顿阈值设大一些。当用户在使用终端设备时，如果终端设备的界面在1-2S内没有反应，用户通过肉眼就可以感受到终端的界面卡顿现象，因此，可以建立硬件评分与界面卡顿阈值之间的对应关系，其中，一种可能的对应关系具体如下：60+：界面卡顿阈值1S40<x≤60：界面卡顿阈值1.5S20<x≤40:界面卡顿阈值2Sx≤20:界面卡顿阈值2.5S当然，上述只是给出了其中一种硬件评分和界面卡顿阈值之间的对应关系，上述不同的硬件评分还可以对应其它数值的界面卡顿阈值，本发明实施例并没有对上述具体的界面卡顿阈值以及硬件评分的划分进行限定。当确定了待监测终端的硬件评分后，根据待监测终端的硬件评分以及上述对应关系，就可以确定出待监测终端的界面卡顿阈值。S120，实时或定期发送监测消息给界面线程对应的消息队列，并记录该监测消息的发送时间，该监测消息携带有消息标识。在对待监测终端进行界面卡顿监测时，需要实时或定期发送监测消息给界面线程对应的消息队列。其中，上述监测消息可以是空消息，该监测消息携带的消息表示可以是该监测消息的编码(Identity，ID)。当发送监测消息给界面线程对应的消息队列后，记录该消息的发送时间。其中，在本发明实施例中，可以通过界面线程的消息发送者Handler发送监测消息给界面线程对应的消息队列。具体的，可以通过Handler中的sendEmptyMessage函数发送监测消息给界面线程的消息队列中。上述可以通过Handler的system.currenttimemillis函数记录上述监测消息的发送时间。在安卓系统中，Handler是专门用于发送消息的工具，在本发明实施例中，可以通过Handler的构造函数得到Handler的实例对象。在构造函数中需要使用Lopper对象，可以通过调用Lopper.getLopper函数来获取Lopper对象。其中，在安卓系统中，界面线程自带消息循环的Lopper，消息循环的Lopper是消息循环的核心逻辑，Lopper工作在界面线程，主要任务就是进行消息循环，Lopper通过无线循环的方式进行消息处理，当Lopper发现有消息后，就会将消息取出来发送到消息队列中，如果没有发现消息，则在原地进行轮询查询。S130，对消息队列中的消息按序进行处理，当接收到携带有消息标识的监测消息的处理请求时，记录监测消息对应的处理请求的接收时间。对于消息队列中的消息，待监测终端会不断的将消息队列中的消息按照消息的在消息队列中的顺序分发给Handler对应的消息处理函数进行处理，Handler对应的消息处理函数按照接收到的消息的顺序对消息进行处理，当接收到上述携带有消息标识的监测消息时以及对该消息进行处理的请求时，Handler对应的消息处理函数对该监测消息进行处理，并记录该监测消息以及处理请求的接收时间。其中，上述Handler对应的消息处理函数可以是handlerMessage。S140，根据上述发送时间、接收时间和界面卡顿阈值，判断待监测终端是否出现界面卡顿。其中，作为一个实施例，如图3所示，上述根据发送时间、接收时间和界面卡顿阈值，判断待监测终端是否出现界面卡顿，包括步骤S310-S330，具体如下。S310，确定上述发送时间和接收时间之间的时间差值；S320，将上述时间差值与界面卡顿阈值进行比较；S330，当上述时间差值大于或等于界面卡顿阈值时，确定待监测终端出现界面卡顿。其中，如果上述记录的发送时间为t1,记录的接收时间为t2，则将t2-t1确定为上述时间差值。将上述时间差值与待监测终端的界面卡顿阈值进行比较，如果上述时间差值小于界面卡顿阈值，则说明待监测终端没有出现界面卡顿，这时不做任何处理；如果上述时间差值大于或等于界面卡顿阈值，则说明待监测终端出现界面卡顿情况。S150，当确定待监测终端出现界面卡顿时，获取待监测终端在上述发送时间和接收时间之间的时间段内的日志信息，该日志信息包括中央处理器的占用信息、内存的占用信息及当前运行程序的调试信息。上述发送时间和接收时间之间的时间段确定为出现界面卡顿，即该时间段为界面卡顿期间。其中，上述中央处理器的占用信息可以通过调用top命令来获取，上述内存的占用信息可以通过调用dumpsysmemory命令来获取。上述运行程序的调试信息指的是开发人员在开发该程序时添加的调试信息，可以通过调用logcat命令来获取上述时间段的调试信息。当获取了上述日志信息后，将获取的日志信息写入待监测终端的日志文件；将上述日志文件发送给服务器。其中，为了节省待监测终端的功耗，并不是每次将日志信息写入日志文件后，都将该日志文件发送给服务器，因此，将日志文件发送给服务器，具体包括：将上述日志文件的大小与预设阈值进行比较；当上述日志文件大于或等于预设阈值时，将上述日志文件发送给服务器；当上述日志文件小于预设阈值时，将日志文件保存在待监测终端。上述预设阈值为预先设置的一个数值，该数值可以设置为1M，也可以设置为其它数值，本发明实施例并不对上述预设阈值的具体大小进行限定。当上述日志文件的大小大于或等于预设阈值时，为了节省上传流量，将上述日志文件进行压缩，并将压缩后的文件发送给服务器，这样开发者可以根据该日志文件分析出现界面卡顿的原因。如果，上述日志文件的大小小于预设阈值，将该日志文件先保存在监测终端，当再次写入日志信息，使得日志文件的大小大于或等于预设阈值时，再将日志文件发送给服务器。本发明实施例提供的界面卡顿监测方法，实现了界面卡顿的自动监测，并且，在监测到出现界面卡顿时，会获取卡顿期间的日志信息，方便开发人员对引起卡顿的原因进行分析，避免了通过问题复现来获取卡顿期间的日志信息，节省了大量的人力和时间。实施例2本发明实施例提供了一种界面卡顿监测装置，如图4所示，该装置包括确定模块410、第一发送模块420、处理模块430、判断模块440以及获取模块450；其中，上述确定模块410，用于根据待监测终端的中央处理器和内存的性能指标，确定待监测终端的界面卡顿阈值；上述第一发送模块420，用于实时或定期发送监测消息给界面线程对应的消息队列，并记录上述监测消息的发送时间，该监测消息携带有消息标识；上述处理模块430，用于对消息队列中的消息按序进行处理，当接收到携带有上述消息标识的监测消息的处理请求时，记录上述监测消息对应的处理请求的接收时间；上述判断模块440，用于根据上述发送时间、上述接收时间和上述界面卡顿阈值，判断待监测终端是否出现界面卡顿；上述获取模块450，用于当确定待监测终端出现界面卡顿时，获取待监测终端在发送时间和接收时间之间的时间段内的日志信息，该日志信息包括中央处理器占用信息、内存占用信息及当前运行程序的调试信息。其中，上述判断模块440根据上述发送时间、上述接收时间和上述界面卡顿阈值，判断待监测终端是否出现界面卡顿，是通过第一确定单元、比较单元和第二确定单元来实现的，具体包括：上述第一确定单元，用于确定发送时间和接收时间之间的时间差值；上述比较单元，用于将上述时间差值与界面卡顿阈值进行比较；上述第二确定单元，用于当上述时间差值大于或等于界面卡顿阈值时，确定待监测终端出现界面卡顿。本发明实施例提供的界面卡顿监测装置，实现了界面卡顿的自动监测，并且，在监测到出现界面卡顿时，会获取卡顿期间的日志信息，方便开发人员对引起卡顿的原因进行分析，避免了通过问题复现来获取卡顿期间的日志信息，节省了大量的人力和时间。本发明实施例所提供的界面卡顿监测装置可以为设备上的特定硬件或者安装于设备上的软件或固件等。本发明实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，前述描述的系统、装置和单元的具体工作过程，均可以参考上述方法实施例中的对应过程，在此不再赘述。在本发明所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本发明提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本
技术领域：
的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围。都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。当前第1页1 2 3