补丁生成方法及装置、更新方法、电子设备、存储介质与流程

本公开涉及计算机技术领域，尤其涉及一种补丁生成方法及装置、补丁更新方法、电子设备、以及计算机可读存储介质。

背景技术：

patch(补丁)技术是指应用程序客户端在更新应用程序内容时，不需要重新下载安装客户端，只需更新本地机器上需要的程序代码和程序资源的技术。patch技术广泛的应用于当前主流应用平台的各类应用程序例如网络游戏中，其中的应用平台例如包括ios、android等移动平台以及windows等pc(personalconputer，个人计算机)平台。

根据patch的策略可将其分为增量patch和全量patch。

所谓增量patch是指：应用程序客户端首次下载安装完应用程序后，记录当前的应用程序内容为v；每当需要应用程序客户端对应用程序进行更新时，便会在服务器端上传相对于上一版本的所有变化内容p，该变化内容p即为增量patch；根据增量patch的版本号分别记录变化内容p1、变化内容p2、……、以及变化内容pn；当应用程序客户端在更新到最新版本时，需要按照版本号的顺序逐个下载所有的增量patch，方可得到最新的应用程序内容vn，即vn＝v+p1+p2+……+pn。增量patch可以支持将patch内容压缩成一个大文件并上传到服务器端，之后在应用程序客户端本地解压。

所谓全量patch是指：当应用程序客户端需要对应用程序进行更新时，在服务器端上传最新的应用程序内容vn；应用程序客户端在下载patch时，只需对比本地的应用程序内容vm与最新的应用程序内容vn之间的差别，并下载其中变化的部分，以使应用程序客户端的应用程序内容更新到最新版本。全量patch要求服务器端与应用程序客户端之间的应用程序内容比对精确到文件级，即要求能够比对应用程序内容中的每一个文件是否有更新。

目前许多应用程序引擎在进行补丁更新时都选用全量patch，但其存在占用空间较大以及耗时较多等问题。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本公开的目的在于提供一种补丁生成方法及装置、补丁更新方法、电子设备、以及计算机可读存储介质，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种补丁生成方法，用于为一应用程序生成补丁；所述补丁生成方法包括：

对原始资源文件进行加密和压缩以得到标准资源文件；

自所述标准资源文件中获取通用于不同终端类型的共用资源文件并配置于共用资源目录下；

对于每一所述终端类型，自所述标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下；

其中，任一所述终端类型对应的补丁包括所述共用资源目录下的共用资源文件以及对应该终端类型的专用资源目录下的专用资源文件。

本公开的一种示例性实施例中，所述不同终端类型包括对应第一应用平台的第一终端、对应第二应用平台的第二终端、以及对应第三应用平台的第三终端；

其中，自所述标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下包括：

自所述标准资源文件中获取适用于所述第一终端的第一专用资源文件并将所述第一专用资源文件配置于对应所述第一终端的第一专用资源目录下；

自所述标准资源文件中获取适用于所述第二终端的第二专用资源文件并将所述第二专用资源文件配置于对应所述第二终端的第二专用资源目录下；

自所述标准资源文件中获取适用于所述第三终端的第三专用资源文件并将所述第三专用资源文件配置于对应所述第三终端的第三专用资源目录下。

本公开的一种示例性实施例中，所述第一终端为运行ios系统的终端，所述第二终端为运行android系统的终端，所述第三终端为运行windows系统的终端。

本公开的一种示例性实施例中，所述不同终端类型包括对应第一硬件配置的第一终端、对应第二硬件配置的第二终端、以及对应第三硬件配置的第三终端；

其中，自所述标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下包括：

自所述标准资源文件中获取适用于所述第一终端的第一专用资源文件并将所述第一专用资源文件配置于对应所述第一终端的第一专用资源目录下；

自所述标准资源文件中获取适用于所述第二终端的第二专用资源文件并将所述第二专用资源文件配置于对应所述第二终端的第二专用资源目录下；

自所述标准资源文件中获取适用于所述第三终端的第三专用资源文件并将所述第三专用资源文件配置于对应所述第三终端的第三专用资源目录下。

本公开的一种示例性实施例中，将原始资源文件进行加密和压缩以得到标准资源文件包括：

根据基准格式将脚本文件、美术资源文件、以及引擎配置文件进行加密和压缩，以得到所述标准资源文件；

其中，所述基准格式为所述应用程序的开发引擎所支持的文件格式。

本公开的一种示例性实施例中，自所述标准资源文件中获取通用于不同终端类型的共用资源文件包括：

自所述标准资源文件中获取所述脚本文件、所述引擎配置文件、以及所述美术资源文件中的场景文件和骨骼动作文件。

本公开的一种示例性实施例中，所述补丁生成方法还包括：

将所述补丁与服务器端存储的历史补丁进行对比，以获取所述补丁相对于所述历史补丁的增量补丁以及相同部分；

将所述增量补丁上传至所述服务器，并针对所述相同部分生成一指向所述服务器端存储的历史补丁的记录标识。

根据本公开的一个方面，提供一种补丁更新方法，所述补丁更新方法包括：

获取根据上述补丁生成方法而生成的补丁；

将获取到的所述补丁与本地内容进行对比，以获取待更新内容；

自所述补丁相对于服务器端存储的历史补丁的增量补丁中下载所述待更新内容的部分或全部；

在所述增量补丁中未完全包括所述待更新内容时，根据指向所述服务器端存储的历史补丁的记录标识自所述历史补丁中下载所述待更新内容的剩余部分。

根据本公开的一个方面，提供一种补丁生成装置，用于为一应用程序生成补丁；所述补丁生成装置包括：

加密压缩模块，用于对原始资源文件进行加密和压缩以得到标准资源文件；

共用资源模块，用于自所述标准资源文件中获取通用于不同终端类型的共用资源文件并配置于共用资源目录下；

专用资源模块，用于对于每一所述终端类型，自所述标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下；

其中，任一所述终端类型对应的补丁包括所述共用资源目录下的共用资源文件以及对应该终端类型的专用资源目录下的专用资源文件。

根据本公开的一个方面，提供一种电子设备，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行上述的补丁生成方法或者上述的补丁更新方法。

根据本公开的一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的补丁生成方法或者上述的补丁更新方法。

本公开示例性实施方式所提供的补丁生成方法及装置、补丁更新方法、电子设备、以及计算机可读存储介质，根据应用程序所使用的资源类型的不同而将所生成的补丁配置于不同的资源目录下。这样一来，通过将各个终端类型均适用的资源文件配置于一共用资源目录下，同时将针对特定终端类型的资源文件配置于对应的专用资源目录下，即可避免通用类补丁的重复生成，从而达到减少补丁生成耗时以及节约占用空间的效果；在此基础上，由于针对各个终端类型均生成了对应的资源文件，即对应各个终端类型均生成有对应的补丁，因此本实施方式可同时适用于不同的终端类型。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开示例性实施例中补丁生成方法的流程图一；

图2示意性示出本公开示例性实施例中补丁生成方法的架构图；

图3示意性示出本公开示例性实施例中补丁存储目录的示意图；

图4示意性示出本公开示例性实施例中补丁生成方法的流程图二；

图5示意性示出本公开示例性实施例中补丁生成及更新方法的示意图；

图6示意性示出本公开示例性实施例中补丁更新方法的流程图；

图7示意性示出本公开示例性实施例中补丁生成装置的示意框图；

图8示意性示出本公开示例性实施例中电子设备的模块示意图；

图9示意性示出本公开示例性实施例中程序产品的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

本示例实施方式提出了一种补丁生成方法，用于为一应用程序生成补丁；如图1所示，所述补丁生成方法可以包括：

s1、对原始资源文件进行加密和压缩以得到标准资源文件；

s2、自标准资源文件中获取通用于不同终端类型的共用资源文件并配置于共用资源目录下；

s3、对于每一终端类型，自标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下。

其中，任一终端类型对应的补丁包括共用资源目录下的共用资源文件以及对应该终端类型的专用资源目录下的专用资源文件。

需要说明的是：本示例实施方式中的应用程序具体可以为软件程序或者游戏程序等。

本公开示例性实施方式所提供的补丁生成方法，根据应用程序所使用的资源类型的不同而将所生成的补丁配置于不同的资源目录下。这样一来，通过将各个终端类型均适用的资源文件配置于一共用资源目录下，同时将针对特定终端类型的资源文件配置于对应的专用资源目录下，即可避免通用类补丁的重复生成，从而达到减少补丁生成耗时以及节约占用空间的效果；在此基础上，由于针对各个终端类型均生成了对应的资源文件，即对应各个终端类型均生成有对应的补丁，因此本实施方式可同时适用于不同的终端类型。

下面结合附图对本示例实施方式中的补丁生成方法进行详细的说明。

在步骤s1中，对原始资源文件进行加密和压缩以得到标准资源文件。

本示例实施方式中，所述原始资源文件是指应用程序开发者提供的资源文件，其具体可以包括：脚本文件、美术资源文件、以及引擎配置文件；其中的美术资源文件可以包括：模型、贴图、骨骼动作、物理、场景、ui(userinterface，用户界面)、声音等。所述标准资源文件是指采用基准格式的资源文件，该基准格式即为应用程序的开发引擎所支持的文件格式。

基于此，本步骤中对原始资源文件进行加密和压缩以得到标准资源文件具体可以包括：根据基准格式将脚本文件、美术资源文件、以及引擎配置文件进行加密和压缩，以得到所述标准资源文件。

举例来说，本实施例中的补丁生成方法可用于为一网络游戏应用程序生成补丁，根据游戏客户端所使用的游戏引擎可将patch分为不同的类别，例如cocos引擎的patch系统以及unity3d引擎的patch系统，这是由于不同的游戏引擎使用不同的脚本语言和文件系统、设有不同的接口、以及适用于不同的游戏平台，因此patch系统需要对不同的游戏引擎进行相应的适配。

以一游戏引擎为例，如图2所示，当需要生成补丁时，首先需要将游戏开发者提供的脚本文件、美术资源文件、以及引擎配置文件等原始资源文件转化成该游戏引擎的游戏客户端所支持的资源格式以及文件系统分布，其可以通过在windows平台上调用该游戏引擎的chef工具对游戏使用的原始资源文件进行cook操作而实现。其中，chef工具是指该游戏引擎所提供的专门用于将该游戏引擎所使用的脚本文件以及美术资源文件按照特定的格式压缩并加密成该游戏引擎游戏所能够支持的文件格式的工具，这个压缩和加密的过程即为cook。例如，该过程可以通过输入指定的参数来控制cook时的选项，例如“--cook-script＝1”用于cook脚本文件，“--cook-package＝1”用于cook美术资源文件等，这样即可分别对脚本文件、美术资源文件、以及引擎配置文件进行加密和压缩，以得到该游戏引擎的游戏客户端所支持的资源格式的标准资源文件。

在步骤s2中，自标准资源文件中获取通用于不同终端类型的共用资源文件并配置于共用资源目录下。

本示例实施方式中，所述终端类型可以根据终端运行的操作系统进行分类，例如运行ios操作系统的终端或者运行android操作系统的终端；当然，所述终端类型还可以根据终端的系统配置进行分类，例如具有ios操作系统的高级配置的终端或者具有ios操作系统的低级配置的终端；本实施例针对终端的分类标准不限于此，凡是可能影响patch生成与更新的因素，均在本实施例的保护范围之内。所述共用资源文件是指各个类型终端均可以适用的资源文件，其例如可以包括脚本文件、引擎配置文件、以及美术资源文件中的场景文件和骨骼动作文件等。所述共用资源目录是指patch目录中指向共用资源文件的目录。

基于此，本步骤中自所述标准资源文件中获取通用于不同终端类型的共用资源文件具体可以包括：自所述标准资源文件中获取所述脚本文件、所述引擎配置文件、以及所述美术资源文件中的场景文件和骨骼动作文件。

举例来说，如图3所示，在通过上述步骤s1得到标准资源文件后，可将通用于不同终端类型的脚本文件、引擎配置文件、以及美术资源文件中的场景文件和骨骼动作文件等共用资源文件放置于一共用资源文件夹中并将其配置于patch目录中的common共用资源目录下。

在步骤s3中，对于每一所述终端类型，自所述标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下。

本示例实施方式中，所述专用资源文件是指仅针对于特定类型终端的资源文件，其例如可以包括美术资源文件中的模型、物理、ui、声音等。所述专用资源目录是指patch目录中指向专用资源文件的目录。

在本实施例中，所述终端类型可以根据终端运行的操作系统进行分类。在此情况下，所述不同终端类型可以包括对应第一应用平台的第一终端、对应第二应用平台的第二终端、以及对应第三应用平台的第三终端；其中，所述第一终端可以为运行ios系统的终端，所述第二终端可以为运行android系统的终端，所述第三终端可以为运行windows系统的终端。

基于此，自所述标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下可以包括：

自标准资源文件中获取适用于第一终端的第一专用资源文件并将第一专用资源文件配置于对应第一终端的第一专用资源目录下；

自标准资源文件中获取适用于第二终端的第二专用资源文件并将第二专用资源文件配置于对应第二终端的第二专用资源目录下；

自标准资源文件中获取适用于第三终端的第三专用资源文件并将第三专用资源文件配置于对应第三终端的第三专用资源目录下。

在本实施例中，所述终端类型也可以根据终端采用的硬件配置进行分类。在此情况下，所述不同终端类型可以包括对应第一硬件配置的第一终端、对应第二硬件配置的第二终端、以及对应第三硬件配置的第三终端；其中，所述第一终端可以采用高级的硬件配置，所述第二终端可以采用中级的硬件配置，所述第三终端可以采用低级的硬件配置。这里所述的高级、中级、低级是一种相对关系，其可根据cpu(centralprocessingunit，中央处理器)、gpu(graphicprocessingunit，图形处理器)等处理器的处理能力进行划分。

基于此，自所述标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下可以包括：

自标准资源文件中获取适用于第一终端的第一专用资源文件并将第一专用资源文件配置于对应第一终端的第一专用资源目录下；

自标准资源文件中获取适用于第二终端的第二专用资源文件并将第二专用资源文件配置于对应第二终端的第二专用资源目录下；

自标准资源文件中获取适用于第三终端的第三专用资源文件并将第三专用资源文件配置于对应第三终端的第三专用资源目录下。

基于上述两种示例性的分类方法，不同类型的终端可以根据特定的分类标准例如划分为第一终端、第二终端、以及第三终端。但是，本实施例不排除其它的分类方法，也不限定根据特定分类方法而划分的终端类型的数量。

需要说明的是：本示例实施方式中的终端分类方法可以单独使用，例如仅根据终端运行的操作系统进行分类，此时可以得到运行ios系统的第一终端、运行android系统的第二终端、以及运行windows系统的第三终端；或者仅根据终端采用的硬件配置进行分类，此时可以得到采用高级硬件配置的第一终端、采用中级硬件配置的第二终端、以及采用低级硬件配置的第三终端。当然，本示例实施方式中的终端分类方法也可以结合使用，例如结合终端运行的操作系统和终端采用的硬件配置进行分类，此时所得到的终端可以包括运行ios系统的三种终端、运行android系统的三种终端、以及运行windows系统的终端。

举例来说，参考图3所示，在通过上述步骤s1得到标准资源文件后，可将适用于ios平台的美术资源文件中的模型、物理、ui等专用资源文件放置于一专用资源文件夹中并将其配置于patch目录中对应ios平台的ios-common专用资源目录下，将适用于android平台的美术资源文件中的模型、物理、ui等专用资源文件放置于一专用资源文件夹中并将其配置于patch目录中对应android平台的android-common专用资源目录下，以及将适用于windows平台的美术资源文件中的模型、物理、ui等专用资源文件放置于一专用资源文件夹中并将其配置于patch目录中对应windows平台的windows-common专用资源目录下。

在此基础上，针对适用于ios平台或者android平台的美术资源文件，不仅包括模型、物理、ui、声音等这类可通用于ios平台或者android平台的专用资源文件，同时还包括贴图这类适用于不同硬件配置的专用资源文件。此时，针对于运行ios平台的终端，可根据其硬件配置的高低，将美术资源文件中的贴图这类专用资源文件放置于一专用资源文件夹中并将其配置于patch目录中对应ios平台且硬件配置不同的ios-high、ios-middle、以及ios-low专用资源目录下；同理，针对于运行android平台的终端，可根据其硬件配置的高低，将美术资源文件中的贴图这类专用资源文件放置于一专用资源文件夹中并将其配置于patch目录中对应android平台且硬件配置不同的android-high、android-middle、以及android-low专用资源目录下；而针对于运行windows平台的终端，可以根据上述方式进行分配，但也可以仅将专用资源文件统一配置于patch目录中对应windows平台的windows-normal专用资源目录下。

这样一来，当各类终端需要进行游戏内容更新时，便可以从步骤2中的共用资源目录下的共用资源文件以及步骤3中的专用资源目录下的专用资源文件中获取需要的待更新补丁。以ios平台的高级硬件配置的游戏客户端为例，其需要下载的资源分别从common目录、ios-common目录、以及ios-high目录中获取。

基于上述过程，如图4所示，所述补丁生成方法还可以进一步包括：

s4、将所生成的补丁与服务器端存储的历史补丁进行对比，以获取该补丁相对于历史补丁的增量补丁以及相同部分；

s5、将增量补丁上传至所述服务器，并针对相同部分生成一指向服务器端存储的历史补丁的记录标识。

其中，所述历史补丁是指已经上传至服务器端的补丁。

本示例实施方式的目的在于为应用程序生成补丁，而传统的补丁系统的弊端在于：每次需要应用程序客户端进行更新时，都需要上传全部的程序内容至服务器端，如果程序内容较大，便会导致服务器端的占用空间增大且上传用时也增大。针对于此，本示例实施方式通过将当前生成的补丁与已经上传的历史补丁进行对比，根据对比结果仅上传有变化的增量补丁而无需上传未变化的相同部分，这样可以大大减少需要上传的文件数量，从而达到减少补丁上传耗时的目的。

举例来说，在通过上述步骤s1-s3生成游戏补丁之后，需要将生成的游戏补丁上传至服务器端，以便于游戏客户端下载更新。如图5所示，在已经上传过一份补丁即历史补丁至服务器端的情况下，如果游戏资源发生变化需要上传一份新的补丁，则可以将根据上述方法生成的补丁与历史补丁进行对比，以得到发生更新变化的增量补丁和未变化的相同部分。针对于发生更新变化的增量补丁，需要将其上传至服务器端，而针对于未变化的相同部分，则会生成一由增量补丁指向历史补丁的patch目录的记录标识。仍以上述的游戏引擎为例，经过测试验证可知，采用本实施例提供的方法进行补丁的生成及上传，可将patch占用空间从7g下降到4g，有效减少42％的占用空间，生成耗时最快可从40分钟下降到16分钟，有效减少60％的生成耗时，上传耗时可从120分钟下降到10分钟，有效减少91％的上传耗时。由此可知，本实施例优化后的补丁生成方法可有效减少patch占用空间、生成耗时以及上传耗时。

本示例实施方式中还提供一种补丁更新方法，如图6所示，所述补丁更新方法可以包括：

s10、获取根据上述的补丁生成方法而生成的补丁；

s20、将获取到的补丁与本地内容进行对比，以获取待更新内容；

s30、自该补丁相对于服务器端存储的历史补丁的增量补丁中下载待更新内容的部分或全部；

s40、在增量补丁中未完全包括待更新内容时，根据指向服务器端存储的历史补丁的记录标识自历史补丁中下载待更新内容的剩余部分。

举例来说，参考图5所示，当游戏客户端需要启动时，会与新上传的增量补丁进行对比，以获得需要更新的内容。经过对比之后，游戏客户端首先会从增量补丁部分下载新更新的内容，而对于增量补丁中没有的内容，游戏客户端则会从历史补丁中进行下载。

由此可知，本实施例提供的补丁下载更新方法与上述的补丁生成方法相对应。具体而言，在补丁的生成及上传过程中，新上传的增量补丁会有一记录标识指向之前已经上传的补丁的patch目录，而游戏引擎的游戏客户端在需要更新时，首先会对比本地游戏资源与服务器端资源的差异，然后再从增量补丁部分和之前上传的历史补丁部分分别前后下载需要更新的资源。

这样一来，在进行补丁更新时，便可以从增量补丁中直接获取最新的更新内容，避免了先从历史补丁中下载一次补丁，再从增量补丁中对已下载且再次更新的内容重复下载，从而节约了补丁更新耗时。

本示例实施方式中还提出了一种补丁生成装置，用于为一应用程序生成补丁。如图7所示，所述补丁生成装置可以包括：

加密压缩模块10，用于对原始资源文件进行加密和压缩以得到标准资源文件；

共用资源模块20，用于自所述标准资源文件中获取通用于不同终端类型的共用资源文件并配置于共用资源目录下；

专用资源模块30，用于对于每一所述终端类型，自所述标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下；

其中，任一所述终端类型对应的补丁包括所述共用资源目录下的共用资源文件以及对应该终端类型的专用资源目录下的专用资源文件。

本公开示例性实施方式所提供的补丁生成装置，根据应用程序所使用的资源类型的不同而将所生成的补丁配置于不同的资源目录下。这样一来，通过将各个终端类型均适用的资源文件配置于一共用资源目录下，同时将针对特定终端类型的资源文件配置于对应的专用资源目录下，即可避免通用类补丁的重复生成，从而达到减少补丁生成耗时以及节约占用空间的效果；在此基础上，由于针对各个终端类型均生成了对应的资源文件，即对应各个终端类型均生成有对应的补丁，因此本实施方式可同时适用于不同的终端类型。

需要说明的是：所述补丁生成装置中各模块单元的具体细节已经在对应的补丁生成方法中进行了详细的描述，这里不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图8来描述根据本发明的这种实施方式的电子设备600。附图中的电子设备600仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，电子设备600以通用计算设备的形式表现。电子设备600的组件可以包括但不限于：上述至少一个处理单元610、上述至少一个存储单元620、连接不同系统组件(包括存储单元620和处理单元610)的总线630。

其中，所述存储单元620存储有程序代码，所述程序代码可以被所述处理单元610执行，使得所述处理单元610执行本说明书上述示例性方法部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元610可以执行如图1中所示的步骤s1、对原始资源文件进行加密和压缩以得到标准资源文件；步骤s2、自标准资源文件中获取通用于不同终端类型的共用资源文件并配置于共用资源目录下；步骤s3、对于每一终端类型，自标准资源文件中获取适用于该终端类型的专用资源文件并配置于对应该终端类型的专用资源目录下。

存储单元620可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)6201和/或高速缓存存储单元6202，还可以进一步包括只读存储单元(rom)6203。

存储单元620还可以包括具有一组(至少一个)程序模块6205的程序/实用工具6204，这样的程序模块6205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线630可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备600也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备600交互的设备通信，和/或与使得该电子设备600能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口650进行。并且，电子设备600还可以通过网络适配器660与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器660通过总线630与电子设备600的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备600使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述示例性方法部分中描述的根据本发明各种示例性实施方式的步骤。

参考图9所示，描述了根据本发明的实施方式的用于实现上述方法的程序产品800，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限。