静态库打包方法、装置、计算机设备和存储介质与流程

[0001]
本申请涉及软件开发技术领域，特别是涉及一种静态库打包方法、装置、计算机设备和存储介质。


背景技术：

[0002]
随着移动端软件开发技术的发展，出现了越来越多的移动应用，而随着迭代的不断进行，很多应用会变得越来越庞大。由于对迭代速度的要求，应用开发者并没有足够的时间去反复的“造轮子”(指重新做一套已存在的功能)，可以去github等开源社区寻找已经封装好的静态库/源码，直接在自己的应用中使用；一些大型公司也可以组建自己的中台项目组，来给各个应用输送血液。
[0003]
目前，市面上主流的ios项目管理工具是cocoapods，很多组件开发团队基于cocoapods来批量管理自己的组件库，由于很多代码层面的内容不能全部开源，因此中台/组件开发者需要将自己编写的内容打包成静态库再发布出去。
[0004]
然而，目前官方提供的插件仅支持单一库的打包，对于多个组件并行开发测试，需要一个个的打包，存在打包效率低的问题。


技术实现要素：

[0005]
基于此，有必要针对上述技术问题，提供一种能够提高打包效率的静态库打包方法、装置、计算机设备和存储介质。
[0006]
一种静态库打包方法，所述方法包括：
[0007]
响应于打包指令，获取所述打包指令对应的指令配置信息；
[0008]
根据所述指令配置信息，确定各所述待打包库的代码文件和资源路径；
[0009]
对各所述待打包库的代码文件进行并行编译，生成对应的静态库；
[0010]
将各所述静态库以及根据各所述资源路径获取的资源进行整合，得到输出库。
[0011]
一种静态库打包装置，所述装置包括：
[0012]
获取模块，用于响应于打包指令，获取所述打包指令对应的指令配置信息；
[0013]
确定模块，用于根据所述指令配置信息，确定各待打包库的代码文件和资源路径；
[0014]
编译模块，用于对各所述待打包库的代码文件进行并行编译，生成对应的静态库；
[0015]
整合模块，用于将各所述静态库以及根据各所述资源路径获取的资源进行整合，得到输出库。
[0016]
一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
[0017]
响应于打包指令，获取所述打包指令对应的指令配置信息；
[0018]
根据所述指令配置信息，确定各所述待打包库的代码文件和资源路径；
[0019]
对各所述待打包库的代码文件进行并行编译，生成对应的静态库；
[0020]
将各所述静态库以及根据各所述资源路径获取的资源进行整合，得到输出库。
[0021]
一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
[0022]
响应于打包指令，获取所述打包指令对应的指令配置信息；
[0023]
根据所述指令配置信息，确定各所述待打包库的代码文件和资源路径；
[0024]
对各所述待打包库的代码文件进行并行编译，生成对应的静态库；
[0025]
将各所述静态库以及根据各所述资源路径获取的资源进行整合，得到输出库。
[0026]
上述静态库打包方法、装置、计算机设备和存储介质，响应于打包指令，获取打包指令对应的指令配置信息；根据指令配置信息，确定各待打包库的代码文件和资源路径；对各待打包库的代码文件进行并行编译，生成对应的静态库；将各静态库以及根据各资源路径获取的资源进行整合，得到输出库。据此，通过并行编译可以实现多静态库同时打包，解决传统技术中多静态库流程化打包导致的耗时问题，提高整体打包效率，同时提供了配置和定制化功能，具备较高的可复用性和可拓展性，开发人员可以基于打包需求配置指令信息，通过发起打包指令即可完成打包工作，无需关心如何去编译以及如何整合资源，实现一键式交付。
附图说明
[0027]
图1为一个实施例中静态库打包方法的应用环境图；
[0028]
图2为一个实施例中静态库打包方法的流程示意图；
[0029]
图3为一个实施例中传统编译过程的示意图；
[0030]
图4为一个实施例中并行编译过程的示意图；
[0031]
图5为一个实施例中对指令配置信息进行标准化的示意图；
[0032]
图6为一个实施例中podfile文件的示意图；
[0033]
图7为一个实施例中标准化后的podspec文件的示意图；
[0034]
图8为一个实施例中标准输出库的示意图；
[0035]
图9为一个实施例中打包前在工程中的文件结构示意图；
[0036]
图10为一个实施例中打包前在文件夹中的文件结构示意图；
[0037]
图11为一个实施例中打包后在文件夹中的文件结构示意图；
[0038]
图12为一个实施例中自定义转化脚本的示意图；
[0039]
图13为一个实施例中静态库打包方法的流程示意图；
[0040]
图14为一个实施例中静态库打包装置的结构框图；
[0041]
图15为一个实施例中计算机设备的内部结构图；
[0042]
图16为一个实施例中计算机设备的内部结构图。
具体实施方式
[0043]
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
[0044]
本申请提供的静态库打包方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信。开发人员可以通过终端102访问软件开发平台，服务器
104可以是该平台所在的服务器。静态库打包方法可以应用于安装有软件开发平台的终端，也可以应用于该平台所在的服务器，还可以应用于包括终端和服务器的系统，并通过终端和服务器的交互实现。其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。
[0045]
在一个实施例中，如图2所示，提供了一种静态库打包方法，以该方法应用于图1中的终端为例进行说明，包括以下步骤s202至步骤s208。
[0046]
s202，响应于打包指令，获取打包指令对应的指令配置信息。
[0047]
打包指令表示触发执行打包操作的指令，指令配置信息表示该打包操作中需执行的指令的详细信息。打包可以理解为将代码编译成静态库的过程，静态库可以理解为将源代码编译成的二进制文件包。在项目开发过程中，一个项目可以包含多个组件库，如登录组件、加密组件、推送组件、热修复组件、云指令组件等，很多组件是相互功能耦合的，通常会将所有的组件源码整合在一个工程中进行统一开发调试，交付时需要打包成静态库的方式来交付，因此需要对组件源码进行打包。
[0048]
在实施时，开发人员可以基于定制化打包需求设置指令配置信息，然后发起打包指令，终端在接收到打包指令后，结合指令配置信息自动执行打包流程，无需开发人员再人为参与。
[0049]
s204，根据指令配置信息，确定各待打包库的代码文件和资源路径。
[0050]
待打包库表示需要进行打包的组件库，待打包库可以是工程下的所有组件库，此时意味着进行全量打包，待打包库也可以是自定义的某几个组件库，此时意味者进行增量打包。代码文件和资源路径可以从待打包库的配置文件中获取，例如，在cocoapods工程中，利用podspec文件来配置组件库的配置信息，包括该组件库的文件、资源、依赖以及基本信息等。
[0051]
s206，对各待打包库的代码文件进行并行编译，生成对应的静态库。
[0052]
编译会把代码文件转化为二进制文件，这样可以方便交付而不会造成源码泄露。并行编译是指采取多线程的方式，对多个需要编译的库进行同步编译，无需等待前一个库编译完成后再进行下一个库编译，减少编译耗时。
[0053]
举例来说，在cocoapods工程中，基于xcode(开发工具)的命令行指令“xcodebuild”进行编译，传统的xcode仅能完成全量编译，如果只想编译其中几个库，需要经过长久的等待，如图3所示，示出了传统编译过程的示意图。本实施例在获取到需要编译的特定库后，利用多线程环境并发实现增量编译，如图4所示，示出了本实施例并行编译过程的示意图。此外，交付版本一般需要兼容4种架构：x86_64，i386，armv7s，arm64。传统的xcode编译需要全量编译两次：模拟器(x86_64，i386)+真机(armv7s，arm64)，而本实施例由于采取多线程的方式，仅需要并发的将整个流程一次性完成，从而可以极大的提高整体编译性能。
[0054]
s208，将各静态库以及根据各资源路径获取的资源进行整合，得到输出库。
[0055]
编译完成之后，对编译后的内容进行整合打包，得到最终的输出库。由于经过编译后，所有需要交付的资源可能散落在各个位置，因此可以根据前面步骤确定的资源路径获取资源，并将获取的资源进行批量拷贝和整合。
[0056]
上述静态库打包方法中，通过并行编译可以实现多静态库同时打包，解决传统技术中多静态库流程化打包导致的耗时问题，提高整体打包效率，同时提供了配置和定制化功能，具备较高的可复用性和可拓展性，开发人员可以基于打包需求配置指令信息，通过发起打包指令即可完成打包工作，无需关心如何去编译以及如何整合资源，实现一键式交付。
[0057]
在一个实施例中，根据指令配置信息，确定各待打包库的代码文件和资源路径的步骤，具体可以包括以下步骤：按照键值对形式对指令配置信息进行标准化，获得指令配置信息关联的键及其对应的值；根据指令配置信息关联的键及其对应的值，确定各待打包库的代码文件和资源路径。
[0058]
指令配置信息中具体可以包含待执行指令的指令符号，还可以包含指令符号对应的具体参数。获得指令配置信息后，可以先检查其是否合法，检查通过后，通过正则匹配来获取到其中每一个指令的详细信息并转换为更易读取的文件(如json文件)，并存储到本地。具体地，对指令配置信息进行键值对(key-value)形式标准化，获得指令配置信息关联的键(key)及其对应的值(value)。可以预先建立指令符号与键之间的映射关系，指令配置信息关联的键即指令配置信息中包含的指令符号对应的键。
[0059]
如图5所示，提供了一个实施例中对指令配置信息进行标准化的示意图，举例来说，开发人员输入的指令配置信息如下文所示：py package.py-s“targeta targetb
”-
w“xxx/xxxx
”-
l，其中，指令符号
“-
s”代表需增量打包的库名称，对应的key用“target”表示，-s“targeta targetb”经标准化后表示为“target:a,b”；指令符号
“-
w”代表工程路径，对应的key用“path”表示，-w“xxx/xxxx”经标准化后表示为“path:xxx/xxxx”；指令符号
“-
l”代表开启日志，对应的key用“logenable”表示，-l经标准化后表示为“logenable:true”。据此，开发人员通过输入相应的指令符号和参数即可完成指令输入，并且可以通过不同指令组合来定制化打包需求，在不修改代码的情况下实现个性化打包配置。
[0060]
本实施例中，通过对指令配置信息进行标准化，利用统一的数据格式作为各个环节的数据传输媒介，有利于快速提取所需信息，提高打包效率。
[0061]
在一个实施例中，根据指令配置信息关联的键及其对应的值，确定各待打包库的代码文件和资源路径的步骤，具体可以包括以下步骤：在指令配置信息关联的键中确定与待打包库标识相对应的第一键，根据第一键对应的值，确定各待打包库的标识；在指令配置信息关联的键中确定与待打包库路径相对应的第二键，根据第二键对应的值，确定各待打包库的路径；根据各待打包库的标识以及路径，获得各待打包库的代码文件和资源路径。
[0062]
待打包库标识用于指示哪些是需要进行打包的库。当指令配置信息中包含增量打包指令时，待打包库标识具体可以指待打包库名称，例如，前述实施例中的-s“targeta targetb”经标准化后表示为“target:a,b”，表示待打包库有两个，名称分别为“a”和“b”。当指令配置信息中包含全量打包指令时，待打包库标识具体可以指当前工程所有库的名称，例如，指令配置信息中包含代表全量打包的指令符号
“-
a”，经标准化后表示为“all:true”，表示待打包库为当前工程所有的库。
[0063]
待打包库路径用于指示从哪里可以获取到待打包库的文件信息。待打包库路径可
以是开发人员输入的路径，也可以是当前目录。当指令配置信息中包含输入路径指令时，待打包库路径具体可以指输入路径，例如，前述实施例中的-w“xxx/xxxx”经标准化后表示为“path:xxx/xxxx”，表示待打包库所在的代码仓库路径为“xxx/xxxx”，将该代码仓库路径作为各待打包库的路径。当指令配置信息中不存在输入路径指令时，待打包库路径具体可以指当前目录，将该当前目录位置作为各待打包库的路径。
[0064]
本实施例中，考虑到打包环境的多样性，提供了开发人员自定义打包输入路径的能力，使得开发人员可以通过特定指令指定打包的路径。此外，在获得输入路径后，还可以进行路径转化，将输入路径转化为绝对路径。举例来说，开发人员输入路径为“../demo/frameworks”，将该输入路径进行转化，得到的绝对路径为“/users/xxx/desktop/demo/tools/../demo/frameworks”。
[0065]
在一个实施例中，在根据指令配置信息关联的键及其对应的值，确定各待打包库的代码文件和资源路径之前，还包括以下步骤：当检测到指令配置信息关联的键中包含与代码更新指令相对应的第三键时，对各待打包库进行代码更新。
[0066]
代码更新指令用于指示进行代码更新，这是考虑到开发人员执行打包时，本地仓库代码可能并非最新代码，因此提供了代码更新指令。具体地，代码更新指令用指令符号
“-
o”表示，其对应的key用“pod”表示，当指令配置信息关联的键中包含“pod”，可认为检测到与代码更新指令相对应的第三键，并对各待打包库进行代码更新，具体可以通过cocoapods的内置指令“pod update”来更新代码。
[0067]
在一个实施例中，获得指令配置信息后，还可以对指令配置信息进行存储，以实现快速打包能力，下次通过直接读取历史指令配置信息，一键完成打包操作，适用于流水线流程。
[0068]
在一个实施例中，根据各待打包库的标识以及路径，获得各待打包库的代码文件和资源路径的步骤，包括可以包括以下步骤：根据各待打包库的标识以及路径，获得各待打包库的配置文件信息；按照键值对形式对各配置文件信息进行标准化，获得各配置文件信息关联的键及其对应的值；根据各配置文件信息关联的键及其对应的值，获得各待打包库的代码文件和资源路径。
[0069]
获得各待打包库的标识以及路径之后，可以获得各待打包库所在的代码仓库配置文件，在cocoapods工程中，利用podfile文件来配置代码仓库的配置信息，包括代码仓库中的所有库名称及路径索引等信息。如图6所示，提供了一个实施例中podfile文件的示意图，包含索引库等信息，这些索引库在cocoapods工程中以target的方式保存起来，可以采取cocoapods提供的ipc指令将podfile信息转化为更易读取的json文件，再提取podfile-json文件中的特定字段来获取所有的target信息，继而获得各待打包库的配置文件信息。
[0070]
在cocoapods工程中，利用podspec文件来配置组件库的配置信息，按照key-value形式对podspec文件信息进行解析转化，转化为更易读取的json文件，然后通过特定key提取所需的资源路径等重要信息。如图7所示，提供了一个实施例中标准化后的podspec文件的示意图，其中包含的vendored_libraries/frameworks/headers/resources等信息(包括依赖库、头文件、索引资源信息)表示打包后需要整合的内容。通过递归的遍历全部json文件并获取vendored_libraries/frameworks/headers/resources等特定key，将所有资源项整合在内存中的索引数组里。
[0071]
在一个实施例中，将各静态库以及根据各资源路径获取的资源进行整合，得到输出库的步骤，具体可以是按照标准化格式将各静态库以及根据各资源路径获取的资源进行整合，得到输出库。
[0072]
如图8所示，提供了一个实施例中标准输出库的示意图，其中包含以下内容：库配置(podspec)、协议(license)、头文件(headers)、二进制库(libraries)、库索引资源(resources)。经过编译后，所有的资源可能并非按照输出包的格式整合，而是散落在各个位置，因此，可以利用资源项对应的索引数组，通过正则匹配获得所有索引资源文件路径，对资源进行批量拷贝操作，保证资源自动整合到固定文件包中。图9-11示出了一个实施例中打包前后的文件结构变化示意图，其中，图9示出了一个实施例中打包前在工程中的文件结构示意图，图10示出了一个实施例中打包前在文件夹中的文件结构示意图，图11示出了一个实施例中打包后在文件夹中的文件结构示意图，图11对应图8的输出库结构，用于交付。
[0073]
在一个实施例中，在按照标准化格式将各静态库以及根据各资源路径获取的资源进行整合，得到输出库后，还包括以下步骤：当检测到自定义转化脚本时，执行自定义转化脚本，将标准化的输出库进行个性化转化。
[0074]
自定义转化脚本用于将标准化的输出库进行个性化转化，考虑到并非所有的输出库都需按照标准化的形式输出，因此本实施例支持个性化配置优化，如图12所示，提供了一个实施例中自定义转化脚本的示意图，通过嵌入式脚本的形式，在完成标准化打包后，再执行脚本指令，将标准化的输出库进行个性化转化，从而无需二次操作就可以完成流程化打包。
[0075]
在一个实施例中，当检测到指令配置信息关联的键中包含与输出路径相对应的第四键时，根据第四键对应的值，确定输出库的目标输出路径；在将各静态库以及根据各资源路径获取的资源进行整合，得到输出库后，将静态库的全部内容复制到目标输出路径。
[0076]
本实施例中，提供了开发人员自定义打包输出路径的能力，使得开发人员可以通过特定指令指定输出库的目标输出路径。具体地，使用指令符号
“-
e”代表输出路径，对应的key用“export”表示，当指令配置信息关联的键中包含“export”，可认为检测到与输出路径相对应的第四键。然后在整合得到输出库后，将输出库的所有内容复制到开发人员指定的输出路径，并发出提示信息，以提醒开发人员已完成输出库的输出。
[0077]
在一个实施例中，如图13所示，提供了一种应用于cocoapods工程的静态库打包方法，包括以下步骤s1301至步骤s1312。
[0078]
s1301，响应于打包指令，获取打包指令对应的指令配置信息。
[0079]
s1302，按照键值对形式对指令配置信息进行标准化，获得指令配置信息关联的键及其对应的值。
[0080]
s1303，判断指令配置信息关联的键中是否包含与代码更新指令相对应的第三键，若是，进入步骤s1304，若否，进入步骤s1305。
[0081]
s1304，执行pod update更新仓库代码。
[0082]
s1305，判断指令配置信息关联的键中是否包含与输入路径相对应的第二键，若是，进入步骤s1306，若否，进入步骤s1307。
[0083]
s1306，根据第二键对应的值确定输入路径，并根据输入路径转化为绝对路径。
[0084]
s1307，根据当前目录转化为绝对路径。
[0085]
s1308，判断指令配置信息关联的键中是否包含与全量打包指令相对应的键，若是，进入步骤s1309，若否，进入步骤s1310。
[0086]
s1309，解析podfile文件，查找全部的库target，解析所有库podspec文件，获取当前库的所有依赖资源。
[0087]
s1310，在指令配置信息关联的键中确定与增量打包指令相对应的第一键，根据第一键对应的值确定各待打包库的名称。
[0088]
s1311，解析podfile文件，根据各待打包库的名称查找对应的库target，解析对应的库podspec文件，获取各待打包库的所有依赖资源。
[0089]
s1312，多线程执行xcodebuild编译。
[0090]
s1313，按照标准化格式，对编译后内容和所有依赖资源进行整合，得到输出库。
[0091]
s1314，判断是否有自定义转化脚本，若是，进入步骤s1315，若否，进入步骤s1316。
[0092]
s1315，执行自定义转化脚本，将标准化格式的输出库转化为自定义格式的输出库。
[0093]
s1316，判断指令配置信息关联的键中是否包含与输出路径相对应的第四键，若是，进入步骤s1317。
[0094]
s1317，根据第四键对应的值确定目标输出路径，将输出库的全部内容复制到目标输出路径。
[0095]
关于步骤s1301～s1317的具体描述可以参见前文实施例，在此不再赘述。上述实施例提供一种使用简单、可定制化的一键式打包工具，提供了多种不同户指令来定制化打包需求，可以完成多静态库同时打包，可以在不修改代码的情况下个性化打包配置。此外，利用标准信息传递格式完成编译前的特定信息提取与存储，利用多线程优势对编译进行优化，压缩整个打包流程耗时，提高编译性能，对编译后的内容进行整合打包，可实现标准化或个性化输出。从而，从编译前到编译后，支撑起整合中台组件的编译打包流程，具备较高的可复用性和可扩展性，能够提高中台组件的开发、输出效率，也可应用到如蓝盾等流水线构建中，形成自动化流程。
[0096]
应该理解的是，虽然上述实施例涉及的各流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，上述实施例涉及的各流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
[0097]
在一个实施例中，如图14所示，提供了一种静态库打包装置1400，该装置可以采用软件模块或硬件模块，或者是二者的结合成为计算机设备的一部分，该装置具体包括：获取模块1410、确定模块1420、编译模块1430和整合模块1440，其中：
[0098]
获取模块1410，用于响应于打包指令，获取打包指令对应的指令配置信息。
[0099]
确定模块1420，用于根据指令配置信息，确定各待打包库的代码文件和资源路径。
[0100]
编译模块1430，用于对各待打包库的代码文件进行并行编译，生成对应的静态库。
[0101]
整合模块1440，用于将各静态库以及根据各资源路径获取的资源进行整合，得到输出库。
[0102]
在一个实施例中，确定模块1420在根据指令配置信息，确定各待打包库的代码文件和资源路径时，具体用于：按照键值对形式对指令配置信息进行标准化，获得指令配置信息关联的键及其对应的值；根据指令配置信息关联的键及其对应的值，确定各待打包库的代码文件和资源路径。
[0103]
在一个实施例中，确定模块1420在根据指令配置信息关联的键及其对应的值，确定各待打包库的代码文件和资源路径时，具体用于：在指令配置信息关联的键中确定与待打包库标识相对应的第一键，根据第一键对应的值，确定各待打包库的标识；在指令配置信息关联的键中确定与待打包库路径相对应的第二键，根据第二键对应的值，确定各待打包库的路径；根据各待打包库的标识以及路径，获得各待打包库的代码文件和资源路径。
[0104]
在一个实施例中，该装置还包括更新模块，用于当检测到指令配置信息关联的键中包含与代码更新指令相对应的第三键时，对各待打包库进行代码更新。
[0105]
在一个实施例中，确定模块1420在根据各待打包库的标识以及路径，获得各待打包库的代码文件和资源路径时，具体用于：根据各待打包库的标识以及路径，获得各待打包库的配置文件信息；按照键值对形式对各配置文件信息进行标准化，获得各配置文件信息关联的键及其对应的值；根据各配置文件信息关联的键及其对应的值，获得各待打包库的代码文件和资源路径。
[0106]
在一个实施例中，整合模块1440在将各静态库以及根据各资源路径获取的资源进行整合，得到输出库时，具体用于：按照标准化格式将各静态库以及根据各资源路径获取的资源进行整合，得到输出库。该装置还包括转化模块，用于当检测到自定义转化脚本时，执行自定义转化脚本，将标准化的输出库进行个性化转化。
[0107]
在一个实施例中，确定模块1420还用于当检测到指令配置信息关联的键中包含与输出路径相对应的第四键时，根据第四键对应的值，确定输出库的目标输出路径。该装置还包括定向输出模块，用于将输出库的全部内容复制到目标输出路径。
[0108]
关于静态库打包装置的具体限定可以参见上文中对于静态库打包方法的限定，在此不再赘述。上述静态库打包装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
[0109]
在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图15所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种静态库打包方法。
[0110]
在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图16所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的
存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过wifi、运营商网络、nfc(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种静态库打包方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
[0111]
本领域技术人员可以理解，图15或图16中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
[0112]
在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。
[0113]
在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
[0114]
在一个实施例中，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方法实施例中的步骤。
[0115]
需要理解的是，上述实施例中的术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。
[0116]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(read-only memory，rom)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(random access memory，ram)或外部高速缓冲存储器。作为说明而非局限，ram可以是多种形式，比如静态随机存取存储器(static random access memory，sram)或动态随机存取存储器(dynamic random access memory，dram)等。
[0117]
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
[0118]
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。