CN111078229A - 一种应用程序处理方法、装置、存储介质及电子设备 - Google Patents

Abstract

本申请涉及软件开发技术领域，提供一种应用程序处理方法、装置、存储介质及电子设备。其中，应用程序处理方法包括：将应用程序的源代码以及编译依赖注入到宿主机上的基础镜像中；向基础镜像中的编译器下发编译指令，以使编译器根据源代码以及编译依赖进行编译，输出编译好的二进制文件以及运行依赖；将应用程序的打包信息注入到基础镜像中；向基础镜像中的打包工具下发打包指令，以使打包工具根据编译好的二进制文件、运行依赖以及打包信息进行打包，输出应用程序的发布包。该方法的编译及打包操作在目标平台的容器镜像内完成，即提供了一种对跨平台应用程序进行编译打包的轻量级的解决方案。另外，整个编译打包流程可自动化完成，执行效率很高。

Description

一种应用程序处理方法、装置、存储介质及电子设备

技术领域

本发明涉及软件开发技术领域，具体而言，涉及一种应用程序处理方 法、装置、存储介质及电子设备。

背景技术

目前，对应用程序跨平台的需求越来越多。在现有的跨平台编译打包 方式中，一般先使用vmare、vbox等虚拟机软件虚拟出多个目标平台系统， 然后手工将待编译的应用程序的源代码拷贝到各虚拟系统中进行编译打包， 其流程繁琐，执行效率低下，并且创建不同平台的虚拟机也会大量消耗宿 主机资源。

发明内容

本申请实施例的目的在于提供一种应用程序处理方法、装置、存储介 质及电子设备，以改善上述技术问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，本申请实施例提供一种应用程序处理方法，包括：将待编 译的应用程序的源代码以及编译依赖注入到部署在宿主机上的基础镜像中； 其中，所述基础镜像为用于部署所述应用程序的目标平台的容器镜像；向 所述基础镜像中的编译器下发编译指令，以使所述编译器根据所述源代码 以及所述编译依赖进行编译，输出编译好的二进制文件以及运行依赖；将 所述应用程序的打包信息注入到所述基础镜像中；向所述基础镜像中的打 包工具下发打包指令，以使所述打包工具根据所述编译好的二进制文件、 所述运行依赖以及所述打包信息进行打包，输出所述应用程序的发布包。

上述应用程序处理方法用于对应用程序的源代码进行编译及打包，最 终生成应用程序的发布包，其相较于现有技术的优势在于：

其一，编译及打包的具体操作在宿主机上的基础镜像内完成，该基础 镜像为用于部署应用程序的目标平台的容器镜像，相较于虚拟机，容器对 于宿主机的资源占用较少，即提供了一种对跨平台应用程序进行编译打包 的轻量级的解决方案。

其二，整个处理流程逻辑简单，可通过宿主机与基础镜像的配合快速 完成应用程序的编译和打包，在一些可选方案中，该方法可以实现为宿主 机上的脚本，运行脚本后自动完成编译和打包流程，无需人工介入，执行 效率很高。

在第一方面的一种实现方式中，在所述将待编译的应用程序的源代码 以及编译依赖注入到部署在宿主机上的基础镜像中之前，所述方法还包括： 将所述基础镜像导入到所述宿主机上容器管理引擎中。

导入基础镜像后，应用程序的打包编译环境构建完成，容器管理引擎 可以对该容器镜像进行管理，包括基于该基础镜像启动容器等。

在第一方面的一种实现方式中，所述编译器在根据所述源代码以及所 述编译依赖进行编译的过程中，还将编译信息实时输出到所述宿主机上。

编译信息包括编译过程中产生的日志等，这些信息输出到宿主机上后， 有利于开发人员实时监控编译过程，及时处理异常状况。

在第一方面的一种实现方式中，在所述向所述基础镜像中的编译器下 发编译指令之后，所述方法还包括：从所述基础镜像中获取所述编译好的 二进制文件以及所述运行依赖，并在所述宿主机上备份。

在应用程序的开发过程中，可能会编译多个版本的源代码，可以将编 译结果输出到宿主机上备份，避免在基础镜像中每次编译后将之前的编译 结果覆盖掉。

在第一方面的一种实现方式中，在所述将所述应用程序的打包信息注 入到所述基础镜像中之前，所述方法还包括：将所述打包工具注入到所述 基础镜像中。

在基础镜像中很可能未携带打包工具，需要后期注入，类似地，如果 基础镜像中未携带编译器，也需要后期注入。

在第一方面的一种实现方式中，在所述将所述应用程序的打包信息注 入到所述基础镜像中之前，所述方法还包括：确认所述基础镜像中的打包 环境符合打包要求；其中，所述打包环境符合要求包括所述基础镜像中已 安装打包工具。

在进行打包之前，可以先对基础镜像中的打包环境进行检查，例如检 查打包工具是否已经就绪等，确保后续的打包操作能够顺利进行。

在第一方面的一种实现方式中，在所述向所述基础镜像中的打包工具 下发打包指令之后，所述方法还包括：从所述基础镜像中获取所述应用程 序的发布包并在所述宿主机上保存。

可以将应用程序的发布包输出到宿主机上保存，从而在后续步骤中将 发布包部署到目标平台上运行。

第二方面，本申请实施例提供一种应用程序处理装置，包括：编译信 息注入模块，用于将待编译的应用程序的源代码以及编译依赖注入到部署 在宿主机上的基础镜像中；其中，所述基础镜像为用于部署所述应用程序 的目标平台的容器镜像；编译模块，用于向所述基础镜像中的编译器下发 编译指令，以使所述编译器根据所述源代码以及所述编译依赖进行编译， 输出编译好的二进制文件以及运行依赖；打包信息注入模块，用于将所述应用程序的打包信息注入到所述基础镜像中；打包模块，用于向所述基础 镜像中的打包工具下发打包指令，以使所述打包工具根据所述编译好的二 进制文件、所述运行依赖以及所述打包信息进行打包，输出所述应用程序 的发布包。

第三方面，本申请实施例提供一种计算机可读存储介质，所述计算机 可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读 取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的 方法。

第四方面，本申请实施例提供一种电子设备，包括：存储器以及处理 器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处 理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式 提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例 中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请 的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人 员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相 关的附图。

图1示出了本申请实施例提供的一种应用程序处理方法的流程图；

图2示出了本申请实施例提供的一种应用程序处理装置的功能模块图；

图3示出了本申请实施例提供的一种电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进 行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此， 一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一 步定义和解释。术语“包括”、“包含”或者其任何其他变体意在涵盖非排 他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅 包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下， 由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、 方法、物品或者设备中还存在另外的相同要素。

图1示出了本申请实施例提供的一种应用程序处理方法的流程图。这 里所谓的处理，至少包括对应用程序的源代码进行编译，以及，对编译好 的二进制文件进行打包两项操作，但也不排除还可以包括其他操作。参照 图1，应用程序处理方法主要通过宿主机和基础镜像之间的交互实现，其中 宿主机同时也是部署基础镜像的设备(该设备可能的结构可以参考后文关 于图3的阐述)，但也不排除在某些实现方式中，图1中由宿主机执行的步 骤可改为由一远程设备执行，该远程设备可以通过网络直接和基础镜像进 行交互。下面具体介绍图1中示出的步骤：

步骤S100：将基础镜像导入宿主机。

在本申请中，将应用程序运行的平台称为目标平台，即执行完本申请 中的应用程序处理方法得到的发布包最终要部署到该目标平台上运行。例 如，目标平台可以是基于arm架构的ubuntu、基于x86_64架构的linux、基 于x86_64架构的windows等，包含目标平台的容器镜像称为基础镜像，基 础镜像也是本申请提出的方法中对应用程序进行编译和打包的环境。本申 请中的应用程序可以是跨平台程序，程序需要在哪个平台上部署就选择对应平台的基础镜像作为编译和打包环境，如果需要在多个平台上部署，则 需准备多个平台的基础镜像。常见平台的基础镜像是一般现有的，可以直 接从容器的镜像仓库中下载官方镜像，具体采用何种容器技术本申请不限 定，例如，可以是Docker、CoreOS等。

需要指出，用于部署基础镜像的宿主机，其具体采用何种平台与目标 平台是无关的，例如宿主机可以采用windows平台，基础镜像则可以是linux 平台的镜像。换句话说，不管宿主机本身是什么平台，通过部署目标平台 的基础镜像都可以实现应用程序的编译和打包，即可以在宿主机上借助于 容器技术实现跨平台的编译和打包。

宿主机获取到基础镜像后，首先需要将基础镜像导入到本地的容器引 擎环境中，例如，若采用Docker容器引擎，可以通过import或load命令进 行镜像导入。导入基础镜像相当于构建好了应用程序的打包编译环境，后 续对应用程序的打包编译操作也在该环境中进行，容器管理引擎可以对导 入的基础镜像进行管理，例如基于该基础镜像启动容器等。需要指出，后 续步骤应当在容器启动后执行。

步骤S101：宿主机将应用程序的源代码以及编译依赖注入到基础镜像 中。

应用程序的源代码是指开发好后待编译的代码，编译依赖包括源代码 在编译过程中需要依赖的一些资源，例如可以是配置文件、程序包等，编 译依赖中还可以包括用于指示编译器如何进行编译的编译脚本。宿主机在 准备好应用程序的源代码以及编译依赖后，可以将其拷贝到基础镜像中指 定的目录下。当然，若基础镜像能够连接网络，而应用程序的源代码存放 在网络中的某资源地址，基础镜像亦可直接从该地址处下载源代码，宿主机只需将下载代码的地址告知基础镜像即可。

步骤S102：宿主机向基础镜像中的编译器下发编译指令。

步骤S103：基础镜像中的编译器根据应用程序的源代码以及编译依赖 进行编译，输出编译好的二进制文件以及运行依赖。

以上两个步骤合并在一起进行阐述，两个步骤的关系是：步骤S102中 宿主机向编译器下发编译指令，步骤S103中编译器响应于该指令执行编译 操作。

要对源代码进行编译，基础镜像中必须包含编译器，一些基础镜像在 制作时已经包含编译器，若未包含，在执行步骤S102之前，宿主机应当获 取编译器并将编译器注入到基础镜像中并安装。

具体的编译过程可以参考现有技术，此处不作阐述。编译器可根据编 译指令的内容、应用程序的源代码以及编译依赖进行编译，输出编译好的 二进制文件(可执行文件)以及运行依赖。其中，运行依赖包括应用程序 在运行时需要依赖的一些资源，例如可以是配置文件、程序包等。

编译器在进行编译的过程中通常会产生编译信息，其中可以包括普通 的提示信息还可以包括异常检测信息，这些编译信息可以组织为日志的形 式。在一种实现方式中，编译器可将编译信息实时输出到宿主机上，从而 开发人员可以在宿主机上或者通过访问宿主机实时监控编译过程，若发现 其中存在异常亦可及时分析及时处理，保障编译过程顺利进行。在下发的 编译指令或注入的编译脚本(属于编译依赖的一部分)中，可以指示编译器将编译信息输出到宿主机。

步骤S104：宿主机从基础镜像中获取编译好的二进制文件以及运行依 赖。

步骤S105：宿主机对编译好的二进制文件以及运行依赖进行备份。

以上两个步骤合并在一起进行阐述，编译好的二进制文件以及运行依 赖可以存放在基础镜像指定的目录中，从而宿主机可以从该目录中获取编 译好的二进制文件以及运行依赖。宿主机可以将获取到的编译好的二进制 文件和运行依赖进行备份，例如可以将其备份到数据库。

进行编译结果备份的原因可能有多种：例如，在应用程序的开发过程 中，可能会编译多个版本的源代码，从而产生多个版本的编译结果，可以 将这些编译结果分别备份到宿主机上，避免在基础镜像中每次编译后将之 前的编译结果覆盖掉。又例如，有时需要使用编译结果(而非最终的打包 结果)用于调试等目的，此时也可以将编译结果先备份到宿主机上。

可以理解的，步骤S104和步骤S105不是必须的，若不需要进行编译 结果的备份，则可略过这两个步骤，直接执行后续步骤。

步骤S106：宿主机检查基础镜像上的打包环境是否符合打包要求。

只有基础镜像上的打包环境满足打包要求，才能够执行后续的打包步 骤，例如，若要进行打包，基础镜像中应该先安装打包工具，若检查后发 现未安装相应的打包工具，则宿主机需要先获取相应的打包工具并将其注 入到基础镜像中(当然注入打包工具也可以在步骤S106之前就执行)完成 安装。上面例子中所谓相应的打包工具和具体要产生的发布包的类型有关， 例如，要生成rpm包，则应当安装制作rpm包的工具，若要生成deb包， 则应当安装制作deb包的工具(rpm和deb是linux系统中常见的两种包格 式)。当然，打包环境不仅仅指是否安装打包工具，还可以包括其他和打包 相关的环境配置信息。

步骤S106为可选步骤，若能够确保打包环境符合打包要求，则可略过 步骤S106，直接执行后续步骤。

步骤S107：宿主机将应用程序的打包信息注入到基础镜像中。

应用程序的打包信息包括应用程序在打包过程中需要依赖的相关配置， 例如可以是程序的版本信息等，打包信息还可以包括用于指示打包工具如 何进行打包的打包脚本。宿主机在准备好应用程序的打包信息后，可以将 其拷贝到基础镜像中指定的目录下。

步骤S108：宿主机向基础镜像中的打包工具下发打包指令。

步骤S109：基础镜像中的打包工具根据编译好的二进制文件、运行依 赖以及打包信息进行打包，输出应用程序的发布包。

以上两个步骤合并在一起进行阐述，两个步骤的关系是：步骤S108中 宿主机向打包工具下发编译指令，步骤S109中打包工具响应于该指令执行 打包操作。

具体的打包过程可以参考现有技术，此处不作阐述。打包工具可根据 打包指令的内容、编译好的二进制文件以及打包信息进行打包，输出应用 程序的发布包。该发布包可以部署到目标平台运行，实现应用程序的功能。

打包工具在打包过程中也有可能产生打包日志，对于打包日志，也可 以采取和编译器产生的编译信息类似的处理方式，将其实时输出到宿主机 上进行打包过程的监控，其具体过程不再赘述(图1也省略未画出)。

步骤S110：宿主机从基础镜像中获取应用程序的发布包。

应用程序的发布包可以存放在基础镜像指定的目录中，从而宿主机可 以从该目录中获取应用程序的发布包。宿主机可以将应用程序的发布包存 档或者将其部署到目标平台上运行。

综上所述，本申请实施例提供的应用程序处理方法提供了一套对跨平 台的应用程序进行编译及打包的完整流程，该方法相较于现有技术的优势 在于：

其一，编译及打包的具体操作在宿主机上的基础镜像内完成，该基础 镜像为用于部署应用程序的目标平台的容器镜像，相较于对照实施例中通 过部署搭载有目标平台的虚拟机进行编译及打包的方式，容器对于宿主机 的资源占用较少，即提供了一种对跨平台应用程序进行编译打包的轻量级 的解决方案。同时，目前已经有很多针对各平台的官方镜像可以使用(特 别对于广泛使用的Docker容器更是如此)，使得本申请中的方案实施起来比较方便。

其二，整个编译打包流程逻辑简单，其核心步骤由宿主机驱动完成， 具体操作则在基础镜像中执行，其过程可以简单概括为：宿主机向基础镜 像注入编译所需信息；宿主机向基础镜像下发编译指令，指示基础镜像进 行编译；宿主机向基础镜像注入打包所需信息；宿主机向基础镜像下发打 包指令，指示基础镜像进行打包。可见，只需要宿主机与基础镜像之间进 行简单的配合即可快速完成应用程序的编译和打包，其执行效率很高。

在一些可选方案中，该应用程序处理方法中由宿主机执行的步骤可以 实现为宿主机上的脚本或者普通的应用程序，以脚本形式为例，对脚本进 行适当配置后，执行该脚本即可自动完成应用程序的编译和打包流程，整 个过程无需人工介入，是完全自动化的，大大减轻了开发人员的负担。在 对照实施例中，一般需要手工将应用程序的源代码拷贝到指定目录，然后 使用交叉编译工具链的形式进行不同平台的编译，之后手动对其生成的二进制文件进行打包，最后生成可用于目标平台的发布包，其中涉及环节复 杂，而且手动操作步骤较多，导致执行效率低下。

此外，可以理解的，本申请实施例提供的应用程序处理方法也可以被 部分地使用：例如，在某一场景中只需要对应用程序的源代码进行编译， 不需要进行打包，则可以只执行步骤S100至步骤S105；又例如，在某一场 景中只需要对已有编译结果进行打包，不需要进行编译，则可以只执行步 骤S106至步骤S110(当然在打包之前先要将编译结果注入到基础镜像中)。

图2示出了本申请实施例提供的应用程序处理装置200的功能模块图。 参照图2，应用程序处理装置200包括：

编译信息注入模块210，用于将待编译的应用程序的源代码以及编译依 赖注入到部署在宿主机上的基础镜像中；其中，所述基础镜像为用于部署 所述应用程序的目标平台的容器镜像；

编译模块220，用于向所述基础镜像中的编译器下发编译指令，以使所 述编译器根据所述源代码以及所述编译依赖进行编译，输出编译好的二进 制文件以及运行依赖；

打包信息注入模块230，用于将所述应用程序的打包信息注入到所述基 础镜像中；

打包模块240，用于向所述基础镜像中的打包工具下发打包指令，以使 所述打包工具根据所述编译好的二进制文件、所述运行依赖以及所述打包 信息进行打包，输出所述应用程序的发布包。

在应用程序处理装置200的一种实现方式中，所述装置还包括：镜像 导入模块，用于在编译信息注入模块210将待编译的应用程序的源代码以 及编译依赖注入到部署在宿主机上的基础镜像中之前，将所述基础镜像导 入到所述宿主机上容器管理引擎中。

在应用程序处理装置200的一种实现方式中，所述编译器在根据所述 源代码以及所述编译依赖进行编译的过程中，还将编译信息实时输出到所 述宿主机上。

在应用程序处理装置200的一种实现方式中，所述装置还包括：编译 结果输出模块，用于在编译模块220向所述基础镜像中的编译器下发编译 指令之后，从所述基础镜像中获取所述编译好的二进制文件以及所述运行 依赖，并在所述宿主机上备份。

在应用程序处理装置200的一种实现方式中，所述装置还包括：打包 工具注入模块，用于在打包信息注入模块230将所述应用程序的打包信息 注入到所述基础镜像中之前，将所述打包工具注入到所述基础镜像中。

在应用程序处理装置200的一种实现方式中，所述装置还包括：打包 环境检查模块，用于在打包信息注入模块230将所述应用程序的打包信息 注入到所述基础镜像中之前，确认所述基础镜像中的打包环境符合打包要 求；其中，所述打包环境符合要求包括所述基础镜像中已安装打包工具。

在应用程序处理装置200的一种实现方式中，所述装置还包括：打包 结果输出模块，用于在打包模块240向所述基础镜像中的打包工具下发打 包指令之后，从所述基础镜像中获取所述应用程序的发布包并在所述宿主 机上保存。

本申请实施例提供的应用程序处理装置200，其实现原理及产生的 技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部 分未提及之处，可参考方法施例中相应内容。

图3示出了本申请实施例提供的一种电子设备的示意图。参照图3，电 子设备300包括：处理器310、存储器320以及通信接口330，这些组件通 过通信总线340和/或其他形式的连接机构(未示出)互连并相互通讯。

其中，存储器320包括一个或多个(图中仅示出一个)，其可以是，但 不限于，随机存取存储器(Random Access Memory，简称RAM)，只读存 储器(Read Only Memory，简称ROM)，可编程只读存储器(Programmable Read-Only Memory，简称PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，简称EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，简称EEPROM)等。 处理器310以及其他可能的组件可对存储器320进行访问，读和/或写其中 的数据。

处理器310包括一个或多个(图中仅示出一个)，其可以是一种集成电 路芯片，具有信号的处理能力。上述的处理器310可以是通用处理器，包 括中央处理器(CentralProcessing Unit，简称CPU)、微控制单元(Micro Controller Unit，简称MCU)、网络处理器(Network Processor，简称NP)或 者其他常规处理器；还可以是专用处理器，包括数字信号处理器 (Digital Signal Processor,简称DSP)、专用集成电路(Application SpecificIntegrated Circuits，简称ASIC)、现场可编程门阵列(Field Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、 分立硬件组件。

通信接口330包括一个或多个(图中仅示出一个)，可以用于和其他设 备进行直接或间接地通信，以便进行数据的交互。例如，通信接口330可 以是以太网接口；可以是高速网络接口(如Infiniband网络)；可以是移动 通信网络接口(如3G、4G、5G网络的接口)；可以是各类总线接口，例如 USB、CAN、I2C、SPI等总线接口；还是可以是具有数据收发功能的其他 类型的接口。

在存储器320中可以存储一条或多条计算机程序指令，处理器310可 以读取并运行这些计算机程序指令，以实现本申请实施例提供的应用程序 处理方法以及其他期望的功能。

可以理解，图3所示的结构仅为示意，电子设备300还可以包括比图 3中所示更多或者更少的组件，或者具有与图3所示不同的配置。图3中所 示的各组件可以采用硬件、软件或其组合实现。例如，在采用硬件方式实 现时，电子设备300可以是个人计算机、手机、平板电脑、服务器等；在 采用软件方式实现时，电子设备300可以是虚拟机。此外，电子设备300 也不限于单台设备，也可以是多台设备的组合或者大量设备构成的集群。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介 质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取 并运行时，执行本申请实施例提供的应用程序处理方法。例如，计算机可 读存储介质可以实现为图3中电子设备300中的存储器320。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以 通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如， 所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划 分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统， 或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦 合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦 合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的， 作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地 方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的 部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个 独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集 成形成一个独立的部分。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围， 对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请 的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本 申请的保护范围之内。

Claims (10)

1.一种应用程序处理方法，其特征在于，包括：

将待编译的应用程序的源代码以及编译依赖注入到部署在宿主机上的基础镜像中；其中，所述基础镜像为用于部署所述应用程序的目标平台的容器镜像；

向所述基础镜像中的编译器下发编译指令，以使所述编译器根据所述源代码以及所述编译依赖进行编译，输出编译好的二进制文件以及运行依赖；

将所述应用程序的打包信息注入到所述基础镜像中；

向所述基础镜像中的打包工具下发打包指令，以使所述打包工具根据所述编译好的二进制文件、所述运行依赖以及所述打包信息进行打包，输出所述应用程序的发布包。

2.根据权利要求1所述的应用程序处理方法，其特征在于，在所述将待编译的应用程序的源代码以及编译依赖注入到部署在宿主机上的基础镜像中之前，所述方法还包括：

将所述基础镜像导入到所述宿主机上容器管理引擎中。

3.根据权利要求1所述的应用程序处理方法，其特征在于，所述编译器在根据所述源代码以及所述编译依赖进行编译的过程中，还将编译信息实时输出到所述宿主机上。

4.根据权利要求1所述的应用程序处理方法，其特征在于，在所述向所述基础镜像中的编译器下发编译指令之后，所述方法还包括：

从所述基础镜像中获取所述编译好的二进制文件以及所述运行依赖，并在所述宿主机上备份。

5.根据权利要求1所述的应用程序处理方法，其特征在于，在所述将所述应用程序的打包信息注入到所述基础镜像中之前，所述方法还包括：

将所述打包工具注入到所述基础镜像中。

6.根据权利要求1所述的应用程序处理方法，其特征在于，在所述将所述应用程序的打包信息注入到所述基础镜像中之前，所述方法还包括：

确认所述基础镜像中的打包环境符合打包要求；其中，所述打包环境符合要求包括所述基础镜像中已安装打包工具。

7.根据权利要求1所述的应用程序处理方法，其特征在于，在所述向所述基础镜像中的打包工具下发打包指令之后，所述方法还包括：

从所述基础镜像中获取所述应用程序的发布包并在所述宿主机上保存。

8.一种应用程序处理装置，其特征在于，包括：

编译信息注入模块，用于将待编译的应用程序的源代码以及编译依赖注入到部署在宿主机上的基础镜像中；其中，所述基础镜像为用于部署所述应用程序的目标平台的容器镜像；

编译模块，用于向所述基础镜像中的编译器下发编译指令，以使所述编译器根据所述源代码以及所述编译依赖进行编译，输出编译好的二进制文件以及运行依赖；

打包信息注入模块，用于将所述应用程序的打包信息注入到所述基础镜像中；

打包模块，用于向所述基础镜像中的打包工具下发打包指令，以使所述打包工具根据所述编译好的二进制文件、所述运行依赖以及所述打包信息进行打包，输出所述应用程序的发布包。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行如权利要求1-7中任一项所述的方法。

10.一种电子设备，其特征在于，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行如权利要求1-7中任一项所述的方法。

Images