应用程序处理方法、装置、计算机设备及存储介质与流程

本申请涉及开发辅助领域，尤其涉及一种应用程序处理方法、装置、计算机设备及存储介质。

背景技术：

xcode是运行在操作系统macosx上的集成开发工具(ide)，由appleinc开发。xcode是开发macos和ios应用程序的最快捷的方式。利用xcode进行开发得到的ios应用程序，需发布到相应的发布平台，例如applestore(应用发布平台)，才能被用户所下载使用，其中，利用xcode开发得到的ios应用程序需打包成能够上传到平台的打包文件，传统上，在对应用程序进行打包时，需通过人为修改并核对应用程序打包时所需的ios应用程序的xcode的配置文件中的信息，例如打包证书、描述文件等，且xcode配置文件结构复杂，配置文件内信息繁多，通过人为修改并核对的方式比较繁琐，获取到配置信息的时间不可控，获取配置信息的效率较低，导致打包稳定性和打包效率低下。

技术实现要素：

本申请提供一种应用程序处理方法、装置、计算机设备及存储介质，可以有效地提高ios应用程序的打包稳定性和打包效率。

一种应用程序处理方法，包括：

接收用户触发的打包请求，打包请求包括ios应用程序的打包类型；

获取打包类型对应的预设配置文件，预设配置文件包含配置参数文件、证书文件和描述文件；

根据配置参数文件、证书文件和描述文件配置ios应用程序的xcode配置信息；

根据xcode配置信息对ios应用程序的源代码进行编译并打包，以获得打包文件。

一种应用程序处理装置，包括：

接收模块，用于接收用户触发的打包请求，打包请求包括ios应用程序的打包类型；

获取模块，用于获取接收模块接收的打包类型对应的预设配置文件，预设配置文件包含配置参数文件、证书文件和描述文件；

配置模块，用于根据获取模块获取的配置参数文件、证书文件和描述文件配置ios应用程序的xcode配置信息；

打包模块，用于配置模块配置的根据xcode配置信息对ios应用程序的源代码进行编译并打包，以获得打包文件。

一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述应用程序处理方法的步骤。一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述应用程序处理方法的步骤。

上述应用程序处理方法、装置、计算机设备及存储介质所提供的方案中，利用获得的包含有配置参数文件、证书文件和描述文件的预设配置文件完成ios应用程序对应的xcode配置，也就是ios应用程序对应的xcode的相关配置通过预设配置文件即可配置完成，无需通过人为修改并核对的方式，获取到配置信息的时间可控，获取配置信息的效率较高，可以有效地提高ios应用程序的打包稳定性和打包效率。

附图说明

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

图1是本申请中应用程序处理方法一个实施例流程示意图；

图2是本申请中应用程序处理方法另一实施例流程示意图；

图3是本申请中应用程序处理方法另一实施例流程示意图；

图4是本申请中应用程序处理方法另一实施例流程示意图；

图5是本申请中应用程序处理方法另一实施例流程示意图；

图6是本申请中应用程序处理方法另一实施例流程示意图；

图7是本申请中应用程序处理装置一个实施例结构示意图；

图8是本申请中应用程序处理装置一个实施例结构示意图；

图9是本申请一实施例中计算机设备的一个实施例结构示意图。

具体实施方式

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

本申请提供的应用程序处理方法，由应用程序处理装置执行，其中，应用程序处理装置可作为独立的执行装置，或集成在计算机设备中以实现上述应用程序处理方法，计算机设备包括但不限于各种个人计算机、笔记本电脑等具备编程能力的开发设备，这里不做限定。本申请应用程序处理方法主要包括：接收用户触发的打包请求，打包请求包括ios应用程序的打包类型；获取打包类型对应的预设配置文件，预设配置文件包含配置参数文件、证书文件和描述文件；根据配置参数文件、证书文件和描述文件配置ios应用程序的xcode配置信息；根据xcode配置信息对ios应用程序的源代码进行编译并打包，从而获得打包文件。由以上技术方案可以看出，与传统方案相比，本申请利用获得的包含有配置参数文件、证书文件和描述文件的预设配置文件完成ios应用程序对应的xcode配置，也就是ios应用程序对应的xcode的相关配置通过预设配置文件即可配置完成，无需通过人为修改并核对的方式，获取到配置信息的时间可控，获取配置信息的效率较高，可以有效地提高ios应用程序的打包稳定性和打包效率。

如图1所示，下面对申请中的应用程序处理方法进行详细的介绍，包括如下步骤：

s10：接收用户触发的打包请求，打包请求包括ios应用程序的打包类型；

应理解，ios系统是一种移动操作系统，以运行在ios系统上所开发的应用程序称为ios应用程序，其中，上述ios应用程序包括但不局限于游戏类应用程序、购物类应用程序、社交类应用程序等等，具体不做限定。通常，上述ios应用程序在xcode开发工具上进行开发，可以了解，xcode开发工具是一种是运行在苹果操作系统上的集成开发环境(integrateddevelopmentenvironment，ide)，通过xcode开发工具开发ios应用程序的是一种常用的开发途经，其中，xcode开发工具具有统一的用户界面设计，编码、测试、调试都在一个简单的窗口内完成，本申请中，可以在上述xcode工具编码出所需的ios应用程序，也就是编写出ios应用程序的源代码。

在本申请中，在编码出ios应用程序的源代码后，为了使得ios应用程序的源代码可以使用，例如对ios应用程序进行测试或发布至应用程序发布平台以供下载使用，例如发布至苹果商城(appstore)，此时需要将ios应用程序的源代码转换至可执行文件，对于ios应用程序而言，也即是需转化为ipa(iphoneapplication)包。因此，在需要对ios应用程序进行打包时，本申请可接收用户触发的包含有打包类型的打包请求。需要说明的是，对于ios应用程序而言，无论是发布至应用程序发布平台或是测试使用，所需要的配置信息都是不同的，因此，用户触发的打包请求中需包含有打包类型。

另外需要说明的是，在实际应用中，可将接收用户触发的打包请求的功能通过虚拟打包插件的形式实现，通过用户点击或触摸上述虚拟打包插件接收上述打包请求。

s20：获取打包类型对应的预设配置文件，预设配置文件包含配置参数文件、证书文件和描述文件；

其中，在接收到包含有打包类型的打包请求后，获取打包类型对应的预设配置文件，其中，预设配置文件包含有配置参数文件、证书文件和描述文件。下面分别对上述文件逐一进行解释：

预设配置文件，是用户针对每一个开发项目，也即针对开发的ios应用程序所预先配置的文件，其中，针对不同的打包类型，预先配置有对应的预设配置文件。

证书文件，也即是指ioscertificates文件，其中，证书文件包括开发证书(developmentcertificate)文件和生产证书(productioncertificate)。开发证书是用于证明开发ios应用程序的开发设备具有开发和真机调试ios应用程序的文件。每个开发证书关联着一个开发者账号，也就是说，只能使用这个开发证书开发这个开发者账号底下的ios应用程序，所以每次为一个开发者帐号开发对应的ios应用程序，就得需要这个开发者账号创建开发证书。生产证书是用于证明开发ios应用程序的开发设备具有发布ios应用程序的权限。需要说明的是，在具体应用中，可通过开发者账号在苹果公司的开发者网站上获取上述证书文件，具体获取过程这里不详细展开描述。

描述文件，也即是指provisioningprofiles(描述文件)，描述文件是用来标识某个运行有ios系统的终端设备是否具有安装某个ios应用程序的权限。具体的，描述文件分为开发描述文件(developprovisioningprofile)和生产描述文件，而生产描述文件又分为临时发布描述文件(distributionadhoc)和正式发布描述文件(distributionappstore/distributionadhouse)。需要说明的是，上述描述文件也可通过关联者账号和证书文件从苹果公司的开发者网站上生成得到，具体过程这里也不一一赘述。

配置参数文件，指的是开发者账号、项目标识号(bundleid)、ios应用程序的版本号(version)等在利用xcode开发工具对ios应用程序进行打包时所要用到的配置信息或参数，具体这里不一一列出。

可以理解，在根据对于ios应用程序的不同需求触发了包含打包类型的打包请求后，可以获取打包类型对应的预设配置文件，从而获得打包ios应用程序所需的配置信息。需要说明的是，本申请中的打包类型包括发布类型和测试类型，其中，发布类型指的编译并打包后生成的ipa包需要上传至应用发布平台(例如appstore)上以供用户下载使用；而测试类型是指ios应用程序对应的ipa包不需提供用户下载，而只是上传至某一测试设备上进行测试使用所需的ipa包。对于上述不同的打包类型，可对ios应用程序的xcode配置信息进行对应的配置，示例性的，若打包类型为测试类型，则获取测试类型对应的预设配置文件包含开发证书、开发描述文件、测试所需要的配置参数文件，例如开发者账号、项目标识符(bundleidentifier，bundleid)，和ios应用程序的项目版本号(version)等，具体这里不一一描述。示例性的，若打包类型为发布类型，则获取发布类型对应的预设配置文件包含生产证书、生产描述文件、测试所需要的配置参数文件，例如开发者账号、项目标识符(bundleidentifier，bundleid)，和ios应用程序的项目版本号(version)等，具体这里也不一一描述。

s30：根据配置参数文件、证书文件和描述文件配置ios应用程序的xcode配置信息；

可以理解，在步骤s30得到上述打包类型对应的配置参数文件、证书文件和描述文件后，可对应配置ios应用程序的xcode配置信息，以完成自动配置。减少了手动添加证书文件、描述文件等认为操作，提高了用户体验。

s40：根据xcode配置信息对ios应用程序的源代码进行编译并打包，以获得打包文件。

可以理解，在配置完xcode配置信息后，也就是对相关打包环境进行配置后，可根据xcode配置信息对ios应用程序的源代码进行编译并打包以获得打包文件，也即是生成ios应用程序对应的ipa包。

在一实施例中，如图2所示，步骤s40之后，也即根据所述xcode配置信息对所述ios应用程序的源代码进行编译并打包，以获得打包文件之后，所述方法还包括如下步骤：

s50：若打包类型为发布类型，则将经过编译并打包获得的打包文件发布至应用发布平台；

在本申请中，根据xcode配置信息对ios应用程序的源代码进行编译并打包，若打包类型为发布类型，则将经过编译并打包生成的打包文件发布至应用发布平台。从这里可以看出，在本方案中，可以根据用户对ios应用程序的不同需求，例如，将ios应用程序发布至appstore，自动配置上述发布需求所需的xcode配置信息并打包上传，提高了用户的体验和打包效率。

s60：若打包类型为测试类型，则将经过编译并打包获得的打包文件上传至测试平台。

如前述，对于上述不同的打包类型，可对ios应用程序的xcode配置信息进行对应的配置，因此，在本申请中，根据xcode配置信息对ios应用程序的源代码进行编译并打包，若所述打包类型为测试类型，则将经过所述编译并打包生成的所述打包文件发布至测试平台，也即上传至测试平台，从这里可以看出，在本方案中，可以根据用户对ios应用程序的不同需求，例如，将ios应用程序上传至测试平台，自动配置上述发布需求所需的xcode配置信息并打包上传，提高了用户的体验和打包效率。

在一实施例中，如图3所示，步骤s30中，也即根据所述配置参数文件、证书文件和描述文件配置所述ios应用程序的xcode配置信息，具体包括如下步骤：

s31：获取打包类型对应的配置脚本文件，配置脚本文件包含配置流程；

在本方案中，为每一种打包类型预设有打包类型对应的配置脚本文件，应理解，配置脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。其中，配置脚本文件包含有配置流程，也就是说，配置脚本文件中通过脚本语言编写有具体的配置流程，该配置流程为对ios应用程序的xcode配置信息进行配置的流程，从而使得可以按照上述配置流程的执行顺序对xcode配置信息进行配置，在本申请中，打包类型对应的配置脚本文件，具体是指预设有针对发布类型对应的配置脚本文件以及测试类型对应的配置脚本文件，由于上述不同打包类型所需要配置的配置信息不同，因此，为了提高配置成功率，分别针对不同的打包类型配置不同的配置脚本文件，提高方案的可实施性。

s32：执行配置脚本文件，根据配置流程、配置参数文件、证书文件和描述文件配置ios应用程序的xcode配置信息。

如前述，配置脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。因此，在获取到了上述配置脚本文件后，可以执行上述配置脚本文件，以按照配置脚本文件的配置流程，配置参数文件、证书文件和描述文件配置ios应用的xcode配置信息。下面以打包类型为发布类型为例举个简单的例子进行说明，假设ios应用程序的项目名称为a；

示例性的，发布类型对应的配置脚本文件的配置流程可如下a-e所示：

a：确定ios应用程序对应的项目a；

b：获取项目a的a.xcodeproj文件、a.workspace以及a.plist等文件；

c：按照上述b步骤获取的顺序，依次修改a.xcodeproj文件、a.workspace以及a.plist等文件的参数，其中，上述参数从配置参数文件中对应获取，例如开发者账号、项目标识符(bundleidentifier，bundleid)，和ios应用程序的项目版本号(version)，具体这里不一一展开描述。

d：添加发布证书；

e：添加发布描述文件。

需要说明的是，上述配置流程在这里只是举例说明，不对具体的流程做限定，只要可完成ios应用程序的xcode配置信息的配置即可，也不做详细描述。

在一实施例中，如图4所示，步骤s40中，也即根据xcode配置信息对ios应用程序的源代码进行编译并打包，以获得打包文件，具体包括如下步骤：

s41、获取打包类型对应的打包脚本文件，打包脚本文件包含打包流程；

在本方案中，为每一种打包类型预设有打包类型对应的打包脚本文件，应理解，打包脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。其中，打包脚本文件包含有打包流程，也就是说，打包脚本文件中通过脚本语言编写有具体的打包流程，该打包流程为根据xcode配置信息对ios应用程序的源代码进行打包的流程，从而使得可以按照上述打包流程的执行顺序和xcode配置信息对ios应用程序的源代码进行打包，在本申请中，打包类型对应的打包脚本文件，包括针对发布类型对应的打包脚本文件，测试类型对应的打包脚本文件，由于上述不同打包类型所需要的打包流程有所差异，因此，为了提高打包成功率，分别针对不同的打包类型配置不同的打包脚本文件。

s42：执行打包脚本文件，根据打包流程和xcode配置信息对ios应用程序的源代码进行编译并打包，以获得打包文件。

如前述，打包脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。因此，在获取到了上述打包脚本文件后，可以执行上述打包脚本文件，以按照打包脚本文件的配置流程和xcode配置信息对ios应用程序的源代码进行编译并打包。下面以打包类型为发布类型为例举个简单的例子进行说明，假设ios应用程序的项目名称为a；打包流程可如下所示：

a1：获取ios应用程序项目配置完xcode配置信息后，该ios应用程序对应的所有项目文件，例如a.xcodeproj文件、a.workspace以及a.plist等文件；

b1：将上述所有项目文件对应的源代码转换为.xcarchive文件；

c1：将上述.xcarchive文件转换成打包文件，也即ipa包文件。

需要说明的是，上述打包流程在这里只是示例性的说明，具体这里不一一详细描述。

在一实施例中，如图5所示，步骤s50中，也即将经过编译并打包生成的打包文件发布至应用发布平台，具体包括如下步骤：

s51：获取发布类型对应的第一上传脚本文件，第一上传脚本文件包含第一上传流程；

在本方案中，对发布类型预设有对应的第一上传脚本文件，应理解，第一上传脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。其中，第一上传脚本文件包含有第一上传流程，也就是说，第一上传脚本文件中通过脚本语言编写有具体的针对于发布类型对应的第一上传流程，该第一上传流程是指将经过编译并打包生成的打包文件上传至应用发布平台的上传流程，从而可以按照第一上传流程将打包文件上传至应用发布平台。

s52：执行第一上传脚本文件，根据第一上传流程将经过编译并打包获得的打包文件上传至应用发布平台。

如前述，第一上传脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。因此，在获取到了第一上传脚本文件后，可以执行第一上传脚本文件，以按照第一上传脚本文件的第一上传流程将经过编译并打包生成的打包文件上传至应用发布平台。由此可见，通过脚本的形式实现了第一上传流程，可减少人为的操作，提高上传流程的便利性，从而提高用户的体验和上传效率。

步骤s60中，如图6所示，也即将经过编译并打包生成的打包文件发布至测试平台，具体包括如下步骤：

s61：获取测试类型对应的第二上传脚本文件，第二上传脚本文件包含第二上传流程；

在本方案中，为测试类型对应的第二上传脚本文件，应理解，第二上传脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。其中，第二上传脚本文件包含有第二上传流程，也就是说，第二上传脚本文件中通过脚本语言编写有具体的针对于发布类型对应的第二上传流程，该第二上传流程为将经过编译并打包生成的打包文件上传至测试平台的上传流程，从而使得可以按照上述第二上传流程将打包文件上传至测试平台。

s62：执行第二上传脚本文件，根据第二上传流程将经过编译并打包获得的打包文件上传至测试平台。

如前述，第二上传脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。因此，在获取到了第二上传脚本文件后，可以执行第二上传脚本文件，以按照第一上传脚本文件的第二上传流程将经过编译并打包生成的打包文件上传至测试平台中。由此可见，通过脚本的形式实现第二上传流程，可减少人为的操作，提高上传流程的便利性，从而提高用户的体验和上传效率。

在一实施例中，配置脚本文件、打包脚本文件和上传脚本文件为通过ruby语言编写的脚本文件。应理解，在具体应用中，通过xcode开发工具的xcodeproj工具可使用ruby脚本，上述配置脚本文件、打包脚本文件和上传脚本文件为通过ruby语言编写的脚本文件，提高方案的可实现性。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

在一实施例中，提供一种应用程序处理装置，该应用程序处理装置与上述实施例中应用程序处理方法一一对应。如图7所示，该应用程序处理装置70包括接收模块701、获取模块702、配置模块703和打包模块704。各功能模块详细说明如下：

接收模块701，用于接收用户触发的打包请求，所述打包请求包括ios应用程序的打包类型；

获取模块702，用于获取所述接收模块701接收的所述打包类型对应的预设配置文件，所述预设配置文件包含配置参数文件、证书文件和描述文件；

配置模块703，用于根据所述获取模块702获取的所述配置参数文件、证书文件和描述文件配置所述ios应用程序的xcode配置信息；

打包模块704，用于所述配置模块703配置的根据所述xcode配置信息对所述ios应用程序的源代码进行编译并打包，以获得打包文件。

也就是说，本申请中的应用程序处理装置可实现应用程序处理方法，由本申请ios应用程序装置的各个模块执行，主要包括如下步骤：接收用户触发的打包请求，打包请求包括ios应用程序的打包类型；获取打包类型对应的预设配置文件，预设配置文件包含配置参数文件、证书文件和描述文件；根据配置参数文件、证书文件和描述文件配置ios应用程序的xcode配置信息；根据xcode配置信息对ios应用程序的源代码进行编译并打包。由以上技术方案可以看出，与传统方案相比，本申请中的ios应用程序装置所实现的方案中，利用获得的包含有配置参数文件、证书文件和描述文件的预设配置文件完成ios应用程序对应的xcode配置，也就是ios应用程序对应的xcode的相关配置通过预设配置文件即可配置完成，无需通过人为修改并核对的方式，获取到配置信息的时间可控，获取配置信息的效率较高，可以有效地提高ios应用程序的打包稳定性和打包效率。

在一实施例中，如图8所示，所述应用程序处理装置还包括：

上传模块705，用于若所述打包类型为发布类型，则将经过所述编译并打包获得的所述打包文件上传至应用发布平台；若所述打包类型为测试类型，则将经过所述编译并打包获得的所述打包文件上传至测试平台。

在一实施例中，配置模块703具体用于：

获取所述打包类型对应的配置脚本文件，所述配置脚本文件包含配置流程；

执行所述配置脚本文件，根据所述配置流程、配置参数文件、证书文件和描述文件配置所述ios应用的xcode配置信息。

在本申请中，根据xcode配置信息对ios应用程序的源代码进行编译并打包，若打包类型为发布类型，则将经过编译并打包生成的打包文件发布至应用发布平台。从这里可以看出，在本方案中，可以根据用户对ios应用程序的不同需求，例如，将ios应用程序发布至appstore，自动配置上述发布需求所需的xcode配置信息并打包上传，提高了用户的体验和打包效率。

在一实施例中，打包模块具体用于：

获取所述打包类型对应的打包脚本文件，所述打包脚本文件包含打包流程；

执行所述打包脚本文件，根据所述打包流程和所述xcode配置信息对所述ios应用程序的源代码进行编译并打包，以获得打包文件。

在一实施例中，所述上传模块用于将所述将经过所述编译并打包获得的打包文件上传至应用发布平台，包括：

所述上传模块具体用于：

获取所述发布类型对应的第一上传脚本文件，所述第一上传脚本文件包含第一上传流程；

执行所述第一上传脚本文件，根据所述第一上传流程将经过所述编译并打包获得的打包文件上传至所述应用发布平台。

第一上传脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。因此，在获取到了上述第一上传脚本文件后，可以执行上述第一上传脚本文件，以按照第一上传脚本文件的第一上传流程将经过编译并打包生成的打包文件上传至应用发布平台。由此可见，通过脚本的形式实现上述上传流程，可减少人为的操作，提高上传流程的便利性，从而提高用户的体验和上传效率。

在一实施例中，所述上传模块用于将所述将经过所述编译并打包获得的打包文件发布至测试平台，包括：

所述上传模块具体用于：

获取所述测试类型对应的第二上传脚本文件，所述第二上传脚本文件包含第二上传流程；

执行所述第二上传脚本文件，根据所述第二上传流程将经过所述编译并打包获得的打包文件上传至所述测试平台。

第二上传脚本文件为一种类似于操作系统中的批处理文件，可以将不同的命令组合起来，并按确定的顺序自动连续地执行。因此，在获取到了上述第二上传脚本文件后，可以执行上述第二上传脚本文件，以按照第一上传脚本文件的第二上传流程将经过编译并打包生成的打包文件上传至测试平台中。由此可见，通过脚本的形式实现上述第二上传流程，可减少人为的操作，提高上传流程的便利性，从而提高用户的体验和上传效率。

在一实施例中，所述配置脚本文件、打包脚本文件和所述上传脚本文件为通过ruby语言编写的脚本文件。

关于应用程序处理装置的具体限定可以参见上文中对于应用程序处理方法的限定，在此不再赘述。上述应用程序处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储获取的描述文件、证书文件等。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种应用程序处理方法。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

接收用户触发的打包请求，所述打包请求包括ios应用程序的打包类型；

获取所述打包类型对应的预设配置文件，所述预设配置文件包含配置参数文件、证书文件和描述文件；

根据所述配置参数文件、证书文件和描述文件配置所述ios应用程序的xcode配置信息；

根据所述xcode配置信息对所述ios应用程序的源代码进行编译并打包，以获得打包文件。由以上技术方案可以看出，与传统方案相比，本申请提供的计算机设备中，处理器执行计算机程序时所实现的方法中，利用获得的包含有配置参数文件、证书文件和描述文件的预设配置文件完成ios应用程序对应的xcode配置，也就是ios应用程序对应的xcode的相关配置通过预设配置文件即可配置完成，无需通过人为修改并核对的方式，获取到配置信息的时间可控，获取配置信息的效率较高，可以有效地提高ios应用程序的打包稳定性和打包效率。

需要说明的上述，关于计算机设备中的处理器执行计算机程序时实现的方法，可具体参阅前述应用程序处理方法对应的步骤，具体这里不重复赘述。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

接收用户触发的打包请求，所述打包请求包括ios应用程序的打包类型；

获取所述打包类型对应的预设配置文件，所述预设配置文件包含配置参数文件、证书文件和描述文件；

根据所述配置参数文件、证书文件和描述文件配置所述ios应用程序的xcode配置信息；

根据所述xcode配置信息对所述ios应用程序的源代码进行编译并打包，以获得打包文件。

由以上技术方案可以看出，与传统方案相比，本申请提供的计算机可读存储介质中，存储在计算机可读存储介质的计算机程序被处理器执行时所实现的方案中，利用获得的包含有配置参数文件、证书文件和描述文件的预设配置文件完成ios应用程序对应的xcode配置，也就是ios应用程序对应的xcode的相关配置通过预设配置文件即可配置完成，无需通过人为修改并核对的方式，获取到配置信息的时间可控，获取配置信息的效率较高，可以有效地提高ios应用程序的打包稳定性和打包效率。

需要说明的上述，关于计算机程序被处理器执行时实现的方法，可具体参阅前述应用程序处理方法对应的步骤，具体这里不重复赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。