CN113434149B - 应用程序生成和加载方法、装置和介质 - Google Patents

Abstract

本公开提供了一种应用程序生成方法、应用程序加载方法、应用程序生成装置和设备以及计算机可读存储介质。应用程序生成方法包括：确定用于生成应用程序的资产集合；对于资产集合中的每个资产，基于预定规则确定是否对该资产进行优化处理，并且在确定对该资产进行优化处理的情况下，对该资产进行优化处理，以生成优化资产集合；基于优化资产集合中的每个资产的优化处理状态，对优化资产集合进行序列化，以生成序列化资产集合；以及基于序列化资产集合生成应用程序。

Description

应用程序生成和加载方法、装置和介质

技术领域

本公开涉及计算机技术领域，并且更具体地涉及一种应用程序生成方法、应用程序加载方法、装置和设备以及计算机可读存储介质。

背景技术

在应用程序的构建过程中，会涉及或包含大量的计算机资产，例如用户界面(UserInterface，UI)资产。以常用的安卓系统应用程序包(Android Application Package，APK)为例，例如对于游戏程序，某些UI模块(例如物品描述、头像等)会重复出现在多个UI界面中。在这种情况下，为了便于复用及开发维护，需要复用的UI模块会被单独制作成一个资产，其可以被其他资产引用。因此，一个UI界面往往会依赖多个其他UI资产，这种复杂的依赖关系使得应用程序的资产组成的复杂度非常高，并且在应用程序运行时，将UI资产加载进内存也需要非常高的耗时。

针对上述问题，可以在完成应用程序的资产制作之后，将具有依赖关系的资产拆分开，再进行打包并生成APK，在应用程序的运行过程中，根据实际的业务需求把依赖的资产加载进内存。然而，资产拆分的方式使得应用程序制作效率低，并且使得对于应用程序资产的后续维护变得困难，而且在应用程序运行过程中，不同UI界面对相同资产模块的重复加载会带来很多重复代码，造成代码逻辑冗余。

发明内容

为了有效解决上述问题，本公开提供了一种应用程序生成方法、应用程序加载方法以及装置和计算机可读存储介质。

根据本公开实施例的一个方面，提供了一种应用程序生成方法，包括：确定用于生成应用程序的资产集合；对于所述资产集合中的每个资产，基于预定规则确定是否对所述资产进行优化处理，并且在确定对所述资产进行优化处理的情况下，对所述资产进行优化处理，以生成优化资产集合；基于所述优化资产集合中的每个资产的优化处理状态，对所述优化资产集合进行序列化，以生成序列化资产集合；以及基于所述序列化资产集合生成所述应用程序。

根据本公开实施例的示例，其中，所述资产集合包括被所述资产集合中的其他资产所依赖的依赖资产，并且，基于预定规则确定是否对所述资产进行优化处理包括：确定所述资产是否为依赖资产；并且在所述资产为依赖资产的情况下，确定对所述资产进行优化处理。

根据本公开实施例的示例，其中，基于预定规则确定是否对所述资产进行优化处理还包括：在所述资产为依赖资产并且所述资产的大小超过预定阈值的情况下，确定对所述资产进行优化处理。

根据本公开实施例的示例，其中，在确定对所述资产进行优化处理的情况下对所述资产进行优化处理包括：将所述资产从依赖其的父资产中删除，并在所述父资产中保存所述资产的名称和路径。

根据本公开实施例的示例，其中，基于所述优化资产集合中的每个资产的优化处理状态对所述优化资产集合进行序列化包括，对于所述优化资产集合中的每个资产：在所述资产被优化处理的情况下，跳过对所述资产的序列化；并且在所述资产未被优化处理的情况下，对所述资产进行序列化。

根据本公开实施例的示例，其中，基于预定规则确定是否对所述资产进行优化处理包括：确定所述资产中是否包含大小超过预定阈值的元素；以及在确定所述资产中包含大小超过预定阈值的元素时，确定对所述资产进行优化处理。

根据本公开实施例的示例，其中，在确定对所述资产进行优化处理的情况下对所述资产进行优化处理包括：将大小超过预定阈值的所述元素从所述资产中删除，并在所述资产中保存所述元素的名称和路径，并且其中，基于所述优化资产集合中的每个资产的优化处理状态对所述优化资产集合进行序列化包括，对于所述优化资产集合中的每个资产：在所述资产被优化处理的情况下，跳过对所述资产的所述元素的序列化，并对所述资产的其他元素进行序列化；并且在所述资产未被优化处理的情况下，对所述资产进行序列化。

根据本公开实施例的示例，其中，对所述资产进行序列化包括：将所述资产的持久化属性写入磁盘文件，所述持久化属性包括所述资产中的元素的内容信息、坐标信息、对齐信息、路径信息、内存信息中的至少一个。

根据本公开实施例的另一方面，提供了一种应用程序加载方法，包括：加载与应用程序的界面对应的资产集合，并基于所述资产集合显示所述界面的至少一部分；接收对所述界面的子界面的触发命令，并确定与所述子界面对应的子界面资产在所述资产集合中是否存在；以及在所述子界面资产在所述资产集合中存在的情况下，显示所述子界面，并且在所述子界面资产在所述资产集合中不存在的情况下，基于所述子界面资产的名称，从依赖所述子界面资产的父资产中获取所述子界面资产的路径，从所述路径加载所述子界面资产，并基于所加载的子界面资产显示所述子界面。

根据本公开实施例的示例，其中，在所述子界面资产在所述应用程序的生成过程中经过优化处理的情况下，所述子界面资产在所述资产集合中不存在。

根据本公开实施例的示例，其中，所述优化处理包括：在所述子界面资产为依赖资产时，将所述子界面资产从依赖其的父资产中删除，并在所述父资产中保存所述子界面资产的名称和路径。

根据本公开实施例的示例，其中，所述触发命令是对所述子界面的操作命令或者所述应用程序通过网络接收的与所述子界面相关的消息命令，并且其中，加载与应用程序的界面对应的资产集合包括：从磁盘文件中获取所述应用程序的序列化资产集合；以及对所述序列化资产集合进行反序列化，以获得与所述应用程序的界面对应的所述资产集合。

根据本公开实施例的另一方面，提供了一种应用程序生成装置，所述装置包括：确定单元，被配置为确定用于生成应用程序的资产集合；优化单元，被配置为对于所述资产集合中的每个资产，基于预定规则确定是否对所述资产进行优化处理，并且在确定对所述资产进行优化处理的情况下，对所述资产进行优化处理，以生成优化资产集合；序列化单元，被配置为基于所述优化资产集合中的每个资产的优化处理状态，对所述优化资产集合进行序列化，以生成序列化资产集合；以及生成单元，被配置为基于所述序列化资产集合生成所述应用程序。

根据本公开实施例的另一方面，提供了一种应用程序，包括加载单元、确定单元和显示单元，其中，加载单元被配置为加载与应用程序的界面对应的资产集合，并且显示单元被配置为基于所述资产集合显示所述界面的至少一部分。确定单元被配置为接收对所述界面的子界面的触发命令，并确定与所述子界面对应的子界面资产在所述资产集合中是否存在。在所述子界面资产在所述资产集合中存在的情况下，显示单元被配置为显示所述子界面。在所述子界面资产在所述资产集合中不存在的情况下，加载单元还被配置为基于所述子界面资产的名称，从依赖所述子界面资产的父资产中获取所述子界面资产的路径，并从所述路径加载所述子界面资产，并且显示单元还被配置为基于所加载的子界面资产显示所述子界面。

根据本公开实施例的另一方面，提供了一种应用程序生成设备，包括：一个或多个处理器；以及一个或多个存储器，其中所述存储器中存储有计算机可读指令，所述计算机可读指令在由所述一个或多个处理器运行时，使得所述一个或多个处理器执行上述各个方面中所述的方法。

根据本公开实施例的另一方面，提供了一种计算机可读存储介质，其上存储有计算机可读指令，所述计算机可读指令在被处理器执行时，使得所述处理器执行如本公开上述各个方面中任一项所述的方法。

根据本公开实施例的另一方面，提供了一种计算机程序产品，其中包括计算机可读指令，所述计算机可读指令在被处理器执行时，使得所述处理器执行如本公开上述各个方面中任一项所述的方法。

利用根据本公开上述各个实施例的应用程序生成方法、应用程序加载方法、装置、设备、计算机可读存储介质以及计算机程序产品，通过解除资产与其父资产的依赖关系，同时在父资产中保存资产的名称和路径，无需对应用程序的资产进行拆分，即可大幅精简应用程序的资产结构，从而能够有效提高应用程序的制作效率，减小应用程序占据的内存和磁盘空间；并且，在后续应用程序的运行过程中，在需要加载被优化的资产时，无需冗余的代码逻辑，通过所保存的该资产或者资产元素的名称和路径，即可以快速进行加载，从而可以有效提高应用程序的加载速度，优化用户体验。

附图说明

通过结合附图对本公开实施例进行更详细的描述，本公开实施例的上述以及其它目的、特征和优势将变得更加明显。附图用来提供对本公开实施例的进一步理解，并且构成说明书的一部分，与本公开实施例一起用于解释本公开，并不构成对本公开的限制。在附图中，相同的参考标号通常代表相同部件或步骤。

图1示出了根据本公开示例的UI资产的布局示意图；

图2示出了根据本公开示例的游戏引擎中的UI资产结构的示意图；

图3示出了根据本公开示例的游戏界面的示意图；

图4示出了根据本公开实施例的应用程序生成方法的流程图；

图5示出了根据本公开实施例的示例的应用程序生成方法的另一流程图；

图6示出了根据本公开实施例的应用程序加载方法的流程图；

图7示出了根据本公开实施例的示例的磁盘文件的结构示意图；

图8示出了根据本公开实施例的示例的应用程序运行的流程图；

图9示出了根据本公开实施例的示例的UI资产结构示意图；

图10示出了根据本公开实施例的应用程序生成装置的结构示意图；

图11示出了根据本公开实施例的应用程序的结构示意图；

图12示出了根据本公开实施例的示例性计算设备的架构的示意图。

具体实施方式

下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

在本公开中，应用程序的资产例如可以指应用程序所涉及或包含的各种虚拟数据、信息、资源等的集合，例如，用户界面(UI)资产可以由文字图片、音视频文件等各种元素构成。图1示出了根据本公开示例的UI资产的布局示意图。如图1所示，一个UI资产例如可以包含若干个菜单和内容区，其中菜单和内容区也可以是单独的资产。在用户点击某一个菜单后(如图1中的菜单1)，内容区会发生相应的变化，也就是说内容区和菜单彼此关联，或者说具有依赖关系。另外，为了更好的视觉表现，UI中的菜单和内容区的上下左右有严格的要求，通常需要做到“像素级”对齐。因此，在制作UI资产时，需要把这些关联资产拼装在一起，以便于进行统一的界面设置和调整。

以游戏应用程序的UI资产进行说明。图2示出了根据本公开示例的游戏引擎中的UI资产结构的示意图。由图2可见，一个游戏界面可以包括多个UI资产，并且每个UI资产又可以包含多个下级资产，或者说依赖于多个下级资产。这种树状的资产结构导致应用程序的资产复杂度非常高，使得应用程序的制作效率低下，体积庞大；并且在应用程序运行时，将所有这些UI资产加载进内存的耗时也很高，例如，使得打开某个游戏界面时具有明显的卡顿感，导致用户体验较差。

图3示出了根据本公开示例的游戏界面的示意图。如图3所示，该游戏界面包括“背包”、“任务”、“地图”、“健康”等多个菜单项。例如，用户可以点击“背包”菜单，从而显示出对应的背包界面。可以看到，在背包界面中，进一步包括“武器”、“护甲”、“头盔”等大量菜单项，点击其中每一项将显示更下一级的多个操作界面，并且这些操作界面之间还可能存在相互的引用和层级关系。也就是说，仅背包界面就由结构复杂的大量资产组成，如果不对这些资产的结构进行优化处理，在用户点击背包界面时，由于加载背包界面的所有资产的耗时很高，会使得打开背包界面出现较大的延迟，从而给用户带来不好的游戏体验。

对于上述问题，一种解决方法是在应用程序的资产制作完成之后，将被重复使用的依赖资产从其上级资产中拆分出来，作为单独的资产进行打包，从而精简应用程序的资产结构；然后，在应用程序的运行过程中，根据实际的业务需求将相应的依赖资产加载进内存。然而，这种方法会带来进一步的问题。一方面，当后续需要对资产进行修改维护时，还需要将资产再次拼装起来，导致操作不便。例如，对于图1中的UI资产，假定为了降低资产复杂度而将其中的内容区拆分出来作为单独的资产，如果后续要对该UI资产的坐标对齐参数进行调整，则需要将内容区与菜单重新拼装起来才能进行统一的调整操作，这是很不便利的。另一方面，在应用程序的运行过程中，对于使用相同资产模块的不同UI界面，在该资产模块被拆分的情况下，不同UI界面会对该资产模块进行重复加载，从而增加很多重复的代码，造成代码逻辑冗余。

有鉴于此，本公开实施例提出了一种应用程序生成方法以及相应的应用程序加载方法，可以避免代码逻辑冗余，大幅精简应用程序的资产结构，提高应用程序的制作效率，并且可以有效提高应用程序的加载速度，优化用户体验。

下面参照图4描述根据本公开实施例的应用程序生成方法。图4示出了根据本公开实施例的应用程序生成方法400的流程图。

如图4所示，在步骤S410中，确定用于生成应用程序的资产集合。这里，应用程序例如可以是安卓系统应用程序包(Android Application Package，APK)，但本公开实施例不限于此，应用程序也可以是诸如EXE(可执行文件)等的任意其他应用程序。如前所述，应用程序可以由很多资产构成，其中可以包括图片、文字、音视频文件等各种元素，这里将这些资产统称为资产集合。应用程序的资产集合中的各个资产之间可以具有依赖关系(或者称为引用关系)，例如资产A可以依赖资产C，并且资产B也可以依赖资产C。在本公开实施例中，可以将被资产集合中的其他资产所依赖的资产称为依赖资产，例如，在上述示例中，可以将资产C称为依赖资产。根据本公开实施例的示例，可以利用应用程序开发引擎来构建用于生成应用程序的资产集合，本公开实施例对此不作具体限制。

在步骤S420中，对于用于生成应用程序的资产集合中的每个资产，可以基于预定规则确定是否对该资产进行优化处理，并且在确定对该资产进行优化处理的情况下，对该资产进行优化处理，以生成优化资产集合。

根据本公开实施例的示例，预定规则可以是资产是否为依赖资产。具体地，资产为依赖资产表明该资产被一个或多个其他资产所依赖，如果不对该资产进行优化处理，会使得资产结构复杂，资产制作效率降低，并且该资产在序列化过程中会被重复序列化，造成应用程序的体积庞大且运行时加载缓慢。因此，可以对依赖资产进行优化处理。这种情况下，基于预定规则确定是否对资产进行优化处理可以包括：确定资产是否为依赖资产，并且在该资产为依赖资产的情况下，确定对该资产进行优化处理。

根据本公开实施例的另一示例，预定规则可以是资产是否为依赖资产并且资产的大小是否超过预定阈值。在实际应用中，如果对所有资产都判断其是否是依赖资产，并且对所有依赖资产都进行优化处理，可能会导致需要判定和优化的资产数量较多，尤其是在存在较多依赖资产的情况下，可能会导致优化处理过程耗时较久，而此时对于一些较小的依赖资产进行优化处理所带来的诸如资产结构精简、APK体积减小、应用程序加载耗时缩短等的优点却可能并不显著。

因此，可以在资产为依赖资产并且该资产的大小超过预定阈值的情况下，才确定对该资产进行优化处理。也就是说，如果资产为依赖资产，但该资产很小，不会对资产结构的复杂度造成太大影响，可以不对其进行优化处理，而只有在资产大小超过预定阈值，导致会明显增加资产结构的复杂度时，才对其进行优化处理。其中，预定阈值可以根据实际设计需求来确定，本公开实施例对此不作具体限制。通过这种方式，可以在有效实现本公开实施例的诸如资产结构精简、APK体积减小、应用程序加载耗时缩短等的优点的情况下，提高资产优化处理的效率。

在本公开实施例中，也可以通过其他预定规则来确定是否对资产进行优化处理，本公开实施例对此不作具体限制。另外，在采用根据本公开实施例的应用程序生成方法时，可以相应地在应用程序的开发引擎中设置优化选项，从而可以通过该优化选项来设置预定的优化规则、确定是否对资产进行优化处理等等。

在本公开实施例的示例中，在确定对资产进行优化处理时，可以通过将该资产从依赖其的父资产中删除，并且在父资产中保存该资产的名称和路径来对该资产进行优化处理。下面结合具体示例进行说明，其中，可以将每一个资产视为一个节点，例如，可以将父资产节点定义为“Node”类型，父资产包含或依赖于多个其他子资产，这些子资产节点可以被定义为<Node>Children。在进行优化处理之前，每个父资产节点的Class Node中包括由多个子资产节点构成的列表，如下所示：

表1优化处理前的数据结构

在确定要对父资产中的某个依赖资产进行优化处理之后，则将该依赖资产节点从父资产节点中的子资产节点列表中删除，并且在父资产节点中保存该依赖资产的名称和路径。例如，在上述示例中，可以将该依赖资产节点从父资产节点的List<Node>Children中删除，并且新增一个SoftNode类型用以保存该依赖资产的名称(Name)和路径(AssetPath)，则优化处理后的数据结构例如可以表示为：

表2优化处理后的数据结构

其中，被优化的资产的路径指向该资产的存储空间，例如可以指向应用程序的根目录、客户端设备中的相关联目录等等，本公开实施例对此不作具体限制。

需要说明的是，表1和表2中的数据结构仅仅作为示例而非限制，例如，父资产节点Node类中除了Children字段之外，还可以包括很多其他属性，并且优化的数据结构也可以采取其他合适的形式，本公开实施例对此不作具体限制。

以上描述了将要优化的资产从其父资产中直接删除同时保留其名称和路径的优化处理方式。根据本公开实施例的另一示例，对于确定要优化的资产，也可以在其父资产节点中保留该资产节点，而仅仅针对该资产中的特定元素进行优化处理，例如对该资产中占据较多磁盘空间及内存空间的图片、字体等元素进行优化处理。则在该示例中，基于预定规则确定是否对资产进行优化处理可以包括：确定资产中是否包含大小超过预定阈值的元素；并且在确定该资产中包含大小超过预定阈值的元素时，确定对该资产进行优化处理。在此情况下，可以通过将该大小超过预定阈值的元素从资产中删除，并在资产中保存该元素的名称和路径，来对该资产进行优化处理，其具体实现方式类似于上文参照表1和表2描述的内容，这里不再赘述。其中，预定阈值可以根据实际设计需求来确定，本公开实施例对此不作具体限制。

通过上述优化处理，对用于生成应用程序的资产集合中的各个资产进行优化处理，以生成优化后的资产集合，该优化资产集合的资产结构被有效地精简，从而提高了应用程序的资产制作效率。

接下来，在步骤S430中，基于该优化资产集合中的每个资产的优化处理状态，对优化资产集合进行序列化，以生成序列化资产集合。

通常，在诸如APK的应用程序的构建过程中，可以包括编译引擎、编译动态库、打包资源和生成APK等过程，其中，打包资源是指将引擎编辑器中的资源转换为设备(例如移动终端)使用的资源的过程，该过程例如可以包括对资源进行序列化、压缩、格式兼容等操作，其中序列化是指将资源的持久化属性写入磁盘文件的过程。在本公开实施例中，在利用优化资产集合生成应用程序之前，也需要进行序列化等操作。

在通过将资产从依赖其的父资产中删除，并在父资产中保存资产的名称和路径来对资产进行优化处理的示例中，对于优化资产集合中的每个资产，在该资产被优化处理的情况下，可以跳过对该资产的序列化，而在该资产未被优化处理的情况下，才对该资产进行序列化。如前面提到的，对资产进行序列化是指将资产的持久化属性写入磁盘文件中，其中持久化属性可以包括资产的元素的内容信息、坐标信息、对齐信息、路径信息、内存信息以及任意其他所需的属性等等。例如，对于一个文本框(Text)，需要持久化的属性可以包括坐标、对齐信息、文本内容、文本颜色等等。又例如，对于一幅图片(Image)，需要持久化的属性可以包括图片路径、图片大小、图片RGB等等。由于通过上述优化处理方式，解除了被优化的资产和其父资产的依赖关系，从而在对父资产进行序列化时，不会触发对该被优化资产的序列化过程，有效降低了资源序列化的时间、能耗和内存成本。

另外，类似地，在通过将大小超过预定阈值的元素从资产中删除，并在资产中保存该元素的名称和路径来对资产进行优化处理的示例中，对于优化资产集合中的每个资产，在该资产被优化处理的情况下，可以跳过对该资产的该元素的序列化，并对该资产的其他元素进行序列化；并且在该资产未被优化处理的情况下，对该资产进行序列化。同样，由于在对被优化的资产进行序列化时，不会触发对该资产中占据内存或磁盘空间较大的元素的序列化，从而可以有效降低资源序列化的时间、能耗和内存成本。

在完成对优化资产集合的序列化以生成序列化资产集合之后，在步骤S440中，可以基于该序列化资产集合生成应用程序。例如，在应用程序为APK时，该过程即将动态链接库、序列化资产等等按照应用平台(诸如移动终端)的规范压缩为单独的应用程序文件。在本公开实施例中，应用程序的应用平台可以是诸如台式计算机、物联网设备等的固定终端，或者可以是诸如智能手机、平板计算机、便携式计算机、智能可穿戴设备、个人数字助理(PDA)等的移动终端，本公开实施例对此不作具体限制。

为了使根据本公开实施例的应用程序生成方法的步骤更加清晰，下面结合图5进行进一步的描述。图5示出了根据本公开实施例的示例的应用程序生成方法的另一流程图。如图5所示，在确定了用于生成应用程序的资产集合之后，对于资产集合中的资产，根据预定规则确定是否对该资产进行优化；如果确定对该资产进行优化，则可以将该资产从其父资产中删除，并在父资产中保存其名称和路径，并可以在之后的序列化过程中跳过对该被优化的资产的序列化；否则，如果不对该资产进行优化，则在之后的序列化过程中对该资产进行序列化；然后对资产集合中的其他资产重复以上操作，即遍历资产集合中的所有资产，直到完成资产集合的序列化；最后，基于序列化后的资产集合，生成应用程序，例如生成APK。

利用上述应用程序生成方法，通过解除资产与其父资产的依赖关系，同时在父资产中保存资产的名称和路径，无需对应用程序的资产进行拆分，即可大幅精简应用程序的资产结构，从而能够有效提高应用程序的制作效率，减小应用程序占据的内存和磁盘空间；并且，在后续应用程序的运行过程中，在需要加载被优化的资产时，无需冗余的代码逻辑，通过所保存的该资产或者资产元素的名称和路径，即可以快速进行加载，从而可以有效提高应用程序的加载速度，优化用户体验。

下面参照图6描述根据本公开实施例的应用程序加载方法。图6示出了根据本公开实施例的应用程序加载方法600的流程图。由于应用程序加载方法600中的部分细节与上文参照图4描述的应用程序生成方法400的部分细节相同，这里为了简单起见，省略了对相同内容的重复描述。

这里的应用程序例如可以是根据上文描述的应用程序生成方法得到的。在应用程序运行时，如图6所示，在步骤S610中，加载与应用程序的界面对应的资产集合，并基于资产集合显示界面的至少一部分。应用程序的界面可以包括多个子界面，例如与图1所示的UI资产对应的应用程序界面可以包括菜单1界面、菜单2界面、菜单3界面等等。在应用程序的初始加载过程中，可以只显示其界面的一部分，例如，在图1中，可以只显示菜单1界面，用户可以根据需要点击其他菜单选项，以显示其他菜单界面。

在本公开实施例中，加载与应用程序的界面对应的资产集合可以是指从诸如磁盘文件的存储空间中获取应用程序的序列化资产集合，并且对该序列化资产集合进行反序列化，以获得与应用程序的界面对应的资产集合。其中，反序列化是与序列化相反的过程，即将资产的持久化属性从磁盘文件中读出的过程。通常，磁盘文件的结构可以如图7所示。图7示出了根据本公开实施例的示例的磁盘文件的结构示意图。如图7所示，磁盘文件可以包括文件头和多个属性部分，其中文件头包含了文件总长度、文件类型等文件描述信息；属性部分则包含该属性的长度信息以及相应的属性内容。在对如图7所示的磁盘文件进行反序列化时，首先读取磁盘文件的文件头以获取描述信息，继而根据描述信息分别读取各个属性部分的内容，直至读取至文件流末端，即完成该磁盘文件的反序列化过程，或者说完成对该磁盘文件中的资产的加载。

在步骤S620中，接收对界面的子界面的触发命令，并确定与该子界面对应的子界面资产在资产集合中是否存在。其中，触发命令可以是对子界面的操作命令，例如在图1中，用户可以通过点击菜单2选项来触发显示菜单2界面；触发命令还可以是应用程序通过诸如有线网络或网线网络接收的与该子界面相关的消息命令，例如，应用程序可能接收到来自其他应用程序的会话消息，该会话消息会触发显示会话窗口，等等。

在应用程序是利用如上所述的应用程序生成方法获得的情况下，用于生成应用程序的资产在被序列化之前经过了优化处理步骤，则一些资产可能会在优化处理的过程中从其父资产中删除，而仅仅保留了其名称和路径，并且因此也不会被序列化，则从磁盘文件中获取的应用程序的序列化资产集合中也不会包括该部分资产，相应地在步骤S610中加载得到的资产集合中也不会包括该部分资产。因此，在步骤S620中接收到对某个子界面的触发命令时，首先确定与该子界面对应的子界面资产在所加载的资产集合中是否存在。

一方面，如果子界面资产在应用程序的生成过程中没有经过优化处理，则该子界面资产在所加载的资产集合中存在，则可以直接基于子界面资产显示相应的子界面。

另一方面，如果子界面资产在应用程序的生成过程中经过了优化处理，则该子界面资产在所加载的资产集合中可能是不存在的。例如，如上文所述，优化处理可以是在子界面资产为依赖资产时，将该子界面资产从依赖其的父资产中删除，并在父资产中保存该子界面资产的名称和路径，则该子界面资产在序列化过程中不会被序列化，那么相应地在所加载的资产集合中该子界面资产也是不存在的。在此情况下，可以基于该子界面资产的名称，从所加载的资产集合中的、依赖该子界面资产的父资产中获取该子界面资产的路径，并从所获取的路径加载该子界面资产，以进一步基于所加载的子界面资产显示该子界面。

为了更清楚地描述根据本公开实施例的应用程序加载方法，参照图8中的示例进行进一步的描述。图8示出了根据本公开实施例的示例的应用程序运行的流程图。如图8所示，首先加载应用程序的资产集合，并据此显示相应的界面的至少一部分，此时，如果没有额外的触发命令，则应用程序的当前运行结束。如果接受到对某一子界面的触发命令，例如对该子界面的操作命令、或者通过网络接收的与该子界面相关的消息命令，则确定该子界面对应的子界面资产在所加载的资产集合中是否存在，如果存在，则可以基于子界面资产直接显示该子界面，应用程序的当前运行结束；如果不存在，则基于子界面资产的名称，从所加载的资产集合中的、该子界面资产的父资产中获取子界面资产的路径，从所获取的路径中加载子界面资产，并相应地显示子界面，则应用程序的当前运行结束。

利用根据本公开实施例的应用程序加载方法，在应用程序经过如上文所述的优化处理的情况下，能够有效提高应用程序的加载速度，优化用户体验。

结合图9中的示例进行说明。图9示出了根据本公开实施例的示例的UI资产结构示意图。如图9所示，标记为①的资产“BP_MobileWidget_NewBag_Container”与标记为②的资产“BP_Container”之间存在依赖关系，如果对于资产②未进行优化处理，则加载资产①时，也会同时触发对资产②的加载，使得对资产①的加载变得缓慢，尤其是在资产②占据较大的磁盘或内存空间时。而如果对资产②进行了如上文描述的优化处理，例如将资产②从资产①中删除以解除二者的依赖关系，而仅在资产①中保存资产②的名称和路径，则加载资产①时不会触发对资产②的加载，从而可以有效提高对资产①的加载速度，而如果需要加载资产②时，也可以快速地从资产①中获取相应的加载路径以进行加载。

通过上述方式，可以显著提高应用程序的加载速度，尤其是对于具有较多不同层级的子界面的界面的加载。以图3中的游戏界面为例，其中背包界面包括较多子界面，如果未对这些子界面的资产进行优化处理，则每次打开背包界面时，都需要加载全部的子界面资产，会导致打开背包界面存在较大的延时。利用本公开实施例的应用程序生成方法和应用程序加载方法，例如可以对背包界面中的武器子界面、护甲子界面、头盔子界面等对应的子界面资产进行优化处理，则在点击“背包”菜单时，可以快速地加载并显示背包界面，而例如如果用户希望进一步打开护甲子界面，也可以快速地根据所存储的路径获取相应的子界面资产，加载并显示护甲子界面。

下面参照图10描述根据本公开实施例的应用程序生成装置。图10示出了根据本公开实施例的应用程序生成装置1000的结构示意图。如图10所示，应用程序生成装置1000可以包括确定单元1010，优化单元1020，序列化单元1030和生成单元1040。除了这4个单元以外，应用程序生成装置1000还可以包括其他单元，但由于它们与本发明实施例的内容无关，这里省略对这些单元的描述。另外，由于应用程序生成装置1000的功能与参照图4描述的应用程序生成方法400的细节类似，这里省略了对部分相同内容的重复描述。

确定单元1010被配置为确定用于生成应用程序的资产集合。这里，应用程序例如可以是安卓系统应用程序包(APK)，但本公开实施例对此不作具体限制，应用程序也可以是诸如EXE(可执行文件)等的任意其他应用程序。如前所述，应用程序可以由很多资产构成，其中可以包括图片、文字、音视频文件等各种元素，这里将这些资产统称为资产集合。应用程序的资产集合中的各个资产之间可以具有依赖关系(或者称为引用关系)，例如资产A可以依赖资产C，并且资产B也可以依赖资产C。在本公开实施例中，可以将被资产集合中的其他资产所依赖的资产称为依赖资产，例如，在上述示例中，可以将资产C称为依赖资产。根据本公开实施例的示例，可以利用应用程序开发引擎来构建用于生成应用程序的资产集合，本公开实施例对此不作具体限制。

优化单元1020被配置为对于用于生成应用程序的资产集合中的每个资产，基于预定规则确定是否对该资产进行优化处理，并且在确定对该资产进行优化处理的情况下，对该资产进行优化处理，以生成优化资产集合。

根据本公开实施例的示例，预定规则可以是资产是否为依赖资产。具体地，资产为依赖资产表明该资产被一个或多个其他资产所依赖，如果不对该资产进行优化处理，会使得资产结构复杂，资产制作效率降低，并且该资产在序列化过程中会被重复序列化，造成应用程序的体积庞大且运行时加载缓慢。因此，优化单元1020可以对依赖资产进行优化处理。这种情况下，优化单元1020可以被配置为：确定资产是否为依赖资产，并且在该资产为依赖资产的情况下，确定对该资产进行优化处理。

根据本公开实施例的另一示例，预定规则可以是资产是否为依赖资产并且资产的大小是否超过预定阈值。在实际应用中，如果对所有资产都判断其是否是依赖资产，并且对所有依赖资产都进行优化处理，可能会导致需要判定和优化的资产数量较多，尤其是在存在较多依赖资产的情况下，可能会导致优化处理过程耗时较久，而此时对于一些较小的依赖资产进行优化处理所带来的诸如资产结构精简、APK体积减小、应用程序加载耗时缩短等的优点却可能并不显著。因此，优化单元1020可以被配置为：在资产为依赖资产并且该资产的大小超过预定阈值的情况下，确定对该资产进行优化处理。也就是说，如果资产为依赖资产，但该资产很小，不会对资产结构的复杂度造成太大影响，可以不对其进行优化处理，而只有在资产大小超过预定阈值，导致会明显增加资产结构的复杂度时，才对其进行优化处理。其中，预定阈值可以根据实际设计需要来确定，本公开实施例对此不作具体限制。通过这种方式，可以在有效实现本公开实施例的诸如资产结构精简、APK体积减小、应用程序加载耗时缩短等的优点的情况下，提高资产优化处理的效率。

在本公开实施例中，优化单元1020也可以通过其他预定规则来确定是否对资产进行优化处理，本公开实施例对此不作具体限制。另外，在采用根据本公开实施例的应用程序生成装置时，可以相应地在应用程序的开发引擎中设置优化选项，从而可以通过该优化选项来设置预定的优化规则、确定是否对资产进行优化处理等等。

在本公开实施例的示例中，在确定对资产进行优化处理时，优化单元1020可以通过将该资产从依赖其的父资产中删除，并且在父资产中保存该资产的名称和路径来对该资产进行优化处理。根据本公开实施例的另一示例，对于确定要优化的资产，优化单元1020也可以在其父资产节点中保留该资产节点，而仅仅针对该资产中的特定元素进行优化处理，例如对该资产中占据较多磁盘空间及内存空间的图片、字体等元素进行优化处理。则在该示例中，优化单元1020可以被配置为：确定资产中是否包含大小超过预定阈值的元素；并且在确定该资产中包含大小超过预定阈值的元素时，确定对该资产进行优化处理。并且，在此情况下，优化单元1020可以通过将该大小超过预定阈值的元素从资产中删除，并在资产中保存该元素的名称和路径，来对该资产进行优化处理。其中，预定阈值可以根据实际设计需求来确定，本公开实施例对此不作具体限制。

通过上述优化处理，对用于生成应用程序的资产集合中的各个资产进行优化处理，以生成优化后的资产集合，该优化资产集合的资产结构被有效地精简，从而提高了应用程序的资产制作效率。

序列化单元1030被配置为基于该优化资产集合中的每个资产的优化处理状态，对优化资产集合进行序列化，以生成序列化资产集合。

在通过将资产从依赖其的父资产中删除，并在父资产中保存资产的名称和路径来对资产进行优化处理的示例中，对于优化资产集合中的每个资产，序列化单元1030可以在该资产被优化处理的情况下，跳过对该资产的序列化，而在该资产未被优化处理的情况下，才对该资产进行序列化。如前面提到的，对资产进行序列化是指将资产的持久化属性写入磁盘文件中，其中持久化属性可以包括资产的元素的内容信息、坐标信息、对齐信息、路径信息、内存信息以及任意其他所需的属性等等。由于通过上述优化处理方式，解除了被优化的资产和其父资产的依赖关系，从而在对父资产进行序列化时，不会触发对该被优化资产的序列化过程，从而有效降低了资源序列化的时间、能耗和内存成本。

另外，类似地，在通过将大小超过预定阈值的元素从资产中删除，并在资产中保存该元素的名称和路径来对资产进行优化处理的示例中，对于优化资产集合中的每个资产，序列化单元1030可以在该资产被优化处理的情况下，跳过对该资产的该元素的序列化，并对该资产的其他元素进行序列化；并且在该资产未被优化处理的情况下，对该资产进行序列化。同样，由于在对被优化的资产进行序列化时，不会触发对该资产中占据内存或磁盘空间较大的元素的序列化，从而可以有效降低资源序列化的时间、能耗和内存成本。

在完成对优化资产集合的序列化以生成序列化资产集合之后，生成单元1040可以基于该序列化资产集合生成应用程序。例如，在应用程序为APK时，该过程即将动态链接库、序列化资产等等按照应用平台(诸如移动终端)的规范压缩为单独的应用程序文件。在本公开实施例中，应用程序的应用平台可以是诸如台式计算机、物联网设备等的固定终端，或者可以是诸如智能手机、平板计算机、便携式计算机、智能可穿戴设备、个人数字助理(PDA)等的移动终端，本公开实施例对此不作具体限制。

利用上述应用程序生成装置，通过解除资产与其父资产的依赖关系，同时在父资产中保存资产的名称和路径，无需对应用程序的资产进行拆分，即可大幅精简资产结构，从而能够有效提高应用程序的制作效率，减小应用程序占据的内存和磁盘空间；并且，在后续应用程序的运行过程中，在需要加载被优化的资产时，无需冗余的代码逻辑，通过所保存的该资产或者资产元素的名称和路径，即可以快速进行加载，从而可以有效提高应用程序的加载速度，优化用户体验。

下面参照图11描述根据本公开实施例的应用程序。图11示出了根据本公开实施例的应用程序1100的结构示意图。如图11所示，应用程序1100可以包括加载单元1110、确定单元1120和显示单元1130。除了这3个单元以外，应用程序1100还可以包括其他单元，但由于它们与本发明实施例的内容无关，这里省略对这些单元的描述。另外，由于应用程序1100的功能与参照图6描述的应用程序加载方法600的细节类似，这里省略了对部分相同内容的重复描述。

这里的应用程序例如可以是根据上文描述的应用程序生成方法得到的。在应用程序运行时，加载单元1110被配置为加载与应用程序的界面对应的资产集合，并且相应地显示单元1130被配置为基于资产集合显示界面的至少一部分。应用程序的界面可以包括多个子界面，例如与图1所示的UI资产对应的应用程序界面可以包括菜单1界面、菜单2界面、菜单3界面等等。在应用程序的初始加载过程中，可以只显示其界面的一部分，例如，在图1中，可以只显示菜单1界面，用户可以根据需要点击其他菜单选项，以显示其他菜单界面。

在本公开实施例中，加载与应用程序的界面对应的资产集合可以是指从诸如磁盘文件的存储空间中获取应用程序的序列化资产集合，并且对该序列化资产集合进行反序列化，以获得与应用程序的界面对应的资产集合。其中，反序列化是与序列化相反的过程，即将资产的持久化属性从磁盘文件中读出的过程。

确定单元1120被配置为接收对界面的子界面的触发命令，并确定与该子界面对应的子界面资产在资产集合中是否存在。其中，触发命令可以是对子界面的操作命令，例如在图1中，用户可以通过点击菜单2选项来触发显示菜单2界面；触发命令还可以是应用程序通过诸如有线网络或网线网络接收的与该子界面相关的消息命令，例如，应用程序可能接收到来自其他应用程序的会话消息，该会话消息会触发显示会话窗口。

在应用程序1100是利用如上所述的应用程序生成方法获得的情况下，用于生成应用程序的资产在被序列化之前经过了优化处理步骤，则一些资产可能会在优化处理的过程中从其父资产中删除，而仅仅保留了名称和路径，并且因此也不会被序列化，则从磁盘文件中获取的应用程序的序列化资产集合中也不会包括该部分资产，相应地加载单元1110得到的资产集合中也不会包括该部分资产。因此，确定单元1120接收到对某个子界面的触发命令时，首先确定与该子界面对应的子界面资产在所加载的资产集合中是否存在。

一方面，如果子界面资产在应用程序的生成过程中没有经过优化处理，则该子界面资产在所加载的资产集合中存在，则显示单元1130可以直接基于子界面资产显示相应的子界面。

另一方面，如果子界面资产在应用程序的生成过程中经过了优化处理，则该子界面资产在所加载的资产集合中可能是不存在的。例如，如上文所述，优化处理可以是在子界面资产为依赖资产时，将该子界面资产从依赖其的父资产中删除，并在父资产中保存该子界面资产的名称和路径，则该子界面资产在序列化过程中不会被序列化，那么相应地在所加载的资产集合中该子界面资产也是不存在的。在此情况下，加载单元1110可以基于该子界面资产的名称，从所加载的资产集合中的、依赖该子界面资产的父资产中获取该子界面资产的路径，并从所获取的路径加载该子界面资产，继而显示单元1130可以基于所加载的子界面资产显示该子界面。

利用根据本公开实施例的应用程序，由于应用程序在生成过程中经过如上文所述的优化处理精简了资产结构，因此所得到的应用程序占据的内存空间得以被有效缩减，并且在运行过程中加载速度快，从而可以显著优化用户体验。

此外，根据本公开实施例的设备(例如，应用程序生成设备等)也可以借助于图12所示的示例性计算设备的架构来实现。图12示出了根据本公开实施例的示例性计算设备的架构的示意图。如图12所示，计算设备1200可以包括总线1210、一个或多个CPU 1220、只读存储器(ROM)1230、随机存取存储器(RAM)1240、连接到网络的通信端口1250、输入/输出组件1260、硬盘1270等。计算设备1200中的存储设备，例如ROM 1230或硬盘1270可以存储计算机处理和/或通信使用的各种数据或文件以及CPU所执行的程序指令。计算设备1200还可以包括用户界面1280。当然，图12所示的架构只是示例性的，在实现不同的设备时，根据实际需要，可以省略图12示出的计算设备中的一个或多个组件。根据本公开实施例的设备可以被配置为执行根据本公开上述各个实施例的应用程序生成方法和应用程序加载方法，或者用于实现根据本公开上述各个实施例的应用程序生成装置或应用程序。

本公开的实施例也可以被实现为计算机可读存储介质。根据本公开实施例的计算机可读存储介质上存储有计算机可读指令。当计算机可读指令由处理器运行时，可以执行参照以上附图描述的根据本公开实施例的应用程序生成方法和应用程序加载方法。计算机可读存储介质包括但不限于例如易失性存储器和/或非易失性存储器。易失性存储器例如可以包括随机存取存储器(RAM)和/或高速缓冲存储器(cache)等。非易失性存储器例如可以包括只读存储器(ROM)、硬盘、闪存等。

根据本公开的实施例，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或者计算机程序包括计算机可读指令，该计算机可读指令存储在计算机可读存储介质中。计算机设备的处理器可以从计算机可读存储介质读取该计算机可读指令，处理器执行该计算机可读指令，使得该计算机设备执行上述各个实施例中描述的应用程序生成方法和应用程序加载方法。

本领域技术人员能够理解，本公开所披露的内容可以出现多种变型和改进。例如，以上所描述的各种设备或组件可以通过硬件实现，也可以通过软件、固件、或者三者中的一些或全部的组合实现。

此外，如本公开和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。本公开中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。

此外，本公开中使用了流程图用来说明根据本公开实施例的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作叠加到这些过程中，或从这些过程移除某一步或数步操作。

除非另有定义，这里使用的所有术语(包括技术和科学术语)具有与本公开所属领域的普通技术人员共同理解的相同含义。还应当理解，诸如在通常字典里定义的那些术语应当被解释为具有与它们在相关技术的上下文中的含义相一致的含义，而不应用理想化或极度形式化的意义来解释，除非这里明确地这样定义。

以上对本公开进行了详细说明，但对于本领域技术人员而言，显然，本公开并非限定于本说明书中说明的实施方式。本公开在不脱离由权利要求书的记载所确定的本公开的宗旨和范围的前提下，可以作为修改和变更方式来实施。因此，本说明书的记载是以示例说明为目的，对本公开而言并非具有任何限制性的意义。

Claims (12)

1.一种应用程序生成方法，包括：

确定用于生成应用程序的资产集合；

对于所述资产集合中的每个资产，基于预定规则确定是否对所述资产进行优化处理，并且在确定对所述资产进行优化处理的情况下，对所述资产进行优化处理，以生成优化资产集合；

基于所述优化资产集合中的每个资产的优化处理状态，对所述优化资产集合进行序列化，以生成序列化资产集合；以及

基于所述序列化资产集合生成所述应用程序，

其中，所述资产集合包括被所述资产集合中的其他资产所依赖的依赖资产，并且，基于预定规则确定是否对所述资产进行优化处理包括：

在所述资产为依赖资产的情况下，确定对所述资产进行优化处理，所述优化处理包括将所述资产从依赖其的父资产中删除，并在所述父资产中保存所述资产的名称和路径，

并且其中，基于所述优化资产集合中的每个资产的优化处理状态对所述优化资产集合进行序列化包括：

对于所述优化资产集合中的每个资产，在所述资产被优化处理的情况下，跳过对所述资产的序列化，以及在所述资产未被优化处理的情况下，对所述资产进行序列化。

2.如权利要求1所述的应用程序生成方法，其中，基于预定规则确定是否对所述资产进行优化处理还包括：

在所述资产为依赖资产并且所述资产的大小超过预定阈值的情况下，确定对所述资产进行优化处理。

3.如权利要求1所述的应用程序生成方法，其中，基于预定规则确定是否对所述资产进行优化处理还包括：

确定所述资产中是否包含大小超过预定阈值的元素；以及

在确定所述资产中包含大小超过预定阈值的元素时，确定对所述资产进行优化处理。

4.如权利要求3所述的应用程序生成方法，其中，在确定对所述资产进行优化处理的情况下对所述资产进行优化处理包括：

将大小超过预定阈值的所述元素从所述资产中删除，并在所述资产中保存所述元素的名称和路径，并且

其中，基于所述优化资产集合中的每个资产的优化处理状态对所述优化资产集合进行序列化包括，对于所述优化资产集合中的每个资产：

在所述资产被优化处理的情况下，跳过对所述资产的所述元素的序列化，并对所述资产的其他元素进行序列化；并且

在所述资产未被优化处理的情况下，对所述资产进行序列化。

5.如权利要求1或4所述的应用程序生成方法，其中，对所述资产进行序列化包括：

将所述资产的持久化属性写入磁盘文件，所述持久化属性包括所述资产中的元素的内容信息、坐标信息、对齐信息、路径信息、内存信息中的至少一个。

6.一种应用程序加载方法，其中应用程序基于如权利要求1所述的方法生成，所述方法包括：

加载与所述应用程序的界面对应的资产集合，并基于所述资产集合显示所述界面的至少一部分；

接收对所述界面的子界面的触发命令，并确定与所述子界面对应的子界面资产在所述资产集合中是否存在；以及

在所述子界面资产在所述资产集合中存在的情况下，显示所述子界面，并且在所述子界面资产在所述资产集合中不存在的情况下，基于所述子界面资产的名称，从依赖所述子界面资产的父资产中获取所述子界面资产的路径，从所述路径加载所述子界面资产，并基于所加载的子界面资产显示所述子界面。

7.如权利要求6所述的应用程序加载方法，其中，在所述子界面资产在所述应用程序的生成过程中经过优化处理的情况下，所述子界面资产在所述资产集合中不存在。

8.如权利要求7所述的应用程序加载方法，其中，所述优化处理包括：

在所述子界面资产为依赖资产时，将所述子界面资产从依赖其的父资产中删除，并在所述父资产中保存所述子界面资产的名称和路径。

9.如权利要求6所述的应用程序加载方法，其中，所述触发命令是对所述子界面的操作命令或者所述应用程序通过网络接收的与所述子界面相关的消息命令，并且

其中，加载与应用程序的界面对应的资产集合包括：

从磁盘文件中获取所述应用程序的序列化资产集合；以及

对所述序列化资产集合进行反序列化，以获得与所述应用程序的界面对应的所述资产集合。

10.一种应用程序生成装置，所述装置包括：

确定单元，被配置为确定用于生成应用程序的资产集合；

优化单元，被配置为对于所述资产集合中的每个资产，基于预定规则确定是否对所述资产进行优化处理，并且在确定对所述资产进行优化处理的情况下，对所述资产进行优化处理，以生成优化资产集合；

序列化单元，被配置为基于所述优化资产集合中的每个资产的优化处理状态，对所述优化资产集合进行序列化，以生成序列化资产集合；以及

生成单元，被配置为基于所述序列化资产集合生成所述应用程序，

其中，所述资产集合包括被所述资产集合中的其他资产所依赖的依赖资产，所述优化单元还被配置为：在所述资产为依赖资产的情况下，确定对所述资产进行优化处理，所述优化处理包括将所述资产从依赖其的父资产中删除，并在所述父资产中保存所述资产的名称和路径，

所述序列化单元还被配置为：对于所述优化资产集合中的每个资产，在所述资产被优化处理的情况下，跳过对所述资产的序列化，以及在所述资产未被优化处理的情况下，对所述资产进行序列化。

11.一种应用程序生成设备，包括：

一个或多个处理器；以及

一个或多个存储器，其中所述存储器中存储有计算机可读指令，所述计算机可读指令在由所述一个或多个处理器运行时，使得所述一个或多个处理器执行如权利要求1-5中任一项所述的方法。

12.一种计算机可读存储介质，其上存储有计算机可读指令，所述计算机可读指令在被处理器执行时，使得所述处理器执行如权利要求1-9中任一项所述的方法。