一种应用程序的运行方法、装置、设备及介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种应用程序的运行方法、装置、设备及介质。

背景技术

随着汽车电控技术的不断发展，整车上的电控单元越来越集成化、平台化和系统化。通常，电控单元的开发过程如下：根据系统类型和软件需求开发应用程序代码，根据供应商提供的单片机配置相应的寄存器和外设驱动等，将应用程序代码进行集成、编译和调试。

目前，应用程序代码的开发过程中，大多采用C语言和C++语言等。当采用多种编程语言开发同一应用程序时，由于难以兼容多种编程语言，因此，需要将多种编程语言统一为同一种编程语言，放弃某些编程语言，而将一种编程语言编写的代码改写为另一种编程语言编写的代码会导致任务繁重，应用程序的开发周期长。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种应用程序的运行方法、装置、设备及介质。

第一方面，本公开提供了一种应用程序的运行方法，包括：

获取应用程序的第一组件和第二组件，第一组件和第二组件的编程语言不同；

对第一组件和第二组件进行编译处理，得到具有相同格式的第一执行文件和第二执行文件；

在容器中运行第一执行文件和第二执行文件。

在一些实施例中，第一组件和第二组件的编程语言包括C语言、C++语言以及RUST语言中的两者。

在一些实施例中，第一执行文件和第二执行文件的格式包括.wasm格式。

在一些实施例中，在在容器中运行第一执行文件和第二执行文件之前还包括：将第一执行文件、第二执行文件、运行时程序、系统服务、生命周期管理以及库函数进行打包，得到容器。

在一些实施例中，在容器中运行第一执行文件和第二执行文件包括：

启动容器中的运行时程序；

在运行时程序中运行第一执行文件和第二执行文件。

在一些实施例中，在容器中运行第一执行文件和第二执行文件之前还包括：

根据容器对应的操作系统类型确定运行时程序的格式。

在一些实施例中，根据容器对应的操作系统类型确定运行时程序的格式包括：

确定容器对应的操作系统类型为Linux，确定运行时程序的格式为.elf格式；或者；

确定容器对应的操作系统类型为Windows，确定运行时程序的格式为.exe格式。

在一些实施例中，在在容器中运行第一执行文件和第二执行文件之前还包括：

对第一执行文件和第二执行文件进行编译处理，得到具有相同格式的第一头文件和第二头文件；

将第一头文件、第二头文件、系统服务、生命周期管理以及库函数进行打包，得到容器。

在一些实施例中，在在容器中运行第一执行文件和第二执行文件之前还包括：

对第一执行文件和第二执行文件进行编译处理，得到具有相同格式的第一头文件和第二头文件；

建立工程文件；

对工程文件、以及容器进行编译处理，得到第三执行文件；

其中，在容器中运行第一执行文件和第二执行文件包括：

运行第三执行文件。

第二方面，本公开提供了一种应用程序的运行装置，包括：

获取模块，配置为获取应用程序的第一组件和第二组件，第一组件和第二组件的编程语言不同；

第一编译模块，配置为对第一组件和第二组件进行编译处理，得到具有相同格式的第一执行文件和第二执行文件；

运行模块，配置为在容器中运行第一执行文件和第二执行文件。

第三方面，本公开提供了一种计算机设备，包括：

存储器和处理器，其中，存储器中存储有计算机程序，当计算机程序被处理器执行时，实现如第一方面所述的方法。

第四方面，本公开提供了一种计算机可读存储介质，存储介质中存储有计算机程序，当计算机程序被处理器执行时，实现如第一方面的方法。

本公开实施例提供的技术方案与现有技术相比具有如下优点：

本公开实施例的应用程序的运行方法、装置、设备及存储介质，能够获取应用程序的第一组件和第二组件，第一组件和第二组件的编程语言不同，并对第一组件和第二组件进行编译处理，得到具有相同格式的第一执行文件和第二执行文件，在容器中运行第一执行文件和第二执行文件。如此，当应用程序的第一组件和第二组件以不同编程语言编写时，无需将第一组件改写为与第二组件相同的编程语言，例如，当第一组件以C语言编写且第二组件以C++语言编写时，无需将以C语言编写的第一组件改写为以C++语言编写，也无需将以C++语言编写的第二组件改写为以C语言编写，可见，基于本公开实施例的应用程序的运行方法，开发人员可灵活选取第一组件和第二组件的编程语言，以不同编程语言编写的第一组件和第二组件可在编译为具有相同格式的第一执行文件和第二执行文件后在容器中运行，有利于缩短程序的开发周期。并且，将第一组件和第二组件进行编译处理之后再在容器中运行，则无需将用于对组件进行编译的模块打包进容器中，有利于缩小容器所占的内存。

附图说明

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

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

图1为本公开实施例提供的一种应用程序的运行方法的流程示意图；

图2为本公开实施例提供的一种Simulink模型转代码的流程示意图；

图3为本公开实施例提供的一种容器的结构示意图；

图4为本公开实施例提供的另一种容器的结构示意图；

图5为本公开实施例提供的又一种容器的结构示意图；

图6为本公开实施例提供的一种应用程序的运行过程的流程示意图；

图7为本公开实施例提供的一种应用程序的运行装置的结构示意图；

图8为本公开实施例提供的一种计算机设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

图1为本公开实施例提供的一种应用程序的运行方法的流程示意图。在本公开一些实施例中，图1所示的方法可以应用于应用程序在容器中运行的情况。

如图1所示，该应用程序的运行方法可以包括如下步骤。

S110、获取应用程序的第一组件和第二组件，第一组件和第二组件的编程语言不同。

具体地，应用程序为开发人员为实现某一预设功能而编写的代码，当该应用程序运行时，可实现该预设功能。

在本公开实施例中，应用程序可以为任意针对车辆的电子控单元(ElectronicControl Unit，ECU)而编写的程序。示例性地，应用程序可以包括交互类应用程序，例如包括导航程序、或者音频播放程序等；应用程序还可以包括自动驾驶类控制程序，例如，自动泊车入库程序、自动路径规划程序、或者自动碰撞预警程序等；应用程序还可以包括电池管理类控制程序，例如，电池充电控制程序、电池内阻检测程序等。

具体地，对于应用程序(尤其是大型应用程序)而言，多方分工开发应用程序的不同组件可有效缩短应用程序的整体研发周期，因此，应用程序通常包括至少两个组件，每个组件包括用于实现应用程序所要实现的预设功能中的其中一部分功能的代码。

具体地，应用程序包括第一组件和第二组件，两者的编程语言不同。本领域技术人员可根据实际情况设置第一组件和第二组件的编程语言，此处不作限定。

可选地，第一组件和第二组件的编程语言包括C语言、C++语言以及RUST语言中的两者。

可以理解的是，C语言、C++语言以及RUST语言是开发人员较常用、比较熟悉的语言。当第一组件和第二组件的编程语言采用开发人员熟悉的语言时，便于开发人员编写组件或者检查组件是否具有漏洞，有利于提高开发程序的编写效率。

在一些实施例中，第一组件和第二组件可以由开发人员直接编写代码得到。

在另一些实施例中，第一组件和第二组件还可以由功能模型转变而来。

具体地，功能模型中包括多个功能模块，其可以实现应用程序所要实现的预设功能中的其中一部分功能，如此，将功能模型转变为代码后，可得到该功能模型对应的组件，且该组件能够实现与该功能模型相同的功能。

可以理解的是，通过由功能模型转为组件的方式得到应用程序，可使开发人员无需直接编写代码，有利于提高应用程序的开发效率，缩小开发周期。

示例性地，功能模型可以包括Simulink模型，在针对ECU的应用程序开发中，开发人员通常使用Simulink软件进行程序开发，在Simulink软件中设计的Simulink模型可以通过模型解析以及代码生成转变为代码。示例性地，图2为本公开实施例提供的一种Simulink模型转代码的流程示意图。参见图2，Simulink模型转代码的流程包括如下步骤：

S210、获取Simulink模型。

S220、对Simulink模型进行代码生成解析处理，得到.rtw格式的模型描述文件。

具体地，在Simulink软件中设计的Simulink模型包括多个功能模块，Simulink模型通过代码生成解析可以转变为.rtw格式的模型描述文件。

S230、对.rtw格式的模型描述文件进行编译处理，得到组件。

具体地，.rtw模型描述文件可通过目标语言编译器进行编译(Target LanguangeCompiler，TLC)处理，转变为代码，从而得到组件。通过对TLC进行设置可以选择代码组件的编程语言，示例性地，组件的编程语言可以是C语言，也可以是C++语言，本公开对此不作限定。

S120、对第一组件和第二组件进行编译处理，得到具有相同格式的第一执行文件和第二执行文件。

具体地，如前文所述，第一组件的编程语言可以为C语言、C++语言、或者RUST语言等高级语言，第一组件通过编译器进行编译处理之后可转变为以预设解释器语言编写的代码，并保存在第一执行文件中。同理，第二组件通过编译器进行编译处理之后也可转变为以预设解释器语言编写的代码，并保存在第二执行文件中。

具体地，第一执行文件和第二执行文件的格式，本领域技术人员可根据实际情况设置，此处不作限定。

可选地，第一执行文件和第二执行文件的格式包括.wasm格式。

可以理解的是，.wasm格式的执行文件中包括的是wasm代码，wasm代码支持多种语言(例如C语言、C++语言、RUST语言等)经过编译处理后得到，因此，将第一组件和第二组件经过编译处理得到wasm代码，可使第一组件和第二组的编程语言具有更多选择性。

具体地，对第一组件和第二组件进行编译处理的具体实施方式，本领域技术人员可根据实际情况设置，此处不作限定。

可选地，对第一组件进行编译处理，得到第一执行文件包括：获取第一组件的第一存储路径；获取第一组件对应的第一编译器的第一调用路径；根据第一调用路径，调用第一编译器，以使第一编译器根据第一存储路径查找第一组件，并对第一组件进行编译处理，得到第一执行文件。

具体地，第一组件编写完成后，会得到多个文件。该多个文件的存储路径即为第一组件的第一存储路径。

例如，当第一组件的编程语言为C语言时，会得到.c文件以及.c文件所依赖的文件，其存储路径即为第一组件的存储路径。

具体地，不同编程语言的组件，其对应的编译器可能不同，因此，需要根据组件的编程语言确定组件对应的编译器，然后获取组件对应的编译器的存储位置(即调用路径)第一组件对应的第一编译器的存储路径(即第一调用路径)。

例如，第一组件的编程语言为C语言(或C++语言)，其对应的编译器包括Clang编译器。获取Clang编译器的存储路径，即可得到第一组件的第一调用路径。

具体地，根据第一调用路径可以找到第一编译器后，第一编译器可根据第一存储路径查找到将要被进行编译处理的第一组件。第一编译器对第一组件进行编译处理的过程可以如下：分配第一执行文件的堆栈空间；定义第一执行文件的文件名；获取第一组件中包含函数符号的源文件；将源文件中的函数符号导出至第一执行文件中；将形式参数导出至第一执行文件中；将除函数符号以及形式参数之外的数据导出至第一执行文件中；将堆栈导出至第一执行文件中。

需要说明的是，对第二组件进行编译处理的具体实施方式可以与对第二组件进行编译处理的具体实施方式相似，此处不再赘述。

可以理解的是，以不同编程语言编写的第一组件和第二组件经过编译处理之后可变为具有相同编程语言(预设解释器语言)的代码，例如，以C语言编写的第一组件以及以C++语言编写的第二组件经过编译处理之后可得到第一执行文件和第二执行文件，第一执行文件和第二执行文件中均包括wasm代码，如此，实现了编程语言的统一，进行使得具有相同格式的第一执行文件和第二执行文件能够在容器中运行。

S130、在容器中运行第一执行文件和第二执行文件。

具体地，容器是将应用程序和应用程序中使用的所有依赖项打包到一个程序包中的软件单元。打包让容器可以将应用程序与其运行所在的主机环境隔离，有利于实现应用程序的平台移植性。

具体地，容器可以包括应用程序所包含的组件对应的执行文件、以及应用程序的中使用的依赖项，例如，依赖项包括运行时环境(Run Time Environment，RTE)、系统服务(Services)、生命周期管理(Manager)、以及函数库，但不限于此。其中，应用程序所包含的组件对应的执行文件可通过运行时环境在容器中运行，运行时环境的具体实现形式与容器所在的操作系统相关。后文中将就典型示例进行说明，此处先不作赘述。

可以理解的是，ECU的控制器的内存通常较小，例如，ECU采用微控制单元(Microcontroller Unit，MCU)做控制器时，MCU的内存仅有几MB，难以在其上设置所占内容较大的容器。本公开实施例中，通过在容器外将第一组件和第二组件进行编译处理得到第一执行文件和第二执行文件之后，再在容器中运行第一执行文件和第二执行文件，使得无需将用于对组件进行编译处理的功能模块打包进容器中，如此，可使容器所占的内存比较小，为顺利在ECU的控制器中设置容器奠定基础。

本公开实施例的应用程序的运行方法，能够获取应用程序的第一组件和第二组件，第一组件和第二组件的编程语言不同，并对第一组件和第二组件进行编译处理，得到具有相同格式的第一执行文件和第二执行文件，在容器中运行第一执行文件和第二执行文件。如此，当应用程序的第一组件和第二组件以不同编程语言编写时，无需将第一组件改写为与第二组件相同的编程语言，例如，当第一组件以C语言编写且第二组件以C++语言编写时，无需将以C语言编写的第一组件改写为以C++语言编写，也无需将以C++语言编写的第二组件改写为以C语言编写，可见，基于本公开实施例的应用程序的运行方法，开发人员可灵活选取第一组件和第二组件的编程语言，以不同编程语言编写的第一组件和第二组件可在编译为具有相同格式的第一执行文件和第二执行文件后在容器中运行，有利于缩短程序的开发周期。并且，通过将第一组件和第二组件进行编译处理之后再在容器中运行，无需将用于对组件进行编译的模块打包进容器中，有利于缩小容器所占的内存。

在本公开一些实施方式中，容器包括：第一执行文件、第二执行文件、运行时程序、系统服务、生命周期管理以及库函数。

相应地，在容器中运行第一执行文件和第二执行文件之前还包括：将第一执行文件、第二执行文件、运行时程序、系统服务、生命周期管理以及库函数进行打包，得到容器。

具体地，将第一执行文件和第二执行文件、以及其使用的所有依赖项打包到一个程序包中，即可得到容器。其中，运行时程序即为前文所述的RTE。

此时，在容器中运行第一执行文件和第二执行文件包括：启动容器中的运行时程序；在运行时程序中运行第一执行文件和第二执行文件。

具体地，先将运行时程序挂载起来，然后在运行时程序中运行第一执行文件和第二执行文件即可。

可以理解的是，通过设置容器中包括运行时程序，可使挂载运行时程序后即可运行第一执行文件和第二执行文件，使得第一执行文件和第二执行文件运行方式简便。

可选地，在容器中运行第一执行文件和第二执行文件之前还包括：根据容器对应的操作系统类型确定运行时程序的格式。

可以理解的是，容器对应的操作系统不同时，运行时程序的格式不同，根据容器对应的操作系统的类型确定容器中运行时程序的格式，可确保第一执行文件和第二执行文件在操作系统上正常运行。

在一些实施例中，根据容器对应的操作系统类型确定运行时程序的格式包括：确定容器对应的操作系统类型为Linux，确定运行时程序的格式为.elf格式。

示例性地，图3为本公开实施例提供的一种容器的结构示意图。其中，图3所示的容器适用于容器对应的操作系统为Linux系统，参见图3，容器包括第一执行文件、第二执行文件、.elf格式的运行时程序、系统服务、生命周期管理以及函数库。其中，.elf格式的运行时程序例如可以为wamrc.elf。此时，先启动wamrc.elf，然后将第一执行文件、第二执行文件运行在wamrc.elf上即可。

在另一些实施例中，确定容器对应的操作系统类型为Windows，确定运行时程序的格式为.exe格式。

示例性地，图4为本公开实施例提供的另一种容器的结构示意图。其中，图4所示的容器适用于容器对应的操作系统为Windows系统，参见图4，容器包括第一执行文件、第二执行文件、.exe格式的运行时程序、系统服务、生命周期管理以及函数库。其中，.exe格式的运行时程序例如可以为wamrc.exe。此时，先启动wamrc.exe，然后将第一执行文件、第二执行文件运行在wamrc.exe上即可。

在本公开另一些实施方式中，容器包括第一头文件、第二头文件、系统服务、生命周期管理以及库函数；其中，第一头文件与第一执行文件对应，第二头文件与第二执行文件对应。

相应地，在容器中运行第一执行文件和第二执行文件之前还包括：对第一执行文件和第二执行文件进行编译处理，得到具有相同格式的第一头文件和第二头文件；将第一头文件、第二头文件、系统服务、生命周期管理以及库函数进行打包，得到容器。

具体地，对第一执行文件和第二执行文件进行编译处理可得到第一头文件和第二头文件，即第一执行文件中代码和第一头文件中代码用于实现相同功能，第二执行文件中代码和第二头文件中代码用于实现相同功能。其中，第一头文件和第二头文件的具体格式，本领域技术人员可根据实际情况设置，此处不作限定。示例性地，第一头文件和第二头文件的格式可以为.h格式。

具体地，将第一头文件、第二头文件、以及其使用的所有依赖项打包到一个程序包中，即可得到容器。

此时，在容器中运行第一执行文件和第二执行文件之前还包括：建立工程文件；对工程文件、以及容器进行编译处理，得到第三执行文件；相应地，在容器中运行第一执行文件和第二执行文件包括：运行第三执行文件。

具体地，工程文件可以包括代码，该代码用于实现与本公开实施例所述的应用程序所实现的预设功能不同的功能，且工程文件中包括用于运行第一执行文件和第二执行文件的代码。如此，将工程文件、第一头文件、以及第二头文件一同进行编译处理得到的第三执行文件中，不仅包括用于运行第一执行文件和第二执行文件的代码(即为前文所述的RTE)，还包括与第一执行文件和第二执行文件对应的代码。其中，第三执行文件的具体格式，本领域技术人员可根据实际情况设置，此处不作限定。示例性地，第三执行文件的格式可以为.elf格式。

具体地，将工程文件以及容器进行编译处理，即将第一头文件、第二头文件、以及容器中应用程序的中使用的依赖项例如系统服务、生命周期管理以及库函数等一同编译进第三执行文件中。

具体地，运行第三执行文件时，会启动第三执行文件中用于运行第一执行文件和第二执行文件的代码，该部分代码可通过第一头文件和第二头文件启动运行第一执行文件和第二执行文件。

示例性地，图5为本公开实施例提供的又一种容器的结构示意图。其中，图5所示的容器适用于容器对应的操作系统为实时操作系统(Real Time Operating System，RTOS)，参见图5，容器包括第一头文件、第二头文件、系统服务、生命周期管理以及函数库。图5所示容器与工程文件一同编译后，集成在第三执行文件中，其中，第三执行文件例如可以为.elf格式的文件。此时，运行.elf格式的第三执行文件时会启动第三执行文件中用于运行第一执行文件和第二执行文件的代码，该部分代码可通过第一头文件和第二头文件启动运行第一执行文件和第二执行文件。

可以理解的是，由于工程文件本身具有用于运行第一执行文件和第二执行文件的代码，因此，将工程文件与容器所包含的代码一同编译得到第三执行文件后，可利用工程文件中用于运行第一执行文件和第二执行文件的代码经过编译后的代码启动运行第一执行文件和第二执行文件，则无需在容器单独地为运行时程序创建一个内存空间以存储该运行时程序，有利于进一步减小容器所占的内存空间，进而减小第三执行文件整体所占的内存空间。

需要说明的是，前文中仅对应用程序包括以不同编程语言编写的第一组件和第二组件时的运行方法进行了详细描述，但是，本领域技术人员应当理解的是，当应用程序还包括与第一组件和第二组件的编程语言不同的组件时，应用程序的运行方法类似，此处不再赘述。

下面，将基于一个具体示例，对本公开实施例提供的应用程序的运行方法进行详细说明。

图6为本公开实施例提供的一种应用程序的运行过程的流程示意图。

如图6所示，该应用程序的运行过程可以具体包括如下步骤。

S610、获取应用程序的第一组件和第二组件，第一组件的编程语言为C语言，第二组件的编程语言为C++语言。

S620、对第一组件和第二组件进行编译处理，得到.wasm格式的第一执行文件和第二执行文件。

S630、在容器中运行.wasm格式的第一执行文件和第二执行文件。

示例性地，当容器对应的操作系统为Linux系统时，可以先启动容器中的wamrc.elf格式的运行时程序，然后将.wasm格式的第一执行文件和第二执行文件运行在wamrc.elf格式的运行时程序上。

示例性地，当容器对应的操作系统为Windows系统时，可以先启动容器中的wamrc.exe格式的运行时程序，然后将.wasm格式的第一执行文件和第二执行文件运行在wamrc.exe格式的运行时程序上。

示例性地，当容器对应的操作系统为RTOS系统时，可先将.wasm格式的第一执行文件转为.h格式的第一头文件，并且，将.wasm格式的第二执行文件转为.h格式的第二头文件，然后，将.h格式的第一头文件、.h格式的第二头文件、系统服务、生命周期管理以及库函数进行打包，得到容器。再然后，将容器以及工程文件统一编译后得到.elf格式的第三执行文件。.elf格式的第三执行文件在运行时，会启动能够运行.wasm格式的第一执行文件和第二执行文件的代码，该部分代码通过.h格式的第一头文件和第二头文件启动运行.wasm格式的第一执行文件和第二执行文件。

需要说明的是，图6中仅示例性示出了应用程序包括以C语言编写的第一组件、以及以C++语言编写的第二组件，但并不限于此，还可以包括采用其它本领域技术人员可知的编程语言编写的组件，此时，在S620中还需要对其它组件进行编译处理，得到与其对应的.wasm格式的执行文件，相应地，在S630中还可运行其它组件对应的.wasm格式的执行文件。

本公开实施例的应用程序的运行方法，通过将C语言编写的第一组件、以及以C++语言编写的第二组件分别编译为.wasm格式的第一执行文件和第二执行文件，使得以不同编程语言编写的第一组件和第二组件可以统一在容器中运行。如此，可使应用程序兼容不同开发语言，并且可快速验证采用各开发语言编写的组件的性能，缩短应用程序的开发周期。此外，将组件编译为.wasm格式的执行文件后，通过将.wasm格式的执行文件在容器中运行，无需将用于对组件进行编译的模块打包进容器中，有利于缩小容器所占的内存，并且可使.wasm格式的执行文件在多种操作系统上运行，有利于缩短应用程序在不同硬件平台移植的开发周期。

图7为本公开实施例提供的一种应用程序的运行装置的结构示意图。

在本公开的一些实施例中，图7所述的装置可以应用于包括车辆ECU的电子设备中。

如图7所示，该应用程序的运行装置包括：

获取模块710，可以配置为获取应用程序的第一组件和第二组件，第一组件和第二组件的编程语言不同；

第一编译模块720，可以配置为对第一组件和第二组件进行编译处理，得到具有相同格式的第一执行文件和第二执行文件；

运行模块730，可以配置为在容器中运行第一执行文件和第二执行文件。

本公开实施例的应用程序的运行装置，能够获取应用程序的第一组件和第二组件，第一组件和第二组件的编程语言不同，并对第一组件和第二组件进行编译处理，得到具有相同格式的第一执行文件和第二执行文件，在容器中运行第一执行文件和第二执行文件。如此，当应用程序的第一组件和第二组件以不同编程语言编写时，无需将第一组件改写为与第二组件相同的编程语言，例如，当第一组件以C语言编写且第二组件以C++语言编写时，无需将以C语言编写的第一组件改写为以C++语言编写，也无需将以C++语言编写的第二组件改写为以C语言编写，可见，基于本公开实施例的应用程序的运行方法，开发人员可灵活选取第一组件和第二组件的编程语言，以不同编程语言编写的第一组件和第二组件可在编译为具有相同格式的第一执行文件和第二执行文件后在容器中运行，有利于缩短程序的开发周期。并且，通过将第一组件和第二组件进行编译处理之后再在容器中运行，无需将用于对组件进行编译的模块打包进容器中，有利于缩小容器所占的内存。

在本公开另一些实施方式中，第一组件和第二组件的编程语言包括C语言、C++语言以及RUST语言中的两者。

在本公开另一些实施方式中，第一执行文件和第二执行文件的格式包括.wasm格式。

在本公开又一些实施方式中，该装置还可以包括：第一打包模块，可以配置为在容器中运行第一执行文件和第二执行文件之前，将第一执行文件、第二执行文件、运行时程序、系统服务、生命周期管理以及库函数进行打包，得到容器。

在本公开再一些实施方式中，运行模块730可以包括：

启动子模块块，可以配置为启动容器中的运行时程序；

运行子模块，可以配置为在运行时程序中运行第一执行文件和第二执行文件。

在本公开再一些实施方式中，该装置还可以包括：确定模块，可以配置为在容器中运行第一执行文件和第二执行文件之前，根据容器对应的操作系统类型确定运行时程序的格式。

在本公开再一些实施方式中，确定模块具体可以配置为确定容器对应的操作系统类型为Linux，确定运行时程序的格式为.elf格式；或者；

确定容器对应的操作系统类型为Windows，确定运行时程序的格式为.exe格式。

在本公开再一些实施方式中，该装置还可以包括：

第二编译模块，可以配置为在在容器中运行第一执行文件和第二执行文件之前，对第一执行文件和第二执行文件进行编译处理，得到具有相同格式的第一头文件和第二头文件；

第二打包模块，可以配置为将第一头文件、第二头文件、系统服务、生命周期管理以及库函数进行打包，得到容器。

在本公开再一些实施方式中，该装置还可以包括：

建立模块，可以配置为建立工程文件；

第三编译模块，可以配置为对工程文件、以及容器进行编译处理，得到第三执行文件；

其中，运行模块730具体可以配置为运行第三执行文件。

需要说明的是，图7所示的应用程序的运行装置700可以执行图1以及图6所示的方法实施例中的各个步骤，并且实现图1以及图6所示的方法实施例中的各个过程和效果，在此不做赘述。

图8为本公开实施例提供的一种计算机设备的结构示意图。

在本公开一些实施例中，图8所示的计算机设备可以为包括车辆ECU的电子设备。

如图8所示，该计算机设备可以包括处理器801以及存储有计算机程序指令的存储器802。

具体地，上述处理器801可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器802可以包括用于信息或指令的大容量存储器。举例来说而非限制，存储器802可以包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个及其以上这些的组合。在合适的情况下，存储器802可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器802可在综合网关设备的内部或外部。在特定实施例中，存储器802是非易失性固态存储器。在特定实施例中，存储器802包括只读存储器(Read-Only Memory，ROM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(Programmable ROM，PROM)、可擦除PROM(Electrical Programmable ROM，EPROM)、电可擦除PROM(Electrically ErasableProgrammable ROM，EEPROM)、电可改写ROM(Electrically Alterable ROM，EAROM)或闪存，或者两个或及其以上这些的组合。

处理器801通过读取并执行存储器802中存储的计算机程序指令，可以执行本公开实施例所提供的应用程序的运行方法。

在一个示例中，该计算机设备还可包括收发器803和总线804。其中，如图8所示，处理器801、存储器802和收发器803通过总线804连接并完成相互间的通信。

总线804包括硬件、软件或两者。举例来说而非限制，总线可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(ExtendedIndustry Standard Architecture，EISA)总线、前端总线(Front Side BUS，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(Industrial Standard Architecture，ISA)总线、无限带宽互连、低引脚数(Low Pin Count，LPC)总线、存储器总线、微信道架构(MicroChannel Architecture，MCA)总线、外围控件互连(Peripheral Component Interconnect，PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(Serial Advanced TechnologyAttachment，SATA)总线、视频电子标准协会局部(Video Electronics StandardsAssociation Local Bus，VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线804可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

本公开实施例还提供了一种计算机可读存储介质，该存储介质可以存储有计算机程序，当计算机程序被处理器执行时，使得处理器实现本公开实施例所提供的应用程序的运行方法。

上述的存储介质可以例如包括计算机程序指令的存储器802，上述指令可由计算机设备的处理器801执行以完成本公开实施例所提供的充电控制方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(Random Access Memory，RAM)、光盘只读存储器(Compact DiscROM，CD-ROM)、磁带、软盘和光数据存储设备等。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。