CN110347398A - 一种应用程序的打包方法和装置 - Google Patents
一种应用程序的打包方法和装置 Download PDFInfo
- Publication number
- CN110347398A CN110347398A CN201810307543.6A CN201810307543A CN110347398A CN 110347398 A CN110347398 A CN 110347398A CN 201810307543 A CN201810307543 A CN 201810307543A CN 110347398 A CN110347398 A CN 110347398A
- Authority
- CN
- China
- Prior art keywords
- business module
- packaged
- module
- code
- dependence
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/443—Optimisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/53—Decompilation; Disassembly
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
本申请实施例提供了一种应用程序的打包方法和装置，所述应用程序的打包方法包括：获取待打包应用程序的源代码；确定所述源代码中代码所属的业务模块；获取所述业务模块之间的依赖关系；依据所述依赖关系，对所述业务模块的代码进行打包，得到所述业务模块的打包文件；采用所述业务模块的打包文件对所述应用程序进行打包。由于将源代码划分为不同的业务模块和分析各个业务模块之间的依赖关系，可以根据依赖关系，采用多线程对多个业务模块进行并发式打包处理，避免了对应用程序的源代码进行一次打包处理耗时长的问题，缩短了应用程序的打包时间，提高了应用程序的打包效率和发布效率。
Description
技术领域
本申请涉及数据处理技术领域，特别是涉及一种应用程序的打包方法和装置。
背景技术
随着应用程序的功能越来越多，应用程序也越来越大，而应用程序通常是打包之后进行发包以供用户下载安装。
对某些大型应用程序而言，例如购物平台和视频平台，功能繁多，代码量非常大，如果不做代码精简优化而直接打包，会导致整个安装包非常大，同时大量的可执行代码也会影响应用程序的线上稳定性，因此对代码的精简、优化等打包是必须的。
目前，应用程序打包通常是直接使用proguard工具直接对应用程序的代码一次性进行精简、优化和混淆后打包，在应用程序的代码量较大时，这种打包方法通常耗时较长，降低了应用程序的打包效率和应用程序的发布效率。
发明内容
鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种应用程序的打包方法和装置。
为了解决上述问题，本申请实施例公开了一种应用程序的打包方法，包括：
获取待打包应用程序的源代码；
确定所述源代码中代码所属的业务模块；
获取所述业务模块之间的依赖关系；
依据所述依赖关系，对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
采用所述业务模块的打包文件对所述应用程序进行打包。
可选地，所述获取待打包应用程序的源代码的步骤包括：
获取待打包的应用程序；
对所述应用程序进行解压缩处理，得到所述应用程序的可执行文件；
对所述可执行文件进行反编译，得到所述应用程序的源代码。
可选地，所述获取所述业务模块之间的依赖关系的步骤包括：
获取预先配置的业务模块依赖列表；
依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块；
依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
可选地，所述依据所述依赖关系，对所述业务模块的代码进行打包，得到所述业务模块的打包文件的步骤包括：
遍历所述业务模块依赖树；
判断当前业务模块是否标识有已打包标识；
若否，则将所述当前业务模块加入任务队列中；
对所述任务队列中的业务模块的代码进行打包，得到业务模块的打包文件，并返回判断当前业务模块是否标识有已打包标识的步骤。
可选地，在对所述任务队列中的业务模块的代码进行打包，得到业务模块的打包文件，并返回判断当前业务模块是否标识有已打包标识的步骤之后还包括：
对打包之后的业务模块标识已打包标识。
可选地，所述对所述任务队列中的业务模块进行打包，得到业务模块的打包文件的步骤包括：
从所述任务列表中提取被依赖列表为空的第一业务模块；
对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件；
如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件；
从所述任务列表中提取所述第一业务模块的依赖表中的第二业务模块；
依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件；
如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
可选地，所述打包包括对所述业务模块的代码进行裁剪、优化、混淆、压缩处理。
为了解决上述问题，本申请实施例公开了一种应用程序的打包方法,包括：
获取待打包应用程序的源代码；
确定所述源代码中代码所属的业务模块；
获取所述业务模块之间的依赖关系；
依据所述依赖关系，采用打包处理集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
采用所述业务模块的打包文件对所述应用程序进行打包。
可选地，还包括：
将所述业务模块的打包文件保存至缓存中，所述缓存包括本地缓存和/或远程服务器缓存。
可选地，所述获取所述业务模块之间的依赖关系的步骤包括：
获取预先配置的业务模块依赖列表；
依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块；
依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
可选地，所述依据所述依赖关系，采用打包处理集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件的步骤包括：
遍历所述业务模块依赖树；
判断当前业务模块是否标识有已打包标识；
若否，将所述当前业务模块加入任务队列中；
采用所述打包处理集群，对所述任务队列中的业务模块的代码进行打包，并返回判断当前业务模块是否标识有已打包标识的步骤。
可选地，在所述采用所述分布式打包处理集群，对所述任务队列中的业务模块的代码进行打包，并返回判断当前业务模块是否标识有已打包标识的步骤之后还包括：
对打包之后的业务模块标识已打包标识。
可选地，所述采用所述打包处理集群，对所述任务队列中的业务模块的代码进行打包的步骤包括：
建立打包处理集群；
从所述任务列表中提取被依赖列表为空的第一业务模块；
将所述第一业务模块发送至所述打包处理集群；
在所述打包处理集群中对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件；
如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件；
从所述任务列表中提取所述第一业务模块的依赖表中的第二业务模块；
将所述第二业务模块发送至所述打包处理集群；
在所述打包处理集群中，依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件；
如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
可选地，所述依据所述依赖关系，采用打包处理集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件的步骤包括：
计算所述业务模块的代码的校验值；
依据所述校验值在本地缓存中查找是否存储有所述业务模块的打包文件；
若是，则获取本地缓存中的打包文件；
若否，则依据所述校验值在远程服务器缓存中查找是否存储有所述业务模块的打包文件；
如果远程服务器缓存中存储有所述业务模块的打包文件，则获取所述远程服务器缓存中的打包文件；
如果远程服务器缓存中不存储有所述业务模块的打包文件，则对所述业务模块的代码进行打包。
可选地，所述打包包括对所述业务模块的代码进行裁剪、优化、混淆、压缩处理。
为了解决上述问题，本申请实施例公开了一种应用程序的打包装置，包括：
源代码获取模块，用于获取待打包应用程序的源代码；
业务模块确定模块，用于确定所述源代码中代码所属的业务模块；
依赖关系获取模块，用于获取所述业务模块之间的依赖关系；
第一业务模块打包模块，用于依据所述依赖关系，对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
第一应用程序打包模块，用于采用所述业务模块的打包文件对所述应用程序进行打包。
可选地，所述源代码获取模块包括：
应用程序获取子模块，用于获取待处理的应用程序；
解压子模块，用于对所述应用程序进行解压缩处理，得到所述应用程序的可执行文件；
反编译子模块，用于对所述可执行文件进行反编译，得到所述应用程序的源代码。
可选地，所述依赖关系获取模块包括：
依赖列表获取子模块，用于获取预先配置的业务模块依赖列表；
依赖树生成子模块，用于依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块；
列表配置子模块，用于依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
可选地，所述第一业务模块打包模块包括：
依赖树遍历子模块，用于遍历所述业务模块依赖树；
标识判断子模块，用于判断当前业务模块是否标识有已打包标识；
任务队列加入子模块，用于将所述当前业务模块加入任务队列中；
第一打包子模块，用于对所述任务队列中的业务模块的代码进行打包，得到所述业务模块的打包文件，并返回判断当前业务模块是否标识有已打包标识的步骤。
可选地，所述第一业务模块打包模块还包括：
标识子模块，用于对打包之后的业务模块标识已打包标识。
可选地，所述第一打包子模块包括：
第一任务提取单元，用于从所述任务列表中提取被依赖列表为空的第一业务模块；
第一打包单元，用于对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件；
第一分析单元，用于如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件；
第二任务提取单元，用于从所述任务列表中提取所述第一业务模块的依赖表中的第二业务模块；
第二打包单元，用于依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件；
第二分析单元，用于如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
可选地，所述打包包括对所述业务模块的代码进行裁剪、优化、混淆、压缩处理。
为了解决上述问题，本申请实施例公开了一种应用程序的打包装置，包括：
源代码获取模块，用于获取待打包应用程序的源代码；
业务模块确定模块，用于确定所述源代码中代码所属的业务模块；
依赖关系获取模块，用于获取所述业务模块之间的依赖关系；
第二业务模块打包模块，用于依据所述依赖关系，采用分布式集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
第二应用程序打包模块，用于采用所述业务模块的打包文件对所述应用程序进行打包。
可选地，还包括：
保存模块，用于将所述业务模块的打包文件保存至缓存中，所述缓存包括本地缓存和/或远程服务器缓存。
可选地，所述依赖关系获取模块包括：
依赖列表获取子模块，用于获取预先配置的业务模块依赖列表；
依赖树生成子模块，用于依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块；
列表配置子模块，用于依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
可选地，所述第二业务模块打包模块包括：
依赖树遍历子模块，用于遍历所述业务模块依赖树；
标识判断子模块，用于判断当前业务模块是否标识有已打包标识；
任务队列加入子模块，用于将所述当前业务模块加入任务队列中；
第二打包子模块，用于采用所述打包处理集群，对所述任务队列中的业务模块的代码进行打包，并返回判断当前业务模块是否标识有已打包标识的步骤。
可选地，所述第二业务模块打包模块还包括：
标识子模块，用于对打包之后的业务模块标识已打包标识。
可选地，所述第二打包子模块包括：
集群建立单元，用于建立打包处理集群；
第一集群任务提取单元，用于从所述任务列表中提取被依赖列表为空的第一业务模块；
第一集群任务发送单元，用于将所述第一业务模块发送至所述打包处理集群；
第一集群打包单元，用于在所述打包处理集群中对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件；
第一集群分析单元，用于如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件；
第二集群任务提取单元，用于从所述任务列表中提取所述第一业务模块的依赖表中被依赖列表不为空的第二业务模块；
第二集群任务发送单元，用于将所述第二业务模块发送至所述打包处理集群；
第二集群打包单元，用于在所述打包处理集群中，依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件；
第二集群分析单元，用于如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
可选地，所述第二业务模块打包模块包括：
校验码计算子模块，用于计算所述业务模块的代码的校验值；
本地缓存查找子模块，用于依据所述校验值在本地缓存中查找是否存储有所述业务模块的打包文件；
本地获取子模块，用于获取本地缓存中的打包文件；
远程缓存查找子模块，用于依据所述校验值在远程服务器缓存中查找是否存储有所述业务模块的打包文件；
远程获取子模块，用于如果远程服务器缓存中存储有所述业务模块的打包文件，则获取所述远程服务器缓存中的打包文件；
打包子模块，用于如果远程服务器缓存中不存储有所述业务模块的打包文件，则对所述业务模块的代码进行打包。
可选地，所述打包包括对所述业务模块的代码进行裁剪、优化、混淆、压缩处理。
为了解决上述问题，本申请实施例公开了一种装置，包括：一个或多个处理器；和其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行本申请实施例所述的一个或多个应用程序的打包方法。
为了解决上述问题，本申请实施例公开了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行本申请实施例所述的一个或多个应用程序的打包方法。
本申请实施例包括以下优点：
本申请实施例中，在获取待打包应用程序的源代码后，确定源代码中代码所属的业务模块；然后获取业务模块之间的依赖关系，并依据依赖关系，对业务模块的代码进行打包，得到业务模块的打包文件；采用业务模块的打包文件对应用程序进行打包，由于将源代码划分为不同的业务模块和分析各个业务模块之间的依赖关系，可以根据依赖关系，采用多线程对多个业务模块进行并发式打包处理，避免了对应用程序的源代码进行一次打包处理耗时长的问题，缩短了应用程序的打包时间，提高了应用程序的打包效率和发布效率。
本申请实施例中，在获取待打包应用程序的源代码后，确定源代码中代码所属的业务模块；然后获取业务模块之间的依赖关系，并依据依赖关系，采用打包处理集群对业务模块的代码进行打包，得到业务模块的打包文件；采用业务模块的打包文件对应用程序进行打包，由于将源代码划分为不同的业务模块和分析各个业务模块之间的依赖关系，可以根据依赖关系，采用打包处理集群对多个业务模块进行并发式打包处理，避免了单机对应用程序的源代码进行一次打包处理耗时长的问题，可以采用打包处理集群同时对应用程序的多个业务模块同时进行打包，大幅缩短了应用程序的打包时间，充分利用了集群资源和提高了应用程序的打包效率和发布效率。
附图说明
图1是本申请的一种应用程序的打包方法实施例1的步骤流程图；
图2是本申请的一种应用程序的打包方法实施例2的步骤流程图；
图3是本申请的一种应用程序的打包方法的示意图；
图4是本申请的一种应用程序的打包方法实施例3的步骤流程图；
图5是本申请的一种应用程序的打包方法实施例4的步骤流程图；
图6是本申请的一种应用程序打包装置实施例1的结构框图；
图7是本申请的一种应用程序打包装置实施例2的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
参照图1，示出了本申请的一种应用程序的打包方法实施例1的步骤流程图，具体可以包括如下步骤：
步骤101，获取待打包应用程序的源代码。
应用程序可以是为完成某项或多项特定工作的计算机程序，它运行在用户模式，可以和用户进行交互，具有可视的用户界面，对应于不同的系统平台，应用程序可以通过不同的编写语言构建，例如对于安卓平台，可以通过Java语言进行编写，其源代码可以为JavaScript代码。
应用程序的源代码可以从应用程序的开发文档中直接读取，也可以是对已打包过的应用程序进行解压后进行反汇编获取应用程序的源代码，本申请实施例对应用程序的源代码的获取方式不加以限制。
步骤102，确定所述源代码中代码所属的业务模块。
在实际应用中，一个应用程序通常包括多个不同的业务模块，各个业务模块对应相应的代码，以利于项目的模块化开发，例如，在一个购物应用程序中，通常包括首页、购物车、商品详情等业务模块，因此可以确定源代码中代码所属的业务模块，具体而言，各个业务模块的代码之间是具有代码边界的，例如可以是各个业务模块之间的调用接口等，可以通过代码边界确定代码所属的业务模块。
步骤103，获取所述业务模块之间的依赖关系。
应用程序中业务模块之间可以是独立的，也可以是具有依赖关系的，即一个业务模块调用另一个业务模块的数据或者功能或者属性等，例如，在购物应用程序中，购物车需要展示商品详情时，购物车对应的业务模块需要调用商品详情页对应的业务模块的框架数据，这就形成了业务模块之间的依赖关系，即一个业务模块被另一个业务模块依赖，或者一个业务模块依赖于另一个业务模块。业务模块之间的依赖关系在项目开发时已经确定，并且写入到应用程序的代码里，通过对代码分析可以得到各个业务模块之间的依赖关系，还可以是项目开发时编写业务模块列表，该列表记载了所有业务模块的依赖关系，可以从业务模块列表中读取业务模块之间的依赖关系。
步骤104，依据所述依赖关系，对所述业务模块的代码进行打包，得到所述业务模块的打包文件。
在将代码划分为不同业务模块和获取到各个业务模块之间的依赖关系后，可以对各个业务模块的代码进行打包，打包过程中，对于依赖其它业务模块的业务模块，在打包时生成该业务模块的依赖配置文件，以供被依赖的业务模块在打包时，依据该依赖配置文件对代进行裁剪、优化，避免依赖配置文件中列出的相关代码被裁剪掉，造成业务模块之间的依赖失败。由于将应用程序的源代码划分为不同的业务模块，可以根据业务模块之间的依赖关系，对多个业务模块采用多线程进行并发式打包处理，相对于一次性对应用程序的全量代码进行打包处理，缩短了打包时间，提高了应用程序的打包效率。
步骤105，采用所述业务模块的打包文件对所述应用程序进行打包。
在对各个业务模块进行打包之后，可以采用各个业务模块的打包文件对应用程序进行打包，具体而言，对应用程序的打包也可以是对主业务模块的打包，即主业务模块依据各个业务模块的依赖配置文件，确定主业务模块中需要保留的、供各个业务模块调用的代码后，对主业务模块的代码进行打包，即可以得到应用程序的打包文件。
本申请实施例中，在获取待打包应用程序的源代码后，确定源代码中代码所属的业务模块，然后获取业务模块之间的依赖关系，并依据依赖关系，对业务模块的代码进行打包，得到业务模块的打包文件；采用业务模块的打包文件对应用程序进行打包，由于将源代码划分为不同的业务模块和分析各个业务模块之间的依赖关系，可以根据依赖关系，采用多线程对多个业务模块进行并发式打包处理，避免了对应用程序的源代码进行一次打包处理耗时长的问题，缩短了应用程序的打包时间，提高了应用程序的打包效率和发布效率。
参照图2，示出了本申请的一种应用程序的打包方法实施例2的步骤流程图，具体可以包括如下步骤：
步骤201，获取待打包应用程序的源代码。
本申请实施例中，应用程序可以通过不同的编写语言构建，例如对于安卓平台，可以通过Java语言进行编写，其源代码可以为JavaScript代码，具体到本申请实施例中，步骤201可以包括如下子步骤：
子步骤S11，获取待打包的应用程序。
子步骤S12，对所述应用程序进行解压缩处理，得到所述应用程序的可执行文件；
子步骤S13，对所述可执行文件进行反编译，得到所述应用程序的源代码。
本申请实施例中，应用程序可以在项目开发者中获取，该应用程序可以是以压缩包的形式存在，因此需要对应用程序进行解压缩，得到可执行文件。可执行文件是指可以有操作系统进行加载执行并可以进行编译的文件，其是通过对源代码进行编译和处理后得到的，因此可以对可执行文件进行反编译，得到应用程序的源代码。
步骤202，确定所述源代码中代码所属的业务模块。
在实际应用中，一个应用程序通常包括多个不同的业务模块，各个业务模块对应相应的代码，以利于项目的模块化开发，例如，在一个购物应用程序中，通常包括首页、购物车、商品详情等业务模块，因此可以确定源代码中代码所属的业务模块，具体而言，各个业务模块的代码之间是具有代码边界的，例如可以是各个业务模块之间的调用接口等，可以通过代码边界确定代码所属的业务模块。
步骤203，获取预先配置的业务模块依赖列表。
本申请实施例中，业务模块之间的依赖可以是一个业务模块调用另一个业务模块的数据，例如调用其它业务模块的框架、某个接口数据等，例如，在购物车中设置商品详情选项后，如果用户在购物车需要查看商品详情属性，则调用商品详情页的页面数据。
业务开发者在应用程序开发时配置业务模块依赖列表，可以读取所有业务模块的依赖列表，每个业务模块的依赖列表中记载了每个业务模块依赖哪些业务模块，以及，每个业务模块被哪些业务模块所依赖。
步骤204，依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块。
本申请实施例中，需要根据业务模块之间的依赖关系对业务模块进行打包，因此可以根据所有业务模块的依赖列表中记载的依赖关系建立应用程序的业务模块依赖树，该依赖树上的一个节点代表一个业务模块，如果一个节点具有上游节点，则说明该节点对应的业务模块被上游节点对应的业务模块所依赖，如果一个节点具有下游节点，则说明该节点对应的业务模块依赖于下游节点对应的业务模块。
步骤205，依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
在实际应用中，一个业务模块有可能被多个业务模块所依赖和/或依赖于多个业务模块，因此需要为每个业务模块配置被依赖列表和依赖列表，被依赖列表中记录该业务模块被哪些业务模块所依赖，依赖列表中记载该业务模块依赖于哪些业务模块。
步骤206，遍历所述业务模块依赖树。
本申请实施例中，遍历是指沿着某条搜索路线，依次对树中每个结点均做一次且仅做一次访问，具体到本申请实施例中，可以从上至下遍历业务模块依赖树的每个节点，即遍历业务模块依赖树中的每个业务模块以找出所有的业务模块。
步骤207，判断当前业务模块是否标识有已打包标识。
在实际应用中，可以对打包处理过的业务模块打上已打包标识，以避免对业务模块重复执行打包处理，当遍历到业务模块依赖树中的一个节点时，判断该节点对应的业务模块是否标识了已打包标识，若是，则跳过该节点，若否，则执行步骤208。
步骤208，将所述当前业务模块加入任务队列中。
如果当前节点对应的业务模块未标识已打包标识，表明该业务模块没有打包处理，将该业务模块移入任务队列中。任务队列可以是根据设备的处理能力设置的一个任务队列，该任务队列可以容纳任务的个数根据设备的处理能力确定。
步骤209，对所述任务队列中的业务模块的代码进行打包，得到业务模块的打包文件。
本申请实施例中，由于业务模块之间具有依赖关系，需要按照依赖关系进行业务模块的打包，具体而言，步骤209可以包括如下子步骤：
子步骤S21，从所述任务列表中提取被依赖列表为空的第一业务模块。
本申请实施例中，对业务模块的打包处理包括对代码的裁剪、优化处理，为避免代码裁剪、优化造成业务模块之间的依赖失败，可以先对没有被依赖的业务模块进行打包处理，即从任务列表中提取被依赖列表为空的第一业务模块，由于第一业务模块是任务队列中没有被依赖的业务模块，第一业务模块可以有多个，以便并发式的对第一业务模块进行打包，提高打包效率。
子步骤S22，对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件。
本申请实施例中，对业务模块进行打包包括对代码裁剪、优化、混淆、压缩等处理，具体而言，可以通过proguard工具对业务模块的代码进行打包，当然，也可以关闭proguard的混淆功能，然后采用其他第三方的加固方案再做单独的混淆的功能。
一个业务模块可以由很多的SDK(Software Development Kit，软件开发工具包)组成，每个SDK可能都包含1个或者多个jar包，例如包括orgin_jar1和origin_jar2两个原始jar包，在使用proguard对上述2个原始jar包进行裁剪、优化等处理前配置输出打包文件为jar1和jar2，在proguard执行完成后可以得到jar1和jar2 2个打包文件。
子步骤S23，如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件。
第一业务模块虽然没有被其它业务模块所依赖，但是其有可能依赖于其它的业务模块，可以对第一业务模块进行分析，以确定其依赖于其它业务的哪些代码，避免其它业务模块打包进行代码裁剪时裁剪掉该部分代码，造成第一业务模块调用失败的问题，例如可以对第一业务模块的代码进行分析，得到第一业务模块依赖了外部的哪些方法、类或者属性，则生成一个清单，即依赖配置文件keep.cfg。
子步骤S24，从所述任务列表中提取所述第一业务模块的依赖表中的第二业务模块。
在对没有被依赖的第一业务模块进行打包处理后得到第一业务模块的依赖配置文件，可以从任务列表中提取其依赖的业务模块进行打包，具体而言，提取第一业务模块的依赖列表中的业务模块作为第二业务模块进行打包处理。
子步骤S25，依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件。
对于第二业务模块，其维护一个被依赖列表，该被依赖列表中记录了依赖于第二业务模块的所有业务模块，例如，可以是第一业务模块，而由于第一业务模块在打包时已经生成依赖配置文件keep.cfg，如步骤S23，因此可以根据第一业务模块的依赖配置文件keep.cfg对第二业务模块进行打包，具体而言，根据第一业务模块的依赖配置文件keep.cfg，确定第二模块中必须保留的代码后进行打包，避免该部分代码被裁剪掉造成第一业务模块依赖调用失败的问题。
第二业务模块在打包时带上依赖列表中的业务模块的keep.cfg一同输入proguard中进行打包，强制保留第一业务模块的keep.cfg中的信息对应的代码，打包后得到第二业务模块的打包文件，例如得到第二业务模块的jar包。
本申请实施例中，第一业务模块和第二模块可以是依赖和被依赖关系，例如，第一业务模块依赖于第二业务模块，则第二业务模块为被依赖，第一模块为依赖，在一个示例中，例如购物平台上，商品详情页可以是第二业务模块，购物车可以是第一业务模块，购物车中显示的商品的属性、价格等信息依赖于商品详情页上的信息，即第一业务模块依赖于第二业务模块。
子步骤S26，如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
第二业务模块可能既被其它业务模块所依赖，同时又依赖于其它的业务模块，可以对第二业务模块的代码进行分析，以确定其依赖于其它业务的哪些代码，避免其它业务模块打包进行代码裁剪时裁剪掉该部分代码，造成第二业务模块调用失败的问题，例如可以对第二业务模块的代码进行分析，得到第二业务模块依赖了外部的哪些方法、类或者属性，则生成一个清单，即依赖配置文件keep.cfg。
需要说明的是，本申请实施例中对于依赖树中的各个节点，可以根据被依赖和依赖的关系，先从上游业务模块进行处理得到依赖配置文件，然后根据依赖配置文件打包下游业务模块，即在被依赖和依赖的两个业务模块中，先打包依赖的业务模块，再打包被依赖的业务模块，避免被依赖的业务模块先打包时裁剪代码，造成依赖的业务模块依赖调用失败的问题。
另外，子步骤S21-S26虽然仅仅说明了第一业务模块和第二业务模块，但是对于任务列表中的业务模块，重复上述步骤直至任务列表中的业务模块打包完为止，即业务模块打包之后标识已打包标识，直到业务模块依赖树中遍历的全是标识有已打包标识的业务模块。
步骤210，采用所述业务模块的打包文件对所述应用程序进行打包。
在对各个业务模块进行打包之后，可以采用各个业务模块的打包文件对应用程序进行打包，具体而言，对应用程序的打包也可以是对主业务模块的打包，即主业务模块依据各个业务模块的依赖配置文件，确定主业务模块中需要保留的、供各个业务模块调用的代码后，对主业务模块的代码进行打包，即可以得到应用程序的打包文件。
为了更清楚说明本申请实施例，以下结合图3进行说明：
如图3所示，假设应用程序包括主业务模块main、业务模块bundle1和业务模块bundle2，业务模块bundle1依赖于业务模块bundle1，同时主业务模块main依赖于业务模块bundle1和业务模块bundle2。
在打包处理时：
首先得到业务模块bundle1的被依赖列表为空(除了main外，没有其他业务模块依赖业务模块bundle1)，因此首先对业务模块bundle1进行Proguard处理得到业务模块bundle1的打包文件jar1和jar2；
其次，业务模块bundle1依赖于业务模块bundle2，因此需要生成业务模块bundle1的keep.cfg，以指示业务模块bundle2在打包时必须保留的代码；
另外，对于业务模块bundle2，其被依赖列表不为空(由于其被业务模块bundle1依赖)，因此在进行Proguard处理前，需要获取业务模块bundle1的keep.cfg，在对业务模块bundle2进行Proguard处理时带上bundle1的keep.cfg以强制保留相关代码，同时业务模块bundle2被主业务模块main依赖，因此需要生成业务模块bundle2的keep.cfg。
最后，对于主模块main，其依赖列表中包括业务模块bundle1和业务模块bundle2，需要获取业务模块bundle1和业务模块bundle2的keep.cfg后进行Proguard处理，完成应用程序的打包。
以上示例仅仅是包含3个业务模块，实际应用中可以包含多个业务模块，多个业务模块的处理过程参考上述示例。
本申请实施例中，在获取待打包应用程序的源代码后，确定源代码中代码所属的业务模块，然后获取业务模块之间的依赖关系，并依据依赖关系，对业务模块的代码进行打包，得到业务模块的打包文件；采用业务模块的打包文件对应用程序进行打包，由于将源代码划分为不同的业务模块和分析各个业务模块之间的依赖关系，可以根据依赖关系，采用多线程对多个业务模块进行并发式打包处理，避免了对应用程序的源代码进行一次打包处理耗时长的问题，缩短了应用程序的打包时间，提高了应用程序的打包效率和发布效率。
本申请实施例中，将未打包的业务模块移入任务列表中，并根据业务模块的被依赖列表和依赖列表对各个业务模块进行打包处理，在打包过程中生成依赖配置文件以供其它业务模块打包时调用打包，能够有序和并发式地对各个业务模块进行打包，提高了打包效率。
本申请实施例将应用程序的源代码划分为各个业务模块进行打包，当业务模块更新时，可以仅对更新的业务模块进行重新打包，避免了对应用程序重新进行全量打包的问题，提高了应用程序的更新效率。
参照图4，示出了本申请的一种应用程序的打包方法实施例3的步骤流程图，具体可以包括如下步骤：
步骤301，获取待打包应用程序的源代码。
步骤302，确定所述源代码中代码所属的业务模块。
步骤303，获取所述业务模块之间的依赖关系。
步骤301-步骤303与实施例1相似，详情参考实施例1的步骤101-103，在此不再重复叙述。
步骤304，依据所述依赖关系，采用打包处理集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件。
本申请实施例中，打包处理集群可以是分布于网络上的数据处理服务器、存储服务器等。本申请实施例在将代码划分为不同业务模块和获取到各个业务模块之间的依赖关系后，可以根据依赖关系将各个业务模块发送至打包处理集群中，采用打包处理集群同时对多个业务模块进行打包处理，打包处理集群返回各个业务模块的打包文件，以避免单机打包由于单机性能的限制，并发式打包处理业务模块的数量有限，造成应用程序打包效率低的问题。
步骤305，采用所述业务模块的打包文件对所述应用程序进行打包。
在对各个业务模块进行打包之后，可以采用各个业务模块的打包文件对应用程序进行打包，具体而言，对应用程序的打包也可以是对主业务模块的打包，即主业务模块依据各个业务模块的依赖配置文件，确定主业务模块中需要保留的、供各个业务模块调用的代码后，对主业务模块的代码进行打包，即可以得到应用程序的打包文件。
本申请实施例中，采用打包处理集群同时对多个业务模块进行并发式打包处理，避免了单机对应用程序的源代码进行一次打包处理耗时长的问题，可以利用打包处理集群强大的处理性能对多个业务模块进行打包，大幅缩短了应用程序的打包时间，充分利用了集群资源和提高了应用程序的打包效率和发布效率。
参照图5，示出了本申请的一种应用程序的打包方法实施例4的步骤流程图，具体可以包括如下步骤：
步骤401，获取待打包应用程序的源代码。
本申请实施例中，应用程序可以通过不同的编写语言构建，例如对于安卓平台，可以通过Java语言进行编写，其源代码可以为JavaScript代码，具体到本申请实施例中，步骤401可以包括如下子步骤：
子步骤S31，获取待打包的应用程序。
子步骤S32，对所述应用程序进行解压缩处理，得到所述应用程序的可执行文件；
子步骤S33，对所述可执行文件进行反编译，得到所述应用程序的源代码。
本申请实施例中，应用程序可以在项目开发者中获取，该应用程序可以是以压缩包的形式存在，因此需要对应用程序进行解压缩，得到可执行文件。可执行文件是指可以有操作系统进行加载执行并可以进行编译的文件，其是通过对源代码进行编译和处理后得到的，因此可以对可执行文件进行反编译，得到应用程序的源代码。
步骤402，确定所述源代码中代码所属的业务模块。
步骤403，获取预先配置的业务模块依赖列表。
步骤404，依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块。
步骤405，依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
步骤406，遍历所述业务模块依赖树。
步骤407，判断当前业务模块是否标识有已打包标识。
步骤408，将所述当前业务模块加入任务队列中。
步骤409，对所述任务队列中的业务模块的代码进行打包，得到所述业务模块的打包文件。
本申请实施例中，由于业务模块之间具有依赖关系，需要按照依赖关系进行业务模块的打包，具体而言，步骤409可以包括如下子步骤：
子步骤S41，建立打包处理集群。
本申请实施例中，集群可以是分布于网络上的处理设备，网络可以是互联网，也可以是局域网，处理设备可以是数据处理服务器、缓存服务器等设备，可以根据应用程序的大小建立相应的打包处理集群。本申请实施例可以是通过打包处理集群外的设备将应用程序的打包任务发送至打包处理集群，由打包处理集群执行步骤402-步骤409，也可以是打包处理集群外的设备执行步骤402到步骤408，步骤409由打包处理集群执行。
子步骤S42，从所述任务列表中提取被依赖列表为空的第一业务模块。
子步骤S43，将所述第一业务模块发送至所述打包处理集群。
本申请实施例中，用户对应用程序打包的设备可以是打包处理集群外的一个设备，任务列表在该设备中建立和进行任务的管理，例如通过打包工具Proguard进行任务的提取和将各个业务模块发送至打包处理集群进行打包和接收打包处理集群返回的打包文件等，具体而言，第一业务模块可以有多个，可以将不同的第一业务模块发送至打包处理集群的不同设备上。
当然，用户对应用程序打包的设备可以是打包处理集群的一个设备，该设备通过打包工具Proguard对打包处理集群的打包过程进行协调和控制。
子步骤S44，在所述打包处理集群中对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件。
本申请实施例中，对业务模块进行打包包括对代码裁剪、优化、混淆、压缩等处理，具体而言，第一业务模块可以有多个，可以在打包处理集群的不同设备上通过proguard工具对各个第一业务模块的代码进行打包，得到第一业务模块的打包文件并返回打包文件。
子步骤S45，如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件。
子步骤S46，从所述任务列表中提取所述第一业务模块的依赖表中被依赖列表不为空的第二业务模块。
子步骤S47，将所述第二业务模块发送至所述打包处理集群。
子步骤S48，在所述打包处理集群中，依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件。
本申请实施例中，打包处理集群对业务模块进行打包后，返回已打包的业务模块的打包文件和依赖配置文件，打包处理集群中的设备可以通过共享数据方式获取依赖配置文件，还可以通过打包处理集群中的控制主机获取依赖配置文件。
在所述打包处理集群中，依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行裁剪，保留第一业务模块需要调用的第二业务模块的代码，到所述第二业务模块的打包文件。
子步骤S49，如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
子步骤S41-子步骤S45的过程与实施例2中子步骤S21-子步骤S26类似，未详述的步骤参考子步骤S21-子步骤S26中对于的叙述，在此不再重复。
另外，子步骤S41-S49虽然仅仅说明了第一业务模块和第二业务模块，但是对于任务列表中的业务模块，重复上述步骤直至任务列表中的业务模块打包完为止，即业务模块打包之后标识已打包标识，直到业务模块依赖树中遍历的全是标识有已打包标识的业务模块。
在本申请的一种优选实施例中，步骤409可以包括如下子步骤：
子步骤S50，计算所述业务模块的代码的校验值；
子步骤S51，依据所述校验值在本地缓存中查找是否存储有所述业务模块的打包文件；
子步骤S52，获取本地缓存中的打包文件；
子步骤S53，依据所述校验值在远程服务器缓存中查找是否存储有所述业务模块的打包文件；
子步骤S54，如果远程服务器缓存中存储有所述业务模块的打包文件，则获取所述远程服务器缓存中的打包文件；
子步骤S55，如果远程服务器缓存中不存储有所述业务模块的打包文件，则对所述业务模块的代码进行打包。
在实际应用中，对于打包工具proguard，如果业务模块是一样的，则proguard得到的打包文件是一样的，因此可以为每个业务模块标识一个校验值，例如可以是MD5值，然后将每个业务模块的打包文件缓存到缓存服务器中。
当获取到一个业务模块的代码后，先计算该业务模块的MD5值，通过MD5值到本地缓存中查找，如果本地缓存中存储有该MD5值对应的业务模块的打包文件，则直接复制该打包文件，如果本地缓存中不存在该业务模块的打包文件，则发送请求至远程服务器的缓存中查找该业务模块的打包文件，如果远程服务器缓存中存储有该业务模块的打包文件，则将远程服务器缓存中的打包文件下载到本地设备中，如果本地缓存和远程服务器缓存均不存在打包文件，则通过proguard对业务模块进行打包处理，具体打包处理如子步骤S41-S49。
本申请实施例，通过缓存查找已有的打包文件，使用已有数据进行打包，避免重复对业务模块打包造成时间和资源浪费的问题，提高了应用程序打包的效率和节省了资源。
步骤410，将所述业务模块的打包文件保存至缓存中，所述缓存包括本地缓存和/或远程服务器缓存。
如果本地缓存和远程服务器缓存中均不存在业务模块的打包文件，通过proguard对业务模块进行打包处理得到业务模块的打包文件后，将业务模块的打包文件存储至本地缓存或者远程服务器缓存中，以供下次打包时直接使用，以缩短打包时间，提高打包的效率
步骤411，采用所述业务模块的打包文件对所述应用程序进行打包。
在对各个业务模块进行打包之后，可以采用各个业务模块的打包文件对应用程序进行打包，具体而言，对应用程序的打包也可以是对主业务模块的打包，即主业务模块依据各个业务模块的依赖配置文件，确定主业务模块中需要保留的、供各个业务模块调用的代码后，对主业务模块的代码进行打包，即可以得到应用程序的打包文件。
本申请实施例中，由于将源代码划分为不同的业务模块和分析各个业务模块之间的依赖关系，可以根据依赖关系，采用打包处理集群对多个业务模块进行并发式打包处理，避免了单机对应用程序的源代码进行一次打包处理耗时长的问题，可以采用打包处理集群同时对应用程序的多个业务模块同时进行打包，大幅缩短了应用程序的打包时间，充分利用了集群资源和提高了应用程序的打包效率和发布效率。
本申请实施例将应用程序的源代码划分为各个业务模块进行打包，当业务模块更新时，可以仅对更新的业务模块进行重新打包，避免了对应用程序重新进行全量打包的问题，提高了应用程序的更新效率。
本申请实施例中，可以在本地缓存或者远程服务器缓存中查找是否存储有业务模块的打包文件，如果存在有打包文件则直接获取，如果不存在则打包处理后将打包文件存储在本地缓存或者远程服务器缓存中，通过缓存获取业务模块的打包文件，可以避免重复对业务模块进行打包造成时间和资源浪费的问题，大幅度缩短了应用程序的打包时间，提高了应用程序的打包效率。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。
参照图6，示出了本申请的一种应用程序打包装置实施例1的结构框图，具体可以包括如下模块：
源代码获取模块501，用于获取待打包应用程序的源代码；
业务模块确定模块502，用于确定所述源代码中代码所属的业务模块；
依赖关系获取模块503，用于获取所述业务模块之间的依赖关系；
第一业务模块打包模块504，用于依据所述依赖关系，对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
第一应用程序打包模块505，用于采用所述业务模块的打包文件对所述应用程序进行打包。
可选地，所述源代码获取模块501包括：
应用程序获取子模块，用于获取待处理的应用程序；
解压子模块，用于对所述应用程序进行解压缩处理，得到所述应用程序的可执行文件；
反编译子模块，用于对所述可执行文件进行反编译，得到所述应用程序的源代码。
可选地，所述依赖关系获取模块503包括：
依赖列表获取子模块，用于获取预先配置的业务模块依赖列表；
依赖树生成子模块，用于依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块；
列表配置子模块，用于依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
可选地，所述第一业务模块打包模块504包括：
依赖树遍历子模块，用于遍历所述业务模块依赖树；
标识判断子模块，用于判断当前业务模块是否标识有已打包标识；
任务队列加入子模块，用于将所述当前业务模块加入任务队列中；
第一打包子模块，用于对所述任务队列中的业务模块的代码进行打包，得到所述业务模块的打包文件，并返回判断当前业务模块是否标识有已打包标识的步骤。
可选地，所述第一业务模块打包模块504还包括：
标识子模块，用于对打包之后的业务模块标识已打包标识。
可选地，所述第一打包子模块包括：
第一任务提取单元，用于从所述任务列表中提取被依赖列表为空的第一业务模块；
第一打包单元，用于对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件；
第一分析单元，用于如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件；
第二任务提取单元，用于从所述任务列表中提取所述第一业务模块的依赖表中的第二业务模块；
第二打包单元，用于依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件；
第二分析单元，用于如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
可选地，所述打包包括对所述业务模块的代码进行裁剪、优化、混淆、压缩处理。
参照图7，示出了本申请的一种应用程序打包装置实施例2的结构框图，具体可以包括如下模块：
源代码获取模块501，用于获取待打包应用程序的源代码；
业务模块确定模块502，用于确定所述源代码中代码所属的业务模块；
依赖关系获取模块503，用于获取所述业务模块之间的依赖关系；
第二业务模块打包模块506，用于依据所述依赖关系，采用分布式集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
第二应用程序打包模块507，用于采用所述业务模块的打包文件对所述应用程序进行打包。
可选地，还包括：
保存模块508，用于将所述业务模块的打包文件保存至缓存中，所述缓存包括本地缓存和/或远程服务器缓存。
可选地，所述依赖关系获取模块503包括：
依赖列表获取子模块，用于获取预先配置的业务模块依赖列表；
依赖树生成子模块，用于依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块；
列表配置子模块，用于依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
可选地，所述第二业务模块打包模块506包括：
依赖树遍历子模块，用于遍历所述业务模块依赖树；
标识判断子模块，用于判断当前业务模块是否标识有已打包标识；
任务队列加入子模块，用于将所述当前业务模块加入任务队列中；
第二打包子模块，用于采用所述打包处理集群，对所述任务队列中的业务模块的代码进行打包，并返回判断当前业务模块是否标识有已打包标识的步骤。
可选地，所述第二业务模块打包模块506还包括：
标识子模块，用于对打包之后的业务模块标识已打包标识。
可选地，所述第二打包子模块包括：
集群建立单元，用于建立打包处理集群；
第一集群任务提取单元，用于从所述任务列表中提取被依赖列表为空的第一业务模块；
第一集群任务发送单元，用于将所述第一业务模块发送至所述打包处理集群；
第一集群打包单元，用于在所述打包处理集群中对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件；
第一集群分析单元，用于如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件；
第二集群任务提取单元，用于从所述任务列表中提取所述第一业务模块的依赖表中被依赖列表不为空的第二业务模块；
第二集群任务发送单元，用于将所述第二业务模块发送至所述打包处理集群；
第二集群打包单元，用于在所述打包处理集群中，依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件；
第二集群分析单元，用于如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
可选地，所述第二业务模块打包模块506包括：
校验码计算子模块，用于计算所述业务模块的代码的校验值；
本地缓存查找子模块，用于依据所述校验值在本地缓存中查找是否存储有所述业务模块的打包文件；
本地获取子模块，用于获取本地缓存中的打包文件；
远程缓存查找子模块，用于依据所述校验值在远程服务器缓存中查找是否存储有所述业务模块的打包文件；
远程获取子模块，用于如果远程服务器缓存中存储有所述业务模块的打包文件，则获取所述远程服务器缓存中的打包文件；
打包子模块，用于如果远程服务器缓存中不存储有所述业务模块的打包文件，则对所述业务模块的代码进行打包。
可选地，所述打包包括对所述业务模块的代码进行裁剪、优化、混淆、压缩处理。
本申请实施例还提供了一种装置，包括：一个或多个处理器；和其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行实施例1和/或实施例2和/或实施例3和/或实施例4所述的一个或多个的方法。
本申请实施例还提供了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行实施例1和/或实施例2和/或实施例3和/或实施例4所述的一个或多个的方法。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种应用程序的打包方法和一种应用程序的打包装置进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。
Claims (17)
1.一种应用程序的打包方法，其特征在于，包括：
获取待打包应用程序的源代码；
确定所述源代码中代码所属的业务模块；
获取所述业务模块之间的依赖关系；
依据所述依赖关系，对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
采用所述业务模块的打包文件对所述应用程序进行打包。
2.如权利要求1所述的打包方法，其特征在于，所述获取待打包应用程序的源代码的步骤包括：
获取待打包的应用程序；
对所述应用程序进行解压缩处理，得到所述应用程序的可执行文件；
对所述可执行文件进行反编译，得到所述应用程序的源代码。
3.如权利要求1所述的打包方法，其特征在于，所述获取所述业务模块之间的依赖关系的步骤包括：
获取预先配置的业务模块依赖列表；
依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块；
依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
4.如权利要求3所述的打包方法，其特征在于，所述依据所述依赖关系，对所述业务模块的代码进行打包，得到所述业务模块的打包文件的步骤包括：
遍历所述业务模块依赖树；
判断当前业务模块是否标识有已打包标识；
若否，则将所述当前业务模块加入任务队列中；
对所述任务队列中的业务模块的代码进行打包，得到业务模块的打包文件，并返回判断当前业务模块是否标识有已打包标识的步骤。
5.如权利要求4所述的打包方法，其特征在于，在对所述任务队列中的业务模块的代码进行打包，得到业务模块的打包文件，并返回判断当前业务模块是否标识有已打包标识的步骤之后还包括：
对打包之后的业务模块标识已打包标识。
6.如权利要求4所述的打包方法，其特征在于，所述对所述任务队列中的业务模块进行打包，得到业务模块的打包文件的步骤包括：
从所述任务列表中提取被依赖列表为空的第一业务模块；
对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件；
如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件；
从所述任务列表中提取所述第一业务模块的依赖表中的第二业务模块；
依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件；
如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
7.如权利要求1所述的打包方法，其特征在于，所述打包包括对所述业务模块的代码进行裁剪、优化、混淆、压缩处理。
8.一种应用程序的打包方法，其特征在于，包括：
获取待打包应用程序的源代码；
确定所述源代码中代码所属的业务模块；
获取所述业务模块之间的依赖关系；
依据所述依赖关系，采用打包处理集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
采用所述业务模块的打包文件对所述应用程序进行打包。
9.如权利要求8所述的打包方法，其特征在于，还包括：
将所述业务模块的打包文件保存至缓存中，所述缓存包括本地缓存和/或远程服务器缓存。
10.如权利要求8所述的打包方法，其特征在于，所述获取所述业务模块之间的依赖关系的步骤包括：
获取预先配置的业务模块依赖列表；
依据所述业务模块依赖列表，生成业务模块依赖树，所述业务模块依赖树的一个节点为一个业务模块；
依据所述业务模块依赖树，为所述业务模块配置被依赖列表和依赖列表。
11.如权利要求10所述的打包方法，其特征在于，所述依据所述依赖关系，采用打包处理集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件的步骤包括：
遍历所述业务模块依赖树；
判断当前业务模块是否标识有已打包标识；
若否，将所述当前业务模块加入任务队列中；
采用所述打包处理集群，对所述任务队列中的业务模块的代码进行打包，并返回判断当前业务模块是否标识有已打包标识的步骤。
12.如权利要求11所述的打包方法，其特征在于，在所述采用所述分布式打包处理集群，对所述任务队列中的业务模块的代码进行打包，并返回判断当前业务模块是否标识有已打包标识的步骤之后还包括：
对打包之后的业务模块标识已打包标识。
13.如权利要求11所述的打包方法，其特征在于，所述采用所述打包处理集群，对所述任务队列中的业务模块的代码进行打包的步骤包括：
建立打包处理集群；
从所述任务列表中提取被依赖列表为空的第一业务模块；
将所述第一业务模块发送至所述打包处理集群；
在所述打包处理集群中对所述第一业务模块的代码进行打包得到所述第一业务模块的打包文件；
如果所述第一业务模块的依赖列表不为空，对所述第一业务模块的代码进行分析，得到所述第一业务模块的依赖配置文件；
从所述任务列表中提取所述第一业务模块的依赖表中的第二业务模块；
将所述第二业务模块发送至所述打包处理集群；
在所述打包处理集群中，依据所述第一业务模块的依赖配置文件对所述第二业务模块的代码进行打包，得到所述第二业务模块的打包文件；
如果所述第二业务模块的依赖列表不为空，对所述第二业务模块的代码进行分析，得到所述第二业务模块的依赖配置文件。
14.如权利要求8所述的打包方法，其特征在于，所述依据所述依赖关系，采用打包处理集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件的步骤包括：
计算所述业务模块的代码的校验值；
依据所述校验值在本地缓存中查找是否存储有所述业务模块的打包文件；
若是，则获取本地缓存中的打包文件；
若否，则依据所述校验值在远程服务器缓存中查找是否存储有所述业务模块的打包文件；
如果远程服务器缓存中存储有所述业务模块的打包文件，则获取所述远程服务器缓存中的打包文件；
如果远程服务器缓存中不存储有所述业务模块的打包文件，则对所述业务模块的代码进行打包。
15.如权利要求8所述的打包方法，其特征在于，所述打包包括对所述业务模块的代码进行裁剪、优化、混淆、压缩处理。
16.一种应用程序的打包装置，其特征在于，包括：
源代码获取模块，用于获取待打包应用程序的源代码；
业务模块确定模块，用于确定所述源代码中代码所属的业务模块；
依赖关系获取模块，用于获取所述业务模块之间的依赖关系；
第一业务模块打包模块，用于依据所述依赖关系，对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
第一应用程序打包模块，用于采用所述业务模块的打包文件对所述应用程序进行打包。
17.一种应用程序的打包装置，其特征在于，包括：
源代码获取模块，用于获取待打包应用程序的源代码；
业务模块确定模块，用于确定所述源代码中代码所属的业务模块；
依赖关系获取模块，用于获取所述业务模块之间的依赖关系；
第二业务模块打包模块，用于依据所述依赖关系，采用分布式集群对所述业务模块的代码进行打包，得到所述业务模块的打包文件；
第二应用程序打包模块，用于采用所述业务模块的打包文件对所述应用程序进行打包。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810307543.6A CN110347398A (zh) | 2018-04-08 | 2018-04-08 | 一种应用程序的打包方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810307543.6A CN110347398A (zh) | 2018-04-08 | 2018-04-08 | 一种应用程序的打包方法和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110347398A true CN110347398A (zh) | 2019-10-18 |
Family
ID=68173180
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810307543.6A Pending CN110347398A (zh) | 2018-04-08 | 2018-04-08 | 一种应用程序的打包方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110347398A (zh) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110825391A (zh) * | 2019-10-31 | 2020-02-21 | 北京金山云网络技术有限公司 | 服务管理方法、装置、电子设备及存储介质 |
| CN111158741A (zh) * | 2019-12-23 | 2020-05-15 | 北京五八信息技术有限公司 | 监控业务模块对第三方类库依赖关系变化的方法及装置 |
| CN111694402A (zh) * | 2020-06-11 | 2020-09-22 | 翱捷科技(上海)有限公司 | 单芯片异构系统的控制方法和可穿戴设备 |
| CN111796861A (zh) * | 2020-06-28 | 2020-10-20 | 上海米哈游天命科技有限公司 | 一种打包方法、装置、电子设备及存储介质 |
| CN112433950A (zh) * | 2020-11-30 | 2021-03-02 | 天津五八到家货运服务有限公司 | 自动搭建测试环境的方法、电子设备及存储介质 |
| CN112445500A (zh) * | 2020-11-30 | 2021-03-05 | 北京达佳互联信息技术有限公司 | 应用程序处理方法、应用程序运行方法及相关设备 |
| CN113377376A (zh) * | 2021-06-09 | 2021-09-10 | 中国工商银行股份有限公司 | 数据包生成方法、数据包生成装置、电子设备及存储介质 |
| CN113535220A (zh) * | 2020-04-15 | 2021-10-22 | 北京京东振世信息技术有限公司 | 一种代码包管理方法和装置 |
| CN113741951A (zh) * | 2020-05-29 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 本地打包方法和装置 |
| CN113900671A (zh) * | 2020-06-22 | 2022-01-07 | 北京字节跳动网络技术有限公司 | 应用程序安装包的数据处理方法、装置及电子设备 |
| CN114356296A (zh) * | 2021-12-30 | 2022-04-15 | 上海米哈游璃月科技有限公司 | 资源打包方法、装置、电子设备及存储介质 |
| CN117369865A (zh) * | 2023-12-07 | 2024-01-09 | 麒麟软件有限公司 | 一种GNU linux通用的应用程序打包方法及图形化应用打包器 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104539725A (zh) * | 2015-01-15 | 2015-04-22 | 北京金和软件股份有限公司 | 一种对生成的app应用进行集群打包的方法 |
| CN107015820A (zh) * | 2016-01-27 | 2017-08-04 | 阿里巴巴集团控股有限公司 | 应用启动方法、装置及服务器 |
| CN107580049A (zh) * | 2017-09-05 | 2018-01-12 | 同程网络科技股份有限公司 | 一种可扩展的高效app渠道包打包平台 |
| CN107704238A (zh) * | 2017-11-28 | 2018-02-16 | 广州市千钧网络科技有限公司 | 一种对项目进行打包的方法及装置 |
-
2018
- 2018-04-08 CN CN201810307543.6A patent/CN110347398A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104539725A (zh) * | 2015-01-15 | 2015-04-22 | 北京金和软件股份有限公司 | 一种对生成的app应用进行集群打包的方法 |
| CN107015820A (zh) * | 2016-01-27 | 2017-08-04 | 阿里巴巴集团控股有限公司 | 应用启动方法、装置及服务器 |
| CN107580049A (zh) * | 2017-09-05 | 2018-01-12 | 同程网络科技股份有限公司 | 一种可扩展的高效app渠道包打包平台 |
| CN107704238A (zh) * | 2017-11-28 | 2018-02-16 | 广州市千钧网络科技有限公司 | 一种对项目进行打包的方法及装置 |
Cited By (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110825391A (zh) * | 2019-10-31 | 2020-02-21 | 北京金山云网络技术有限公司 | 服务管理方法、装置、电子设备及存储介质 |
| CN110825391B (zh) * | 2019-10-31 | 2023-10-13 | 北京金山云网络技术有限公司 | 服务管理方法、装置、电子设备及存储介质 |
| CN111158741A (zh) * | 2019-12-23 | 2020-05-15 | 北京五八信息技术有限公司 | 监控业务模块对第三方类库依赖关系变化的方法及装置 |
| CN111158741B (zh) * | 2019-12-23 | 2024-04-12 | 北京五八信息技术有限公司 | 监控业务模块对第三方类库依赖关系变化的方法及装置 |
| CN113535220A (zh) * | 2020-04-15 | 2021-10-22 | 北京京东振世信息技术有限公司 | 一种代码包管理方法和装置 |
| CN113535220B (zh) * | 2020-04-15 | 2023-11-03 | 北京京东振世信息技术有限公司 | 一种代码包管理方法和装置 |
| CN113741951A (zh) * | 2020-05-29 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 本地打包方法和装置 |
| CN111694402B (zh) * | 2020-06-11 | 2021-10-01 | 翱捷科技股份有限公司 | 单芯片异构系统的控制方法和可穿戴设备 |
| CN111694402A (zh) * | 2020-06-11 | 2020-09-22 | 翱捷科技(上海)有限公司 | 单芯片异构系统的控制方法和可穿戴设备 |
| CN113900671A (zh) * | 2020-06-22 | 2022-01-07 | 北京字节跳动网络技术有限公司 | 应用程序安装包的数据处理方法、装置及电子设备 |
| CN111796861A (zh) * | 2020-06-28 | 2020-10-20 | 上海米哈游天命科技有限公司 | 一种打包方法、装置、电子设备及存储介质 |
| CN112445500A (zh) * | 2020-11-30 | 2021-03-05 | 北京达佳互联信息技术有限公司 | 应用程序处理方法、应用程序运行方法及相关设备 |
| CN112433950A (zh) * | 2020-11-30 | 2021-03-02 | 天津五八到家货运服务有限公司 | 自动搭建测试环境的方法、电子设备及存储介质 |
| CN113377376A (zh) * | 2021-06-09 | 2021-09-10 | 中国工商银行股份有限公司 | 数据包生成方法、数据包生成装置、电子设备及存储介质 |
| CN114356296A (zh) * | 2021-12-30 | 2022-04-15 | 上海米哈游璃月科技有限公司 | 资源打包方法、装置、电子设备及存储介质 |
| CN117369865A (zh) * | 2023-12-07 | 2024-01-09 | 麒麟软件有限公司 | 一种GNU linux通用的应用程序打包方法及图形化应用打包器 |
| CN117369865B (zh) * | 2023-12-07 | 2024-04-05 | 麒麟软件有限公司 | 一种GNU linux通用的应用程序打包方法及图形化应用打包器 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110347398A (zh) | 一种应用程序的打包方法和装置 | |
| CN109088764A (zh) | 访问请求处理方法及相关设备 | |
| CN104424199A (zh) | 搜索方法和装置 | |
| CN104572689A (zh) | 数据同步方法、装置及系统 | |
| Shukla et al. | A multiphase pre-copy strategy for the virtual machine migration in cloud | |
| US8843632B2 (en) | Allocation of resources between web services in a composite service | |
| CN101382958A (zh) | 网页加载方法和网页加载装置 | |
| CN110507986B (zh) | 动画信息的处理方法和装置 | |
| CN106656920B (zh) | Http服务的处理方法、装置、存储介质及处理器 | |
| CN106909595B (zh) | 一种数据迁移方法及装置 | |
| CN110286917A (zh) | 文件打包方法、装置、设备及存储介质 | |
| CN104168250B (zh) | 基于cgi框架的业务流程控制方法及装置 | |
| Pande et al. | Enhanced web application and browsing performance through service-worker infusion framework | |
| CA3167981C (en) | Offloading statistics collection | |
| CN109800005A (zh) | 一种客户端热更新方法及装置 | |
| CN114691148A (zh) | 模型推理加速方法、装置、电子设备及存储介质 | |
| CN110287444B (zh) | 网站检测方法、装置及存储介质 | |
| Schirmer et al. | Fusionize: Improving serverless application performance through feedback-driven function fusion | |
| JP2017033117A (ja) | クラスタ内リソース管理システム、クラスタ内リソース管理方法、管理サーバ及びプログラム | |
| CN114047949A (zh) | 一种应用系统国产平台迁移适配方法 | |
| CN111611479A (zh) | 用于网络资源推荐的数据处理方法及相关装置 | |
| CN116302328A (zh) | 智能合约数据处理方法和系统 | |
| CN111753226A (zh) | 一种页面加载方法和装置 | |
| US20220382689A1 (en) | Forwarding incoming io to scm namespaces | |
| CN115186214A (zh) | 页面配置方法、装置、计算机设备及计算机可读存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |