CN114911481A - 代码编译方法、装置以及电子设备 - Google Patents

Abstract

本申请涉及计算机技术领域，并提供了一种代码编译方法、装置以及电子设备。该方法包括：获取应用程序所包括业务模块的模块代码，并对模块代码进行局部编译处理得到运行文件；存储运行文件得到运行文件的存储路径信息，并保存存储路径信息；当启动应用程序时，按照存储路径信息加载运行文件，以通过运行该运行文件执行业务模块。本申请一方面，只需对业务模块的模块代码进行局部编译处理，无需检查变动和完成应用程序的全部编译流程，减少了编译耗时，并且局部编译处理的方式与其他编译加速技术兼容并行，能够多方面的加快编译速度；另一方面，按照存储路径信息加载局部编译处理得到的运行文件，文件加载流程简化，优化了开发效率和开发体验。

Description

代码编译方法、装置以及电子设备

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种代码编译方法、代码编译装置以及电子设备。

背景技术

在项目开发过程中，需要不断的编译代码。但是重新编译时，耗时非常长。

通过引入编译加速技术加快编译速度。而引入编译加速技术的成本非常高，并且对于较为老旧的项目，优化效果也并不显著。

鉴于此，本领域亟需开发一种新的代码编译方法及装置。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本申请的技术背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本申请的目的在于提供一种代码编译方法、代码编译装置、计算机可读介质以及电子设备，进而至少在一定程度上克服编译成本高和效果差的技术问题。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供一种代码编译方法，该方法包括：获取应用程序所包括业务模块的模块代码，并对所述模块代码进行局部编译处理得到运行文件；

存储所述运行文件得到所述运行文件的存储路径信息，并保存所述存储路径信息；

当启动所述应用程序时，按照所述存储路径信息加载所述运行文件，以通过运行所述运行文件执行所述业务模块。

根据本申请实施例的一个方面，提供一种代码编译装置，该装置包括：局部编译模块，被配置为获取应用程序所包括业务模块的模块代码，并对所述模块代码进行局部编译处理得到运行文件；

信息存储模块，被配置为存储所述运行文件得到所述运行文件的存储路径信息，并保存所述存储路径信息；

文件加载模块，被配置为当启动所述应用程序时，按照所述存储路径信息加载所述运行文件，以通过运行所述运行文件执行所述业务模块。

在本申请的一些实施例中，基于以上技术方案，所述局部编译模块包括：代码编译子模块，被配置为对所述模块代码进行局部编译处理得到压缩文件；

压缩编译子模块，被配置为对所述压缩文件进行局部编译处理得到运行文件。

在本申请的一些实施例中，基于以上技术方案，所述代码编译子模块包括：编译文件单元，被配置为对所述模块代码进行局部编译处理得到编译文件；

打包处理单元，被配置为对所述编译文件进行局部打包处理得到压缩文件。

在本申请的一些实施例中，基于以上技术方案，所述信息存储模块包括：文件生成子模块，被配置为生成与所述应用程序对应的配置文件，并获取所述压缩文件的文件标识信息；

路径存储子模块，被配置为按照所述文件标识信息将所述存储路径信息保存在所述配置文件中。

在本申请的一些实施例中，基于以上技术方案，所述文件生成子模块，包括：目录确定单元，被配置为确定所述应用程序的程序目录；

配置文件单元，被配置为在所述程序目录下生成与所述应用程序对应的配置文件。

在本申请的一些实施例中，基于以上技术方案，所述文件加载模块，包括：加载器确定子模块，被配置为确定与所述应用程序对应的自定义类加载器；

信息加载子模块，被配置为利用所述自定义类加载器按照所述存储路径信息加载所述运行文件。

在本申请的一些实施例中，基于以上技术方案，所述信息加载子模块，包括：文件存在单元，被配置为若存在所述配置文件，利用所述自定义类加载器按照所述存储路径信息加载所述运行文件。

在本申请的一些实施例中，基于以上技术方案，所述信息加载子模块，还包括：

全量编译单元，被配置为若未存在所述配置文件，从与所述应用程序对应的程序文件中加载所述运行文件；其中，所述程序文件是对所述应用程序的程序代码进行全量编译处理得到的。

根据本申请实施例的一个方面，提供一种计算机可读介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如以上技术方案中的代码编译方法。

根据本申请实施例的一个方面，提供一种电子设备，该电子设备包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器被配置为经由执行所述可执行指令来执行如以上技术方案中的代码编译方法。

在本申请实施例提供的技术方案中，一方面，只需对业务模块的模块代码进行局部编译处理，无需检查变动和完成应用程序的全部编译流程，编译流程简单，减少了编译耗时，编译速度也得到了极大地提升，进一步的，局部编译处理的方式与其他编译加速技术兼容并行，能够多方面的加快编译速度；另一方面，按照存储路径信息加载局部编译处理得到的运行文件，文件加载流程简化，优化了开发效率和开发体验。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示意性地示出了应用本申请技术方案的示例性系统的架构示意图；

图2示意性地示出了本申请的一些实施例中一种代码编译方法的步骤流程图；

图3示意性地示出了在本申请的一些实施例中局部编译处理的方法的步骤流程图；

图4示意性地示出了在本申请的一些实施例中进一步局部编译处理的方法的步骤流程图；

图5示意性地示出了在本申请的一些实施例中保存存储路径信息的方法的步骤流程图；

图6示意性地示出了在本申请的一些实施例中生成配置文件的方法的步骤流程图；

图7示意性地示出了在本申请的一些实施例中加载运行文件的方法的步骤流程图；

图8示意性地示出了在本申请的一些实施例中进一步加载运行文件的方法的步骤流程图；

图9示意性地示出了在本申请些实施例在应用场景下保存存储路径信息的方法的步骤流程图；

图10示意性地示出了在本申请的一些实施例中在应用场景下加载运行文件的方法的步骤流程图；

图11示意性地示出了在本申请一些实施例中的一种代码编译装置的结构框图；

图12示意性地示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

在本领域的相关技术中，在项目开发中，往往依赖若干个aar(Android Archive，安卓归档文件)或者是jar(Java Archive，Java归档文件)，每个aar或jar有可能依赖子aar或jar，尤其是安卓开发的项目中。

具体的，现在的大型项目往往采用模块化来部署代码。举例而言，source为整个项目的源代码，项目中含有业务模块A、业务模块B和业务模块C三个业务模块。并且，这三个业务模块都为arr部署，然后被source引用。其中，业务模块A又有两个依赖包，分别是AA和BB，以aar或jar部署引用，亦即子aar或子jar。

当aar与子aar，或者是jar与子jar，或者是aar与子jar，或者是jar与子aar之间的依赖关系产生变化时，需要重新编译，导致耗时非常长。特别是比较老的大型项目，耗时更长。

具体的，当修改业务模块A中的代码时，需要重新进行编译。

举例而言，重新编译首先编译业务模块A的代码得到aar，然后将aar部署到本地或者远程的maven仓库。进一步的，修改source中业务模块A的引用地址成为maven仓库的地址。最后，编译source代码。

其中，maven仓库可以通过一小段描述信息来管理项目的构建，是报告和文档的项目管理工具软件。maven仓库是部署用的，一般安卓系统的应用程序的发布流程中会把依赖包或arr依赖包推送到maven仓库存储。

在编译处理的过程中，修改中业务模块A的引用地址是可选的。当将aar部署到maven仓库的原位置时，无需修改引用地址。而在source代码的过程中，会自动检查依赖关系是否发生变动。

该检查过程是安卓编译的流程，会对比远程依赖包的MD5(MD5Message-DigestAlgorithm，MD5信息摘要算法)值。在安卓编译的过程中，利用MD5信息摘要算法基于源代生成一个独一无二的数字签名，亦即MD5值。因此，当MD5值变化时，认为依赖关系产生变化。而依赖关系可以是source与业务模块A之间的依赖关系，source引用业务模块A。

除此之外，该检查过程也可以通过对文件长度、文件时间戳进行校验实现，或者是利用其他算法，例如SHA-1(Secure Hash Algorithm 1，安全散列算法1)实现。

值得说明的是，编译业务模块A的代码得到aar的耗时十分短，一般可以在10秒内完成。aar部署到本地或者远程的maven仓库的耗时也不长，取决于网络的情况。但是，编译source代码由于要经过对源代码整个的变动检查和编译流程，因此耗时非常长。

一般的，通过引入编译加速的技术减少耗时，但是编译加速技术的成本往往非常高，且优化效果不够显著。

基于以上方案存在的问题，本申请提供了代码编译方法、代码编译装置、计算机可读介质以及电子设备。

图1示出了应用本申请技术方案的示例性系统架构示意图。

如图1所示，系统架构100可以包括终端110、网络120、服务器端130。其中，终端110和服务器端130通过网络120连接。

终端110可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。网络120可以是能够在终端110和服务器端130之间提供通信链路的各种连接类型的通信介质，例如可以是有线通信链路、无线通信链路或者光纤电缆等等，本申请在此不做限制。服务器130可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

具体地，终端110可以获取应用程序所包括业务模块的模块代码，并对模块代码进行局部编译处理得到运行文件。然后，存储运行文件得到运行文件的存储路径信息，并保存存储路径信息。进一步的，当启动应用程序时，按照存储路径信息加载运行文件，以通过运行运行文件执行业务模块。

另外，本申请实施例中的代码编译方法可以应用于终端，也可以应用于服务器端，本申请对此不做特殊限定。

除此之外，本申请实施例中的代码编译方法可以应用于除终端110之外的第三方终端150。终端110和终端150通过网络140连接。

终端150也可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。网络140可以是能够在终端110和终端150之间提供通信链路的各种连接类型的通信介质，例如可以是有线通信链路、无线通信链路或者光纤电缆等等，本申请在此不做限制。

具体地，终端110可以获取应用程序所包括业务模块的模块代码，并对模块代码进行局部编译处理得到运行文件。然后，将运行文件复制到终端150上，以将运行文件存储到终端150上得到在终端150上的存储路径信息。终端150可以保存对应的存储路径信息。进一步的，当在终端150上启动应用程序时，终端150可以按照存储路径信息加载运行文件，以通过运行运行文件执行业务模块。

除此之外，在终端150上的应用并不局限于直接通过终端110复制，也可以是通过服务器130实现的，本示例性实施例对此不做特殊限定。因此，本申请实施例中的代码编译方法的应用场景是多种的，可以依据实际情况的需求应用。

本申请实施例主要以代码编译方法应用于终端110来举例说明。

下面结合具体实施方式对本申请提供的代码编译方法、代码编译装置、计算机可读介质以及电子设备做出详细说明。

图2示意性地示出了本申请的一些实施例中代码编译方法的步骤流程图，如图2所示，代码编译方法主要可以包括以下步骤：

步骤S210.获取应用程序所包括业务模块的模块代码，并对模块代码进行局部编译处理得到运行文件。

步骤S220.存储运行文件得到运行文件的存储路径信息，并保存存储路径信息。

步骤S230.当启动应用程序时，按照存储路径信息加载运行文件，以通过运行运行文件执行业务模块。

在本申请的示例性实施例中，一方面，只需对业务模块的模块代码进行局部编译处理，无需检查变动和完成应用程序的全部编译流程，编译流程简单，减少了编译耗时，编译速度也得到了极大地提升，进一步的，局部编译处理的方式与其他编译加速技术兼容并行，能够多方面的加快编译速度；另一方面，按照存储路径信息加载局部编译处理得到的运行文件，文件加载流程简化，优化了开发效率和开发体验。

下面对代码编译方法的各个步骤进行详细说明。

在步骤S210中，获取应用程序所包括业务模块的模块代码，并对模块代码进行局部编译处理得到运行文件。

在本申请的示例性实施例中，大型项目或者是应用程序可以采用模块化的方式部署代码。举例而言，一个应用程序的的源代码可以部署为A、B和C三个业务模块，因此，每个业务模块都存在有对应的模块代码，分别是模块代码A、模块代码B和模块代码C。

其中，应用程序(Moible Application，简称Moible APP或APP)。一般的，被程序APP，或手机软件、手机应用程序、移动应用程序、移动应用或手机APP等，是指设计给智能手机、平板电脑或其他移动设备运行的一种应用程序。

因此，在要提升编译速度时，可以通过对模块代码进行局部编译处理的方式实现。

在可选的实施例中，图3示出了局部编译处理的方法的步骤流程图，如图3所示，该方法至少包括以下步骤：在步骤S310中，对模块代码进行局部编译处理得到压缩文件。

在可选的实施例中，图4示出了进一步局部编译处理的方法的步骤流程图，如图4所示，该方法至少包括以下步骤：在步骤S410中，对模块代码进行局部编译处理得到编译文件。

编译是利用编译程序从源语言编写的源程序产生目标程序的过程。亦即，编译就是把高级语言变成计算机可以识别的2进制语言。由于计算机只认识1和0，编译程序可以把人们熟悉的语言换成2进制的以实现编译。编译程序把一个源程序翻译成目标程序的工作过程分为五个阶段：词法分析、语法分析、语义检查和中间代码生成、代码优化和目标代码生成。其中，编译程序主要是进行词法分析和语法分析，又称为源程序分析，分析过程中发现有语法错误，可以给出提示信息。

编译语言是一种以编译器来实现的编程语言。它不像直译语言一样由解释器将代码一句一句运行，而是以编译器先将代码编译为机器码，再加以运行。理论上，任何编程语言都可以是编译式，或直译式的。它们之间的区别仅与程序的应用有关。

那么，局部编译处理是仅对模块代码，而不是应用程序的所有源代码进行编译处理的方式。

举例而言，如果对jni(Java Native Interface，Java本地接口)相关部分进行局部编译，可以执行make libandroid_runtime；如果编译Java相关部分，执行makeframework；若编译services相关部分，执行make services。

除此之外，局部编译处理可以是利用编译服务器实现的。具体的，将模块代码发送至编译服务器，编译服务器在接收到该模块代码时，可以解析出对应的代码目录和硬件号，从而在该代码目录下下载对应的模块代码，并通过硬件号确定编译方式，然后按照该编译方式对模块代码进行编译处理。

不仅如此，局部编译方式还可以利用能够实现局部编译的编译工具，或者是能够实现局部编译的编译器等方式完成，本示例性实施例对此不做特殊限定。

因此，先对模块代码进行局部编译处理之后可以得到与模块代码对应的编译文件。

在步骤S420中，对编译文件进行局部打包处理得到压缩文件。

在得到编译文件之后，可以对编译文件进行打包处理得到压缩文件。由于编译文件是由局部编译处理得到的，因此打包处理也不是对应用程序的整个源代码进行编译后的打包处理，而是对业务模块对应的局部编译处理得到的编译文件进行的局部打包处理。

在局部打包处理之后得到的压缩文件可以是aar或者是jar。

aar或jar都是安卓在源代码构建阶段的依赖库的打包方式。在大型工程里，往往一个项目会依赖若干aar或jar，每个aar或jar有可能依赖子aar或子jar。

aar文件是谷歌为安卓开发所设计的一种Library格式。与jar不同的是，aar除了jar code之外，还包含资源文件，即xml(Extensible Markup Language，可扩展标记语言)文件、图片或文字等，而jar只含有class文件和清单文件。

在本示例性实施例中，通过局部编译处理和局部打包处理可以得到压缩文件，无需进行全量编译处理，提升了编译速度，优化了编译处理方式。

在步骤S320中，对压缩文件进行局部编译处理得到运行文件。

在得到压缩文件之后，可以对压缩文件进行二次局部编译处理。

此时的局部编译处理可以是利用安卓自带的编译工具实现的，例如Dx工具。通过Dx工具可以将压缩文件，例如aar或者jar转换为android(安卓)dalvik虚拟机支持的dex格式的文件，亦即运行文件。由于android系统的dalvik虚拟机和普通的Java虚拟机支持的可执行文件格式不同，所以需要调用android官方Dx工具进行转换。

在本示例性实施例中，通过两次不同的局部编译处理之后可以得到运行文件，完整执行了局部编译过程，为后续局部运行运行文件提供了文件基础。

在步骤S220中，存储运行文件得到运行文件的存储路径信息，并保存存储路径信息。

在本申请的示例性实施例中，在得到运行文件之后，可以将运行文件存储在能够运行的终端设备上。该终端设备可以是自身设备，也可以是第三方终端设备，本示例性实施例对此不做特殊限定。

当终端设备为自身设备时，存储该运行文件可以得到在该自身设备中的存储路径信息；当终端设备为第三方终端设备时，可以将运行文件复制到第三方终端设备，以得到在第三方终端设备中的存储路径信息。

进一步的，将该存储路径信息也存储起来。

值得说明的是，存储路径信息可以是开发人员指定的，也可以是根据实际情况确定出的，本示例性实施例对此不做特殊限定。

在可选的实施例中，图5示出了保存存储路径信息的方法的步骤流程图，如图5所示，该方法至少包括以下步骤：在步骤S510中，生成与应用程序对应的配置文件，并获取压缩文件的文件标识信息。

在可选的实施例中，图6示出了生成配置文件的方法的步骤流程图，如图6所示，该方法至少包括以下步骤：在步骤S610中，确定应用程序的程序目录。

在终端设备中确定出该应用程序的程序目录。该程序目录可以是应用程序对应的总目录，也可以是为配置文件单独生成的目录，本示例性实施例对此不做特殊限定。

在步骤S620中，在程序目录下生成与应用程序对应的配置文件。

在确定程序目录之后，可以在该程序目录下生成一个配置文件。值得说明的是，该配置文件可以不断进行更新，更新的方式是修改配置文件中的存储路径信息。

在本示例性实施例中，在程序目录下生成与应用程序对应的配置文件，为保存存储路径信息提供了保存位置，也便于后续加载运行文件，在存储方式的方面提升了编译和运行速度。

在生成配置文件之后，可以获取压缩文件的文件标识信息。该文件标识信息可以是aar或jar的包名和文件名，也可以是其他标识信息，本示例性实施例对此不做特殊限定。

其中，包名(package name)是按照符合android标准的原则进行设计的。一般的，使用包名作为应用程序的唯一标识。亦即，包名是唯一的，一个包名代表一个应用程序，不允许两个应用程序使用相同的包名。包名的命名规则可以包含大写字母、小写字母、数字和下户线，可以用英文的句号分隔，隔开的每一段都必须以字母开头。而文件名可以是压缩文件的文件名称。

在步骤S520中，按照文件标识信息将存储路径信息保存在配置文件中。

在得到压缩文件的文件标识信息之后，可以按照文件标识信息在配置文件中保存存储路径信息。

在本示例性实施例中，将存储路径信息保存在配置文件中，为存储路径信息的保存提供了存储位置，并且，便于后续加载运行文件时根据文件标识信息确定加载位置。

在步骤S230中，当启动应用程序时，按照存储路径信息加载运行文件，以通过运行运行文件执行业务模块。

在本申请的示例性实施例中，在保存好存储路径信息之后，可以在应用程序的启动时机，按照存储路径信息加载运行文件。

在可选的实施例中，图7示出了加载运行文件的方法的步骤流程图，如图7所示，该方法至少包括以下步骤：在步骤S710中，确定与应用程序对应的自定义类加载器。

其中，Java类加载器的作用是寻找类文件，然后加载class文件到JVM(JavaVirtual Machine，Java虚拟机)中，链接(验证、准备、解析)并初始化，最终形成可以被虚拟机直接使用的Java类型。

为使得Java类加载器可以实现按照存储路径信息加载运行文件的目的，可以自定义一个自定义类加载器(ClassLoader)。自定义类加载器只需集成自定义类加载器的抽象类，并重写findClass方法即可。

在步骤S720中，利用自定义类加载器按照存储路径信息加载运行文件。

在可选的实施例中，图8示出了进一步加载运行文件的方法的步骤流程图，如图8所示，该方法至少包括以下步骤：在步骤S810中，若存在配置文件，利用自定义类加载器按照存储路径信息加载运行文件。

为确定是按照存储路径信息中加载运行文件，还是从与应用程序对应的程序文件中加载，可以先判断是否存在配置文件。

对配置文件是否存在的判断可以是在程序目录中查询。不仅如此，在确定存在配置文件后，为确定是否在配置文件中存在与模块代码对应的运行文件，还可以进一步判断是否有按照压缩文件的文件标识信息存储的存储路径信息。

当确定不仅存在配置文件，还在配置文件中存储有按照压缩文件的文件标识信息存储的存储路径信息时，可以利用自定义类加载器加载运行文件。

自定义类加载器是用来加载运行文件，亦即Java类到Java虚拟机中的一种加载器。与普通程序不同的是，Java程序中的class文件并不是本地可执行的程序。当运行Java程序时，自定义类加载器首先运行JVM，然后再把Java class加载到JVM中运行。

在步骤S820中，若未存在配置文件，从与应用程序对应的程序文件中加载运行文件；其中，程序文件是对应用程序的程序代码进行全量编译处理得到的。

为确定是按照存储路径信息中加载运行文件，还是从与应用程序对应的程序文件中加载，可以先判断是否存在配置文件。对配置文件是否存在的判断可以是在程序目录中查询。

当确定程序目录中不存在配置文件时，可以从应用程序的程序文件中加载运行文件。

具体的，程序文件是对应用程序的全部源代码，亦即程序代码进行全量编译处理得到的。例如，程序文件可以是APK(Android application package，Android应用程序包)。

APK是android操作系统所使用的一种应用程序包文件格式，用于分发和安装移动应用程序和中间件。一个android应用程序的源代码想要在android设备上运行，必须先进行全量编译处理，然后被打包成一个能够为android系统所能识别的文件才可以被运行，而这种可以被android系统识别且运行的文件格式即为APK。一个APK文件中包含被编译的代码文件、文件资源(resources)、资产文件(assets)、证书(certificates)和清单文件(manifest file)。其中，代码文件可以是.dex文件，亦即运行文件。

亦即，程序文件的编译处理对象不同于运行文件的编译处理对象。程序文件的编译对象是全部的程序代码，而运行文件编译的对象是业务模块的模块代码。

显然，由于全量编译的耗时较大，因此在编译对象不同，且采用局部编译时，可以极大地提升编译速度。

在加载到运行文件之后，可以在本地运行该运行文件，以执行对应的业务模块的功能。

下面结合一具体应用场景对本申请实施例中提供的代码编译方法做出详细说明。

图9示出了应用场景下保存存储路径信息的方法的步骤流程图，如图9所示，在步骤S910中，获取应用程序的业务模块的源代码，亦即模块代码。

其中，business A表示业务模块A。

在步骤S920中，编译成安卓归档文件。

具体的，对模块代码进行局部编译处理得到压缩文件，例如aar，也可以是jar，本示例性实施例对此不做特殊限定。

首先对模块代码进行局部编译处理得到的编译文件，然后对编译文件进行局部打包处理得到压缩文件。

具体的，局部编译处理是仅对模块代码，而不是应用程序的所有源代码进行编译处理的方式。

举例而言，如果对jni(Java Native Interface，Java本地接口)相关部分进行局部编译，可以执行make libandroid_runtime；如果编译Java相关部分，执行makeframework；若编译services相关部分，执行make services。

除此之外，局部编译处理可以是利用编译服务器实现的。具体的，将模块代码发送至编译服务器，编译服务器在接收到该模块代码时，可以解析出对应的代码目录和硬件号，从而在该代码目录下下载对应的模块代码，并通过硬件号确定编译方式，然后按照该编译方式对模块代码进行编译处理。

不仅如此，局部编译方式还可以利用能够实现局部编译的编译工具，或者是能够实现局部编译的编译器等方式完成，本示例性实施例对此不做特殊限定。

因此，先对模块代码进行局部编译处理之后可以得到与模块代码对应的编译文件。

在得到编译文件之后，可以对编译文件进行打包处理得到压缩文件。由于编译文件是由局部编译处理得到的，因此打包处理也不是对应用程序的整个源代码进行编译后的打包处理，而是对业务模块对应的局部编译处理得到的编译文件进行的局部打包处理。

在局部打包处理之后得到的压缩文件可以是aar或jar。

在步骤S930中，对压缩文件进行局部编译处理得到运行文件，亦即d ex动态包。

在得到压缩文件之后，可以对压缩文件进行二次局部编译处理。

此时的局部编译处理可以是利用安卓自带的编译工具实现的，例如Dx工具。通过Dx工具可以将压缩文件，例如aar或者jar转换为android(安卓)dalvik虚拟机支持的dex格式的文件，亦即运行文件。

由于android系统的dalvik虚拟机和普通的Java虚拟机支持的可执行文件格式不同，所以需要调用android官方Dx工具进行转换。

在步骤S940中，将运行文件复制到手机中。

在得到运行文件之后，可以将运行文件存储在能够运行的终端设备上。该终端设备可以是第三方终端设备，例如手机。当终端设备为手机时，可以将运行文件复制到手机，以得到在手机中的存储路径信息。

在步骤S950中，修改应用程序加载配置。

具体的，修改与应用程序的程序目录中存储的配置文件。该程序目录可以是应用程序对应的总目录，也可以是为配置文件单独生成的目录，本示例性实施例对此不做特殊限定。在确定程序目录之后，可以在该程序目录下生成一个配置文件。值得说明的是，该配置文件可以不断进行更新，更新的方式是修改配置文件中的存储路径信息。

因此，在已生成配置文件时，若重新要存储与运行文件对应的存储路径信息，可以是修改配置文件中的存储内容，以使得能够按照存储路径信息加载到运行文件。

在步骤S960中，重启应用程序。

在修改完配置文件后，可以重新启动应用程序以完成对运行文件的重新加载。

图10示出了在应用场景下加载运行文件的方法的步骤流程图，如图10所示，在步骤S1010中，启动应用程序，以使应用程序启动运行。

在步骤S1020中，自定义一自定义类加载器，亦即ClassLoader。

为使得Java类加载器可以实现按照存储路径信息加载运行文件的目的，可以自定义一个自定义类加载器(ClassLoader)。自定义类加载器只需集成自定义类加载器的抽象类，并重写findClass方法即可。

在步骤S1030中，加载业务模块A。

具体的，加载与业务模块，例如business A对应的运行文件。

为加载与business A对应的运行文件，可以对是否存在配置文件进行检查。

在步骤S1040中，检查配置文件，亦即检查是否存在配置文件。

为确定是按照存储路径信息中加载运行文件，还是从与应用程序对应的程序文件中加载，可以先判断是否存在配置文件。

对配置文件是否存在的判断可以是在程序目录中查询。不仅如此，在确定存在配置文件后，为确定是否在配置文件中存在与模块代码对应的运行文件，还可以进一步判断是否有按照压缩文件的文件标识信息存储的存储路径信息。

在步骤S1050中，若不存在配置文件，可以从与应用程序对应的程序代码中加载得到。

其中，程序代码为应用程序的源代码。

当确定程序目录中不存在配置文件时，可以从应用程序的程序文件中加载运行文件。

具体的，程序文件是对应用程序的全部源代码，亦即程序代码进行全量编译处理得到的。亦即，程序文件的编译处理对象不同于运行文件的编译处理对象。程序文件的编译对象是全部的程序代码，而运行文件编译的对象是业务模块的模块代码。

显然，由于全量编译处理的耗时较大，因此在编译对象不同，且采用局部编译时，可以极大地提升编译速度。

在步骤S1060中，若存在配置文件，利用自定义类加载器按照存储路径信息加载运行文件。

该运行文件即为dex动态包。

当确定不仅存在配置文件，还在配置文件中存储有按照压缩文件的文件标识信息存储的存储路径信息时，可以利用自定义类加载器加载运行文件。

为了实现在存在配置文件时，直接加载运行文件，可以自定义一自定义加载器实现。

自定义类加载器是用来加载运行文件，亦即Java类到Java虚拟机中的一种加载器。与普通程序不同的是，Java程序中的class文件并不是本地可执行的程序。当运行Java程序时，自定义类加载器首先运行JVM，然后再把Java class加载到JVM中运行。

因此，当存在配置文件时，无需从应用程序的源代码对应的程序文件，例如apk中加载运行文件，而是按照已经保存好的存储路径信息加载运行文件。

值得说明的是，存储路径信息可以是开发人员指定的。

基于以上应用场景可知，本申请实施例提供的代码编译方法，一方面，只需对业务模块的模块代码进行局部编译处理，无需检查变动和完成应用程序的全部编译流程，编译流程简单，减少了编译耗时，编译速度也得到了极大地提升，进一步的，局部编译处理的方式与其他编译加速技术兼容并行，能够多方面的加快编译速度；另一方面，按照存储路径信息加载局部编译处理得到的运行文件，文件加载流程简化，优化了开发效率和开发体验。

应当注意，尽管在附图中以特定顺序描述了本申请中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的代码编译方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的代码编译方法的实施例。

图11示意性地示出了在本申请一些实施例中的一种代码编译装置的结构框图，如图11所示，代码编译装置1100主要可以包括：局部编译模块1110、信息存储模块1120和文件加载模块1130。

局部编译模块1110，被配置为获取应用程序所包括业务模块的模块代码，并对模块代码进行局部编译处理得到运行文件；信息存储模块1120，被配置为存储运行文件得到运行文件的存储路径信息，并保存存储路径信息；文件加载模块1130，被配置为当启动应用程序时，按照存储路径信息加载运行文件，以通过运行运行文件执行业务模块。

在本申请的一些实施例中，局部编译模块包括：代码编译子模块，被配置为对模块代码进行局部编译处理得到压缩文件；

压缩编译子模块，被配置为对压缩文件进行局部编译处理得到运行文件。

在本申请的一些实施例中，代码编译子模块包括：编译文件单元，被配置为对模块代码进行局部编译处理得到编译文件；

打包处理单元，被配置为对编译文件进行局部打包处理得到压缩文件。

在本申请的一些实施例中，信息存储模块包括：文件生成子模块，被配置为生成与应用程序对应的配置文件，并获取压缩文件的文件标识信息；

路径存储子模块，被配置为按照文件标识信息将存储路径信息保存在配置文件中。

在本申请的一些实施例中，文件生成子模块，包括：目录确定单元，被配置为确定应用程序的程序目录；

配置文件单元，被配置为在程序目录下生成与应用程序对应的配置文件。

在本申请的一些实施例中，文件加载模块，包括：加载器确定子模块，被配置为确定与应用程序对应的自定义类加载器；

信息加载子模块，被配置为利用自定义类加载器按照存储路径信息加载运行文件。

在本申请的一些实施例中，信息加载子模块，包括：文件存在单元，被配置为若存在配置文件，利用自定义类加载器按照存储路径信息加载运行文件。

在本申请的一些实施例中，基于以上技术方案，所述信息加载子模块，还包括：

全量编译单元，被配置为若未存在配置文件，从与应用程序对应的程序文件中加载运行文件；其中，程序文件是对应用程序的程序代码进行全量编译处理得到的。

本申请各实施例中提供的代码编译装置的具体细节已经在对应的方法实施例中进行了详细的描述，因此此处不再赘述。

图12示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图12示出的电子设备的计算机系统1200仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图12所示，计算机系统1200包括中央处理单元(Central Processing Unit，CPU)1201，其可以根据存储在只读存储器(Read-Only Memory，ROM)1202中的程序或者从储存部分1208加载到随机访问存储器(Random Access Memory，RAM)1203中的程序而执行各种适当的动作和处理。在RAM 1203中，还存储有系统操作所需的各种程序和数据。CPU1201、ROM 1202以及RAM 1203通过总线1204彼此相连。输入/输出(Input/Output，I/O)接口1205也连接至总线1204。

以下部件连接至I/O接口1205：包括键盘、鼠标等的输入部分1206；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1207；包括硬盘等的储存部分1208；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1209。通信部分1209经由诸如因特网的网络执行通信处理。驱动器1210也根据需要连接至I/O接口1205。可拆卸介质1211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1210上，以便于从其上读出的计算机程序根据需要被安装入储存部分1208。

特别地，根据本申请的实施例，各个方法流程图中所描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1209从网络上被下载和安装，和/或从可拆卸介质1211被安装。在该计算机程序被中央处理单元(CPU)1201执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

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

Claims (10)

1.一种代码编译方法，其特征在于，所述方法包括：

获取应用程序所包括业务模块的模块代码，并对所述模块代码进行局部编译处理得到运行文件；

存储所述运行文件得到所述运行文件的存储路径信息，并保存所述存储路径信息；

当启动所述应用程序时，按照所述存储路径信息加载所述运行文件，以通过运行所述运行文件执行所述业务模块。

2.根据权利要求1所述的代码编译方法，其特征在于，所述对所述模块代码进行局部编译处理得到运行文件，包括：

对所述模块代码进行局部编译处理得到压缩文件；

对所述压缩文件进行局部编译处理得到运行文件。

3.根据权利要求2所述的代码编译方法，其特征在于，所述对所述模块代码进行局部编译处理得到压缩文件，包括：

对所述模块代码进行局部编译处理得到编译文件；

对所述编译文件进行局部打包处理得到压缩文件。

4.根据权利要求2所述的代码编译方法，其特征在于，所述保存所述存储路径信息，包括：

生成与所述应用程序对应的配置文件，并获取所述压缩文件的文件标识信息；

按照所述文件标识信息将所述存储路径信息保存在所述配置文件中。

5.根据权利要求4所述的代码编译方法，其特征在于，所述生成与所述应用程序对应的配置文件，包括：

确定所述应用程序的程序目录；

在所述程序目录下生成与所述应用程序对应的配置文件。

6.根据权利要求4所述的代码编译方法，其特征在于，所述按照所述存储路径信息加载所述运行文件，包括：

确定与所述应用程序对应的自定义类加载器；

利用所述自定义类加载器按照所述存储路径信息加载所述运行文件。

7.根据权利要求6所述的代码编译方法，其特征在于，所述利用所述自定义类加载器按照所述存储路径信息加载所述运行文件，包括：

若存在所述配置文件，利用所述自定义类加载器按照所述存储路径信息加载所述运行文件。

8.根据权利要求7所述的代码编译方法，其特征在于，所述利用所述自定义类加载器按照所述存储路径信息加载所述运行文件，还包括：

若未存在所述配置文件，从与所述应用程序对应的程序文件中加载所述运行文件；其中，所述程序文件是对所述应用程序的程序代码进行全量编译处理得到的。

9.一种代码编译装置，其特征在于，所述装置包括：

局部编译模块，被配置为获取应用程序所包括业务模块的模块代码，并对所述模块代码进行局部编译处理得到运行文件；

信息存储模块，被配置为存储所述运行文件得到所述运行文件的存储路径信息，并保存所述存储路径信息；

文件加载模块，被配置为当启动所述应用程序时，按照所述存储路径信息加载所述运行文件，以通过运行所述运行文件执行所述业务模块。

10.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至8中任一项所述的代码编译方法。

Images