应用程序的热修复方法及终端与流程

本发明属于信息技术领域，尤其涉及一种应用程序的热修复方法及终端。

背景技术：

Android APP在释放一个版本之后，经常会遇到由于用户投诉或者严重bug而需要对所述APP进行修复的情况。现有的修复过程包括：1.开发者修改现有版本的APP，编译、打包生成升级包，测试以及发布新版本的升级包；2.用户设备提示用户下载升级包，并根据用户操作下载升级包以及安装、覆盖现有版本。有时候开发者仅仅修改了一行代码，也需要对整个APP进行编译打包，以及进行发布宣传和提示操作，开发者侧的修复成本高；而在用户侧，则需要用户手动下载升级包、手动进行安装，过程繁琐，有时候安装过程甚至会中断用户的当前业务。

技术实现要素：

鉴于此，本发明实施例提供一种应用程序的热修复方法及终端，以降低应用程序的修复成本，简化应用程序的修复操作。

第一方面，提供了一种应用程序的热修复方法，所述热修复方法包括：

第一终端将预设应用的修复代码打包生成热修复补丁包，然后将所述热修复补丁包下发至已安装所述预设应用的第二终端；

所述第二终端接收并保存所述热修复补丁包，当所述预设应用启动时，加载所述热修复补丁包，对所述预设应用进行热修复。

进一步地，所述第一终端将预设应用的修复代码打包生成热修复补丁包包括：

所述第一终端对所述预设应用的已修复版本中的每一个类进行哈希运算，得到第一哈希文件；

将所述第一哈希文件与所述预设应用的未修复版本的第二哈希文件进行比对，得到修复后的类并生成所述类的class文件；

根据所述class文件生成dex文件，并将所述dex文件打包为热修复补丁包。

进一步地，所述第一终端将预设应用的修复代码打包生成热修复补丁包包括：

所述第一终端保存所述预设应用的未修复版本中class文件的消息摘要信息，使用未修复版本的mapping文件来编译已修复版本,生成消息摘要信息；

将编译后的所述消息摘要信息与所述预设应用的已修复版本中class文件的消息摘要信息进行比对，得到修复后的class文件；

根据所述修复后的class文件生成dex文件，并将所述dex文件打包为热修复补丁包。

进一步地，所述当所述预设应用启动时，加载所述热修复补丁包，对所述预设应用进行热修复包括：

在所述预设应用启动时，将所述热修复补丁包写入到所述预设应用的私有目录文件中；

从所述热修复补丁包的dex文件中获取第一dexElements数组，以及从所述预设应用的未修复版本中获取第二dexElements数组；

拼接所述第一dexElements数组和第二dexElements数组，得到第三dexElements数组，并将所述dex文件插入至所述第三dexElements数组的首位；

将所述第三dexElements数组通过反射的方式设置给热修复补丁列表再赋值回类加载器，以使得所述类加载器载入所述dex文件。

第二方面，提供了一种终端，所述终端包括：

生成模块，用于将预设应用的修复代码打包生成热修复补丁包；

下发模块，用于将所述热修复补丁包下发至已安装所述预设应用的第二终端，以使得所述第二终端在所述预设应用启动时加载所述热修复补丁包并对所述预设应用进行热修复。

进一步地，所述生成模块包括：

运算单元，用于对所述预设应用的已修复版本中的每一个类进行哈希运算，得到第一哈希文件；

第一比对单元，用于将所述第一哈希文件与所述预设应用的未修复版本的第二哈希文件进行比对，得到修复后的类并生成所述类的class文件；

第一打包单元，用于根据所述class文件生成dex文件，并将所述dex文件打包为热修复补丁包。

进一步地，所述生成模块包括：

编译单元，用于保存所述预设应用的未修复版本中class文件的消息摘要信息，使用未修复版本的mapping文件来编译已修复版本,生成消息摘要信息；

第二比对单元，用于将编译后的所述消息摘要信息与所述预设应用的已修复版本中class文件的消息摘要信息进行比对，得到修复后的class文件；

第二打包单元，用于根据所述修复后的class文件生成dex文件，并将所述dex文件打包为热修复补丁包。。

第三方面，提供了一种终端，所述终端包括：

接收模块，用于接收并保存第一终端下发的热修复补丁包；

修复模块，用于当所述预设应用启动时，加载所述热修复补丁包，对所述预设应用进行热修复。

进一步地，所述修复模块包括：

写入单元，用于在所述预设应用启动时，将所述热修复补丁包写入到所述预设应用的私有目录文件中；

获取单元，用于从所述热修复补丁包的dex文件中获取第一dexElements数组，以及从所述预设应用的未修复版本中获取第二dexElements数组；

拼接单元，用于拼接所述第一dexElements数组和第二dexElements数组，得到第三dexElements数组，并将所述dex文件插入至所述第三dexElements数组的首位；

修复单元，用于将所述第三dexElements数组通过反射的方式设置给热修复补丁列表再赋值回类加载器，以使得所述类加载器载入所述dex文件。

与现有技术相比，本发明实施例由第一终端将预设应用的修复代码打包生成热修复补丁包，然后将所述热修复补丁包下发至已安装所述预设应用的第二终端；所述第二终端接收并保存所述热修复补丁包，当所述预设应用启动时，则加载所述热修复补丁包，对所述预设应用进行热修复；从而实现了对异常应用程序的热修复，整个修复过程动态静默执行，无需用户进行任何操作，极大地简化了应用程序的修复操作，也无需中断用户的当前业务，提升了用户体验感；且本发明只对发生异常的地方进行修复，有效地降低了版本发布和升级的成本，修复效率高。

附图说明

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

图1是本发明实施例提供的应用程序的热修复系统的组成结构图；

图2是本发明实施例提供的应用程序的热修复方法的实现流程图；

图3是本发明实施例提供的应用程序的热修复方法中步骤S101的具体实现流程图；

图4是本发明另一实施例提供的应用程序的热修复方法中步骤S101的具体实现流程图；

图5是本发明实施例提供的应用程序的热修复方法中步骤S103的实现流程图；

图6是本发明实施例提供的第三dexElements数组的结构示意图；

图7是本发明实施例提供的终端的组成结构图；

图8是本发明另一实施例提供的终端的组成结构图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明实施例由第一终端将预设应用的修复代码打包生成热修复补丁包，然后将所述热修复补丁包下发至已安装所述预设应用的第二终端；所述第二终端接收并保存所述热修复补丁包，当所述预设应用启动时，则加载所述热修复补丁包，对所述预设应用进行热修复；从而实现了对异常应用程序的热修复，整个修复过程动态静默执行，无需用户进行任何操作，极大地简化了应用程序的修复操作，也无需中断用户的当前业务，提升了用户体验感；且本发明只对发生异常的地方进行修复，有效地降低了版本发布和升级的成本，修复效率高。本发明实施例还提供了相应的终端，以下分别进行详细的说明。

图1示出了本发明实施例提供的应用程序的热修复系统的组成结构，为了便于说明，仅示出了与本发明实施例相关的部分。

在本发明实施例中，所述应用程序的热修复系统包括开发人员侧的第一终端1和用户侧的至少一个第二终端2，所述第一终端1与所述第二终端2之间通过有线或者无线的方式连接通信。所述第一终端1包括但不限于服务器、电脑等计算机设备，所述第二终端2包括但不限于智能手机、平板电脑、电视机、智能穿戴设备、音乐播放设备(比如MP4)等用户设备。

在本发明实施例中，所述第一终端1用于根据开发人员的操作，将预设应用的修复代码打包生成热修复补丁包，并将所述热修复补丁包下发至已安装所述预设应用的第二终端2。

所述第二终端2接收并保存所述热修复补丁包，当所述预设应用启动时，则加载所述热修复补丁包，对所述预设应用进行热修复。

进一步地，所述第一终端1包括：

生成模块11，用于将预设应用的修复代码打包生成热修复补丁包；

下发模块12，用于将所述热修复补丁包下发至已安装所述预设应用的第二终端，以使得所述第二终端在所述预设应用启动时加载所述热修复补丁包并对所述预设应用进行热修复。

作为本发明的一个优选示例，所述生成模块11具体包括：

运算单元111，用于对所述预设应用的已修复版本中的每一个类进行哈希运算，得到第一哈希文件；

第一比对单元112，用于将所述第一哈希文件与所述预设应用的未修复版本的第二哈希文件进行比对，得到修复后的类并生成所述类的class文件；

第一打包单元113，用于根据所述class文件生成dex文件，并将所述dex文件打包为热修复补丁包。

在这里，所述未修复版本和已修复版本都是针对所述预设应用来定义的，所述未修复版本是指存在问题待修复的当前线上版本，所述已修复版本是指问题已修复完毕的将要发布的版本。

对于普通代码，本发明实施例首先遍历所述预设应用已修复版本中的全部类，对每个类进行哈希运算，即hash运算，并将运算结果写入到所述已修复版本对应的hashFile中，得到第一哈希文件。然后比较所述第一哈希文件与所述预设应用的未修复版本对应的第二哈希文件，得到所有发生过修复的类，并生成所述类的class文件；最后将所述class文件转换成dex文件，并将所述dex文件打包为热修复补丁包，从而完成对普通代码的热修复补丁包的制作。

作为本发明的另一个优选示例，所述生成模块11还可以包括：

编译单元114，用于保存所述预设应用的未修复版本中class文件的消息摘要信息，使用未修复版本的mapping文件来编译已修复版本,生成消息摘要信息；

第二比对单元115，用于将编译后的所述消息摘要信息与所述预设应用的已修复版本中class文件的消息摘要信息进行比对，得到修复后的class文件；

第二打包单元116，用于根据所述修复后的class文件生成dex文件，并将所述dex文件打包为热修复补丁包。

在这里，对于混淆代码，本发明实施例首先保存未修复版本中所有的class文件的消息摘要信息。其中，所述消息摘要信息可选为MD5信息，即通过消息摘要算法第五版(Message Digest Algorithm MD5)算出的摘要信息。然后使用已修复版本的mapping文件进行编译，将编译后的所述消息摘要信息与已修复版本的消息摘要信息进行比对，取出已修复版本中与未修复版本中不相同的class文件，得到修复后的class文件。最后将所述class文件转换成dex文件，并将所述dex文件打包为热修复补丁包，从而完成对混淆代码的热修复补丁包的制作。

示例性地，所述dex文件为patch.dex文件，所述热修复补丁包为patch_dex.jar或者patch_dex.apk文件，因此可以使用dx工具，将所述class文件转换成patch.dex，然后将所述patch.dex打包成patch_dex.jar或者patch_dex.apk文件，从而完成热修复补丁包的制作。

进一步地，所述第二终端2具体包括：

接收模块21，用于接收并保存第一终端下发的热修复补丁包；

修复模块22，用于当所述预设应用启动时，加载所述热修复补丁包，对所述预设应用进行热修复。

进一步地，所述修复模块22包括：

写入单元221，用于在所述预设应用启动时，将所述热修复补丁包写入到所述预设应用的私有目录文件中；

获取单元222，用于从所述热修复补丁包的dex文件中获取第一dexElements数组，以及从所述预设应用的未修复版本中获取第二dexElements数组；

拼接单元223，用于拼接所述第一dexElements数组和第二dexElements数组，得到第三dexElements数组，并将所述dex文件插入至所述第三dexElements数组的首位；

修复单元224，用于将所述第三dexElements数组通过反射的方式设置给热修复补丁列表再赋值回类加载器，以使得所述类加载器载入所述dex文件。

在这里，本发明实施例中，所述第一终端1下发热修复补丁包至所述预设应用后，所述预设应用将所述热修复补丁包存储在所述第二终端2的指定路径下。当所述预设应用启动时，所述第二终端2将所述热修复补丁包写入到预设应用的私有目录中的文件夹里，并对所述热修复补丁包进行解析获取dex文件，从所述dex文件中获取第一dexElements数组，以及从未修复版本中获取第二dexElements数组。将所述第一dexElements数组和第二dexElements数组拼接，得到第三dexElements数组，并将所述dex文件置于所述第三dexElements数组的首位，最后将所述第三dexElements数组通过反射的方式设置给热修复补丁列表再赋值回类加载器。所述类加载器在遍历PathList时则首先载入放置在所述第三dexElements数组第一位上的dex文件，所述dex文件里面包含了修复后的class文件。对于所述第三dexElements数组后面dex文件中相同类的class文件，所述类加载器将不再加载。在所述预设应用运行findclass时，则查找并执行修复后的class文件，未修复的class文件不再执行，从而完成对所述预设应用的异常修复。整个修复过程动态静默执行，无需用户进行任何操作，也无需中断用户当前业务，极大地提升了用户体验感；且本发明只对发生异常的地方进行修复，有效地降低了发布和升级成本，修复效率高。

图2示出了本发明实施例提供的应用程序的热修复方法的实现流程。

在本发明实施例中，所述应用程序的热修复方法应用于上述图1实施例中所述的应用程序的热修复系统。

参阅图2，所述应用程序的热修复方法包括：

在步骤S201中，第一终端将预设应用的修复代码打包生成热修复补丁包。

在本发明实施例中，第一终端为开发者侧的计算机设备，包括但不限于服务器、电脑等。所述第一终端通过比对所述预设应用的已修复版本和未修复版本得到所述修复代码。其中，所述未修复版本和已修复版本都是针对所述预设应用来定义的，所述未修复版本是指存在问题待修复的当前线上版本，所述已修复版本是指问题已修复完毕的将要发布的版本。

可选地，所述修复代码包括普通代码，所述普通代码未与未修复版本中的原有代码混淆。对于此类修复代码，本发明实施例通过比较未修复版本和已修复版本的哈希文件来获取。图3示出了本发明实施例提供的应用程序的热修复方法中步骤S201的实现流程。

参阅图3，所述步骤S201包括：

在步骤S301中，所述第一终端对所述预设应用的已修复版本中的每一个类进行哈希运算，得到第一哈希文件。

在步骤S302中，将所述第一哈希文件与所述预设应用的未修复版本的第二哈希文件进行比对，得到修复后的类并生成所述类的class文件。

在步骤S303中，根据所述class文件生成dex文件，并将所述dex文件打包为热修复补丁包。

在这里，对于普通代码，本发明实施例首先遍历已修复版本中的全部类，对每个类进行哈希运算，即hash运算，并将运算结果写入到所述已修复版本对应的hashFile中，得到第一哈希文件。然后比较所述第一哈希文件与未修复版本对应的第二哈希文件，得到所有发生过修复的类，并生成所述类的class文件；最后将所述class文件转换成dex文件，并将所述dex文件打包为热修复补丁包，从而完成对普通代码的热修复补丁包的制作。

可选地，所述修复代码还包括混淆代码，所述混淆代码与未修复版本中的原有代码混淆。对于此类修复代码，本发明实施例通过比较未修复版本和已修复版本中所有class文件的消息摘要信息来获取。图4示出了本发明实施例提供的应用程序的热修复方法中步骤S201的实现流程。

参阅图4，所述步骤S201包括：

在步骤S401中，所述第一终端保存所述预设应用的未修复版本中class文件的消息摘要信息，使用未修复版本的mapping文件来编译已修复版本,生成消息摘要信息。

在步骤S402中，将编译后的所述消息摘要信息与所述预设应用的已修复版本中class文件的消息摘要信息进行比对，得到修复后的class文件。

在步骤S403中，根据所述修复后的class文件生成dex文件，并将所述dex文件打包为热修复补丁包。

对于混淆代码，本发明实施例首先保存未修复版本中所有的class文件的消息摘要信息。其中，所述消息摘要信息可选为MD5信息，即通过消息摘要算法第五版(Message Digest Algorithm MD5)算出的摘要信息。然后使用已修复版本的mapping文件对所述未修复版本的消息摘要信息进行编译，将编译后的所述消息摘要信息与已修复版本的消息摘要信息进行比对，取出已修复版本与未修复版本中不相同的class文件，得到修复后的class文件。最后将该修复后的class文件转换为dex文件，并将所述dex文件打包为热修复补丁包，从而完成对混淆代码的热修复补丁包的制作。

示例性地，所述dex文件为patch.dex文件，所述热修复补丁包为patch_dex.jar或者patch_dex.apk文件，因此可以使用dx工具，将所述class文件转换成patch.dex，然后将所述patch.dex打包成patch_dex.jar或者patch_dex.apk文件。

综合上述图3和图4示例，可见本发明实施例只对发生异常的地方进行修复，只对修复代码进行打包生成热修复补丁包，极大地简化了热修复补丁包的制作过程，有效地降低了版本发布和升级成本。

在步骤S202中，所述第一终端将所述热修复补丁包下发至已安装所述预设应用的第二终端。

在这里，制作好的热修复补丁包，可以通过预设的推送协议框架下发至第二终端。所述预设的推送协议框架包括但不限于比如可扩展通讯和表示协议(Extensible Messaging and Presence Protocol，简称XMPP)或者云到端消息框架(Android Cloud to Device Messaging，简称C2DM)等。

在步骤S203中，所述第二终端接收并保存所述热修复补丁包，当所述预设应用启动时，加载所述热修复补丁包，对所述预设应用进行热修复。

在这里，第二终端接收第一终端下发的热修复补丁包，并存储在指定路径下，以供所述预设应用启动时加载。图5示出了本发明实施例提供的应用程序的热修复方法中步骤S203的具体实现流程。

参阅图5，所述步骤S203包括：

在步骤S501中，在所述预设应用启动时，将所述热修复补丁包写入到所述预设应用的私有目录文件中。

在步骤S502中，从所述热修复补丁包的dex文件中获取第一dexElements数组，以及从所述预设应用的未修复版本中获取第二dexElements数组。

在步骤S503中，拼接所述第一dexElements数组和第二dexElements数组，得到第三dexElements数组，并将所述dex文件插入至所述第三dexElements数组的首位。

示例性地，图6示给出了本发明实施例提供的第三dexElements数组的结构示意图。

在步骤S504中，将所述第三dexElements数组通过反射的方式设置给热修复补丁列表再赋值回类加载器，以使得所述类加载器载入所述dex文件。

在这里，所述类加载器为ClassLoader。在所述第三dexElements数组赋值给类加载器之后，所述类加载器在遍历热修复补丁列表PathList时则首先载入放置在所述第三dexElements数组第一位上的dex文件，所述dex文件里面包含了修复后的class文件。对于所述第三dexElements数组后面dex文件中相同类的class文件，所述类加载器将不再加载。在所述预设应用运行findclass时，则查找并执行修复后的class文件，未修复的class文件不再执行，从而完成对所述预设应用的异常修复。整个修复过程动态静默执行，无需用户进行任何操作，也无需中断用户当前的业务，极大地提升了用户体验感；且本发明只对发生异常的地方进行修复，有效地降低了发布和升级成本，修复效率高。

本发明实施例由第一终端将预设应用的修复代码打包生成热修复补丁包，然后将所述热修复补丁包下发至已安装所述预设应用的第二终端；所述第二终端接收并保存所述热修复补丁包，当所述预设应用启动时，则加载所述热修复补丁包，对所述预设应用进行热修复；从而实现了对异常应用程序的热修复，整个修复过程动态静默执行，无需用户进行任何操作，极大地简化了应用程序的修复操作，也无需中断用户的当前业务，提升了用户体验感；且本发明只对发生异常的地方进行修复，有效地降低了版本发布和升级的成本，修复效率高。

图7示出了本发明实施例提供的终端的组成结构，为了便于说明，仅示出了与本发明实施例相关的部分。

在本发明实施例中，所述终端用于实现上述图1至图5实施例中所述的开发者侧的第一终端1的功能，所述终端包括但不限于电脑、服务器等计算机设备。

参阅图7，所述终端包括：

生成模块11，用于将预设应用的修复代码打包生成热修复补丁包；

下发模块12，用于将所述热修复补丁包下发至已安装所述预设应用的第二终端，以使得所述第二终端在所述预设应用启动时加载所述热修复补丁包并对所述预设应用进行热修复。

进一步地，作为本发明的一个优选示例，所述生成模块11包括：

运算单元111，用于对所述预设应用的已修复版本中的每一个类进行哈希运算，得到第一哈希文件。

第一比对单元112，用于将所述第一哈希文件与所述预设应用的未修复版本的第二哈希文件进行比对，得到修复后的类并生成所述类的class文件。

第一打包单元113，用于根据所述class文件生成dex文件，并将所述dex文件打包为热修复补丁包。

进一步地，作为本发明的另一个优选示例，所述生成模块11还包括：

编译单元114，用于保存所述预设应用的未修复版本中class文件的消息摘要信息，使用未修复版本的mapping文件来编译已修复版本,生成消息摘要信息。

第二比对单元115，用于将编译后的所述消息摘要信息与所述预设应用的已修复版本中class文件的消息摘要信息进行比对，得到修复后的class文件。

第二打包单元116，用于根据所述修复后的class文件生成dex文件，并将所述dex文件打包为热修复补丁包。

图8示出了本发明实施例提供的终端的组成结构，为了便于说明，仅示出了与本发明实施例相关的部分。

在本发明实施例中，所述终端用于实现上述图1至图5实施例中所述的用户侧的第二终端2的功能，所述终端包括但不限于智能手机、平板电脑、电视机、播放器等智能设备。

参阅图8，所述终端包括：

接收模块21，用于接收并保存第一终端下发的热修复补丁包。

修复模块22，用于当所述预设应用启动时，加载所述热修复补丁包，对所述预设应用进行热修复。

进一步地，所述修复模块22包括：

写入单元221，用于在所述预设应用启动时，将所述热修复补丁包写入到所述预设应用的私有目录文件中。

获取单元222，用于从所述热修复补丁包的dex文件中获取第一dexElements数组，以及从所述预设应用的未修复版本中获取第二dexElements数组。

拼接单元223，用于拼接所述第一dexElements数组和第二dexElements数组，得到第三dexElements数组，并将所述dex文件插入至所述第三dexElements数组的首位。

修复单元224，用于将所述第三dexElements数组通过反射的方式设置给热修复补丁列表再赋值回类加载器，以使得所述类加载器载入所述dex文件。

需要说明的是，本发明实施例中的系统可以用于实现上述方法实施例中的全部技术方案，其各个功能模块的功能可以根据上述方法实施例中的方法具体实现，其具体实现过程可参照上述实例中的相关描述，此处不再赘述。

综上所述，本发明实施例由第一终端将预设应用的修复代码打包生成热修复补丁包，然后将所述热修复补丁包下发至已安装所述预设应用的第二终端；所述第二终端接收并保存所述热修复补丁包，当所述预设应用启动时，则加载所述热修复补丁包，对所述预设应用进行热修复；从而实现了对异常应用程序的热修复，整个修复过程动态静默执行，无需用户进行任何操作，极大地简化了应用程序的修复操作，也无需中断用户的当前业务，提升了用户体验感；且本发明只对发生异常的地方进行修复，有效地降低了版本发布和升级的成本，修复效率高。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

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

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

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

另外，在本发明各个实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元、模块单独物理存在，也可以两个或两个以上单元、模块集成在一个单元中。

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

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