CN115237455B - 应用管理方法及相关设备 - Google Patents

Abstract

本申请关于一种应用管理方法及相关设备，涉及软件技术领域。本申请中，第一应用仓库可以向应用商店发送第一下载请求，第一下载请求用于请求下载应用商店中的第一应用。之后，第一应用仓库可以接收来自应用商店的第一应用。也就是说，本申请中通过仓库进行应用程序的传输，简化了传输的过程，用户能够更便捷的开发、运行应用程序。

Description

应用管理方法及相关设备

技术领域

本申请涉及软件技术领域，尤其涉及一种应用管理方法及相关设备。

背景技术

应用程序(application，APP)也称应用，是指为完成某项或多项特定工作的计算机程序，可以运行在用户模式和用户进行交互，可以具有可视的用户界面。

目前，应用的开发者可以将开发好的应用上架到应用商店中，需要使用应用的用户可以从应用商店中下载应用的安装包，并通过下载的应用安装包将应用安装到本地终端(如手机、平板电脑、智能电视等)。之后，用户可以通过终端运行应用。

但是，目前终端运行应用需要下载、安装等步骤，过程较为繁琐，影响用户的使用体验。

发明内容

本申请提供一种应用管理方法及相关设备，可以简化运行应用的步骤，便于终端运行应用。

本申请的技术方案如下：

第一方面，本申请提供一种应用管理方法，所述方法应用于第一应用仓库；所述方法包括：

向应用商店发送第一下载请求，第一下载请求用于请求下载应用商店中的第一应用，应用商店中存储有第一应用。接收来自应用商店的第一应用。

一些实现方式中，第一应用与应用商店中的第二应用具有关联关系，能够调用第二应用以实现第二应用的功能。该应用管理方法还包括：接收来自应用商店的第二应用。

一些实现方式中，第一应用中包括第一信息，第一信息用于指示与第一应用关联的第二应用。

一些实现方式中，第一信息包括第二应用的标识。应用商店中的不同应用的标识不同。

第二方面，本申请提供一种应用管理方法，所述方法应用于第二应用仓库，所述方法包括：

向应用商店发送第二下载请求，第二下载请求用于请求从应用商店下载第二应用。基于第二应用生成第一应用。

一些实现方式中，该应用管理方法还包括：向应用商店发送应用上传请求，应用上传请求用于指示向应用商店上传第一应用。向应用商店发送第一应用。

一些实现方式中，该应用管理方法还包括：建立第一应用与第二应用的关联关系，第一应用能够调用第二应用以实现第二应用的功能。根据关联关系，基于第二应用生成第一应用。向应用商店发送第一应用，第一应用中包含第一应用与第二应用的关联关系。

第三方面，本申请提供一种应用管理方法，所述方法应用于应用商店，所述方法包括：

接收来自第一应用仓库的第一下载请求，第一下载请求用于请求下载应用商店中的第一应用。响应于第一下载请求，向第一应用仓库发送第一应用。

一些实现方式中，该应用管理方法还包括：响应第二应用仓库发送的应用上传请求，接收来自第二应用仓库的第一应用。

一些实现方式中，应用商店中存储有第二应用，该应用管理方法还包括：接收来自第二应用仓库的第二下载请求，第二下载请求用于请求下载第二应用。向第二应用仓库发送第二应用。

一些实现方式中，该应用管理方法还包括：建立第一应用和第二应用的关联关系。第一应用能够调用第二应用以实现第二应用的功能。

一些实现方式中，第一应用中包括第一信息，第一信息用于指示与第一应用关联的第二应用。

一些实现方式中，该应用管理方法还包括：响应于第一下载请求，向第一应用仓库发送第一应用和第二应用，第一应用包含第一应用和第二应用的关联关系。

第四方面，本申请提供一种应用管理装置，所述装置应用于第一应用仓库。该装置包括：

发送模块，用于向应用商店发送第一下载请求，第一下载请求用于请求下载应用商店中的第一应用，应用商店中存储有第一应用。接收模块，用于接收来自应用商店的第一应用。

一些实现方式中，第一应用与应用商店中的第二应用具有关联关系，能够调用第二应用以实现第二应用的功能。接收模块，还用于接收来自应用商店的第二应用。

一些实现方式中，第一应用中包括第一信息，第一信息用于指示与第一应用关联的第二应用。

一些实现方式中，第一信息包括第二应用的标识。应用商店中的不同应用的标识不同。

第五方面，本申请提供一种应用管理装置，所述装置应用于第二应用仓库。该装置包括：

发送模块，用于向应用商店发送第二下载请求，第二下载请求用于请求从应用商店下载第二应用。处理模块，用于基于第二应用生成第一应用。

一些实现方式中，发送模块，还用于向应用商店发送应用上传请求，应用上传请求用于指示向应用商店上传第一应用。发送模块，还用于向应用商店发送第一应用。

一些实现方式中，处理模块，还用于建立第一应用与第二应用的关联关系，第一应用能够调用第二应用以实现第二应用的功能。处理模块，还用于根据关联关系，基于第二应用生成第一应用。发送模块，还用于向应用商店发送第一应用，第一应用中包含第一应用与第二应用的关联关系。

第六方面，本申请提供一种应用管理装置，所述装置应用于应用商店。

该装置包括：

接收模块，用于接收来自第一应用仓库的第一下载请求，第一下载请求用于请求下载应用商店中的第一应用。发送模块，用于响应于第一下载请求，向第一应用仓库发送第一应用。

一些实现方式中，接收模块，还用于响应第二应用仓库发送的应用上传请求，接收来自第二应用仓库的第一应用。

一些实现方式中，应用商店中存储有第二应用。接收模块，还用于接收来自第二应用仓库的第二下载请求，第二下载请求用于请求下载第二应用。发送模块，还用于向第二应用仓库发送第二应用。

一些实现方式中，该装置还包括：处理模块，处理模块，还用于建立第一应用和第二应用的关联关系。第一应用能够调用第二应用以实现第二应用的功能。

一些实现方式中，第一应用中包括第一信息，第一信息用于指示与第一应用关联的第二应用。

一些实现方式中，发送模块，还用于响应于第一下载请求，向第一应用仓库发送第一应用和第二应用，第一应用包含第一应用和第二应用的关联关系。

第七方面，本申请提供一种电子设备。电子设备包括：处理器，用于存储处理器可执行指令的存储器；处理器被配置为执行所述指令时，使得电子设备实现如第一方面、第二方面或第三方面中任意一种可能的实现方式所述的方法。

第八方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序指令；当所述计算机程序指令被电子设备执行时，使得电子设备实现如第一方面、第二方面或第三方面中任意一种可能的实现方式所述的方法。

第九方面，本申请提供一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备中运行时，所述电子设备中的处理器实现如第一方面、第二方面或第三方面中任意一种可能的实现方式所述的方法。

基于上述第一方面至第九方面中的任一方面，本申请至少具备如下有益效果：

本申请中，第一应用仓库、应用商店和第二应用仓库中传输的均为第一应用。也就是说，第二应用仓库可以将第一应用传输至应用商店，第一应用仓库可以从应用商店获取第一应用。这样一来，在第一应用下载到第一应用仓库之后，消费者可以运行第一应用。相较于目前的技术方案，本申请技术方案下载的并非应用安装包，无需再安装第一应用。如此，通过仓库进行应用程序的传输，简化了传输的过程，用户能够更便捷的开发、运行应用程序。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理，并不构成对本申请的不当限定。

图1为本申请实施例提供的模型和预定义的关系示意图；

图2为本申请实施例提供的数据模型的示意图；

图3为本申请实施例提供的应用管理方法的流程示意图；

图4为本申请实施例提供的应用管理方法的另一流程示意图；

图5为本申请实施例提供的第二应用的APP模型的组成示意图；

图6为本申请实施例提供的应用管理方法的又一流程示意图；

图7为本申请实施例提供的应用管理方法的又一流程示意图；

图8为本申请实施例提供的一种应用管理***的组成示意图；

图9为本申请实施例提供的应用管理装置的结构示意图；

图10为本申请实施例提供的应用管理装置的另一结构示意图；

图11为本申请实施例提供的应用管理装置的又一结构示意图；

图12为本申请实施例提供的应用管理装置的又一结构示意图。

具体实施方式

为了使本领域普通人员更好地理解本申请的技术方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

还应当理解的是，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其他特征、整体、步骤、操作、元素和/或组件的存在或添加。

“和/或”用于描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

应用程序也称应用，是指为完成某项或多项特定工作的计算机程序，可以运行在用户模式和用户进行交互，可以具有可视的用户界面。

目前，应用的开发者可以将开发好的应用上架到应用商店中，需要使用APP的用户可以从应用商店中下载应用安装包，并通过应用安装包将应用安装到本地终端(如手机、平板电脑、智能电视等)。其中，应用商店可以在服务器、计算机等硬件设备上实现，也可以为用户提供一个可以交互的应用商店界面，供用户下载需要的应用。

例如，应用商店中存储有应用A、应用B和应用C。本地终端可以显示应用商店的界面，应用商店的界面包括：应用A的图标、应用B的图标和应用C的图标。然后，在用户需要应用A的情况下，本地终端可以接收用户的下载应用A的操作。响应于下载应用A的操作，本地终端可以从应用商店下载应用A的安装包，并通过应用A的安装包将应用A安装到本地终端。

但是，将应用保存到本地终端之后，会占用本地终端的存储资源，影响本地终端的性能。并且，在下载安装完成应用之后，终端才可以运行下载完成的应用。因此，终端运行应用的过程较为繁琐。此外，在运行应用时，本地终端需要为应用分配运行所需要的资源(如内存资源)，即运行应用会进一步占用本地终端的资源。如此，在运行应用时，会进一步影响本地终端的性能。

基于此，本申请实施例提供了一种应用管理方法，该方法可以应用于应用仓库和应用商店，通过该方法不仅可以简化运行应用的步骤，而且可以有效节省应用所占据的本地终端的存储资源，进而提高本地终端的性能。

需要说明的是，在工业相关场景中，可以基于服务器、计算机等硬件设备构建一个工业互联网平台，该工业互联网平台可以包括应用仓库和应用商店。应用的开发者可以将开发好的应用上架到工业互联网平台中，需要使用应用的用户可以从工业互联网平台中下载使用应用。

示例性地，该方法具体可以在应用仓库和应用商店对应的硬件设备上实现，如：硬件设备可以包括服务器、计算机等。其中，服务器可以是单独的一个服务器，或者，也可以是由多个服务器构成的服务器集群。部分实施方式中，服务器集群还可以是分布式集群。本申请对应用仓库和应用商店对应的硬件设备的具体实现方式不作限制。

需要说明的是，本申请实施例中涉及到的应用仓库侧实现步骤，均可以是由应用仓库对应的硬件设备来实现。本申请实施例中涉及到的应用商店侧实现步骤，均可以是由应用商店对应的硬件设备来实现。其中，应用仓库和应用商店可以部署在同一个硬件设备上。或者，应用仓库和应用商店可以部署在不同硬件设备上。

下面以应用仓库和应用商店为例，介绍本申请实施例提供的应用管理方法。其中，应用仓库可以包括第一应用仓库和第二应用仓库，第一应用仓库为消费者所使用的应用仓库，第二应用仓库为开发者所使用的应用仓库。

需要说明的是，消费者是指使用终端运行应用的用户。开发者是指开发应用的用户。

在本申请实施例中，对应用进行管理的方法可以分为四个阶段，四个阶段包括：阶段一、阶段二、阶段三和阶段四。其中，阶段一为在开发平台开发应用，生成开发完成的应用(可以称为成品应用)。阶段二为将成品应用上传至第二应用仓库。阶段三为将成品应用从第二应用仓库上传至应用商店。阶段四为将成品应用从应用商店下载至第一应用仓库。

下面先对阶段一，即将开发完成的应用(可以称为成品应用)上传至第二应用仓库的过程进行介绍。

在一些实施例中，第一应用(即成品应用)可以仅实现第一应用自身的功能函数的程序逻辑。

在本申请实施例中，开发第一应用的过程可以如下：

1)创建第一应用的APP模型(即应用模型)，并为第一应用的APP模型分配唯一标识(如全球唯一标识)。例如，第一应用的开发者可以在开发工作室中创建第一应用的APP模型。

2)定义第一应用的APP模型依赖的数据模型，发布第一应用的APP模型依赖的数据模型的数据预定义(简称第二应用的数据预定义)。

需要说明的是，本申请中提到了模型和预定义的概念，模型是在建模抽象时描述对象结构的信息，预定义是确定了结构的模型并配置有参数的信息。预定义上记录了模型的信息，预定义用来实例化对象，实例化对象是按照其模型的结构构建对象的结构，并把参数值作为对象的初始值。预定义也能被其他模型引用为子预定义。

例如，创建数据模型时，操作可以包括：新建模型，分配名字和标识；添加成员，指定成员类型；删除成员；添加或删除子预定义；设置子预定义的初值；更新模型版本；发布某模型版本生成预定义等。创建预定义时，操作可以包括：指定某模型版本发布(创建)预定义；分配名称和标识；设置预定义的参数值(属性的值和成员的值)等。

图1为本申请实施例提供的模型和预定义的关系示意图。

如图1所示，模型可以包括基本属性和成员列表；基本属性可以包括名称、描述、全局唯一标识符(globally unique identifier，GU ID)、版本等信息；成员列表可以包括：“成员1：名称+类型”、“成员2：名称+类型”、“成员3：名称+类型”等信息。

预定义可以包括基本属性和成员列表；基本属性可以包括名称、描述、GUID、模型GUID+版本等信息；成员列表可以包括：“成员1+值”、“成员2+值”、“成员3+值”等信息。

步骤2)中所述的数据模型是数据库中的概念，描述了数据库中数据对象的结构，是客观世界对象的抽象描述。

示例性地，图2为本申请实施例提供的数据模型的示意图。如图2所示，数据模型可以包括：基本属性、成员列表、以及子模型列表。具有子模型的数据模型是复合的数据模型，如：图中的数据模型A为复合的数据模型，数据模型B和数据模型C是数据模型A的子模型。

数据模型中，基本属性描述了数据的固有属性，包括名称、描述、GUID、时间属性(如精度)、空间属性(如坐标系、几何形状)等；成员列表描述了自由定义的字段，每个成员描述其字段名称、数据类型，如：成员1、成员2等。子模型列表中记录了引用为子模型的数据模型的数据预定义的标识，建立了子模型和数据模型之间的依赖关系，例如，数据模型A的子模型列表包括数据模型B和数据模型C的数据预定义的标识，如：“名称B1+引用模型ID+参数值”、“名称B2+引用模型ID+参数值”、“名称C3+引用模型ID+参数值”等。

例如，电机设备都具有转速、温度、电流等参数，建立电机设备的数据模型，电机设备的数据模型可以包括转速、温度、电流的成员，通过电机设备的数据模型可以对同类的电机统一描述。

又例如，假设压缩机车间内部都有定盘生产线、静盘生产线、总装生产线，建立压缩机车间的数据模型，压缩机车间的数据模型的内部可以包括子模型：定盘生产线、静盘生产线、总装生产线等。压缩机车间的数据模型可以描述同类的压缩机车间模型。

3)定义第一应用的APP模型依赖的资源对象(简称第一应用的资源对象)到资源库，并为第一应用的资源对象分配唯一标识(如全球唯一标识)。

其中，资源对象是数据库中的概念。把二进制文件数据进行对象化组织和管理，为每个资源对象分配标识，第一应用的APP模型能够通过资源对象的标识访问资源对象的数据。

例如，把图标定义为资源对象和第一应用的APP模型之间形成依赖关系，则第一应用的APP模型可以使用这个图标。又例如，把视频文件定义为资源对象和第一应用的APP模型之间形成依赖关系，则第一应用的APP模型可以通过依赖关系读取视频文件进行播放。

4)在第二应用的APP模型上建立第二应用的依赖数据预定义列表，从第二应用的***仓库中选择第二应用的数据预定义，将第二应用的数据预定义的标识记录在第二应用的依赖数据预定义列表上。其中，第二应用的***仓库中的数据预定义可以是开发者自建的，也可以是从应用商店上购买的。

5)在第二应用的APP模型上建立第二应用的依赖资源列表，从资源库中选择第二应用的资源对象，把第二应用的资源对象的标识记录在第二应用的依赖资源列表上。其中，资源库中的资源对象可以是开发者自建的，也可以是从应用商店上购买的。

6)编写第一应用的APP模型的功能函数的程序逻辑。

7)根据第一应用的APP模型生成第一应用的APP模型的预定义(简称第一应用的预定义，也可以称为第一应用的配置信息)，并为第一应用的预定义分配唯一标识(如全球唯一标识)。第一应用的预定义的标识即第一应用的标识。

其中，发布第一应用的预定义时，还可以设置预定义的参数值(如：属性的值和成员的值)。

在另一些实施例中，第一应用(即成品应用)可以实现多个应用的功能函数的程序逻辑。以下以多个应用包括第一应用和第二应用为例，介绍开发第一应用的过程。

在本申请实施例中，开发第一应用的过程可以如下：

a)执行上述步骤1)-步骤5)。

b)添加第一应用的APP模型的子APP列表，从第一应用的***仓库中选择作为子APP的第二应用的预定义，将第二应用的预定义的标识记录在第一应用的APP模型的子APP列表上。第二应用的预定义即从应用商店获取的第二应用。第二应用的预定义的标识即前述实施例中所述的第二应用的标识。

需要说明的是，第二应用的预定义可以由第二应用的版权所有者或者开发者上传到应用商店中。并且，可以在应用商店添加第二应用的图标logo、应用说明和第二应用的价格表。

c)执行上述步骤6)-步骤7)。

可以理解的，第二应用的开发过程与第一应用的开发过程类似。其区别仅仅在于，当第二应用不包括更深层级的子APP(即第二应用没有调用其他应用实现其他应用的功能)时，第二应用的开发过程中不包括类似于上述步骤6)中所述的过程。当第二应用还包括更深层级的子APP(即第二应用调用其他应用实现其他应用的功能)时，第二应用的开发过程中与上述步骤1)-步骤8)所述的过程一致。在此对第二应用的开发过程不再赘述。

在第一应用开发完成之后，下面对阶段二，即将成品应用上传至第二应用仓库的过程进行介绍。

图3为本申请实施例提供的应用管理方法的流程示意图。如图3所示，该应用管理方法可以包括：

S301、第二应用仓库向开发平台发送第一上传请求。

其中，第一上传请求用于请求开发平台上传第一应用。

在一种可能的实现方式中，第二应用仓库接收第一上传操作，所述第一上传操作用于指示将开发平台中存储的第一应用上传至第二应用仓库。响应于第一上传操作，第二应用仓库向开发平台发送第一上传请求。

在本申请实施例中，开发平台用于生成第一应用。

一种可能的设计中，第一应用包括第一应用的配置信息，第一应用的配置信息由第一应用的应用模型生成，第一应用的应用模型用于指示第一应用的程序代码。第一应用的应用模型用于实现第一应用的功能函数的程序逻辑。

示例性的，应用A中的数据模型能够实现功能A、功能B和功能C，则应用A的数据模型包括：用于实现功能A的程序代码、用于实现功能B的程序代码、用于实现功能C的程序代码、和描述功能A、功能B和功能C之间的逻辑关系的程序代码。

一种可能的设计中，开发平台可以部署在云端服务器。

可以理解的是，在开发平台部署在云端服务器的情况下，开发人员在开发平台开发应用程序时，不会占用开发者本地终端的资源。如此，可以节约开发者本地终端的资源，提高开发者本地终端的性能。

另一种可能的设计中，开发平台可以部署在开发本地服务器(即本地终端)。

可以理解的是，在开发平台部署在本地服务器的情况下，在开发平台开发应用程序时，可以提高获取本地数据的速度。如此，可以提高开发效率，降低开发应用的程序时间。

需要说明的是，通常情况下，为了避免占用本地服务器较多资源，在应用程序的数据量小于预设数据量阈值的情况下，可以将开发平台部署在本地服务器。例如，预设数据量阈值可以为10兆。又例如，预设数据量阈值可以为100兆。又例如，预设数据量阈值可以为150兆。

S302、开发平台接收第一上传请求。

一种可能的设计中，第一上传请求包括第一应用的标识。

在一些实施例中，开发平台中存储有第一应用与第一应用的标识之间的对应关系。开发平台可以根据第一应用的标识查询第一应用。

S303、开发平台向第二应用仓库发送第一应用。

S304、第二应用仓库接收来自开发平台的第一应用。

S305、第二应用仓库保存第一应用。

需要说明的是，本申请实施例对第二应用仓库部署的终端不作限定。

一种可能的设计中，第二应用仓库可以部署在云端服务器。

也就是说，第一应用可以存储在云端服务器。

另一种可能的设计中，第二应用仓库可以包括第三子仓库和第四子仓库。其中，第三子仓库部署在云端服务器，第四子仓库部署在本地服务器。第三子仓库用于存储第一应用。

也就是说，第一应用可以存储在部署云端服务器的仓库。

可以理解的是，在第一应用开发完成之后，开发平台可以将第一应用上传至第二应用仓库。这样一来，开发完成的应用无需占用开发者的本地终端。如此，可以节约开发者的本地终端的资源，提高本地终端的性能。

在一些实施例中，在开发平台向第二应用仓库上传第一应用之前，第二应用仓库可以从应用商店下载第二应用，并由开发平台建立第一应用与第二应用的关联关系。

图4为本申请实施例提供的应用管理方法的流程示意图。如图4所示，该应用管理方法可以包括：

S401、第二应用仓库向应用商店发送第二下载请求。

其中，第二下载请求用于请求下载第二应用。

在本申请实施例中，应用商店中存储有第二应用。第二应用可以包括第二应用的配置信息，第二应用的配置信息由第二应用的应用模型生成，第二应用的应用模型用于指示第二应用的程序代码。

S402、应用商店接收来自第二应用仓库的第二下载请求。

一种可能的设计中，第二下载请求包括第二应用的标识。

在一些实施例中，应用商店中存储有第二应用与第二应用的标识之间的对应关系。开发平台可以根据第二应用的标识查询第二应用。

S403、应用商店向第二应用仓库发送第二应用。

S404、第二应用仓库接收来自应用商店的第二应用。

在一些实施例中，在第二应用仓库向应用商店发送第二下载请求之后，第二应用仓库可以基于第二应用生成第一应用。

S405、第二应用仓库保存第二应用。

在本申请实施例中，第二应用可以存储至部署在云端服务器的第二应用仓库。

可以理解的是，第二应用仓库可以从应用商店下载第二应用，并保存第二应用。也就是说，第二应用可以存储多个应用，如第一应用和第二应用。这样一来，不仅可以节约本地终端的资源，而且开发平台可以从第二应用仓库调用其他应用，以提高开发效率。

在一些实施例中，开发者或者版权所有者可以将第一应用与第二应用建立关联关系，以使得第一应用能够调用第二应用以实现第二应用的功能。如图4所示，该应用管理方法还可以包括：

S406、开发平台向第二应用仓库发送第一调用请求。

其中，第一调用请求用于请求调用第二应用。

S407、第二应用仓库接收来自开发平台的第一调用请求。

在一些实施例中，第二应用仓库存储有第二应用与第二应用的标识之间的对应关秀。在第二应用仓库接收来自开发平台的第一调用请求之后，第二应用仓库根据第二应用的标识查找第二应用。

S408、第二应用仓库向开发平台发送第二应用。

相应的，开发平台接收来自第二应用仓库的第二应用。

S409、开发平台建立第一应用与第二应用之间的关联关系。

其中，第一应用与第二应用之间建立关联关系之后，第一应用能够调用第二应用以实现第二应用的功能。

在一种可能的实现方式中，开发平台将第二应用的标识添加至第一应用的应用模型。或者，开发平台可以在第一应用中增加第二应用的标识，或者，增加能够指示第二应用的一些字段。第二应用的标识或者能够指示第二应用的字段即为上述第一信息。也即，第一信息可以包括：第二应用的标识或能够指示第二应用的一些字段。

本申请中，应用商店中的不同应用的标识不同。也即，应用商店中的不同应用具有唯一标识。

需要说明的是，第一应用和第二应用的版权所有者相同或不同。第一应用和第二应用的开发者相同或不同。

这样一来，在调用第一应用的时候，可以根据第二应用的标识，调用第二应用，以实现第二应用的功能。

可选的，第二应用仓库可以建立第一应用与第二应用的关联关系。之后，第二应用仓库可以根据第一应用与第二应用的关联关系，基于第二应用生成第一应用。

示例性地，图5为本申请实施例提供的第一应用的APP模型的组成示意图。

如图5所示，第一应用的应用模型可以包括：基本属性、依赖数据列表、功能函数列表、以及子APP列表。

基本属性可以包括：名称、描述、以及GUID(即第一应用的应用模型的唯一标识)。

依赖数据列表记录了第一应用的应用模型需要使用的数据模型或资源对象，在第一应用的应用模型，以及依赖的数据模型或资源对象之间建立了关系。例如，“数据1：数据ID”、“数据2：数据ID”等表示依赖的数据模型的数据预定义的标识或资源对象的标识。依赖数据列表可以包括上述依赖数据预定义列表和/或上述依赖资源列表。

功能函数列表可以包括：函数1、函数2等第一应用的APP模型的功能函数，这些功能函数是第一应用的应用模型的程序逻辑的实现。

子APP列表中记录了第二应用的信息，在第一应用的应用模型和第二应用之间建立的关联关系。例如，子APP列表可以包括子APP-B1、APP-C2、APP-D3等第二应用的标识和配置参数。也即，应用模型B、应用模型C、以及应用模型D等可以是上述第二应用。

在另一种可能的实现方式中，开发平台将第二应用的预定义(即第二应用的配置信息)添加至第一应用。

示例性的，假如应用A包括功能A和功能B，应用B包括功能C。在应用A与应用B建立关联关系之后，应用A可以调用应用B实现功能C。

可以理解的是，开发平台从第二应用仓库调用第二应用，可以建立第一应用与第二应用之间关联关系。如此，开发人员无需开发第二应用，可以使得第一应用能够调用第二应用以实现第二应用的功能，即调用第一应用可以实现第二应用的功能。

在另一些实施例中，第二应用和第一应用的开发者相同，开发者可以在本地开发完成第二应用，并根据第二应用开发生成第一应用，然后将第二应用和第一应用上架到应用商店中。

在一些实施例中，在第一应用上传至第二应用仓库之后，开发者或者版权所有者可以将第一应用上传至应用商店(即阶段三)。

图6为本申请实施例提供的应用管理方法的流程示意图。如图6所示，该应用管理方法可以包括：

S601、应用商店向第二应用仓库发送第二上传请求。

其中，第二上传请求用于指示向应用商店上传第一应用。

在一种可能的实现方式中，应用商店接收第二上传操作，第二上传操作用于指示将第一应用上传至应用商店。响应于第二上传操作，应用商店向第二应用仓库发送第二上传请求。

S602、第二应用仓库接收来自应用商店的第二上传请求。

一种可能的设计中，第二上传请求包括第一应用的标识。

在一些实施例中，第二应用仓库根据第一应用的标识查找第一应用。

S603、第二应用仓库向应用商店发送第一应用。

在一些实施例中，第二应用仓库向应用商店发送第一应用，其中，第一应用中包括第一应用与第二应用的关联关系。

S604、应用商店接收来自第二应用仓库的第一应用。

在一些实施例中，应用商店接收到第一应用之后，可以保存第一应用。

可以理解的是，将第一应用上传至应用商店之后，应用商店可以保存第一应用。这样一来，消费者可以从应用商店下载第一应用，并运行第一应用。而无需再安装第一应用，减少了运行第一应用的流程，提升了用户的使用体验。

在另一些实施例中，第二应用仓库向应用商店发送应用上传请求，并向所述应用商店发送所述第一应用，应用上传请求用于指示向应用商店上传所述第一应用。

可选的，应用上传请求包括第一应用。

可以理解的是，第二应用仓库向应用商店发送应用上传请求，并向所述应用商店发送所述第一应用。如此，可以将第一应用传输至应用商店，简化了传输应用的过程。

在本申请实施例中，应用商店响应第二应用仓库发送的应用上传请求，接收来自第二应用仓库的所述第一应用。

在一些实施例中，应用商店中存储第一应用与第二应用之后，应用商店可以建立第一应用与第二应用之间的关联关系。

例如，第二应用可以实现的功能为第二功能，则第一应用中不包括用于实现第二功能的代码，也可以通过调用第二应用的方式实现第二功能。

通过建立第一应用和第二应用的关联关系，可以使得当第一应用被下载时，应用商店能够将第一应用和第二应用一并进行下发。例如，用户可以使用用户设备(如手机、电脑等)向应用商店发送下载第一应用的请求。应用商店可以响应于该请求，向用户设备下发第一应用，同时，由于第一应用和第二应用之间建立了关联关系，所以应用商店可以基于该关联关系一并向用户设备下发第二应用。当用户设备运行下载后的第一应用时，第一应用可以调用下载的第二应用实现第二应用的功能。

下面对建立第一应用和第二应用的关联关系的实现方式进行示例性说明。

一些实现方式中，第一应用中可以包括第一信息，第一信息用于指示与第一应用关联的第二应用。应用商店建立第一应用和第二应用的关联关系，可以包括：基于第一应用中包括的第一信息，建立第二应用和第一应用的关联关系；或者，将第一应用中包括的第一信息作为第二应用和第一应用的关联关系。

在应用商店中存储有应用的情况下，第一应用仓库可以从应用商店获取应用。下面对阶段四，即将成品应用从应用商店下载至第一应用仓库进行介绍。

图7为本申请实施例提供的应用管理方法的流程示意图。如图7所示，该应用管理方法可以包括：

S701、第一应用仓库向应用商店发送第一下载请求。

其中，第一下载请求用于请求下载应用商店中的第一应用，应用商店中存储有第一应用。

在一种可能的实现方式中，第一应用仓库可以接收第一下载操作(如购买第一应用的操作)，第一下载操作用于请求获取使用第一应用的权限。响应于第一下载操作，第一应用仓库向应用商店发送第一下载请求。

S702、应用商店接收来自第一应用仓库的第一下载请求。

其中，第一下载请求包括第一应用的标识。

在一些实施例中，应用商店中存储有第一应用与第一应用的标识之间的对应关系。应用商店可以根据第一应用的标识查找第一应用。

S703、应用商店向第一应用仓库发送第一应用。

在一种可能的实现方式中，响应于第一下载请求，应用商店向第一应用仓库发送第一应用的预定义，第一应用的预定义包括第一应用的应用模型。

S704、第一应用仓库接收来自应用商店的第一应用。

S705、第一应用仓库保存第一应用。

也就是说，第一应用仓库中保存有第一应用的配置信息，即第一应用仓库中保存有第一应用的功能函数的程序逻辑和第一应用的配置数据。

可以理解的是，在第一应用下载到第一应用仓库之后，消费者可以运行第一应用(即第一应用的配置信息)。相较于目前的技术方案，本申请技术方案下载的并非应用安装包，无需再安装第一应用。如此，可以减少运行第一应用的流程，提升了用户的使用体验。

在一些实施例中，第一应用仓库可以部署在云端服务器。也就是说，第一应用可以保存在云端服务器。

在另一些实施例中，第一应用仓库中部分仓库可以部署在云端服务器，另一部分仓库可以部署在本地终端。第一应用仓库包括第一子仓库和第二子仓库。其中，第一子仓库部署在云端服务器，第二子仓库部署在本地终端。

需要说明的是，第一应用保存在第一子仓库。也就是说，第一应用可以保存在云端服务器。

可以理解的是，第一应用保存在云端服务器，可以避免占用本地终端的存储资源。如此，可以节约本地终端的资源，进而提高本地终端的性能。

在一些实施例中，第一应用与应用商店中的第二应用具有关联关系，能够调用第二应用以实现第二应用的功能。在第一应用仓库向应用商店发送第一下载请求之后，应用商店响应于第一下载请求，可以向第一应用仓库发送第一应用和第二应用。

在本申请实施例中，第一应用中包括第一信息，第一信息用于指示与第一应用关联的第二应用。其中，第一信息包括第二应用的标识。

在一种可能的实现方式中，在第一应用仓库向应用商店发送第一下载请求之后，应用商店可以根据第一应用的标识查找第一应用。之后，根据第一应用中第二应用的标识，查找第二应用。之后，应用商店向第一应用仓库发送第一应用和第二应用。第一应用仓库可以接收来自应用商店的第一应用和第二应用。之后，第一应用仓库可以保存第一应用和第二应用。

也就是说，在本申请实施中，第一应用仓库中可以保存第一应用的预定义和第二应用的预定义。

可以理解的是，在第一应用和第二应用下载到第一应用仓库之后，消费者可以从应用商店下载第一应用和第二应用，并运行第一应用。相较于目前的技术方案，本申请技术方案下载的并非应用安装包，无需再安装第一应用。如此，可以减少运行第一应用的流程，提升了用户的使用体验。并且，用户只需下载第一应用便可以同时下载第一应用和第二应用，并在运行第一应用之后，可以调用第二应用的功能，减少了终端下载和运行第二应用的步骤。

在一些实施例中，在第一应用仓库中保存第一应用之后，用户可以通过目标计算节点运行第一应用。其中，目标计算节点可以为云端服务器。或者，目标计算节点可以为本地终端。

需要说明的是，应用商店、应用仓库所部署的云端服务器和目标计算节点对应的云端服务器可以为同一个云端服务器，也可以为不同的云端服务器，本申请实施例对此不作限定。

在一种可能的实现方式中，响应于第一运行操作(如双击第一应用的图标)，可以生成第一运行请求，第一运行操作用于触发运行第一应用，第一运行请求用于请求运行第一应用。第一应用仓库可以接收第一运行请求。之后，第一应用仓库向目标计算节点发送第一应用，以使得目标计算节点创建第一应用的实例，将第一应用的功能逻辑部署在目标计算节点；其中，目标计算节点用于通过目标资源运行第一应用的实例。

在一种可能的设计中，第一应用仓库向目标计算节点发送第二指示消息，第二指示消息用于指示目标计算节点为运行第一应用分配目标资源。其中，第二指示消息可以包括第一应用和第二信息，第二信息用于指示目标资源的数量。

示例性的，目标资源包括：第一数量的中央处理器(central processing unit，CPU)资源、第二数量的内存资源、第三数量的网络带宽等。例如，目标资源包括：5％的CPU资源、8％的内存资源、100兆的网络带宽。

目标计算节点可以接收第二指示消息。之后，目标计算节点根据第一应用的配置信息(即第一应用的预定义)创建第一应用的实例，并根据第一应用的配置信息的标识确定第一应用的应用模型，将第一应用的应用模型中的功能函数的程序逻辑部署在目标计算节点。

需要说明的是，应用的预定义中携带了应用的应用模型的标识。目标计算节点可以从第一应用的预定义中确定第一应用的应用模型的标识。之后，目标计算节点根据第一应用的应用模型的标识确定第一应用的应用模型，将应用的应用模型的功能函数的程序逻辑部署在目标计算节点。

示例性的，应用A的预定义中存储的应用A的应用模型的标识为标识a，则目标计算节点可以根据标识a获取应用A的应用模型，将应用A的应用模型的功能函数的程序逻辑部署在目标计算节点。

在另一种可能的设计中，第一应用仓库可以向运维计算节点发送第一应用，其中，运维计算节点用于维护第一应用的运行。之后，运维计算节点可以向目标计算节点发送第二指示消息。

可选的，第一应用仓库或者运维***(即运维计算节点)中存储有多个计算节点的资源信息，计算节点的资源信息用于反映计算节点中可用资源的数量。第一应用仓库或者运维***可以根据多个计算节点的资源信息，确定目标计算节点，目标计算节点为多个计算节点中可用资源最多的计算节点。

可以理解的是，第一应用仓库接收第一运行请求，向目标计算节点发送第一应用，以使得目标计算节点创建第一应用的实例，将第一应用的功能逻辑部署在目标计算节点；其中，目标计算节点用于通过目标资源运行第一应用的实例。也就是说，本申请实施例中的第一应用从应用商店下载到第一应用仓库之后，可以直接运行，而无需安装，减少了运行应用的流程。并且，第一应用可以运行在目标计算节点，不会占用本地终端的资源，以提高本地终端的性能。

可选的，在本申请中，第一应用可以称为成品APP，第一应用的子APP(如第二应用)可以称为零件APP。成品APP可以是能够独立运行的程序。零件APP可以是能够独立运行的APP程序，也可以是不独立运行的程序。零件APP能够作为一个或多个成品APP的子APP，实现被成品APP调用以实现零件APP的功能。

可以理解的，零件APP和成品APP是个相对概念，作为子APP的应用都可以认称为零件APP。例如，存在一个第三应用可以调用第一应用实现第一应用的功能时，第三应用是成品APP，第一应用是零件APP。

下面以一个具体的示例，对本申请实施例提供的应用管理方法进行更进一步的说明。

图8为本申请实施例提供的一种应用管理***的组成示意图。如图8所示，应用管理***可以包括至少一个开发***(如开发***1和开发***2)、至少一个应用商店、以及至少一个消费者***。

其中，开发***1包括第二开发平台和第二应用仓库。第二开发平台可以是用于开发成品APP(如上述第一应用)，第二应用仓库用于存储开发完成的成品APP和其他子APP。成品APP的开发者可以从应用商店中下载零件APP到第二应用仓库中。之后，开发者可以将第二应用仓库中的零件APP发送至第二开发平台。第二开发平台可以调用零件APP生成成品APP，该成品APP与零件APP具有关联关系，能够调用零件APP实现零件APP的功能。之后，第二开发平台可以向第二应用仓库发布成品APP，并将成品APP上架到应用商店中。其中，第二应用仓库可以通过网络把成品APP上传到应用商店。

开发***2包括第一开发平台和第三应用仓库。第一开发平台可以是用于开发零件APP(如上述第二应用)，第三应用仓库用于存储开发完成的零件APP和其他子APP。开发者或者版权所有者可以将零件APP上架到应用商店中。

可选的，开发***1和开发***2可以为同一个开发***(如开发***1)。也就是说，开发***1中的第二开发平台既可以开发成品APP，也可以开发零件APP。同理，第二应用仓库可以存储成品APP和零件APP，并将成品APP和零件APP上架至应用商店。

需要说明的是，开发平台可以开发应用的应用模型，并将应用模型存储在开发平台的底层数据库中。应用仓库可以将应用(即应用的配置信息或者应用的预定义)存储在应用仓库的底层数据库中。开发平台和应用仓库是两个服务***通过网络通信进行数据传输的。

应用商店用于存储开发完成的成品APP和零件APP。并且，应用商店中存储有成品APP与零件APP之间的关联关系。并且，版权所有者在应用商店可以创建应用对应的资源，包括上传成品APP的预定义、零件App预定义，上传应用的图标，添加应用的说明，制定应用的价位等。并且，应用商店响应于下载操作，可以向消费者***传输成品APP与零件APP。应用商店可以为用户(消费者和开发者)展示应用的相关信息(如图标、说明、价格等)。

需要说明的是，成品App的版权所有者从应用商店中下载零件App到第二应用仓库时，下载App需要支付费用，或者，不需要支付费用。

示例性的，应用商店可以包括商店1和商店2，商店1用于存储展示成品APP，商店2用于存储展示零件APP。商店1和商店2占用的应用商店的数据库中的分区不同。可选的，成品APP和零件APP可以存储在同一个商店(如商店1)。

消费者***包括第一应用仓库，第一应用仓库可以是使用第一应用的消费者(用户)侧的仓库。消费者可以使用本地终端从应用商店中下载成品APP到第一应用仓库。当消费者使用用户设备从应用商店中下载成品APP时，应用商店可以将成品APP和与成品APP具有关联关系的零件APP一并下发到消费者***。其中，第一应用仓库既可以部署在本地终端，也可以部署在云端服务器。

第一应用仓库可以下载第一应用，并生成第一应用的实例。之后，第一应用仓库可以向运行环境发送第一应用的实例，以使得运行环境运行第一应用。

可选的，消费者***还可以包括运维***，该运维***用于维护APP的运行。在第一应用仓库接收到运行成品APP的指令时，第一应用仓库可以向运维***发送成品APP。之后，运维***可以根据成品APP创建成品APP的实例，并将成品APP的实例发送至运行环境。同时，运维***可以指示运行环境为成品APP的实例分配目标资源。运维***可以根据成品APP的预定义的标识，确定成品APP的应用模型，并将成品APP的应用模型的功能函数的程序逻辑部署在运行环境。之后，运行环境可以调用目标资源运行成品APP的实例，执行成品APP的功能函数的程序逻辑。其中，成品APP的实例包括成品APP的预定义的标识(即成品APP的标识)。运维***、应用仓库，运行环境之间通过网络通信完成App程序文件的部署过程。

其中，该运行环境可以部署在目标计算节点。

可选的，应用商店可以包括一个由店铺***和交易***组成的商店***。该商店***可以作为应用商店的运营商运营的商品交易流通***。APP软件开发企业(即开发者)和生产企业(即消费者)可以通过商店***完成APP的交易和共享。其中，店铺***可以包括一个或多个店铺，用于存放上架的APP商品，负责APP的上架、下载、授权钥匙分发等。交易***可以实现订单管理、支付管理等功能。

可以理解的，在实际实施时，本申请实施例所述的应用商店、应用仓库、本地终端等可以包含有用于实现前述对应的应用管理方法的一个或多个硬件结构和/或软件模块，这些执行硬件结构和/或软件模块可以构成一个电子设备。本领域技术人员应该很容易意识到，结合本文中所申请的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

基于这样的理解，以应用商店包含的硬件结构和/或软件模块为例，本申请实施例还对应提供一种应用管理装置，可以应用于上述第一应用仓库(如应用商店对应的硬件设备)。图9为本申请实施例提供的应用管理装置的结构示意图。如图9所示，该应用管理装置可以包括：发送模块901、接收模块902。

发送模块901，用于向应用商店发送第一下载请求，第一下载请求用于请求下载应用商店中的第一应用，应用商店中存储有第一应用。接收模块902，用于接收来自应用商店的第一应用。

一些实现方式中，第一应用与应用商店中的第二应用具有关联关系，能够调用第二应用以实现第二应用的功能。接收模块902，还用于接收来自应用商店的第二应用。

一些实现方式中，第一应用中包括第一信息，第一信息用于指示与第一应用关联的第二应用。

一些实现方式中，第一信息包括第二应用的标识。应用商店中的不同应用的标识不同。

本申请实施例还对应提供一种应用管理装置，可以应用于上述第二应用仓库。图10为本申请实施例提供的应用管理装置的另一结构示意图。如图10所示，该应用管理装置可以包括：发送模块1001和处理模块1002。

发送模块1001，用于向应用商店发送第二下载请求，第二下载请求用于请求从应用商店下载第二应用。处理模块1002，用于基于第二应用生成第一应用。

一些实现方式中，发送模块1001，还用于向应用商店发送应用上传请求，应用上传请求用于指示向应用商店上传第一应用。发送模块1001，还用于向应用商店发送第一应用。

一些实现方式中，处理模块1002，还用于建立第一应用与第二应用的关联关系，第一应用能够调用第二应用以实现第二应用的功能。处理模块1002，还用于根据关联关系，基于第二应用生成第一应用。发送模块1001，还用于向应用商店发送第一应用，第一应用中包含第一应用与第二应用的关联关系。

本申请实施例还对应提供一种应用管理装置，可以应用于上述应用商店。图11为本申请实施例提供的应用管理装置的另一结构示意图。如图11所示，该应用管理装置可以包括：接收模块1101、发送模块1102和处理模块1103。

接收模块1101，用于接收来自第一应用仓库的第一下载请求，第一下载请求用于请求下载应用商店中的第一应用。发送模块1102，用于响应于第一下载请求，向第一应用仓库发送第一应用。

一些实现方式中，接收模块1101，还用于响应第二应用仓库发送的应用上传请求，接收来自第二应用仓库的第一应用。

一些实现方式中，应用商店中存储有第二应用。接收模块1101，还用于接收来自第二应用仓库的第二下载请求，第二下载请求用于请求下载第二应用。发送模块1102，还用于向第二应用仓库发送第二应用。

一些实现方式中，该装置还包括：处理模块1103，处理模块1103，还用于建立第一应用和第二应用的关联关系。第一应用能够调用第二应用以实现第二应用的功能。

一些实现方式中，第一应用中包括第一信息，第一信息用于指示与第一应用关联的第二应用。

一些实现方式中，发送模块1102，还用于响应于第一下载请求，向第一应用仓库发送第一应用和第二应用，第一应用包含第一应用和第二应用的关联关系。

图12示出了上述实施例中所涉及的应用管理装置的又一种可能的结构。该应用管理装置包括：处理器1201和通信接口1202。处理器1201用于对装置的动作进行控制管理，例如，执行上述方法实施例中所示的方法流程中的各个步骤，和/或用于执行本文所描述的技术的其它过程。通信接口1202用于支持该应用管理装置与其他网络实体的通信。应用管理装置还可以包括存储器1203和总线1204，存储器1203用于存储装置的程序代码和数据。

其中，上述处理器1201可以实现或执行结合本发明公开内容所描述的各种示例性的逻辑方框，单元和电路。该处理器可以是中央处理器，通用处理器，数字信号处理器，专用集成电路，现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本发明公开内容所描述的各种示例性的逻辑方框，单元和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

存储器1203可以包括易失性存储器，例如随机存取存储器；该存储器也可以包括非易失性存储器，例如只读存储器，快闪存储器，硬盘或固态硬盘；该存储器还可以包括上述种类的存储器的组合。

总线1204可以是扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。总线1204可以分为地址总线、数据总线、控制总线等。为便于表示，图12中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

如上所述，本申请实施例可以根据上述方法示例对应用管理方法中涉及到的各执行主体进行功能模块的划分。其中，上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。另外，还需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。

关于上述实施例中的应用管理装置，其中各个模块执行操作的具体方式、以及具备的有益效果，均已经在前述方法实施例中进行了详细描述，此处不再赘述。

本申请实施例还提供一种电子设备，该电子设备可以是应用商店对应的硬件设备，或者开发侧的设备，又或者上述用户设备。电子设备包括：处理器，用于存储处理器可执行指令的存储器；处理器被配置为执行所述指令时，使得电子设备实现如前述实施例所述的方法。

在示例性实施例中，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序指令；当所述计算机程序指令被电子设备执行时，使得电子设备实现如前述实施例所述的方法。

可选的，上述计算机可读存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，本申请实施例还提供一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备中运行时，所述电子设备中的处理器实现如前述实施例所述的方法。

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

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

Claims (25)

1.一种应用管理方法，其特征在于，所述方法应用于消费者***的第一应用仓库，所述第一应用仓库部署在云端服务器，所述方法包括：

向应用商店发送第一下载请求，所述第一下载请求用于请求下载应用商店中的第一应用，所述应用商店中存储有所述第一应用，所述第一应用与所述应用商店中的第二应用具有关联关系，能够调用所述第二应用以实现所述第二应用的功能；其中，所述第一应用包括所述第二应用的配置信息，所述第一应用和所述第二应用之间的关联关系包括所述第一应用和所述第二应用的配置信息之间的关联关系，所述第一应用和所述第二应用的配置信息的关联关系是所述应用商店、或第二应用仓库、或第二开发平台将所述第二应用的配置信息添加至所述第一应用中建立的；

接收来自所述应用商店的所述第一应用和所述第二应用；

其中，所述第二应用是第一开发平台开发的应用；所述第一应用是所述第二开发平台或第二应用仓库基于所述关联关系和所述第二应用生成的应用；

接收运行所述第一应用的指令；

响应于运行所述第一应用的指令，向运维***发送所述第一应用，以使得所述运维***在运行环境创建所述第一应用的实例，并运行所述第一应用的实例。

2.根据权利要求1所述的方法，其特征在于，

所述第一应用中包括第一信息，所述第一信息用于指示与所述第一应用关联的所述第二应用。

3.根据权利要求2所述的方法，其特征在于，

所述第一信息包括所述第二应用的标识；

所述应用商店中的不同应用的标识不同。

4.一种应用管理方法，其特征在于，所述方法应用于开发***的第二应用仓库，所述第二应用仓库部署在云端服务器，所述方法包括：

向应用商店发送第二下载请求，所述第二下载请求用于请求从应用商店下载第二应用；其中，所述第二应用是第一开发平台开发的应用；

建立第一应用与所述第二应用的关联关系，所述第一应用能够调用所述第二应用以实现所述第二应用的功能；其中，所述第一应用包括所述第二应用的配置信息，所述第一应用和所述第二应用之间的关联关系包括所述第一应用和所述第二应用的配置信息之间的关联关系，所述第一应用和所述第二应用的配置信息的关联关系是将所述第二应用的配置信息添加至所述第一应用中建立的；

根据所述关联关系，基于所述第二应用生成所述第一应用；

接收运行所述第一应用的指令；

响应于运行所述第一应用的指令，向运维***发送所述第一应用，以使得所述运维***在运行环境创建所述第一应用的实例，并运行所述第一应用的实例。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

向所述应用商店发送应用上传请求，所述应用上传请求用于指示向所述应用商店上传所述第一应用；

向所述应用商店发送所述第一应用。

6.根据权利要求5所述的方法，其特征在于，所述向所述应用商店发送所述第一应用，包括：

向所述应用商店发送所述第一应用，所述第一应用中包含所述第一应用与所述第二应用的关联关系。

7.一种应用管理方法，其特征在于，所述方法应用于应用商店，所述应用商店中存储有第二应用，所述第二应用是第一开发平台开发的应用；所述方法包括：

接收来自第一应用仓库的第一下载请求，所述第一下载请求用于请求下载应用商店中的第一应用，所述第一应用仓库部署在云端服务器；

响应于所述第一下载请求，向所述第一应用仓库发送所述第一应用；

建立所述第一应用和所述第二应用的关联关系；其中，所述第一应用包括所述第二应用的配置信息，所述第一应用和所述第二应用之间的关联关系包括所述第一应用和所述第二应用的配置信息之间的关联关系，所述第一应用和所述第二应用的配置信息的关联关系是将所述第二应用的配置信息添加至所述第一应用中建立的；

其中，所述第一应用能够调用所述第二应用以实现所述第二应用的功能；所述第一应用是第二开发平台或第二应用仓库基于所述关联关系和所述第二应用生成的应用，所述第一应用运行时，在运行环境创建所述第一应用的实例，并运行所述第一应用的实例。

8.根据权利要求7所述的方法，其特征在于，在所述接收来自第一应用仓库的第一下载请求之前，所述方法还包括：

响应第二应用仓库发送的应用上传请求，接收来自所述第二应用仓库的所述第一应用。

9.根据权利要求7或8所述的方法，其特征在于，所述方法还包括：

接收来自第二应用仓库的第二下载请求，所述第二下载请求用于请求下载所述第二应用；

向所述第二应用仓库发送所述第二应用。

10.根据权利要求9所述的方法，其特征在于，

所述第一应用中包括第一信息，所述第一信息用于指示与所述第一应用关联的所述第二应用。

11.根据权利要求10所述的方法，其特征在于，所述响应于所述第一下载请求，向所述第一应用仓库发送所述第一应用，包括：

响应于所述第一下载请求，向所述第一应用仓库发送所述第一应用和第二应用，所述第一应用包含所述第一应用和所述第二应用的关联关系。

12.一种应用管理装置，其特征在于，所述装置应用于消费者***的第一应用仓库，所述第一应用仓库部署在云端服务器，所述装置包括：

发送模块，用于向应用商店发送第一下载请求，所述第一下载请求用于请求下载应用商店中的第一应用，所述应用商店中存储有所述第一应用，所述第一应用与所述应用商店中的第二应用具有关联关系，能够调用所述第二应用以实现所述第二应用的功能；其中，所述第一应用包括所述第二应用的配置信息，所述第一应用和所述第二应用之间的关联关系包括所述第一应用和所述第二应用的配置信息之间的关联关系，所述第一应用和所述第二应用的配置信息的关联关系是所述应用商店、或第二应用仓库、或第二开发平台将所述第二应用的配置信息添加至所述第一应用中建立的；

接收模块，用于接收来自所述应用商店的所述第一应用和所述第二应用；

其中，所述第二应用是第一开发平台开发的应用；所述第一应用是所述第二开发平台或第二应用仓库基于所述关联关系和所述第二应用生成的应用；

所述接收模块，还用于接收运行所述第一应用的指令；

响应于运行所述第一应用的指令，所述发送模块，还用于向运维***发送所述第一应用，以使得所述运维***在运行环境创建所述第一应用的实例，并运行所述第一应用的实例。

13.根据权利要求12所述的装置，其特征在于，

所述第一应用中包括第一信息，所述第一信息用于指示与所述第一应用关联的所述第二应用。

14.根据权利要求13所述的装置，其特征在于，

所述第一信息包括所述第二应用的标识；

所述应用商店中的不同应用的标识不同。

15.一种应用管理装置，其特征在于，所述装置应用于开发***的第二应用仓库，所述第二应用仓库部署在云端服务器，所述装置包括：

发送模块，用于向应用商店发送第二下载请求，所述第二下载请求用于请求从应用商店下载第二应用；其中，所述第二应用是第一开发平台开发的应用；

处理模块，用于建立第一应用与所述第二应用的关联关系，所述第一应用能够调用所述第二应用以实现所述第二应用的功能；其中，所述第一应用包括所述第二应用的配置信息，所述第一应用和所述第二应用之间的关联关系包括所述第一应用和所述第二应用的配置信息之间的关联关系，所述第一应用和所述第二应用的配置信息的关联关系是将所述第二应用的配置信息添加至所述第一应用中建立的；

所述处理模块，还用于根据所述关联关系，基于所述第二应用生成第一应用；

接收模块，用于接收运行所述第一应用的指令；

响应于运行所述第一应用的指令，所述发送模块，还用于向运维***发送所述第一应用，以使得所述运维***在运行环境创建所述第一应用的实例，并运行所述第一应用的实例。

16.根据权利要求15所述的装置，其特征在于，

所述发送模块，还用于向所述应用商店发送应用上传请求，所述应用上传请求用于指示向所述应用商店上传所述第一应用；

所述发送模块，还用于向所述应用商店发送所述第一应用。

17.根据权利要求15或16所述的装置，其特征在于，

所述发送模块，还用于向所述应用商店发送所述第一应用，所述第一应用中包含所述第一应用与所述第二应用的关联关系。

18.一种应用管理装置，其特征在于，所述装置应用于应用商店，所述应用商店中存储有第二应用，所述第二应用是第一开发平台开发的应用；所述装置包括：

接收模块，用于接收来自第一应用仓库的第一下载请求，所述第一下载请求用于请求下载应用商店中的第一应用，所述第一应用仓库部署在云端服务器；

发送模块，用于响应于所述第一下载请求，向所述第一应用仓库发送所述第一应用；

处理模块，用于建立所述第一应用和所述第二应用的关联关系；其中，所述第一应用包括所述第二应用的配置信息，所述第一应用和所述第二应用之间的关联关系包括所述第一应用和所述第二应用的配置信息之间的关联关系，所述第一应用和所述第二应用的配置信息的关联关系是将所述第二应用的配置信息添加至所述第一应用中建立的；

其中，所述第一应用能够调用所述第二应用以实现所述第二应用的功能；所述第一应用是第二开发平台或第二应用仓库基于所述关联关系和所述第二应用生成的应用，所述第一应用运行时，在运行环境创建所述第一应用的实例，并运行所述第一应用的实例。

19.根据权利要求18所述的装置，其特征在于，

所述接收模块，还用于响应第二应用仓库发送的应用上传请求，接收来自所述第二应用仓库的所述第一应用。

20.根据权利要求18或19所述的装置，其特征在于，

所述接收模块，还用于接收来自第二应用仓库的第二下载请求，所述第二下载请求用于请求下载所述第二应用；

所述发送模块，还用于向所述第二应用仓库发送所述第二应用。

21.根据权利要求20所述的装置，其特征在于，

所述第一应用中包括第一信息，所述第一信息用于指示与所述第一应用关联的所述第二应用。

22.根据权利要求21所述的装置，其特征在于，

所述发送模块，还用于响应于所述第一下载请求，向所述第一应用仓库发送所述第一应用和第二应用，所述第一应用包含所述第一应用和所述第二应用的关联关系。

23.一种电子设备，其特征在于，包括：处理器；存储器；以及计算机程序；其中，所述计算机程序存储在所述存储器上，当所述计算机程序被所述处理器执行时，使得所述电子设备实现如权利要求1-3任一项所述的方法，或者，如权利要求4-6中任一项所述的方法，又或者，如权利要求7-11任一项所述的方法。

24.一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，其特征在于，当所述计算机程序在电子设备上运行时，使得所述电子设备实现如权利要求1-3任一项所述的方法，或者，如权利要求4-6中任一项所述的方法，又或者，如权利要求7-11任一项所述的方法。

25.一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，其特征在于，当所述计算机可读代码在电子设备中运行时，所述电子设备中的处理器实现如权利要求1-3任一项所述的方法，或者，如权利要求4-6中任一项所述的方法，又或者，如权利要求7-11任一项所述的方法。