应用安装包处理方法及装置与流程

本发明涉及应用的安装包的封装与发布技术，尤其涉及一种应用安装包处理方法及装置。

背景技术：

随着互联网行业特别是移动互联网的蓬勃发展，应用(app)特别是移动应用的种类和数量迅猛增长，各行各业都开放出可供在移动终端安装的应用，用户可以根据需求从不同的渠道需要的应用在移动终端安装并使用。

目前获取应用的渠道繁多，出现多样化的趋势，以安卓应用为例，获取应用安装包的渠道包括安卓官方的应用商店，以及众多第三方厂商定制化的应用商店，因此，有必要对应用的安装包的渠道进行标识，一方面供用户了解所安装应用的来源渠道，另一方面，可以基于渠道的标识对用户从不同渠道下载安装应用的情况进行统计，从而优化配置应用在不同渠道的上线。

相关技术采用在应用的安装包中加入渠道标识的方式，这需要对用户上传的海量的安装包内添加渠道信息，例如对安装包进行重新编译或者重新签名的处理。

相关技术提供的这种在应用的安装包中添加渠道标识的方式，耗时且会消耗大量的计算资源，也影响了不同渠道的安装包的上线发布效率。

综上所述，如何高效标识向不同渠道发布的安装包，从而保证不同渠道的安装包的上线发布效率，尚无有效解决方案。

技术实现要素：

本发明实施例提供一种应用安装包处理方法及装置，能够高效形成针对不同渠道的渠道包。

本发明实施例的技术方案是这样实现的：

第一方面，本发明实施例提供一种应用安装包处理方法，所述方法包括：

获取应用的安装包、以及所述应用的待发布渠道的渠道标识；

对应用的安装包进行解包处理，得到所述安装包中的目录结构；

在所述目录结构中定位用于存储签名信息的签名信息目录，在所述签名信息目录中创建与所述渠道标识对应的渠道标识文件；

对创建有渠道标识文件的所述目录结构进行打包处理，得到对应所述待发布渠道的渠道包。

第二方面，本发明实施例提供一种应用安装包处理装置，所述装置包括：

获取单元，用于获取应用的安装包、以及所述应用的待发布渠道的渠道标识；

解包单元，用于对应用的安装包进行解包处理，得到所述安装包中的目录结构；

创建单元，用于在所述目录结构中定位用于存储签名信息的签名信息目录，在所述签名信息目录中创建与所述渠道标识对应的渠道标识文件；

打包单元，用于对创建有渠道标识文件的所述目录结构进行打包处理，得到对应所述待发布渠道的渠道包。

本发明实施例具有这样的有益效果：

在安装包的目录结构的签名信息目录中添加文件时，由于没有对目录结构中的其他目录进行修改，而通过在签名信息目录中添加渠道标识文件的方式在安装包中植入渠道信息，既不需要对安装包再次编译，也无需要对安装包再次签名，仅仅涉及安装包的解包和打包操作，从而显著提升了形成渠道包的效率，保证了渠道包在不同渠道的上线效率。

附图说明

图1是本发明实施例中应用安装包处理方法一个可选的流程示意图；

图2是本发明实施例中应用安装包处理装置的一个可选的软硬件结构示意图；

图3-1是本发明实施例中应用安装包处理方法的一个可选的场景示意图；

图3-2是本发明实施例中应用安装包处理方法的一个可选的场景示意图；

图4-1是本发明实施例中应用安装包处理方法的一个可选的流程示意图；

图4-2是本发明实施例中应用安装包处理方法的一个可选的流程示意图；

图4-3是本发明实施例中应用安装包处理方法的一个可选的流程示意图；

图5-1是本发明实施例中用户侧终端安装渠道包的一个可选的操作示意图；

图5-2是本发明实施例中用户向渠道包打包平台上传安装包和渠道标识的一个可选的操作示意图；

图6-1是本发明实施例中渠道包打包的一个可选的技术架构示意图；

图6-2是本发明实施例中安装包解包后一个可选的目录结构的示意图；

图6-3是本发明实施例中在安装包的目录结构中创建有空文件的一个可选的示意图；

图6-4是本发明实施例中对在安装包的目录结构中创建的空文件的名称修改后的一个可选的示意图；

图6-5是本发明实施例中应用安装包处理方法的一个可选的流程示意图；

图7是本发明实施例中应用安装包处理装置的一个可选的结构示意图。

具体实施方式

以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本发明，并不用于限定本发明。另外，以下所提供的实施例是用于实施本发明的部分实施例，而非提供实施本发明的全部实施例，在不冲突的情况下，本发明实施例记载的技术方案可以任意组合的方式实施。

对本发明进行进一步详细说明之前，对本发明实施例中涉及的名词和术语进行说明，本发明实施例中涉及的名词和术语适用于如下的解释。

安装包，用于供终端安装应用以实现相应功能的封装文件，以安卓系统为例，安装包为apk封装格式的文件。

渠道，用户获取应用的安装包的途径。

以安卓为例，包括安卓官方的应用商店、第三方的应用商店，手机厂商自带应用商店和运营商渠道等。

渠道标识，用于唯一标识渠道的信息，如序列号、名称以及二者的组合形式。

渠道包：用户针对同一发布的针对不同的渠道的安装包，安装包中携带渠道的标识。例如，同一版本应用可以发布有对应多个渠道的安装包，也可以发布针对一个渠道的安装包。

发明人在在实施本发明的过程中发现可以使用这样的方式在应用中标识应用来自哪个应用商店(渠道)：

1)针对每个渠道，在应用的源代码结构中植入渠道标识，并进行完全的编译、打包形成安装包。

以安卓应用为例，在基于源代码包的目录结构(把二进制代码)进行编译打包之前，在源代码包的目录结构中的androidmanifest中添加渠道标识，然后，对源代码包进行编译和打包得到渠道包。

以需要得到渠道1至渠道100共计100个渠道的渠道包为例，对于渠道1，在应用的源代码包的目录结构中的androidmanifest中添加渠道1标识，然后，对源代码包的目录结构进行编译打包得到渠道1的渠道包并进行签名，对于渠道2至渠道100进行上述类似的操作，通过100次的编译打包操作，得到对应渠道1至渠道100的渠道包。

2)针对每个渠道，对已有的安装包解包添加渠道标识并重新打包和签名。

仍以安卓应用为例，通过apktool工具进行对已经签名的安装包进行解包，然后修改在安装包的目录结构中androidmanifest的渠道标识，最后再通过apktool在目标结构进行打包和签名。

以需要得到渠道1至渠道100共计100个渠道的渠道包为例，对于渠道1，对应应用的安装包进行解包得到其中的目录结构，在androidmanifest中添加渠道1标识，然后，对安装包的目录结构进行打包得到渠道1的渠道包并进行签名，对于渠道2至渠道100进行上述类似的操作，通过100次的打包和签名操作，得到对应渠道1至渠道100的渠道包。

可以看出，上述方式涉及大量的编译或者签名操作，而目前的渠道数量相当多，用户每发布一个应用的新版本，就需要对应海量的渠道形成渠道包，消耗计算资源、影响应用的新版本的发布效率。

针对上述问题，本发明实施例提供一种应用安装包处理方法，参见图1示出的应用安装包处理方法的一个可选的流程示意图，获取应用的安装包、以及应用的待发布渠道的渠道标识(步骤101)，对应用的安装包进行解包处理，得到安装包中的目录结构(步骤102)；在目录结构中定位用于存储签名信息的签名信息目录，在签名信息目录中创建与渠道标识对应的渠道标识文件(步骤103)；对创建有渠道标识文件的目录结构进行打包处理，得到对应待发布渠道的渠道包(步骤104)；可选地，发布渠道包至相应的渠道(步骤105)。

发明人发现，在安装包的目录结构的签名信息目录中添加文件时，由于没有对目录结构中的其他目录进行修改，因此通过在签名信息目录中添加道标识文件的方式在安装包中携带渠道信息，既不需要对安装包再次编译，也无需要对安装包再次签名，仅仅涉及安装包的解包和打包操作，从而显著提升了形成渠道包的效率，保证了渠道包在不同渠道的上线效率。

本发明实施例还提供用以执行图1示出的应用安装包处理方法的应用安装包处理装置，在硬件层面上，示例性地，应用安装包处理装置可以基于服务器或服务器集群的资源如计算资源(如处理器)和通信资源(如网络接口)实现，在软件层面上，应用安装包处理装置可以实施为存储于服务器或服务器集群的存储介质中的可执行指令(包括诸如程序、模块之类的计算机可执行指令)。

如上所述，以应用安装包处理装置基于服务器或服务器集群资源实现，参见图2示出的应用安装包处理装置14的一个可选的软硬件结构示意图，应用安装包处理装置14包括硬件层、中间层、操作系统层和软件层。然而，本领域的技术人员应当理解，图2示出的应用安装包处理装置14的结构仅为示例，并不构成对应用安装包处理装置14结构的限定。例如，应用安装包处理装置14可以根据实施需要设置较图2更多的组件，或者根据实施需要省略设置部分组件。

应用安装包处理装置14的硬件层包括处理器141、输入/输出接口143，存储介质144以及网络接口142，组件可以经系统总线连接通信。

处理器141可以采用中央处理器(cpu)、微处理器(mcu，microcontrollerunit)、专用集成电路(asic，applicationspecificintegratedcircuit)或逻辑可编程门阵列(fpga，field－programmablegatearray)实现。

输入/输出接口143可以采用如显示屏、触摸屏、扬声器等输入/输出器件实现。

存储介质144可以采用闪存、硬盘、光盘等非易失性存储介质实现，也可以采用双倍率(ddr，doubledatarate)动态缓存等易失性存储介质实现，其中存储有用以执行上述应用安装包处理方法的可执行指令。

示例性地，存储介质144可以与应用安装包处理装置14共同在同一地点设置，也可以相对于应用安装包处理装置14异地远程设置，或者相对应用安装包处理装置14本地和异地分布设置。网络接口142向处理器141提供外部数据如异地设置的存储介质144的访问能力，示例性地，网络接口142可以基于近场通信(nfc，nearfieldcommunication)技术、蓝牙(bluetooth)技术、紫蜂(zigbee)技术进行的近距离通信，另外，还可以实现如基于码分多址(cdma，codedivisionmultipleaccess)、宽带码分多址(wcdma，widebandcodedivisionmultipleaccess)等通信制式及其演进制式的通信。

驱动层包括用于供操作系统146识别硬件层并与硬件层各组件通信的中间件145，例如可以为针对硬件层的各组件的驱动程序的集合。

操作系统146用于提供面向用户的图形界面，示例性地，包括插件图标、桌面背景和应用图标，操作系统146支持用户经由图形界面对应用安装包处理装置14的控制。本发明实施例对上述应用安装包处理装置14的软件环境如操作系统类型、版本不做限定，例如可以是安卓操作系统、ios操作系统、linux操作系统或unix操作系统等。

参见图3-1示出的本发明提供的应用安装包处理方法的一个典型的应用场景进行说明，在图3-1示出的应用安装包处理系统10中，以前述的应用安装包处理装置实施为渠道包打包平台为例12，渠道包打包平台12向开发者11提供图形化的设置界面，支持开发者11上传待发布的应用的安装包，并支持在图形界面中设置需要安装包需要发布的渠道也即应用商店13，渠道包打包平台12基于安装包形成对应对各渠道的渠道包13，发布至相应的渠道。用户侧终端14下载不同渠道的渠道包进行安装，用户侧终端14在安装的渠道包的过程中可以显示渠道的标识以提示安装来源，并且，渠道包打包平台12在用户侧终端14安装渠道包时获取相应的渠道标识，从而可以统计出针对同一应用向不同渠道发布的渠道包的实际安装情况。

再结合图4-1对图3-1示出的应用安装包处理场景的实现过程进行说明。

参见图4-1示出的应用安装包处理方法的一个可选的流程示意图，包括以下步骤：

步骤201，渠道包打包平台加载基于web的图形界面。

供开发者通过基于web的图形界面批量上传安装包、以及批量设置针对安装包待发布的渠道的渠道标识。

步骤202，渠道包打包平台获取用户(如开发者)上传的应用的安装包、以及应用的待发布渠道的渠道标识。

步骤203，渠道包打包平台调用解包工具，对应用的安装包进行解包处理，得到安装包中的目录结构。

示例性地，当应用的安装包为安卓应用的apk包时，由于apk包是一种压缩格式，因此渠道包打包平台对apk包作为压缩包进行解包处理。

步骤204，渠道包打包平台在目录结构中定位用于存储签名信息的签名信息目录。

以安卓应用的安装包为例，其中的签名信息目录的名称为meta-info，相当于一个信息包，其中的文件和子目录获得java2平台的认可与解释，用来配置应用程序、扩展程序、类加载器和服务等。

后续步骤205至步骤208对渠道包打包平台在签名信息目录中创建与渠道标识对应的渠道标识文件的处理进行说明。

对于一个安装包来说，往往需要针对大量的渠道形成相应的渠道包，为了提升形成渠道包的效率，通过构建目录结构的副本，在副本中批量化创建渠道标识文件的方式形成渠道包，步骤205中进行说明。

步骤205，渠道包打包平台创建与待发布渠道数量相应的目录结构的副本。

步骤206，渠道包打包平台在各目录结构的副本的签名信息目录中对应创建与各渠道标识对应的文件。

例如，假设需要形成对应渠道1至渠道100的渠道包，那么对于安装包解包后，形成解包后目录结构的100个副本，在副本中对应创建对应渠道1至100的渠道标识对应的文件。

步骤207，为了进一步提升在签名信息目录中创建与渠道标识对应的文件的效率，对于解包后的各目录结构的副本，渠道包打包平台在签名信息目录中创建以渠道标识命名的空文件。

示例性地，在签名信息目录中创建以特定名称命名的空文件。

步骤208，渠道包打包平台根据渠道标识修改所创建的空文件的名称为与渠道标识对应的名称。

例如，假设需要形成对应渠道1至渠道100的渠道包，那么对于安装包解包后，形成解包后目录结构的100个副本，首先，在100个副本中一次性创建签名信息目录中创建以渠道标识命名的空文件，然后，利用渠道1至渠道100的渠道标识对应修改副本1中副本100中文件的名称，以批量化的方式提升处理效率。

步骤209，渠道包打包平台调用打包工具对创建有渠道标识文件的目录结构进行打包处理，得到对应待发布渠道的渠道包。

示例性地，以安卓的安装包为例，调用apktool工具对解包后的目录结构(创建有与渠道标识对应的空文件)进行打包形成对应相应渠道的渠道包，由于是在签名信息目录植入了渠道标识信息，因此应用的安装包不需要重新进行签名处理。

步骤210，渠道包打包平台发布渠道包至相应的渠道。

示例性地渠道包打包平台通过与各应用商店发布接口传输所对应形成的渠道包，在应用商店上线渠道包。

步骤211，渠道响应于用户侧终端获取渠道包的请求，向用户侧终端发送渠道包，供用户侧终端运行安装渠道包。

需要指出的是，图4-1中以向一个渠道发布渠道包为例并在终端侧运行安装为例说明，对于其他渠道发布渠道包的处理可以参照步骤210和步骤211实施。

在一个实施例中，参见图4-2示出的应用安装包处理方法的一个可选的流程示意图，基于图4-1，在用户侧终端从渠道系下载渠道包之后，还包括以下步骤：

步骤212，用户侧终端运行安装渠道包。

步骤213，渠道包打包平台基于运行安装的渠道包中的渠道标识文件，获取运行的渠道包的渠道标识。

示例性地，渠道包打包平台可以通过java代码(当然，也可以通过其他形式代码如c代码)读取渠道标识文件得到相应的渠道标识，将渠道标识赋值给安装包运行时用于保存渠道标识的变量，从而，用户侧终端运行安装包的过程中，对渠道包的来源渠道进行提示，如图5-1所示，提示用户渠道包的所来源的渠道，如提示用户即将安装的应用来自哪个应用商店，从而供用户决定是否继续安装渠道包，实现提示用户渠道包来源的效果。

在一个实施例中，参见图4-3示出的应用安装包处理方法的一个可选的流程示意图，基于图4-2，在渠道包打包平台获取到用户侧终端运行安装的渠道包的渠道标识以后，还可以包括以下步骤：

步骤214，渠道包打包平台基于不同终端侧安装的渠道包的渠道标识，统计出同一应用在不同渠道的安装分布情况。

用户侧终端在运行渠道包时，向渠道包打包平台上传渠道包的标识，示例性地，参见图3-2，用户侧终端14在运行渠道包时向渠道包打包平台14上传所安装渠道包的应用标识以及渠道标识，渠道包打包平台对不同的渠道包被运行安装的次数以“应用标识-渠道标识-运行安装次数”这样的数据结构在数据库15中存储。渠道包打包平台12基于数据库15中同一应用的不同渠道包被运行安装的次数，形成同一应用在不同渠道的安装分布情况，用于供用户了解在不同渠道发布的渠道包被相应渠道的用户安装的情况，从而实现后续向不同渠道发布渠道包进行优化的效果。

例如，假设用户通过渠道包打包平台向渠道1发布了具有渠道1标识的渠道包，通过渠道包打包平台向渠道2发布了具有渠道2标识的渠道包，用户侧终端在运行渠道包的过程中渠道包打包平台上传应用标识和渠道标识，渠道包打包平台统计出应用的不同渠道包被运行安装的次数，作为后续向渠道发布渠道包的参考，例如，若渠道1的渠道包的运行安装的次数大于渠道2的渠道包被运行安装的次数，则后续可以在渠道1首先发布渠道包，从而使得新版本的应用的普及安装程度。

下面再以安卓应用的安装包为例，对前述记载的形成渠道包的过程进行说明。

参见图6-1示出的渠道包打包的技术方案架构图，在渠道包打包的技术架构中实现渠道包修改引擎的功能，可选地，渠道包修改引擎作为独立于渠道包打包平台的功能实体，或者，作为嵌入到渠道包打包平台的功能实体而使渠道包打包平台集成渠道包修改引擎的功能。

渠道包修改引擎负责将不同渠道的渠道编号添加到apk包，渠道包打包平台集成了渠道包修改引擎，可选地，如图5-2所示，渠道包打包平台向用户提供批量打包渠道包等快捷功能操作界面工具，开发人员在图形界面中可以针对上传一次性对应多个渠道的渠道标识，渠道包打包平台通过集成的渠道包修改引擎对上传的apk添加相应的渠道标识。

本发明实施例中对apk包打包的实现方式是：由于android应用的apk包本身是压缩格式，因此将apk包当作一个压缩文件(如zip文件包)进行解压，在保存签名信息的目录下添加一个空文件，并将空文件用渠道标识(如渠道名称)来命名，由于对签名信息的目录的修改而且不需要重新签名，同时也不涉及对安装包的重新编译等，仅仅通过“解压-添加渠道标识-打包”这样的步骤即可完成批量的渠道包的打包操作，从而明显提升了渠道包批量打包的时间。

结合图6-1至图6-5对渠道包的技术方案的主要流程进行说明。

首先，用户向渠道包打包平台上传apk包和渠道号。由于apk包是一个zip文件，因此渠道包打包平台直接解压apk包，解压后得到的根目录会有一个如图6-2所示的meta-inf目录61，用于存储签名信息。

发明人发现android应用的打包流程有个特点，如果在meta-inf目录内添加空文件，则不需要对安装包重新签名。因此，通过对应不同渠道在eta-inf目录添加对应的空文件，可以在安装包中唯一标识一个渠道。

其次，用脚本向apk包中添加空文件。

渠道包打包平台使用脚本代码来给解压后的apk包添加空文件，空文件的前缀为qqpimsecure。

下面的代码以python脚本为例子说明添加空文件的处理过程：

importzipfilezipped＝zipfile.zipfile(your_apk,'a',zipfile.zip_deflated)

empty_channel_file＝

"meta-inf/qqpimsecure_{channel}".format(channel＝your_channel)

zipped.write(your_empty_file,empty_channel_file)

添加完空渠道文件后的目录，meta-info目录多了一个如图6-3所示的名为qqpimsecure_123的空文件62。

其次，替换空文件的名称为目标渠道的渠道号。

替换后的安装包的结构如图6-4所示，比如要发布的渠道包的渠道号为：123456789，则把空文件qqpimsecure_123的文件名字修改为：qqpimsecure_12345678963，对根目录结构打包形成新的apk包(也称为对应渠道123456789的渠道包)，至此完成一个渠道包的打包流程。

再次，apk包运行时动态读取并设置渠道号。

apk包在用户侧终端运行时，渠道包打包平台通过java代码、c代码、python代码等形式代码读取meta-inf目录下面的渠道号文件，并把渠道号赋值给程序里面的保存渠道号的变量，从而，在程序运行时设置安装包的渠道号。

上述流程的所有功能都可以集成到渠道包修改引擎，由渠道包打包平台通过调用渠道包修改引擎而完成上述的渠道包打包处理。

渠道包打包平台在本发明实施例中实施为基于web的在线打包系统，集成了渠道包修改引擎，为打包提供良好的界面交互，用户只要上传apk包，设置好对应的渠道号，渠道包打包平台即可快速形成对应不同渠道的渠道包。

对前述应用安装包处理装置的逻辑功能结构进行说明，参见图7示出的应用安装包处理装置70的一个可选的结构示意图，包括：

获取单元71，用于获取应用的安装包、以及应用的待发布渠道的渠道标识；

解包单元72，用于对应用的安装包进行解包处理，得到安装包中的目录结构；

创建单元73，用于在目录结构中定位用于存储签名信息的签名信息目录，在签名信息目录中创建与渠道标识对应的渠道标识文件；

打包单元74，用于对创建有渠道标识文件的目录结构进行打包处理，得到对应待发布渠道的渠道包；

发布单元75，用于发布渠道包至相应的渠道。

在一个实施例中，创建单元73，还用于创建与待发布渠道数量相应的目录结构的副本，在各目录结构的副本的签名信息目录中对应创建与各渠道标识对应的文件。

在一个实施例中，创建单元73，还用于在签名信息目录中创建以渠道标识命名的空文件。

在一个实施例中，创建单元73，还用于在签名信息目录中创建以特定名称命名的空文件，并根据渠道标识修改所创建的空文件的名称为与渠道标识对应的名称。

在一个实施例中，获取单元71，还用于在渠道包被终端侧运行时，基于运行的安装包中的渠道标识文件获取运行的渠道包的渠道标识。

在一个实施例中，获取单元71，还用于通过java代码读取渠道标识文件得到相应的渠道标识，将渠道标识赋值给安装包运行时用于保存渠道标识的变量。

在一个实施例中，装置还包括：

统计单元76，用于基于不同终端侧安装的渠道包的渠道标识，统计出同一应用在不同渠道的安装分布情况。

实际应用中，图7示出各单元可由图2中示出的硬件层的硬件资源实现，例如获取单元71可由网络接口142实现，解包单元72、创建单元73和打包单元75可由处理器141通过执行存储介质144中可执行指令而实现。

综上所述，本发明实施例具有以下有益效果：

1)在安装包的目录结构的签名信息目录中添加文件时，由于没有对目录结构中的其他目录进行修改，而通过在签名信息目录中添加渠道标识文件的方式在安装包中携带渠道信息，即不需要对安装包再次编译，也无需要对安装包再次签名，仅仅涉及安装包的解包和打包操作，从而显著提升了形成渠道包的效率，保证了渠道包在不同渠道的上线效率。

2)提示用户渠道包的所来源的渠道，如提示用户即将安装的应用来自哪个应用商店，从而供用户决定是否继续安装渠道包，实现提示用户渠道包来源的效果。

3)形成同一应用在不同渠道的安装分布情况，用于供用户了解在不同渠道发布的渠道包被相应渠道的用户安装的情况，从而实现对后续向不同渠道发布渠道包进行优化的效果。

本领域的技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储装置、随机存取存储器(ram，randomaccessmemory)、只读存储器(rom，read-onlymemory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。