自动签名打包部署方法、装置、智能终端和存储介质与流程

1.本技术涉及计算机信息技术领域，尤其涉及一种自动签名打包部署方法、装置、智能终端和存储介质。


背景技术：

2.随着软件开发技术的发展，对软件的快速、高效、部署的要求也越来越高。目前，开发人员完成自身的开发任务之后，将完成的程序代码手动打包签名发送至测试人员，由测试人员对该打包后的程序代码进行测试。软件需要频繁的进行更新，涉及的更新代码规模或大或小，手动进行打包、签名等重复性操作，耗时耗力，不仅容易出错，且效率较低。


技术实现要素：

3.本技术实施例提供了一种自动签名打包部署方法、装置、智能终端和存储介质，可以解决现有技术中手动进行打包、签名等重复性操作，耗时耗力，容易出错且效率较低的技术问题。
4.第一方面，本技术实施例提供了一种自动签名打包部署方法，包括：
5.当检测到代码库有新提交的代码文件时，自动拉取所述新提交的代码文件；
6.对所述新提交的代码文件进行编译处理，生成可执行文件；
7.打包所述可执行文件，并调用预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名；
8.将签名后的安装包部署至待测试服务器。
9.在第一方面的一种可能的实现方式中，所述对所述新提交的代码文件进行编译处理，生成可执行文件，包括：
10.从指定路径拷贝依赖库，所述依赖库是指打包所述新提交的代码需依赖的库环境；
11.基于所述依赖库，对所述新提交的代码文件进行编译处理，生成可执行文件。
12.在第一方面的一种可能的实现方式中，所述对所述新提交的代码文件进行编译处理，生成可执行文件，包括：
13.对所述新提交的代码文件进行预处理，得到目标代码文件；
14.对所述目标代码文件进行编译，得到汇编代码文件；
15.对所述汇编代码文件进行处理，得到目标文件；
16.通过链接器将目标文件链接在一起，生成可执行文件。
17.在第一方面的一种可能的实现方式中，所述调用预设签名工具在打包过程中对所述可执行文件进行签名，包括：
18.获取目标目录以及所述目标目录的层次结构，所述目标目录为所述可执行文件的存储目录；
19.根据所述层次结构，逐层查找所述目标目录下的可执行文件，并对查找到的可执
行文件进行签名。
20.在第一方面的一种可能的实现方式中，所述调用预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名，包括：
21.读取所述预设签名工具的授权信息；
22.验证所述授权信息是否有效；
23.若有效，则调用所述预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名；
24.若所述授权信息无效，则提示自动签名失败。
25.在第一方面的一种可能的实现方式中，所述授权信息包括时间戳和密钥，所述验证所述授权信息是否有效，包括：
26.基于所述时间戳，验证所述授权信息是否已过期；
27.若未过期，验证所述密钥是否与云端密钥一致；
28.若一致，则确定所述授权信息有效。
29.第二方面，本技术实施例提供了一种自动签名打包部署装置，包括：
30.代码检测拉取单元，用于当检测到代码库有新提交的代码文件时，自动拉取所述新提交的代码文件；
31.编译处理单元，用于对所述新提交的代码文件进行编译处理，生成可执行文件；
32.打包签名单元，用于打包所述可执行文件，并调用预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名；
33.部署单元，用于将签名后的安装包部署至待测试服务器。
34.第三方面，本技术实施例提供了一种智能终端，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的自动签名打包部署方法。
35.第四方面，本技术实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的自动签名打包部署方法。
36.第五方面，本技术实施例提供了一种计算机程序产品，当计算机程序产品在智能终端上运行时，使智能终端执行如上述第一方面所述的自动签名打包部署方法。
37.本技术实施例中，通过当检测到代码库有新提交的代码文件时，自动拉取所述新提交的代码文件，对所述新提交的代码文件进行编译处理，生成可执行文件，然后打包所述可执行文件，并调用预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名，再将签名后的安装包部署至待测试服务器。本方案将打包签名自动化，无需人工手动打包及签名，不仅可节省人工避免打包出错遗漏，还可以大大提高打包签名的效率。
附图说明
38.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些
附图获得其他的附图。
39.图1是本技术实施例提供的自动签名打包部署方法的实现流程图；
40.图2是本技术实施例提供的自动签名打包部署方法中步骤s102的一种具体实现流程图；
41.图3是本技术实施例提供的自动签名打包部署方法中步骤s102的另一种具体实现流程图；
42.图4是本技术实施例提供的自动签名打包部署方法中调用预设签名工具在打包过程中对所述可执行文件进行签名的一种具体实现流程图；
43.图5是本技术实施例提供的自动签名打包部署方法中步骤s103的一种具体实现流程图；
44.图6是本技术实施例提供的自动签名打包部署方法中验证所述预设签名工具授权信息的一种具体实现流程图；
45.图7是本技术实施例提供的自动签名打包部署装置的结构框图；
46.图8是本技术实施例提供的智能终端的示意图。
具体实施方式
47.以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本技术实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本技术。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本技术的描述。
48.应当理解，当在本技术说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
49.还应当理解，在本技术说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
50.如在本技术说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
[0051]
另外，在本技术说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
[0052]
在本技术说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本技术的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
[0053]
图1示出了本技术实施例提供的自动签名打包部署方法的实现流程，在本技术实施例中，执行端为智能终端，该方法流程包括步骤s101至s104。各步骤的具体实现原理如
下：
[0054]
s101：当检测到代码库有新提交的代码文件时，自动拉取所述新提交的代码文件。
[0055]
本技术实施例中，通过jenkins检测代码库是否有新提交的代码文件，然后在检测到代码库有新提交的代码文件时，自动拉取该新提交的代码文件到编译服务器。上述新提交的代码文件是最终打包生成安装包所需要的代码文件。
[0056]
jenkins一个开源软件项目，是基于java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，实现软件的持续集成、持续交付和持续部署。
[0057]
在本技术实施例中，实时检测代码库是否新提交了代码文件，若检测到代码库有新提交的代码文件时，自动拉取新提交的代码文件进行后续处理，无需人工手动操作。
[0058]
在一种可能的实施方式中，定时检测代码库是否新提交了代码文件。例如，在指定时间内检测代码库是否新提交了代码文件。
[0059]
s102：对所述新提交的代码文件进行编译处理。
[0060]
本实施例中，在编译服务器对新提交的代码文件进行编译处理。
[0061]
作为本技术一种可能的实施方式，图2示出了本技术实施例提供的自动签名打包部署方法中步骤s102的一种具体实现流程，详述如下：
[0062]
a1：从指定路径拷贝依赖库，所述依赖库是指打包所述新提交的代码需依赖的库环境。所述指定路径用于标识预设存放依赖库的目录。将拷贝的依赖库存放至指定目录下。
[0063]
a2：基于所述依赖库，对所述新提交的代码文件进行编译处理，生成可执行文件。
[0064]
本技术实施例中，为有效进行编译处理，提前拷贝依赖库至指定目录，基于该依赖库对新提交的代码文件进行编译处理。
[0065]
在一些实施方式中，通过pipeline配置打包依赖的库环境的自动拷贝，将依赖库放在指定的目录下，然后通过脚本，在每次编译的时候，将相应的依赖库拷贝到编译目录下。pipeline是一套运行在jenkins上的工作流框架，将原本独立运行在单个或者多个节点的任务连接起来，实现单个任务难以完成的任务。
[0066]
由于自动编译机制每次编译完都需要清理本地的编译环境，在本技术实施例中，每次在检测到代码库有新提交的代码文件，自动拉取所述新提交的代码文件之后，调用脚本将依赖库拷贝至指定目录，实现依赖库自动拷贝。
[0067]
作为本技术一种可能的实施方式，图3示出了本技术实施例提供的自动签名打包部署方法中步骤s102的另一种具体实现流程，详述如下：
[0068]
b1：对所述新提交的代码文件进行预处理，得到目标代码文件。
[0069]
本实施例中，预处理相当于根据预处理指令组装新的c/c++程序。所述新提交的代码经过预处理，会产生一个没有宏定义，没有条件编译指令，没有特殊符号的输出文件，即为上述目标代码文件，该目标代码文件的含义同原本的文件无异，只是内容表达上有所不同。
[0070]
在一种实施方式中，读取所述新提交的代码文件，对其中的伪指令(以#开头的指令)进行处理，删除所有的注释，添加行号和文件名标识，以便于编译时编译器产生调试用的行号信息及用于编译时产生的编译错误或警告时能够显示行号；保留所有的#pragma编译器指令。
[0071]
其中，上述预处理的具体处理内容包括：
[0072]
①
将所有的“#define”删除，并且展开所有的宏定义；
[0073]
②
处理所有的条件编译指令，如：“#if”、“#ifdef”、“#elif”、“#else”、“endif”等。这些伪指令的引入使得程序员可以通过定义不同的宏来决定编译程序对哪些代码进行处理。预编译程序将根据有关的文件，将那些不必要的代码过滤掉。
[0074]
③
处理“#include”预编译指令，将被包含的文件插入到该预编译指令的位置。
[0075]
需说明的是，上述预处理过程可能是递归进行的，也就是说被包含的文件可能还包含其他文件。
[0076]
b2：对所述目标代码文件进行编译，得到汇编代码文件。
[0077]
本实施例中，将预处理完的文件进行一系列词法分析、语法分析、语义分析及优化后，产生相应的汇编代码文件。词法分析、语法分析、语义分析等具体算法参见现有技术，此处不赘述。
[0078]
b3：对所述汇编代码文件进行处理，得到目标文件。
[0079]
所述目标文件包括二进制文件和打包需要的中间文件。本实施例中，通过汇编器将编译完的汇编代码文件翻译成机器指令，并生成可重定位目标程序的.o文件，该.o文件为二进制文件，字节编码是机器指令。
[0080]
汇编器是将汇编代码转变成机器可以执行的指令，每一个汇编语句几乎都对应一条机器指令。所以汇编器的汇编过程相对于编译器来讲比较简单，它没有复杂的语法，也没有语义，也不需要做指令优化，只是根据汇编指令和机器指令的对照表一一翻译即可。
[0081]
b4：通过链接器将目标文件链接在一起，生成可执行文件。
[0082]
本技术实施例中，通过链接器将相关的目标文件链接在一起，生成可执行文件。
[0083]
由汇编程序生成的目标文件并不能立即就被执行，其中可能还有许多没有解决的问题。本实施例中，将生成的.obj文件与库文件.lib等文件链接，生成可执行文件(.exe文件)。例如，某个源文件中的函数可能引用了另一个源文件中定义的某个符号(如变量或者函数调用等)，在程序中可能调用了某个库文件中的函数，通过链接程序的处理方能得以解决。
[0084]
链接的主要工作就是将有关的目标文件彼此相连接，也就是将在一个文件中引用的符号同该符号在另外一个文件中的定义连接起来，使得所有的这些目标文件成为一个能够被操作系统装入执行的统一整体。
[0085]
s103：打包所述可执行文件，并调用预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名。
[0086]
本实施中，当检测到可执行文件的打包指令时，即触发预设签名工具的调用。在对编译处理后的文件进行打包的过程中，将编译处理后得到的可执行文件与打包所需的库文件进行打包，生成安装包。本技术实施例中，在打包的过程中自动调用预设签名工具对可执行文件进行签名，还调用预设签名工具对打包后生成的安装包进行签名。
[0087]
上述预设签名工具是预先编写的，用于为安装包以及安装包内可执行文件自动签名的工具。一种实施方式中，上述预设签名工具使用go语言编写。该预设签名工具中预先写入授权信息，所述授权信息包括数字签名证书的时间戳和密钥，该预设签名工具还预先写入调用系统签名工具signtool.exe的调用指令。
[0088]
本技术实施例中，jenkins在每次打包过程中都会调用预设签名工具对编译处理生成的可执行文件进行签名，以及对打包生成的安装包进行签名，实现自动签名，无需人工手动操作打包签名，不仅节省人工，还提高了打包效率。
[0089]
示例性地，在进入打包流程时，调用预设签名工具对编译处理后的可执行文件进行自动签名，然后对签名后的可执行文件进行打包，生成安装包，具体地，将签名后的可执行文件与打包所需的库文件一起打包，生成安装包。再调用预设签名工具对打包生成的安装包进行签名。
[0090]
本技术实施例中，在对编译处理后的文件进行打包的过程中，通过调用预设签名工具先对编译处理后得到的可执行文件(散包)进行签名，再对打包生成的安装包进行签名，无需人工手动对散包和安装包一一进行签名，节省人工，同时，可有效避免漏签。
[0091]
作为本技术一种可能的实施方式，图4示出了本技术实施例提供的自动签名打包部署方法中，调用预设签名工具在打包过程中对所述可执行文件进行签名的一种具体实现流程，详述如下：
[0092]
c1：获取目标目录以及所述目标目录的层次结构，所述目标目录为所述可执行文件的存储目录。
[0093]
在一种可能的实施方式中，获取项目信息，基于项目信息确定该项目中可执行文件的存储目录。其中，所述项目信息为预先配置的信息。
[0094]
c2：根据所述层次结构，逐层查找所述目标目录下的可执行文件，并对查找到的可执行文件进行签名。
[0095]
本实施例中，预设签名工具根据目标目录的层次结构，逐层遍历查找目标目录下编译处理后得到的可执行文件，在找到一个可执行文件后，将存在该可执行文件相同目标目录下的所有可执行文件都进行签名，无需人工一一查找签名，可有效提高签名效率。
[0096]
作为本技术一种可能的实施方式，图5示出了本技术实施例提供的自动签名打包部署方法步骤s103的另一种具体实现流程，详述如下：
[0097]
d1：读取所述预设签名工具的授权信息。
[0098]
所述授权信息包括数字签名证书的时间戳和密钥。所述时间戳用于指示所述授权信息的有效期。
[0099]
d2：验证所述授权信息是否有效。数字签名证书存在有效期。
[0100]
d3：若有效，则调用所述预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名。
[0101]
d4：若所述授权信息无效，则提示自动签名失败。进一步的，提示自动签名失败原因是授权信息无效。
[0102]
本技术实施例中，通过验证授权信息是否有效来确定是否可以对安装包进行签名，保障打包签名的有效性。
[0103]
作为本技术一种可能的实施方式，如图6所示，本技术实施例提供的自动签名打包部署方法中，上述验证所述授权信息是否有效的步骤，包括：
[0104]
d21：基于所述时间戳，验证所述授权信息是否已过期。一般地，所述授权信息存在有效期，获取当前系统的时间戳，将当前系统的时间戳与所述时间戳比较，若当前系统的时间戳在所述时间戳范围内，则可验证该授权信息未过期，若当前系统的时间戳不在所述时
间戳范围内，则可验证该授权信息已过期。
[0105]
d22：若未过期，验证所述密钥是否与云端密钥一致。所述云端密钥是指预先存储在云端服务器的密钥。
[0106]
d23：若一致，则确定所述授权信息有效。
[0107]
d24：若不一致，则确定所述授权信息无效。
[0108]
本实施例中，将所述授权信息中的密钥与云端密钥进行比对，判断是否一致，若一致，则验证该授权信息中的密钥正确，授权信息有效。若不一致，则验证该授权信息中的密钥错误，授权信息无效。
[0109]
s104：将签名后的安装包部署至待测试服务器。
[0110]
本实施例中，可通过pipeline直接将签名后的安装包发送到待测试的服务器上，以进行后续的测试。
[0111]
示例性地，以一个应用场景为例，基于jenkins拉取gitlab代码，过pipeline配置打包依赖的库环境的自动拷贝，自动拷贝依赖库环境，在依赖库环境下进行编译处理，调用预设签名工具对编译处理后得到的可执行文件以及打包所述可执行文件生成的安装包进行签名，实现打包签名自动化，再将签名好的安装包部署至指定的测试服务器。
[0112]
由上可见，本技术实施例中，通过当检测到代码库有新提交的代码文件时，自动拉取所述新提交的代码文件，对所述新提交的代码文件进行编译处理，生成可执行文件，然后打包所述可执行文件，并调用预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名，再将签名后的安装包部署至待测试服务器。本方案将打包签名自动化，无需人工手动打包及签名，不仅可节省人工避免打包出错遗漏，还可以大大提高打包签名的效率。
[0113]
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。
[0114]
对应于上文实施例所述的自动签名打包部署方法，图7示出了本技术实施例提供的自动签名打包部署装置的结构框图，为了便于说明，仅示出了与本技术实施例相关的部分。
[0115]
参照图7，该自动签名打包部署装置包括：代码检测拉取单元71，编译处理单元72，打包签名单元73，部署单元74，其中：
[0116]
代码检测拉取单元71，用于当检测到代码库有新提交的代码文件时，自动拉取所述新提交的代码文件；
[0117]
编译处理单元72，用于对所述新提交的代码文件进行编译处理，生成可执行文件；
[0118]
打包签名单元73，用于打包所述可执行文件，并调用预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名；
[0119]
部署单元74，用于将签名后的安装包部署至待测试服务器。
[0120]
作为本技术一种可能的实施方式，上述编译处理单元72包括：
[0121]
拷贝模块，用于从指定路径拷贝依赖库，所述依赖库是指打包所述新提交的代码需依赖的库环境；
[0122]
编译处理模块，用于基于所述依赖库，对所述新提交的代码文件进行编译处理，生
成可执行文件。
[0123]
作为本技术一种可能的实施方式，上述编译处理单元72包括：
[0124]
预处理模块，用于对所述新提交的代码文件进行预处理，得到目标代码文件；
[0125]
编译模块，用于对所述目标代码文件进行编译，得到汇编代码文件；
[0126]
汇编模块，用于对所述汇编代码文件进行处理，得到目标文件；
[0127]
链接模块，用于通过链接器将目标文件链接在一起，生成可执行文件。
[0128]
作为本技术一种可能的实施方式，上述打包签名单元73包括：
[0129]
存储信息获取模块，用于获取目标目录以及所述目标目录的层次结构，所述目标目录为所述可执行文件的存储目录；
[0130]
执行文件签名模块，用于根据所述层次结构，逐层查找所述目标目录下的可执行文件，并对查找到的可执行文件进行签名。
[0131]
作为本技术一种可能的实施方式，上述打包签名单元73包括：
[0132]
授权信息读取模块，用于读取所述预设签名工具的授权信息；
[0133]
授权信息验证模块，用于验证所述授权信息是否有效；若有效，则调用所述预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名；若所述授权信息无效，则提示自动签名失败。
[0134]
作为本技术一种可能的实施方式，上述授权信息验证模块具体用于：
[0135]
基于所述时间戳，验证所述授权信息是否已过期；
[0136]
若未过期，验证所述密钥是否与云端密钥一致；
[0137]
若一致，则确定所述授权信息有效。
[0138]
由上可见，本技术实施例中，通过当检测到代码库有新提交的代码文件时，自动拉取所述新提交的代码文件，对所述新提交的代码文件进行编译处理，生成可执行文件，然后打包所述可执行文件，并调用预设签名工具在打包过程中对所述可执行文件进行签名，以及对打包生成的安装包进行签名，再将签名后的安装包部署至待测试服务器。本方案将打包签名自动化，无需人工手动打包及签名，不仅可节省人工避免打包出错遗漏，还可以大大提高打包签名的效率。
[0139]
需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本技术方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。
[0140]
本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如图1至图6表示的任意一种自动签名打包部署方法的步骤。
[0141]
本技术实施例还提供一种智能终端，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如图1至图6表示的任意一种自动签名打包部署方法的步骤。
[0142]
本技术实施例还提供一种计算机程序产品，当该计算机程序产品在智能终端上运行时，使得智能终端执行实现如图1至图6表示的任意一种自动签名打包部署方法的步骤。
[0143]
图8是本技术一实施例提供的智能终端的示意图。如图8所示，该实施例的智能终端8包括：处理器80、存储器81以及存储在所述存储器81中并可在所述处理器80上运行的计
算机程序82。所述处理器80执行所述计算机程序82时实现上述各个自动签名打包部署方法实施例中的步骤，例如图1所示的步骤s101至s104。或者，所述处理器80执行所述计算机程序82时实现上述各装置实施例中各模块/单元的功能，例如图7所示单元71至74的功能。
[0144]
示例性的，所述计算机程序82可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器81中，并由所述处理器80执行，以完成本技术。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段，该指令段用于描述所述计算机程序82在所述智能终端8中的执行过程。
[0145]
所述智能终端8可以为服务器。所述智能终端8可包括，但不仅限于，处理器80、存储器81。本领域技术人员可以理解，图8仅仅是智能终端8的示例，并不构成对智能终端8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述智能终端8还可以包括输入输出设备、网络接入设备、总线等。
[0146]
所述处理器80可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
[0147]
所述存储器81可以是所述智能终端8的内部存储单元，例如智能终端8的硬盘或内存。所述存储器81也可以是所述智能终端8的外部存储设备，例如所述智能终端8上配备的插接式硬盘，智能存储卡(smart media card,smc)，安全数字(secure digital,sd)卡，闪存卡(flash card)等。进一步地，所述存储器81还可以既包括所述智能终端8的内部存储单元也包括外部存储设备。所述存储器81用于存储所述计算机程序以及所述智能终端所需的其他程序和数据。所述存储器81还可以用于暂时地存储已经输出或者将要输出的数据。
[0148]
需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本技术方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。
[0149]
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0150]
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以
为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、电载波信号、电信信号以及软件分发介质。例如u盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。
[0151]
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
[0152]
以上所述实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。