一种文件系统变化的探测方法、探测装置及相应电子设备
技术领域
本申请涉及文件管理,更具体地,涉及一种文件系统变化的探测方法、探测装置及相应的电子设备。
背景技术
在许多系统开发中经常会需要探测或者感知文件(本申请中的“文件”指计算机系统保存数据的物理单元,包括通常所说的文件和目录)的变化,比如在监控系统中需要感知机器上日志文件的变化(如尺寸、文件名和最后修改时间等),从而触发做进一步的处理。通常做法是使用轮询的方式来探测文件变化,如通过一个守护线程按照一定的频率扫描文件的元数据信息,然后对记录的上一次的信息和本次获取的信息做比较,判断文件的变化。但是因为该方案采用一定的周期频率来执行文件信息的采集,那么轮询间隔中发生的变化可能会被忽略,这会导致文件处理的错误。
Linux内核提供了一种称为Inotify的文件系统变化通知机制,在Andorid系统上有基于Inotify的系统内核监听实现,可以实时探测出文件变化,但该实现方案只能基于Android手机,不适用于其他系统平台。而且,该方案在一个应用的多个处理模块需要同时监控不同文件时,也只能创建一个Inotify实例,如果这些文件同时发生变化,Inotify实例只能将把多个事件混合报出,应用还需要为不同处理模块过滤和分发事件,线程监控模型非常低效。
发明内容
本申请实施例要解决的技术问题是提供一种更高效的文件系统变化的探测方法和探测装置。
为了解决上述问题,本申请提供了一种文件系统变化的探测方法,包括:
基于当前操作系统内核的文件系统变化通知机制,侦听内核在监视实例上监视到文件操作事件时发出的通知;
侦听到内核的所述通知后,读取内核缓存的第一事件结构,所述第一事件结构中封装有文件操作事件的文件操作信息;
根据配置的对文件操作信息的过滤条件对待选事件结构进行过滤,将符合过滤条件的待选事件结构上报,其中,所述待选事件结构为所述第一事件结构或对所述第一事件结构做格式变换得到的统一的第二事件结构。
较佳地,
所述过滤条件包括时间敏感度的过滤条件,所述待选事件结构中的文件操作信息包含事件类型和事件发生时间信息;
根据配置的所述过滤条件对待选事件结构进行过滤,包括:上报一待选事件结构后,缓存其中的事件类型和事件发生时间信息,对一待选事件结构进行过滤时,如其中的事件发生时间距离最近一次上报的同类事件的发生时间超过设置的时长阈值,则该待选事件结构符合时间敏感度的过滤条件,否则丢弃该待选事件结构。
较佳地,
所述过滤条件包括文件大小变化敏感度的过滤条件,所述待选事件结构中的文件操作信息包含事件类型和文件大小信息;
根据配置的所述过滤条件对待选事件结构进行过滤,包括:缓存所述待选事件结构中的事件类型和文件大小信息,上报一待选事件结构之后,每次对同类事件的待选事件结构进行过滤时,对本次事件相对于上次事件的文件大小变化量进行累计,如累计值超过设置的变化量阈值,则该待选事件结构符合文件大小变化敏感度的过滤条件,否则丢弃该待选事件结构。
较佳地,
所述过滤条件包括事件类型的过滤条件,所述待选事件结构中的文件操作信息包含事件类型信息;
根据配置的所述过滤条件对待选事件结构进行过滤,包括:对待选事件结构进行过滤时,如该待选事件结构对应的事件类型属于配置文件中配置的需要监视的事件类型,则该待选事件结构符合事件类型的过滤条件,否则丢弃该待选事件结构。
较佳地,
所述基于当前操作系统内核的文件系统变化通知机制,侦听内核在监视实例上监视到文件操作事件时发出的通知之前,还包括:
在应用中存在对文件系统变化有不同的探测需求且需要同时进行探测的多个处理模块时,为其中的每一处理模块创建一监视实例,且对不同的监视实例,使用不同的进程执行探测。
较佳地,
所述将符合过滤条件的待选事件结构上报,包括:将符合过滤条件的待选事件结构写入一阻塞队列,然后唤醒应用中相应的处理模块。
较佳地,
所述待选事件结构是所述第二事件结构,对所述第一事件结构做格式变换得到统一的第二事件结构,包括:
读取内核缓存的第一事件结构之后,根据当前操作系统的类型对所述第一事件结构进行相应解析,解析得到的文件操作信息重新封装为统一的第二事件结构。
相应地,本申请还提供了一种文件系统变化的探测装置,包括:
侦听模块,用于基于当前操作系统内核的文件系统变化通知机制,侦听内核在监视实例上监视到文件操作事件时发出的通知;
读取模块,用于侦听到内核的所述通知后,读取内核缓存的第一事件结构,所述第一事件结构中封装有文件操作事件的文件操作信息;
过滤模块,用于根据配置的所述过滤条件对待选事件结构进行过滤,将符合过滤条件的待选事件结构上报,其中,所述待选事件结构为所述第一事件结构或对所述第一事件结构做格式变换得到的统一的第二事件结构。
较佳地,
所述过滤模块使用的过滤条件包括时间敏感度的过滤条件,所述待选事件结构中的文件操作信息包含事件类型和事件发生时间信息;
所述过滤模块根据配置的所述过滤条件对待选事件结构进行过滤,包括:上报一待选事件结构后,缓存其中的事件类型和事件发生时间信息,对一待选事件结构进行过滤时,如其中的事件发生时间距离最近一次上报的同类事件的发生时间超过设置的时长阈值,则该待选事件结构符合时间敏感度的过滤条件,否则丢弃该待选事件结构。
较佳地,
所述过滤模块使用的过滤条件包括文件大小变化敏感度的过滤条件,所述待选事件结构中的文件操作信息包含事件类型和文件大小信息;
所述过滤模块根据配置的所述过滤条件对待选事件结构进行过滤,包括:缓存所述待选事件结构中的事件类型和文件大小信息,上报一待选事件结构之后,每次对同类事件的待选事件结构进行过滤时,对本次事件相对于上次事件的文件大小变化量进行累计,如累计值超过设置的变化量阈值,则该待选事件结构符合文件大小变化敏感度的过滤条件,否则丢弃该待选事件结构。
较佳地,
所述过滤模块使用的过滤条件包括事件类型的过滤条件,所述待选事件结构中的文件操作信息包含事件类型信息;
所述过滤模块根据配置的所述过滤条件对待选事件结构进行过滤,包括:对待选事件结构进行过滤时,如该待选事件结构对应的事件类型属于配置文件中配置的需要监视的事件类型,则符合事件类型的过滤条件,否则丢弃该待选事件结构。
较佳地,
所述侦听模块侦听内核在监视实例上监视到文件操作事件时发出的通知,其中,所述监视实例在应用中存在对文件系统变化有不同的探测需求且需要同时进行探测的多个处理模块时,是针对其中的每一处理模块创建一个。
较佳地,
所述过滤模块将符合过滤条件的待选事件结构上报,包括:将符合过滤条件的待选事件结构写入一阻塞队列,然后唤醒应用中相应的处理模块。
较佳地,
所述探测装置还包括:重封装模块,用于根据当前操作系统的类型对所述读取模块读取的第一事件结构进行相应解析,解析得到的文件操作信息重新封装为统一的第二事件结构,将所述第二事件结构作为所述过滤模块的待选事件结构。
相应地,本申请还提供了一种电子设备,包括具有文件管理功能的操作系统,还包括上述任一探测装置。
上述实施方案基于时间敏感度、文件大小变化敏感度等条件对内核通知的事件进行过滤,可以防止过于频繁地事件上报带来的不便,为高层系统提供精确但粒度合适的事件上报,提升应用的性能。一些实施例中,针对应用中探测需求不同的处理模块分别创建监视实例并用不同的探测线程加以处理,优化了现有的探测处理线程模型,同时在文件数量上也得意突破Select的限制。另外,将系统内核的事件结构重封装为统一的事件结构,可以实现跨平台的文件探测。
本申请实施例要解决的技术问题是提供一种可以跨平台实现的文件系统变化的探测方法、探测装置及相应的电子设备。
为了解决上述问题,本申请提供了一种文件系统变化的探测方法,包括:
基于当前操作系统内核的文件系统变化通知机制,侦听内核在监视实例上监视到文件操作事件时发出的通知;
侦听到内核的所述通知后,读取内核缓存的第一事件结构,所述第一事件结构中封装有文件操作事件的文件操作信息;
根据当前操作系统的类型对所述第一事件结构进行相应解析,解析得到的文件操作信息重新封装为统一的第二事件结构后上报。
较佳地,
在应用中存在对文件系统变化有不同的探测需求且需要同时进行探测的多个处理模块时,所述监视实例是为其中的各个处理模块分别创建的,且对不同的监视实例,使用不同的进程执行探测。
相应地,本申请还提供了一种文件系统变化的探测装置,包括:
侦听模块,用于基于当前操作系统内核的文件系统变化通知机制,侦听内核在监视实例上监视到文件操作事件时发出的通知;
读取模块,用于侦听到内核的所述通知后,读取内核缓存的第一事件结构,所述第一事件结构中封装有文件操作事件的文件操作信息;
重封装模块,用于根据当前操作系统的类型对所述第一事件结构进行相应解析,解析得到的文件操作信息重新封装为统一的第二事件结构后上报。
较佳地,
所述侦听模块侦听内核在监视实例上监视到文件操作事件时发出的通知,其中,所述监视实例在应用中存在对文件系统变化有不同的探测需求且需要同时进行探测的多个处理模块时,是针对其中的每一处理模块创建一个。
相应地,本申请还提供了一种电子设备,包括具有文件管理功能的操作系统,还包括上述任一探测装置。
上述方案将系统内核规定的事件结构重封装为统一的事件结构,可以实现跨平台的探测,为在Mac,Windows,Linux,Android(base Linux)或者其他Linux based系统平台提供了统一兼容的解决方案。
附图说明
图1是本申请实施例一文件探测方法的流程图;
图2是本申请实施例一文件探测装置的模块图;
图3是本申请实施例二文件探测方法的流程图;
图4是本申请实施例二文件探测装置的模块图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚明白,下文中将结合附图对本申请的实施例进行详细说明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互任意组合。
在本申请一个典型的配置中,电子设备、探测装置包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
实施例一
如图1所示,本实施例的文件系统变化的探测方法包括:
步骤110,基于当前操作系统内核的文件系统变化通知机制,侦听内核在监视实例上监视到文件操作事件时发出的通知;
以Linux2.6内核提供的文件系统变化通知机制--inotify为例,内核以创建的inotify实例为单位对文件操作事件(简称为“事件”)进行监视,该inotify实例要监视的事件可以通过添加Watch对象来设置,包括要监视的文件和对文件的操作类型如“创建文件”、“写文件”、“删除文件”、“修改文件的时间戳”、“重命名”等。内核监视到有事件发生时,会将该事件的文件操作信息封装到inotify_event结构中并插入该inotify实例对应的事件队列,然后唤醒(即通知)侦听文件系统事件的用户态进程。Linux提供的文件I/O操作函数如select、epoll或poll等均可用于侦听事件。
Andorid方案只能为一个应用设置一个inotify实例。本实施例中,在应用中存在对文件系统变化有不同的探测需求且需要同时进行探测的多个处理模块时,为其中的每一处理模块创建一监视实例,且对不同的监视实例,使用不同的进程执行探测。这样就不会象Andorid方案将多个处理模块要探测的事件混合上报,应用无需为不同处理模块过滤和分发事件,提高了探测的效率。
基于Windows内核提供的Overlapped I/O机制,Mac os内核提供的FS EventStream(FS事件流)机制也可以实现上述文件系统变化通知机制。Windows系统提供的IoCompletionPort操作,Mac os系统提供的DirSnapshot操作均可用于监视文件系统事件,但各操作系统内核对文件操作信息的封装结构不同。
上述基于内核的文件系统变化通知机制,采用各个系统内核和文件系统驱动作为底层的触发机制,在事件发生后会立即获取通知,而不需要所无谓的轮询,可以减轻系统负载,且不会存在事件遗漏的情况。对于数据文件变化能做到细粒度的监控和探测,实现精确感知。
步骤120,侦听到内核的通知后,读取内核缓存的第一事件结构,所述第一事件结构中封装有文件操作事件的文件操作信息;
文中的“第一事件结构”和“第二事件结构”是由事件的文件操作信息按一定规则构成的结构体(也即数据集合)。
Linux系统通过在inotify实例上调用文件读取函数(read函数)可以读取内核缓存的第一事件结构。Windows系统中的readCompletionPort函数,Mac os系统中的DirSnapshot函数具有与read函数相似的功能。
步骤130,根据当前操作系统的类型,对所述第一事件结构进行相应解析,解析得到的文件操作信息重新封装为统一的第二事件结构;
不同操作系统的第一事件结构不同,相应的解析方法也不同,所述本步骤要根据当前操作系统的类型对所述第一事件结构进行相应解析。本步骤将不同操作系统的第一事件结构做格式转换为统一的第二事件结构后,对第二事件结构的后续处理就无需考虑当前是什么操作系统,可以跨平台地实现,为多种不同内核的运行机制下提供了用户所需要的统一特性。
下面给出的示例表示一种统一的第二事件结构EventWrapper:
其中,
EVENTWRAPPER表示重封装后的结构体;
UNIT32ID表示事件唯一ID;
FD表示文件(包括目录)描述符;
FD SIZE表示文件(包括目录)大小;
UINT32EV_TYPE表示操作类型;
Time TS表示事件发生时间;
UNIT32SYS_TYPE表示系统类型如Mac,Linux,Windows等;
PTRCALLBACK func表示事件发生后的回调函数;
event_wrapper表示结构名;
*lpevent_wrapper表示结构体类型指针。
需要说明的是,上述EventWrapper根据不同需要可以有不同的变化,例如,当用一个监视实例监视一个文件时,可以不用参数FD,而参数FD SIZE也是可选的。
在上述步骤120中,也可以用两个线程分别实现侦听和重封装,即:监视线程读取内核缓存的第一事件结构后,先将其写入一个阻塞队列,然后唤醒重封装线程;重封装线程先读取一级阻塞队列中的事件结构,再进行后续的重封装处理。这样可以将侦听线程和重封装线程隔离,异步化。
步骤140,根据配置的对文件操作信息的过滤条件对第二事件结构进行过滤,将符合过滤条件的第二事件结构上报。
本实施例中,将符合过滤条件的第二事件结构上报,是将符合过滤条件的第二事件结构写入一阻塞队列并唤醒应用中相应的处理模块(可通过回调函数实现)。阻塞队列(BlockingQueue)是一种特殊的队列,如果BlockQueue是空的,从BlockingQueue读取数据的操作将会被阻断进入等待状态,直到BlockingQueue写入数据才会被唤醒。同样,如果BlockingQueue是满的,任何试图往里写数据的操作也会被阻断进入等待状态,直到BlockingQueue里有空间才会被唤醒继续操作。使用阻塞队列可以节约系统资源。因为本实施例是为有不同探测需求的处理模块分别设置探测进程,所以上报时直接上报给相应的处理模块即可,不再需要额外的过滤和分发。
本步骤中,配置的对文件操作信息的过滤条件包括时间敏感度和/或文件大小变化敏感度。
在基于精确内核事件的方案中会遇到AAA问题,即在一个时间范围内,实体发生了多次变化,每次变化的内容相同,此时需要防止过多的事件对外部观察者的骚扰。同一类事件在很短的时间内被内核报告多次,这并不是内核的错误或者BUG,而是由于应用程序对文件的操作方法来决定的,如果过于敏感的事件被大量的报出,对于应用系统的探测非常不便,处理不好也会极大影响应用的性能。
本实施例设置文件变化的时长阈值来表示时间敏感度。本步骤中,上报一EventWrapper后,缓存其中的事件类型和事件发生时间信息,对一EventWrapper进行过滤时,判断其中的事件发生时间距离最近一次上报的同类事件的发生时间是否超过设置的时长阈值,如果是,则该EventWrapper符合时间敏感度的过滤条件,否则丢弃该EventWrapper。例如:以2秒作为时长阀值,如果2秒内外围系统多次改变某一文件,操作系统内核监视到多个同类事件,经过此处的过滤,将只报告一个事件给应用。文中,事件类型由文件操作信息中的文件信息和/或操作类型信息确定,同类事件的这些信息相同。
本实施例设置文件大小的变化量阈值来表示文件大小变化敏感度,本步骤中,需缓存EventWrapper中的事件类型和文件大小信息,上报一EventWrapper之后,每次对同类事件的EventWrapper进行过滤时,对本次事件相对上次事件的文件大小变化量进行累计,并判断累计值是否超过设置的变化量阈值,如果是,则该EventWrapper符合文件大小变化敏感度的过滤条件,否则,丢弃该EventWrapper。例如:以100K为变化量阀值,如果外围系统多次改变某一文件的大小,将该文件由200K变为150K再变为250K时,变化量等于50K+100K=150,将报告一个事件给应用。设置该阈值可以在文件大小变化很小时不进行上报,在文件大小变化较大(一般文件变化也较大)再进行上报,取得一个合适的粒度。
对于要监视的事件类型,可以利用系统内核提供的相应函数来设置,但是该设置相对比较繁琐。为了方便用户随时屏蔽和打开某类事件的侦听,本实施例允许用户在配置文件中对需要监视的事件类型进行配置,并将事件类型作为过滤条件。相应地,对EventWrapper进行过滤时,判断该EventWrapper对应的事件类型是否属于配置的需要监视的事件类型,如果是,则该EventWrapper符合事件类型的过滤条件,否则直接丢弃该EventWrapper。
针对文件操作信息设置过滤条件的方式不限于以上几种,完全可以根据实际需要做其他的设置,
以上步骤就实现了对文件系统变化的探测,上报之后,相应的处理模块可以读取重封装后的事件结构并进行相应的处理。
相应地,本实施例文件系统变化的探测装置如图2所示,包括:
侦听模块10,用于基于当前操作系统内核的文件系统变化通知机制,侦听内核在监视实例上监视到文件操作事件时发出的通知。
读取模块20,用于侦听到内核的所述通知后,读取内核缓存的第一事件结构,所述第一事件结构中封装有文件操作事件的文件操作信息。
重封装模块30,用于根据当前操作系统的类型对所述第一事件结构进行相应解析,解析得到的文件操作信息重新封装为统一的第二事件结构。
过滤模块40,用于根据配置的对文件操作信息的过滤条件对第二事件结构进行过滤,将符合过滤条件的第二事件结构上报。
较佳地,过滤模块使用的过滤条件包括时间敏感度的过滤条件,所述第二事件结构中的文件操作信息包含事件类型和事件发生时间信息;
所述过滤模块根据配置的所述过滤条件对第二事件结构进行过滤,包括:上报一第二事件结构后,缓存其中的事件类型和事件发生时间信息,对一第二事件结构进行过滤时,判断其中的事件发生时间距离最近一次上报的同类事件的发生时间是否超过设置的时长阈值,如果是,则该第二事件结构符合时间敏感度的过滤条件,如果否,丢弃该第二事件结构。
较佳地,所述过滤模块使用的过滤条件包括文件大小变化敏感度的过滤条件,所述第二事件结构中的文件操作信息包含事件类型和文件大小信息;
所述过滤模块根据配置的所述过滤条件对第二事件结构进行过滤,包括:缓存所述第二事件结构中的事件类型和文件大小信息,上报一第二事件结构之后,每次对同类事件的第二事件结构进行过滤时,对本次事件相对于上次事件的文件大小变化量进行累计,并判断累计值是否超过设置的变化量阈值,如果是,则该第二事件结构符合文件大小变化敏感度的过滤条件,如果否,丢弃该第二事件结构。
较佳地,所述过滤模块使用的过滤条件包括事件类型的过滤条件,所述第二事件结构中的文件操作信息包含事件类型信息;
所述过滤模块根据配置的所述过滤条件对第二事件结构进行过滤,包括:对第二事件结构进行过滤时,判断该第二事件结构对应的事件类型是否是配置文件中配置的需要监视的事件类型,如果是,则该第二事件结构符合事件类型的过滤条件,如果不是,丢弃该第二事件结构,其中,所述事件类型至少由文件操作信息中的文件信息和/或操作类型信息确定。
较佳地,所述侦听模块侦听内核在监视实例上监视到文件操作事件时发出的通知,其中,所述监视实例在应用中存在对文件系统变化有不同的探测需求且需要同时进行探测的多个处理模块时,是针对其中的每一处理模块创建一个。
较佳地,所述过滤模块将符合过滤条件的第二事件结构上报,包括:将符合过滤条件的第二事件结构写入一阻塞队列,然后唤醒应用中相应的处理模块。
本实施例还提供一种电子设备,包括具有文件管理功能的操作系统及上述探测装置。
上述实施方案基于时间敏感度、文件大小变化敏感度等条件对内核通知的事件进行过滤,可以防止过于频繁地事件上报带来的不便,为高层系统提供精确但粒度合适的事件上报,提升应用的性能。而将系统内核的事件结构重封装为统一的事件结构,实现了跨平台的文件探测,不必为不同的平台编制不同的代码。此外,上述实施例针对应用中探测需求不同的处理模块分别创建监视实例并用不同的探测线程加以处理,优化了Android的探测处理线程模型,分组数量越多,性能越优,同时在文件数量上也得意突破Select的限制。当需要探测的文件规模达到1W以上的时候依然可以在一个较低的系统压力下精确的捕获数据文件变化。
在实施例一的基础上,读取内核缓存的第一事件结构后,也可以不进行重封装,直接对第一事件结构进行上述过滤处理,可以得到该实施例的一个变例,该变例同样可以防止过于频繁地事件上报,为高层系统提供精确但粒度合适的事件上报。
实施例二
本实施例和实施例一相比,不考虑对事件结构的过滤处理,其文件系统变化的探测方法如图3所示,包括:
步骤210,基于当前操作系统内核的文件系统变化通知机制,侦听内核在监视实例上监视到文件操作事件时发出的通知;
本步骤同步骤110;
步骤220,侦听到内核的通知后,读取内核缓存的第一事件结构,所述第一事件结构中封装有文件操作事件的文件操作信息;
本步骤同步骤120;
步骤230,根据当前操作系统的类型,对所述第一事件结构进行相应解析,解析得到的文件操作信息重新封装为统一的第二事件结构;
本步骤同步骤130;
步骤240,将所述第二事件结构上报。
相应地,本实施例的探测装置如图4所示,包括:
侦听模块10,用于基于当前操作系统内核的文件系统变化通知机制,侦听内核在监视实例上监视到文件操作事件时发出的通知。
读取模块20,用于侦听到内核的所述通知后,读取内核缓存的第一事件结构,所述第一事件结构中封装有文件操作事件的文件操作信息。
重封装模块30,用于根据当前操作系统的类型对所述第一事件结构进行相应解析,解析得到的文件操作信息重新封装为统一的第二事件结构并上报。
本实施例将系统内核的事件结构重封装为统一的事件结构,应用对上报的事件结构进行处理时,不必针对不同的操作系统编制不同的代码,因而具有跨平台的特性。
本实施例还提供一种电子设备,包括具有文件管理功能的操作系统及上述探测装置。
本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成,所述程序可以存储于计算机可读存储介质中,如只读存储器、磁盘或光盘等。可选地,上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现,相应地,上述实施例中的各模块/单元可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。
以上所述仅为本申请的优选实施例而已,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。