CN115421780A - 应用程序的开发方法及相关设备 - Google Patents

Abstract

本申请关于一种应用程序的开发方法及相关设备，涉及软件技术领域。本申请中，开发平台可以向第一应用仓库发送调用请求，调用请求用于请求第二应用的配置信息，配置信息是基于应用的结构数据模型生成的。开发平台接收来自第一应用仓库的第二应用的配置信息。开发平台建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，生成更新后的第一应用的结构数据模型，更新后的第一应用的结构数据模型包括第二应用的配置信息。本申请可以降低协同开发应用程序的复杂度。

Description

应用程序的开发方法及相关设备

技术领域

本申请涉及软件技术领域，尤其涉及一种应用程序的开发方法及相关设备。

背景技术

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

目前，应用的开发者在开发应用程序的过程中，可以通过电子设备从代码仓库获取其他开发者上传的源代码(可以简称为仓库源代码)，并通过仓库源代码开发应用程序，以实现协同开发的目的。但是，目前的代码仓库中存储的是源代码，应用的开发者通过电子设备获取仓库源代码之后，需要通过电子设备将仓库源代码与本地源代码进行整合配置(如修改仓库源代码，以使得仓库源代码与本地源代码可以兼容)，才可以完成应用程序的开发工作。因此，如何降低协同开发应用程序的复杂度，成为一个亟待解决的技术问题。

发明内容

本申请提供一种应用程序的开发方法及相关设备，可以降低协同开发应用程序的复杂度。

本申请的技术方案如下：

第一方面，本申请提供一种应用程序的开发方法，该方法应用于开发平台，开发平台中存储有第一应用的结构数据模型，结构数据模型包括应用的功能函数。该方法包括：

向第一应用仓库发送调用请求，调用请求用于请求第二应用的配置信息，配置信息是基于应用的结构数据模型生成的。接收来自第一应用仓库的第二应用的配置信息。建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，生成更新后的第一应用的结构数据模型，更新后的第一应用的结构数据模型包括第二应用的配置信息。

一些实现方式中，该应用程序的开发方法还可以包括：根据更新后的第一应用的结构数据模型，生成第一应用的配置信息。

另一些实现方式中，该应用程序的开发方法还可以包括：向第二应用仓库发送上传请求，上传请求用于上传第一应用的配置信息。

另一些实现方式中，上传请求包括：目标账号和第一应用的配置信息，目标账号为登录开发平台的账号。

另一些实现方式中，该应用程序的开发方法还可以包括：获取第一应用仓库的地址信息。根据第一应用仓库的地址信息，向第一应用仓库发送调用请求。

另一些实现方式中，第一应用仓库与第二应用仓库相同，或者，第一应用仓库与第二应用仓库不相同。

第二方面，本申请提供一种应用程序的开发方法，该方法应用于第一应用仓库，第一应用仓库中存储有多个应用的配置信息，配置信息是基于应用的结构数据模型生成的，结构数据模型包括应用的功能函数。该方法包括：

接收来自开发平台的调用请求，调用请求用于请求第二应用的配置信息，第二应用为多个应用中任一应用。向开发平台发送第二应用的配置信息。

一些实现方式中，调用请求包括：目标账号，目标账号为登录开发平台的账号；第一应用仓库中存储有多个账号的访问权限信息，访问权限信息用于指示账号是否具有访问第一应用仓库的权限。该应用程序的开发方法还可以包括：根据目标账号和多个账号的访问权限信息，确定目标账号的访问权限信息。若目标账号的访问权限信息为第一权限信息，则向开发平台发送第二应用的配置信息，第一权限信息用于指示具有访问第一应用仓库的权限。

另一些实现方式中，该应用程序的开发方法还可以包括：若目标账号的访问权限信息为第二权限信息，则向开发平台发送验证失败消息，验证失败消息用于指示目标账号未具有访问第一应用仓库的权限，第二权限信息指示未具有访问第一应用仓库的权限。

另一些实现方式中，该应用程序的开发方法还可以包括：获取移动请求，移动请求用于指示向第三应用仓库发送第二应用的配置信息。响应于移动请求，向第三应用仓库发送第二应用的配置信息。

第三方面，本申请提供一种应用程序的开发方法，该方法应用于第二应用仓库。该方法包括：

接收来自开发平台的上传请求，上传请求用于请求上传第一应用的配置信息，上传请求包括第一应用的配置信息。存储第一应用的配置信息。

一些实现方式中，上传请求还包括：目标账号，目标账号为登录开发平台的账号；第二应用仓库中存储有多个账号的访问权限信息，访问权限信息用于指示账号是否具有访问第二应用仓库的权限。上述“存储第一应用的配置信息”的方法可以包括：若目标账号的访问权限信息为第一权限信息，则存储第一应用的配置信息，第一权限信息用于指示具有访问应用仓库的权限。

另一些实现方式中，第一应用的配置信息包括：第二应用的配置信息。

另一些实现方式中，该应用程序的开发方法还可以包括：接收来自运行平台的运行请求消息，运行请求消息用于指示运行第一应用。向运行平台发送第一应用的配置信息，以使得运行平台为第一应用分配资源，并根据第一应用的配置信息运行第一应用。

第四方面，本申请提供一种应用程序的开发装置，该装置应用于开发平台，开发平台中存储有第一应用的结构数据模型，结构数据模型包括应用的功能函数；装置包括：

发送单元，用于向第一应用仓库发送调用请求，调用请求用于请求第二应用的配置信息，配置信息是基于应用的结构数据模型生成的。接收单元，用于接收来自第一应用仓库的第二应用的配置信息。处理单元，用于建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，生成更新后的第一应用的结构数据模型，更新后的第一应用的结构数据模型包括第二应用的配置信息。

一些实现方式中，处理单元，还用于根据更新后的第一应用的结构数据模型，生成第一应用的配置信息。

另一些实现方式中，发送单元，还用于向第二应用仓库发送上传请求，上传请求用于上传第一应用的配置信息。

另一些实现方式中，上传请求包括：目标账号和第一应用的配置信息，目标账号为登录开发平台的账号。

另一些实现方式中，处理单元，还用于获取第一应用仓库的地址信息。接收单元，具体用于获取根据第一应用仓库的地址信息，向第一应用仓库发送调用请求。

另一些实现方式中，第一应用仓库与第二应用仓库相同，或者，第一应用仓库与第二应用仓库不相同。

第五方面，本申请提供一种应用程序的开发装置，该装置应用于第一应用仓库，第一应用仓库中存储有多个应用的配置信息，配置信息是基于应用的结构数据模型生成的，结构数据模型包括应用的功能函数；装置包括：

接收单元，用于接收来自开发平台的调用请求，调用请求用于请求第二应用的配置信息，第二应用为多个应用中任一应用。发送单元，用于向开发平台发送第二应用的配置信息。

一些实现方式中，调用请求包括：目标账号，目标账号为登录开发平台的账号；第一应用仓库中存储有多个账号的访问权限信息，访问权限信息用于指示账号是否具有访问第一应用仓库的权限。装置还包括：处理单元，用于根据目标账号和多个账号的访问权限信息，确定目标账号的访问权限信息。发送单元，具体用于若目标账号的访问权限信息为第一权限信息，则向开发平台发送第二应用的配置信息，第一权限信息用于指示具有访问第一应用仓库的权限。

另一些实现方式中，发送单元，还具体用于若目标账号的访问权限信息为第二权限信息，则向开发平台发送验证失败消息，验证失败消息用于指示目标账号未具有访问第一应用仓库的权限，第二权限信息指示未具有访问第一应用仓库的权限。

另一些实现方式中，处理单元，还用于获取移动请求，移动请求用于指示向第三应用仓库发送第二应用的配置信息。发送单元，还用于响应于移动请求，向第三应用仓库发送第二应用的配置信息。

第六方面，本申请提供一种应用程序的开发装置，该装置应用于第二应用仓库，装置包括：

接收单元，接收来自开发平台的上传请求，上传请求用于请求上传第一应用的配置信息，上传请求包括第一应用的配置信息。存储单元，用于存储第一应用的配置信息。

一些实现方式中，上传请求还包括：目标账号，目标账号为登录开发平台的账号；第二应用仓库中存储有多个账号的访问权限信息，访问权限信息用于指示账号是否具有访问第二应用仓库的权限。存储单元，具体用于若目标账号的访问权限信息为第一权限信息，则存储第一应用的配置信息，第一权限信息用于指示具有访问应用仓库的权限。

另一些实现方式中，第一应用的配置信息包括：第二应用的配置信息。

另一些实现方式中，装置还包括：发送单元。接收单元，还用于接收来自运行平台的运行请求消息，运行请求消息用于指示运行第一应用。发送单元，用于向运行平台发送第一应用的配置信息，以使得运行平台为第一应用分配资源，并根据第一应用的配置信息运行第一应用。

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

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

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

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

本申请中，开发平台可以向第一应用仓库发送调用请求，以请求第二应用的配置信息。并且，配置信息是基于应用的结构数据模型生成的，第二应用的配置信息可以实现第二应用的结构数据模型中的功能函数的功能。之后，第一应用仓库可以接收调用请求，并向开发平台发送第二应用的配置信息。然后，第二应用仓库可以接收第二应用的配置信息，并建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，生成更新后的第一应用的结构数据模型，更新后的第一应用的结构数据模型包括第二应用的配置信息。这样一来，开发平台无需将代码之间进行整合配置，仅需要建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，便可以直接使用第二应用的配置信息，降低了协同开发应用程序的复杂度。

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

附图说明

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

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

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

图3A为本申请实施例提供的应用程序的开发方法的流程示意图；

图3B为本申请实施例提供的结构数据模型的组成示意图；

图4为本申请实施例提供的应用程序的开发方法的又一流程示意图；

图5为本申请实施例提供的应用程序的开发方法的又一流程示意图；

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

图7为本申请实施例提供的应用程序的开发系统的组成示意图；

图8为本申请实施例提供的应用程序的开发装置的结构示意图；

图9为本申请实施例提供的应用程序的开发装置的另一结构示意图；

图10为本申请实施例提供的应用程序的开发装置的另一结构示意图；

图11为本申请实施例提供的应用程序的开发装置的另一结构示意图。

具体实施方式

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

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

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

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

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

目前，应用的开发者在开发应用程序的过程中，可以通过电子设备从代码仓库获取其他开发者上传的源代码(可以简称为仓库源代码)，并通过仓库源代码开发应用程序，以实现协同开发的目的。但是，目前的代码仓库中存储的是源代码，应用的开发者通过电子设备获取仓库源代码之后，需要通过电子设备将仓库源代码与本地源代码进行整合，才可以完成应用程序的开发工作。因此，如何降低协同开发应用程序的复杂度，成为一个亟待解决的技术问题。

基于此，本申请实施例提供了一种应用程序的开发方法，该方法可以应用于开发平台，开发平台中存储有第一应用的结构数据模型，结构数据模型包括应用的功能函数。开发平台可以向第一应用仓库发送调用请求，调用请求用于请求第二应用的配置信息，配置信息是基于应用的结构数据模型生成的。也就是说，第二应用的配置信息与第二应用的结构数据模型关联，可以实现第二应用的功能。之后，开发平台可以接收来自第一应用仓库的第二应用的配置信息。然后，开发平台可以根据第一应用的结构数据模型和第二应用的配置信息，更新第一应用的结构数据模型，第一应用的结构数据模型包括第二应用的配置信息。如此，开发人员无需通过开发平台将本地代码与仓库源代码进行整合配置，仅需要通过开发平台将第二应用的配置信息添加至第一应用的结构数据模型，降低了协同开发应用程序的复杂度。并且，由于第一应用的结构数据模型包括第二应用的配置信息，可以通过第一应用的配置信息实现第二应用的功能。

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

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

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

下面以开发平台、应用仓库和运行平台为例，介绍本申请实施例提供的应用程序的开发方法。

在本申请实施例中，开发平台可以创建第一应用的结构数据模型，并存储第一应用的结构数据模型，结构数据模型包括应用的功能函数。

可选的，开发平台可以根据第一应用的结构数据模型，生成第一应用的配置信息，配置信息是基于应用的结构数据模型生成的。

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

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

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

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

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

可选的，结构数据模型还可以包括：子模型列表。

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

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

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

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

在一些实施例中，开发平台可以建立第一应用的结构数据模型与其他应用的配置信息之间的关系，以完成第一应用的协同开发，其他应用为除第一应用以外的应用。

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

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

其中，调用请求用于请求第二应用的配置信息，配置信息是基于应用的结构数据模型生成的。

在本申请实施例中，第一应用仓库中存储有第二应用的配置信息。

在一种可能的实现方式中，开发平台可以接收开发人员的第一操作指令，该第一操作指令用于确定调用的第二应用。开发平台根据第一操作指令确定第二应用的标识。之后，开发平台向第一应用仓库发送携带有第二应用的标识的调用请求。

在一些实施例中，在开发平台向第一应用仓库发送调用请求之前。开发平台可以获取第一应用仓库的地址信息。之后，开发平台可以根据第一应用仓库的地址信息，向第一应用仓库发送调用请求。

在一种可能的实现方式中，开发平台可以显示多个应用仓库的标识(如应用仓库的图标、名称等)，多个应用仓库包括第一应用仓库。之后，开发平台可以接收用户的仓库选择操作，该仓库选择操作用于确定第一应用仓库。响应于仓库选择操作，开发平台可以获取第一应用仓库的地址信息，并显示第一应用仓库中的应用。之后，开发平台可以接收用户的应用选择操作，该应用选择操作用于确定第二应用。响应于应用选择操作，开发平台可以确定第二应用，并根据第一应用的仓库的地址信息，向第一应用仓库发送调用请求。

在另一种可能的实现方式中，开发平台可以显示多个应用的标识(如应用的图标、名称)，该多个应用为至少一个应用仓库中存储的应用，至少一个应用仓库包括第一应用仓库。发平台可以接收用户的应用选择操作，该应用选择操作用于确定第二应用。响应于应用选择操作，开发平台可以确定第二应用，并获取存储第二应用的第一应用仓库的标识。之后，开发平台根据第一应用的仓库的地址信息，向第一应用仓库发送调用请求。

可以理解的是，开发平台通过获取第一应用的仓库的地址信息，可以保障向存储有第二应用的配置信息的应用仓库发送调用请求，从而保障开发平台可以获取到第二应用的配置信息，以实现协同开发第一应用效果。

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

其中，调用请求用于请求第二应用的配置信息。

在本申请实施例中，第一应用仓库中存储有多个应用的配置信息。第二应用为多个应用中任一应用。

在一些实施例中，调用请求可以包括第二应用的配置信息标识。在第一应用仓库接收来自开发平台的调用请求之后，第一应用仓库可以根据第二应用的配置信息标识从多个应用的配置信息中，确定第二应用的配置信息。

需要说明的是，本申请实施例对配置信息标识不作限定。例如，配置信息标识可以为配置信息的GUID(即配置信息的唯一标识)。又例如，配置信息标识可以为配置信息的GUID+版本号。又例如，配置信息标识可以为配置信息的GUID+应用标识(如应用名称)。

S303、第一应用仓库向开发平台发送第二应用的配置信息。

在一种可能的实现方式中，调用请求还可以包括开发平台的标识。第一应用仓库可以根据开发平台的标识，向开发平台发送第二应用的配置信息。

需要说明的是，本申请实施例对开发平台的标识不作限定。例如，开发平台的标识可以为开发平台的地址信息。又例如，开发平台的标识可以为开发平台的平台名称。又例如，开发平台的标识可以为登录开发平台的账号信息。

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

S305、开发平台建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，生成更新后的第一应用的结构数据模型。

其中，更新后的第一应用的结构数据模型包括第二应用的配置信息。

示例性的，第一应用的结构数据模型可以包括转速、温度、电流的成员，还可以包括：第二应用的配置信息，如压强50、压力面积10。

在一种可能的实现方式中，第一应用的结构数据模型包括：第一信息，该第一信息用于记录与第一应用的结构数据模型具有关联关系的子配置信息，该子配置信息为第一应用的结构数据模型的子模型的配置信息。开发平台可以将第二应用的配置信息加入第一信息，以建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，生成更新后的第一应用的结构数据模型。

在另一种可能的实现方式中，开发平台可以将第二应用的配置信息标识加入第一信息，以建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，生成更新后的第一应用的结构数据模型。

示例性地，图3B为本申请实施例提供的第一应用的结构数据模型的组成示意图。

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

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

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

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

子模型列表(即第一信息)中记录了与第一应用的结构数据模型具有关联关系的子配置信息。例如，子模型列表可以包括：应用A的配置信息(与应用A的结构数据模型相对应)、应用B的配置信息(与应用B的结构数据模型相对应))和应用C的配置信息(与应用C的结构数据模型相对应))。也即，第一应用的结构数据模型分别与应用A的配置信息、应用B的配置信息和应用C的配置信息具有关联关系，第一应用可以调用应用A、应用B和应用C。

在一种可能的设计中，开发平台中存储有第一应用的结构数据模型。

可选的，在开发平台存储第一应用的结构数据模型之前，开发平台可以创建第一应用的结构数据模型。下面对创建第一应用的结构数据模型的过程进行介绍。

开发平台可以创建第一应用的结构数据模型，为第一应用的结构数据模型分配唯一标识(如全球唯一标识)。并且，开发平台可以编写第一应用的结构数据模型的功能函数的程序逻辑。并且，开发平台可以定义第一应用的结构数据模型依赖的资源对象(简称第一应用的资源对象)到资源库，并为第一应用的资源对象分配唯一标识(如全球唯一标识)。

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

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

基于上述技术方案，开发平台可以向第一应用仓库发送调用请求，以请求第二应用的配置信息。并且，配置信息是基于应用的结构数据模型生成的，第二应用的配置信息可以实现第二应用的结构数据模型中的功能函数的功能。之后，第一应用仓库可以接收调用请求，并向开发平台发送第二应用的配置信息。然后，第二应用仓库可以接收第二应用的配置信息，并建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，生成更新后的第一应用的结构数据模型，更新后的第一应用的结构数据模型包括第二应用的配置信息。这样一来，开发平台无需将代码之间进行整合配置，仅需要建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，便可以直接使用第二应用的配置信息，降低了协同开发应用程序的复杂度。

需要说明的是，当前开发平台生成第一应用的结构数据模型之后，消费者用户无法通过第一应用的结构数据模型实例化对象，可能导致消费者无法使用第一应用。

图4为本申请实施例提供的另一种应用程序的开发方法的流程示意图。如图4所示，在S305之后，该应用程序的开发方法可以包括：

S401、开发平台根据更新后的第一应用的结构数据模型，生成第一应用的配置信息。

在一种可能的实现方式中，开发平台可以对更新后的第一应用的结构数据模型的属性成员配置参数值，生成第一应用的配置信息。

也就是说，开发平台对更新后的第一应用的结构数据模型配置参数值时，仅对第一应用的结构数据模型配置参数值，不改变第二应用的结构数据模型的配置参数值。

示例性的，假如第一应用的结构数据模型可以包括转速、温度、电流的成员，第二应用的配置信息包括：压强50、压力面积10。开发平台生成第一应用的配置信息可以包括：转速为100、温度为30、电流为2、第二应用的配置信息(压强50、压力面积10)。

在另一种可能的实现方式中，开发平台可以对更新后的第一应用的结构数据模型中的属性成员配置参数值，并重新配置第二应用的配置信息，生成第一应用的配置信息。其中，第一应用的配置信息包括更新后的第二应用的配置信息。

也就是说，开发平台对更新后的第一应用的结构数据模型配置参数值时，不仅对第一应用的结构数据模型配置参数值，不改变第二应用的结构数据模型的配置参数值。

示例性的，假如第一应用的结构数据模型可以包括转速、温度、电流的成员，第二应用的配置信息包括：压强50、压力面积10。开发平台生成第一应用的配置信息可以包括：转速为100、温度为30、电流为2、更新后的第二应用的配置信息(压强30、压力面积5)。

可以理解的是，在生成第一应用的配置信息之后，便可以进行实例化对象，且该实例化对象可以调用第二应用的功能函数以实现第二应用的功能。

需要说明的是，当前开发平台生成第一应用的配置信息之后，消费者用户无法通过开发平台获取第一应用的配置信息，可能导致消费者无法使用第一应用。

在一些实施例中，在S401之后，开发平台可以发布第一应用的配置信息，以供电子设备获取第一应用的配置信息。

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

其中，上传请求用于上传第一应用的配置信息，上传请求艾克第一应用的配置信息。

在一种可能的设计中，第二应用仓库与第一应用仓库相同。

也就是说，开发平台可以从一个应用仓库(如应用仓库A)获取第二应用的配置信息。在生成第一应用的配置信息之后，将第一应用的配置信息上传至应用仓库A。

在另一种可能的设计中，第二应用仓库与第一应用仓库不相同。

也就是说，开发平台可以从一个应用仓库(如应用仓库A)获取第二应用的配置信息。在生成第一应用的配置信息之后，将第一应用的配置信息上传至另一个应用仓库(如应用仓库B)。

S403、第二应用仓库接收来自开发平台的上传请求。

S404、第二应用仓库存储第一应用的配置信息。

基于上述技术方案，开发平台可以将第一应用的配置信息上传至第二应用仓库。如此，可以保障消费者通过运行平台从第二应用仓库获取第一应用的配置信息，以创建第一应用的配置信息的实例化对象，运行第一应用。

在一些实施例中，在第二应用仓库存储第一应用的配置信息之后，运行平台可以调用第一应用的配置信息，以运行第一应用。

图5为本申请实施例提供的另一种应用程序的开发方法的流程示意图。如图5所示，在S404之后，该应用程序的开发方法可以包括：

S501、运行平台向第二应用仓库发送运行请求消息。

其中，运行请求消息用于指示运行第一应用。

可选的，运行请求消息可以包括：第一应用的标识。

S502、第二应用仓库接收来自运行平台的运行请求消息。

S503、第二应用仓库向运行平台发送第一应用的配置信息。

在本申请实施例中，在第二应用仓库向运行平台发送第一应用的配置信息之后，以使得运行平台为第一应用分配资源，并根据第一应用的配置信息运行第一应用，该资源为运行第一应用所需要的资源。

在一种可能的设计中，运行平台接收来自第二应用仓库的第一应用的配置信息之后，运行平台可以为第一应用根据第一应用的配置信息，创建第一应用的实例化对象。并且，运行平台可以为第一应用的实例化对象分配运行资源。

需要说明的是，本申请实施例对资源不作限定。例如，资源可以包括：中央处理器(central processing unit，CPU)资源、内存资源、显存资源等。

可选的，运行平台可以向目标计算节点发送第一应用的配置信息。之后，目标计算节点接收到第一应用的配置信息之后，可以为第一应用分配资源，运行第一应用。

可以理解的是，第二应用仓库接收来自运行平台的运行请求消息之后，可以向运行平台发送第一应用的配置信息。这样一来，可以使得运行平台为第一应用分配资源，并根据第一应用的配置信息运行第一应用，保障了消费者可以通过运行平台运行第一应用。

需要说明的是，不同的开发人员可以通过自己的用户账号登录开发平台。并且，不同的用户账号的权限信息不同，该权限信息用于指示用户账号访问仓库的权限。也就是说，不同的用户账号可以访问不同的应用仓库。

在一些实施例中，应用仓库接收到开发平台的请求之后，可以校验用户账号的权限信息，以确定用户账号是否可以访问应用仓库。

图6为本申请实施例提供的另一种应用程序的开发方法的流程示意图。如图6所示，在S303之前，该应用程序的开发方法可以包括：

S601、第一应用仓库根据目标账号和多个账号的访问权限信息，确定目标账号的访问权限信息。

在本申请实施例中，第一应用仓库中存储有多个账号的访问权限信息，访问权限信息用于指示账号是否具有访问第一应用仓库的权限。其中，访问权限信息可以为第一权限信息或第二权限信息，第一权限信息用于指示具有访问第一应用仓库的访问权限，第二权限信息用于指示未具有访问第一应用仓库的访问权限。

示例性的，如表1所示，其示出了第一应用仓库中存储的多个账号的访问权限信息。

表1

账号	访问权限信息
		账号A	第一权限信息
账号B	第一权限信息
		账号C	第二权限信息

也就是说，账号A的访问权限信息为第一权限信息，即账号A具有访问第一应用仓库的权限。账号B的访问权限信息为第一权限信息，即账号B具有访问第一应用仓库的权限。账号C的访问权限信息为第二权限信息，即账号C未具有访问第一应用仓库的权限。

需要说明的是，本申请实施例对访问权限信息的表示形式不作限定。例如，访问权限信息可以通过数值表示(如“0”、“1”)。又例如，访问权限信息可以通过字母表示(如“a”、“b”)。又例如，访问权限信息可以通过字符表示(如“，”、“！”)。

需要说明的是，第一应用仓库中存储有多个账号的访问权限信息，可以是由开发人员或者运维人员预先配置的。或者，第一应用仓库中存储有多个账号的访问权限信息，可以是由用户账号耗费资源兑换的。

在一种可能的实现方式中，调用请求包括目标账号。在开发平台向第一应用仓库发送调用请求之后，第一应用仓库可以从多个账号中确定与目标账号相同的账号，并将与目标账号相同的账号的访问权限信息作为目标账号的访问权限。若与目标账号相同的账号的访问权限信息为第一权限信息，第一应用仓库则确定目标账号的访问权限信息为第一权限信息。若与目标账号相同的账号的访问权限信息为第二权限信息，第一应用仓库则确定目标账号的访问权限信息为第二权限信息。

示例性的，结合表1，假如目标账号为账号A，则目标账号的访问权限信息为第一权限信息。假如目标账号为账号C，则目标账号的访问权限信息为第二权限信息。

在另一种可能的实现方式中，第一应用仓库中存储的多个账号的访问权限信息均为第一权限信息。也就是说，第一应用仓库中仅存储了能够访问第一应用仓库的账号。

在本申请实施例中，调用请求包括目标账号。在开发平台向第一应用仓库发送调用请求之后，第一应用仓库可以确定多个账号中是否存在与目标账号相同的账号。若多个账号中存在与目标账号相同的账号，第一应用仓库则确定目标账号的访问权限信息为第一权限信息。若多个账号中存在与目标账号不同的账号，第一应用仓库则确定目标账号的访问权限信息为第二权限信息。

示例性的，假如第一应用仓库中存储有账号A、账号B和账号C。假如目标账号为账号A，则目标账号的访问权限信息为第一权限信息。假如目标账号为账号D，则目标账号的访问权限信息为第二权限信息。

在一些实施例中，在第一应用仓库确定目标账号的访问权限信息之后，若目标账号的访问权限信息为第一权限信息，第一应用仓库则执行S303。

可以理解的是，第一应用仓库验证目标账号的访问权限信息，可以保障在目标账号具有访问权限时才可以获取第二应用的配置信息。如此，便于应用仓库对存储的应用的配置信息进行管理。

若目标账号的访问权限信息为第二权限信息，第一应用仓库则执行S602。

S602、第一应用仓库向开发平台发送验证失败消息。

其中，验证失败消息用于指示目标账号未具有访问第一应用仓库的权限。

示例性的，验证失败消息可以为“您没有访问第一应用仓库的权限”。

可以理解的是，第一应用仓库验证目标账号的访问权限信息，可以保障在目标账号未具有访问权限时不能获取第二应用的配置信息。如此，便于应用仓库对存储的应用的配置信息进行管理。

在一些实施例中，上传请求还包括：目标账号和第一应用的配置信息，目标账号为登录开发平台的账号。第二应用仓库中存储有多个账号的访问权限信息，访问权限信息用于指示账号是否具有访问第二应用仓库的权限。在第二应用仓库接收到开发平台的上传请求之后，第二应用仓库可以根据多个账号的访问权限信息校验目标账号是否具有访问第二应用仓库的权限。

在一种可能的设计中，若目标账号的访问权限信息为第一权限信息，第二应用仓库则可以存储第一应用的配置信息，第一权限信息用于指示具有访问应用仓库的权限。

在另一种可能的设计中，若目标账号的访问权限信息为第二权限信息，第二应用仓库则可以拒绝存储第一应用的配置信息。也就是说，第二应用仓库中未存储有第一应用的配置信息。

可以理解的是，在目标账号具有访问应用仓库的权限的情况下，第二应用可以存储开发平台上传的第一应用的配置信息。如此，可以便于其他的开发平台协同开发应用程序，或者消费者通过运行平台运行第一应用。并且，在目标账号未具有访问应用仓库的权限的情况下，第二应用仓库可以拒绝存储第一应用的配置信息。如此，减少占用应用仓库的存储空间，提高空间利用率。

在一些实施例中，本申请实施例中的第一应用仓库和第二应用仓库均为应用仓库系统中的应用仓库。该应用仓库系统可以包括多个层级的应用仓库。

在一种可能的设计中，多个层级的应用仓库可以为树形结构的应用仓库。该多个层级的应用仓库可以包括根应用仓库。不同层级的应用仓库可以由不同的账号访问。

在一些实施例中，具有应用仓库的访问权限的账号可以更新应用仓库中存储的应用的配置信息。应用仓库可以接收第二账号的更新操作，更新操作用于更新应用仓库中的应用的配置信息。响应于更新操作，应用仓库可以更新应用的配置信息。

在一种可能的设计中，更新操作可以包括：增加应用的配置信息、删除应用的配置信息。

需要说明的是，不同的应用仓库中存储的应用的配置信息不同。并且不同账号访问应用仓库的权限不同。这样一来，可能导致登录账号的开发平台需要一个应用(如应用A)的配置信息时，该账号能够访问的应用仓库中未存储有应用A的配置信息，且不具有访问权限的应用仓库中存储有应用A的配置信息。

在一些实施例中，该应用仓库系统可以包括第三应用仓库。第一应用仓库可以获取移动请求，移动请求用于指示第三应用仓库发送第二应用的配置信息。

需要说明的是，本申请实施例对获取移动请求的方式不作限定。例如，第一应用仓库可以接收来自开发平台的移动请求，该开发平台登录有第一账号，该第一账号具有访问第一应用仓库的访问权限。又例如，第一应用仓库可以接收用户的移动操作，该移动操作用于触发生成移动请求。

之后，响应于移动请求，第一应用仓库可以向第三应用仓库发送第二应用的配置信息，该第二应用的配置信息为第一应用仓库中存储的任一应用的配置信息。第三应用仓库可以接收来自第一应用仓库的第二应用的配置信息，并存储第二应用的配置信息。

示例性的，假如第一应用仓库中存储有应用A的配置信息，第三应用仓库中存储有应用B的配置信息。第一应用仓库可以向第三应用仓库发送应用A的配置信息。如此，第三应用仓库可以存储有应用B的配置信息和应用A的配置信息。并且，具有第三应用仓库的访问权限的账号可以通过开发平台调用应用A的配置信息，以实现协同开发应用程序。

可以理解的是，第一应用仓库获取移动请求，并响应于移动请求，向第三应用仓库发送第二应用的配置信息。如此，可以保障应用仓库之间互相共享应用的配置信息，增加了协同开发应用程序的便利性。

下面结合具体示例对本申请实施例进行介绍。如图7所示，应用程序的开发系统可以包括：开发平台一、开发平台二、应用仓库系统(如根仓库、子仓库一、子仓库二)和运行平台。其中，登录开发平台一的账号一具有访问子仓库一的访问权限，登录开发平台二的账号二具有访问子仓库一和子仓库二的访问权限。

开发平台一可以创建应用A的结构数据模型，并可以向子仓库一上传应用A的配置信息。之后，开发平台二可以从子仓库一获取应用A的配置信息。并且，开发平台二中存储有应用B的结构数据模型，开发平台二可以建立应用B的结构数据模型与应用A的配置信息之间的关系，生成更新后的应用B的结构数据模型。然后，开发平台二可以基于更新后的应用B的结构数据模型，发布应用B的配置信息至子仓库二。然后，运行平台可以从子仓库二中移出应用B的配置信息，并基于应用B的配置信息实例化对象，以运行应用B。

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

基于这样的理解，以开发平台包含的硬件结构和/或软件模块为例，本申请实施例还对应提供一种应用程序的开发装置，可以应用于开发平台，开发平台中存储有第一应用的结构数据模型，结构数据模型包括应用的功能函数。图8为本申请实施例提供的应用程序的开发装置的结构示意图。如图8所示，该应用程序的开发装置可以包括：发送单元801、接收单元802和处理单元803。

发送单元801，用于向第一应用仓库发送调用请求，调用请求用于请求第二应用的配置信息，配置信息是基于应用的结构数据模型生成的。接收单元802，用于接收来自第一应用仓库的第二应用的配置信息。处理单元803，用于建立第一应用的结构数据模型与第二应用的配置信息之间的层级关系，生成更新后的第一应用的结构数据模型，更新后的第一应用的结构数据模型包括第二应用的配置信息。

一些实现方式中，处理单元803，还用于根据更新后的第一应用的结构数据模型，生成第一应用的配置信息。

另一些实现方式中，发送单元801，还用于向第二应用仓库发送上传请求，上传请求用于上传第一应用的配置信息。

另一些实现方式中，上传请求包括：目标账号和第一应用的配置信息，目标账号为登录开发平台的账号。

另一些实现方式中，处理单元803，还用于获取第一应用仓库的地址信息。接收单元802，具体用于获取根据第一应用仓库的地址信息，向第一应用仓库发送调用请求。

另一些实现方式中，第一应用仓库与第二应用仓库相同，或者，第一应用仓库与第二应用仓库不相同。

本申请实施例还对应提供一种应用程序的开发装置，可以应用于第一应用仓库，第一应用仓库中存储有多个应用的配置信息，配置信息是基于应用的结构数据模型生成的，结构数据模型包括应用的功能函数。图9为本申请实施例提供的应用程序的开发装置的结构示意图。如图9所示，该应用程序的开发装置可以包括：接收单元901、发送单元902和处理单元903。

接收单元901，用于接收来自开发平台的调用请求，调用请求用于请求第二应用的配置信息，第二应用为多个应用中任一应用。发送单元902，用于向开发平台发送第二应用的配置信息。

一些实现方式中，调用请求包括：目标账号，目标账号为登录开发平台的账号；第一应用仓库中存储有多个账号的访问权限信息，访问权限信息用于指示账号是否具有访问第一应用仓库的权限。处理单元903，用于根据目标账号和多个账号的访问权限信息，确定目标账号的访问权限信息。发送单元902，具体用于若目标账号的访问权限信息为第一权限信息，则向开发平台发送第二应用的配置信息，第一权限信息用于指示具有访问第一应用仓库的权限。

另一些实现方式中，发送单元902，还具体用于若目标账号的访问权限信息为第二权限信息，则向开发平台发送验证失败消息，验证失败消息用于指示目标账号未具有访问第一应用仓库的权限，第二权限信息指示未具有访问第一应用仓库的权限。

另一些实现方式中，处理单元903，还用于获取移动请求，移动请求用于指示向第三应用仓库发送第二应用的配置信息。发送单元902，还用于响应于移动请求，向第三应用仓库发送第二应用的配置信息。

本申请实施例还对应提供一种应用程序的开发装置，可以应用于第二应用仓库。图10为本申请实施例提供的应用程序的开发装置的结构示意图。如图10所示，该应用程序的开发装置可以包括：接收单元1001、存储单元1002和发送单元1003。

接收单元1001，接收来自开发平台的上传请求，上传请求用于请求上传第一应用的配置信息，上传请求包括第一应用的配置信息。存储单元1002，用于存储第一应用的配置信息。

一些实现方式中，上传请求还包括：目标账号，目标账号为登录开发平台的账号；第二应用仓库中存储有多个账号的访问权限信息，访问权限信息用于指示账号是否具有访问第二应用仓库的权限。存储单元1002，具体用于若目标账号的访问权限信息为第一权限信息，则存储第一应用的配置信息，第一权限信息用于指示具有访问应用仓库的权限。

另一些实现方式中，第一应用的配置信息包括：第二应用的配置信息。

另一些实现方式中，接收单元1001，还用于接收来自运行平台的运行请求消息，运行请求消息用于指示运行第一应用。发送单元1003，用于向运行平台发送第一应用的配置信息，以使得运行平台为第一应用分配资源，并根据第一应用的配置信息运行第一应用。

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (15)

1.一种应用程序的开发方法，其特征在于，所述方法应用于开发平台，所述开发平台中存储有第一应用的结构数据模型，所述结构数据模型包括应用的功能函数；所述方法包括：

向第一应用仓库发送调用请求，所述调用请求用于请求第二应用的配置信息，所述配置信息是基于应用的结构数据模型生成的；

接收来自所述第一应用仓库的所述第二应用的配置信息；

建立所述第一应用的结构数据模型与所述第二应用的配置信息之间的层级关系，生成更新后的所述第一应用的结构数据模型，所述更新后的所述第一应用的结构数据模型包括所述第二应用的配置信息。

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

根据所述更新后的所述第一应用的结构数据模型，生成所述第一应用的配置信息。

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

向第二应用仓库发送上传请求，所述上传请求用于上传所述第一应用的配置信息。

4.根据权利要求3所述的方法，其特征在于，上传请求包括：目标账号和所述第一应用的配置信息，所述目标账号为登录所述开发平台的账号。

5.根据权利要求1-4中任一项所述的方法，其特征在于，在所述向第一应用仓库发送调用请求之前，所述方法还包括：

获取所述第一应用仓库的地址信息；

所述向第一应用仓库发送调用请求，包括：

根据所述第一应用仓库的地址信息，向所述第一应用仓库发送所述调用请求。

6.根据权利要求5所述的方法，其特征在于，所述第一应用仓库与第二应用仓库相同，或者，所述第一应用仓库与所述第二应用仓库不相同。

7.一种应用程序的开发方法，其特征在于，所述方法应用于第一应用仓库，所述第一应用仓库中存储有多个应用的配置信息，所述配置信息是基于应用的结构数据模型生成的，所述结构数据模型包括应用的功能函数；所述方法包括：

接收来自开发平台的调用请求，所述调用请求用于请求第二应用的配置信息，所述第二应用为所述多个应用中任一应用；

向所述开发平台发送所述第二应用的配置信息。

8.根据权利要求7所述的方法，其特征在于，所述调用请求包括：目标账号，所述目标账号为登录所述开发平台的账号；所述第一应用仓库中存储有多个账号的访问权限信息，所述访问权限信息用于指示账号是否具有访问所述第一应用仓库的权限；

在所述向所述开发平台发送所述第二应用的配置信息之前，所述方法还包括：

根据所述目标账号和所述多个账号的访问权限信息，确定所述目标账号的访问权限信息；

所述向所述开发平台发送所述第二应用的配置信息，包括：

若所述目标账号的访问权限信息为第一权限信息，则向所述开发平台发送所述第二应用的配置信息，所述第一权限信息用于指示具有访问所述第一应用仓库的权限。

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

若所述目标账号的访问权限信息为第二权限信息，则向所述开发平台发送验证失败消息，所述验证失败消息用于指示所述目标账号未具有访问所述第一应用仓库的权限，所述第二权限信息指示未具有访问所述第一应用仓库的权限。

10.根据权利要求7-9中任一项所述的方法，其特征在于，所述方法还包括：

获取移动请求，所述移动请求用于指示向第三应用仓库发送所述第二应用的配置信息；

响应于所述移动请求，向所述第三应用仓库发送所述第二应用的配置信息。

11.一种应用程序的开发方法，其特征在于，所述方法应用于第二应用仓库，所述方法包括：

接收来自开发平台的上传请求，所述上传请求用于请求上传第一应用的配置信息，所述上传请求包括所述第一应用的配置信息；

存储所述第一应用的配置信息。

12.根据权利要求11所述的方法，其特征在于，所述上传请求还包括：目标账号，所述目标账号为登录所述开发平台的账号；所述第二应用仓库中存储有多个账号的访问权限信息，所述访问权限信息用于指示账号是否具有访问所述第二应用仓库的权限；

所述存储所述第一应用的配置信息，包括：

若所述目标账号的访问权限信息为第一权限信息，则存储所述第一应用的配置信息，所述第一权限信息用于指示具有访问所述应用仓库的权限。

13.一种应用程序的开发装置，其特征在于，所述装置应用于开发平台，所述开发平台中存储有第一应用的结构数据模型，所述结构数据模型包括应用的功能函数；所述装置包括：

发送单元，用于向第一应用仓库发送调用请求，所述调用请求用于请求第二应用的配置信息，所述配置信息是基于应用的结构数据模型生成的；

接收单元，用于接收来自所述第一应用仓库的所述第二应用的配置信息；

处理单元，用于建立所述第一应用的结构数据模型与所述第二应用的配置信息之间的层级关系，生成更新后的所述第一应用的结构数据模型，所述更新后的所述第一应用的结构数据模型包括所述第二应用的配置信息。

14.一种应用程序的开发装置，其特征在于，所述装置应用于第一应用仓库，所述第一应用仓库中存储有多个应用的配置信息，所述配置信息是基于应用的结构数据模型生成的，所述结构数据模型包括应用的功能函数；所述装置包括：

接收单元，用于接收来自开发平台的调用请求，所述调用请求用于请求第二应用的配置信息，所述第二应用为所述多个应用中任一应用；

发送单元，用于向所述开发平台发送所述第二应用的配置信息。

15.一种应用程序的开发装置，其特征在于，所述装置应用于第二应用仓库，所述装置包括：

接收单元，接收来自开发平台的上传请求，所述上传请求用于请求上传第一应用的配置信息，所述上传请求包括所述第一应用的配置信息；

存储单元，用于存储所述第一应用的配置信息。

Images