本发明涉及计算机技术领域，更具体地，涉及一种应用程序签名方法及装置。
背景技术：
随着移动终端的普及及应用程序的种类越来越多，移动终端上安装的应用程序越来越多。由于应用程序必须要经过数字签名才能够安装到android系统中，从而如何对应用程序签名是个关键问题。现有的应用程序签名方法主要是有两种：第一种、通过在电脑端安装androidstudio开发工具，并且配套有所有的安装环境。第二种、通过命令行进行签名。
在实现本发明的过程中，发现现有技术至少存在以下问题：在第一种签名方法中，签名过程条件要求比较苛刻，且在androidstudio中进行签名时需要设置很多比较复杂的步骤。在第二种签名方法中，由于是通过命令行进行签名，没有统一的界面交互，应用程序的开发者需要对命令行很熟悉才行，即对签名者的要求较高。综上，对应用程序签名时难度较高、效率较低。
技术实现要素：
本发明提供一种克服上述问题或者至少部分地解决上述问题的方法及装置。
根据本发明的一方面，提供了一种应用程序签名方法，该方法包括：
获取用户登陆时的用户信息；
检测本地是否存储所述用户信息对应的签名文件；
当本地未存储所述用户信息对应的签名文件时，向服务器发送签名文件获取请求；
当所述服务器存储有所述用户信息对应的签名文件时，获取所述用户信息对应的签名文件及对应的密码信息；
基于所述签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。
根据本发明的另一方面，提供了一种应用程序签名装置，该装置包括：
第一获取模块，用于获取用户登陆时的用户信息；
检测模块，用于检测本地是否存储所述用户信息对应的签名文件；
发送模块，用于当本地未存储所述用户信息对应的签名文件时，向服务器发送签名文件获取请求；
第二获取模块，用于当所述服务器存储有所述用户信息对应的签名文件时，获取所述用户信息对应的签名文件及对应的密码信息；
签名模块，用于基于所述签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。
本申请提出的技术方案带来的有益效果是：
通过获取用户登陆时的用户信息，检测本地是否存储所述用户信息对应的签名文件。当本地未存储所述用户信息对应的签名文件时，向服务器发送签名文件获取请求，当所述服务器存储有所述用户信息对应的签名文件时，获取所述用户信息对应的签名文件及对应的密码信息。基于所述签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。由于对整个签名过程进行了封装，用户只需进行登陆等其它简单操作便可对应用程序进行签名，从而使得签名过程较简单，签名效率较高。另外，由于将签名文件及对应的密码信息备份至服务器，从而提高了签名文件及密码信息的安全性。最后，通过对签名的应用程序进行对齐优化，能够以空间换时间的方式来提高应用程序执行效率。
附图说明
图1为本发明实施例的一种应用程序签名方法的流程示意图；
图2为本发明实施例的一种应用程序签名方法的流程示意图；
图3为本发明实施例的一种应用程序签名装置的结构示意图。
具体实施方式
下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。
随着移动终端的普及及应用程序的种类越来越多，移动终端上安装的应用程序越来越多。android通过数字签名来标识应用程序的作者和在应用程序之间建立信任关系，而非决定最终用户可以安装哪些应用程序。这个数字签名由应用程序的作者完成，并不需要权威的数字签名机构认证，它只是用来让应用程序包自我认证的。
应用程序通过使用数字签名，有如下优势：
1、有利于程序升级
当新版程序和旧版程序的数字签名相同时，android系统才会认为这两个程序是同一个程序的不同版本。如果新版程序和旧版程序的数字签名不相同，则android系统认为他们是不同的程序，并产生冲突，会要求新程序更改包名。
2、有利于程序的模块化设计和开发。
android系统允许拥有同一个数字签名的程序运行在一个进程中，android程序会将他们视为同一个程序。所以开发者可以将自己的程序分模块开发，而用户只需要在需要的时候下载适当的模块。
3、可以通过权限(permission)的方式在多个程序间共享数据和代码。
android提供了基于数字签名的权限赋予机制，应用程序可以和其他的程序共享概功能或者数据给那那些与自己拥有相同数字签名的程序。如果某个权限(permission)的protectionlevel是signature，则这个权限就只能授予那些跟该权限所在的包拥有同一个数字签名的程序。
数字签名的有效期要包含应用程序的预计生命周期，一旦数字签名失效，持有过期数字签名的应用程序将不能正常升级。如果多个应用程序使用同一个数字签名，则该数字签名的有效期要包含所有程序的预计生命周期。因此，在进行数字签名时，需考虑数字证书的有效期。androidmarket强制要求所有应用程序数字签名的有效期要持续到2033年10月22日以后。
另外，数字签名需包含如下要点：
1、所有的应用程序都必须有数字证书，android系统不会安装一个没有数字证书的应用程序
2、android程序包使用的数字证书可以是自签名的，不需要一个权威的数字证书机构签名认证
3、如果要正式发布一个android，必须使用一个合适的私钥生成的数字证书来给程序签名，而不能使用adt插件或者ant工具生成的调试证书来发布。
4、数字证书都是有有效期的，android只是在应用程序安装的时候才会检查证书的有效期。如果程序已经安装在系统中，即使证书过期也不会影响程序的正常功能。
5、android使用标准的java工具keytoolandjarsigner来生成数字证书，并给应用程序包签名。
6、使用zipalign优化程序。
具体在进行签名时，无论是在模拟器上还是在实际的物理设备上，我们都知道android系统不会安装运行任何一款未经数字签名的应用程序。通常为了开发调试方便，在开发阶段我们会使用一个调试的签名文件来对应用程序进行签名操作。当应用程序需要正式发布的时候我们再对其使用正式签名文件来对其进行签名操作。根据应用程序签名的阶段，数字签名可分为如下两种模式：
1、调试模式(debugmode)：
在调试模式下，androidstudio开发工具为了方便开发人员调试的方便，会自动的使用debug密钥为应用程序签名，因此我们可以直接运行程序。这个过程是开发工具自己去处理的，主要目的是方便开发者调试的方便。
debug密钥：一个名为debug.keystore的文件
存放位置：c:\users\xxxx\.android\debug.keystore。其中，xxxx对应替换为自己操作系统的用户名。如果直接使用debug.keystore来签名有可能会引起下面的2个风险：
(1)debug签名的应用程序不能在androidmarket上架销售，它会强制你使用自己的签名；
(2)debug.keystore在不同的机器上所生成的可能都不一样，就意味着如果你换了机器进行应用程序版本升级，那么将会出现上面那种程序不能覆盖安装的问题。
对于上述情形，当开发的程序只有开发者自己使用，则不会产生什么问题。应用程序升级时，卸载再安装就可以了。但是当应用程序包含很多使用客户时，则会导致应用程序无法升级的问题。基于上述分析，我们可以发现应用程序一定要有自己的数字证书来签名。
2、发布模式(releasemode)
当要发布程序时，开发者就需要使用自己的数字证书给apk包签名。自己签名的证书需要自己去生成。
基于上述对应用签名的相关论述，可以得到如下结论：应用程序必须要经过数字签名才能够安装到android系统中。因此，如何对应用程序签名是个关键问题。现有的应用程序签名方法主要是有两种：第一种、通过在电脑端安装androidstudio开发工具，并且配套有所有的安装环境。第二种、通过命令行进行签名。
为了便于说明，在对本实施例及后续实施例进行阐述之前，先对各项术语进行解释。
androidstudio：androidstudio是一个基于intellijidea的android集成开发工具，该开发工具与eclipseadt类似。androidstudio提供了集成的android开发工具用于开发和调试。
androidmarket：android应用市场，主要功能是提供各种android的软件下载
debugmode：调试模式，主要用于开发阶段的一种模式。
releasemode：发布模式，主要是用于软件正式发布时的一种模式。
token：服务器返回到一个字符串，可以用于唯一标定一个用户。
md5：md5即message-digestalgorithm5(信息-摘要算法5)，用于确保信息传输完整一致。是计算机广泛使用的杂凑算法之一(又译摘要算法、哈希算法)，主流编程语言普遍已有md5实现。将数据(如汉字)运算为另一固定长度值，是杂凑算法的基础原理，md5的前身有md2、md3和md4。
jdk：jdk是java语言的软件开发工具包，主要用于移动设备、嵌入式设备上的java应用程序。jdk是整个java开发的核心，它包含了java的运行环境，java工具和java基础的类库。
keytool：keytool是个密钥和证书管理工具。它使用户能够管理自己的公钥/私钥对及相关证书，用于(通过数字签名)自我认证(用户向别的用户/服务认证自己)或数据完整性以及认证服务。它还允许用户储存他们的通信对等者的公钥(以证书形式)。
bat脚本：一种window平台的脚本文件
rsa：rsa公开密钥密码体制。所谓的公开密钥密码体制就是使用不同的加密密钥与解密密钥，是一种“由已知加密密钥推导出解密密钥在计算上是不可行的”密码体制。
基于上述内容，本实施例提供一种应用程序签名方法，该方法用于客户端。参见图1，该应用程序签名方法流程包括：101、获取用户登陆时的用户信息；102、检测本地是否存储签名用户信息对应的签名文件；103、当本地未存储签名用户信息对应的签名文件时，向服务器发送签名文件获取请求；104、当服务器存储有签名用户信息对应的签名文件时，获取签名用户信息对应的签名文件及对应的密码信息；105、基于签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。
本发明实施例提供的方法，通过获取用户登陆时的用户信息，检测本地是否存储签名用户信息对应的签名文件。当本地未存储签名用户信息对应的签名文件时，向服务器发送签名文件获取请求，当签名服务器存储有签名用户信息对应的签名文件时，获取签名用户信息对应的签名文件及对应的密码信息。基于签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。由于对整个签名过程进行了封装，用户只需进行登陆等其它简单操作便可对应用程序进行签名，从而使得签名过程较简单，签名效率较高。另外，由于将签名文件及对应的密码信息备份至服务器，从而提高了签名文件及密码信息的安全性。最后，通过对签名的应用程序进行对齐优化，能够以空间换时间的方式来提高应用程序执行效率。
作为一种可选实施例，签名获取签名用户信息对应的签名文件及对应的密码信息，包括：
接收签名服务器返回的下载地址及对应的密码信息；
根据签名下载地址下载对应的签名文件。
作为一种可选实施例，签名基于签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名之前，还包括：
接收签名服务器发送的md值；
通过签名md值，对签名文件进行校验。
作为一种可选实施例，签名基于签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名之前，还包括：
当签名服务器未存储签名用户信息对应的签名文件时，通过第二预设脚本自动生成签名文件；
获取用户输入的密码信息。
作为一种可选实施例，签名获取用户输入的密码信息之后，还包括：
将自动生成的签名文件及用户输入的密码信息备份至签名服务器。
上述所有可选技术方案，可以采用任意结合形成本发明的可选实施例，在此不再一一赘述。
基于上述图1对应的实施例所提供的内容，本发明实施例提供了一种应用程序签名方法，该方法用于客户端。参见图2，本实施例提供的方法流程包括：201、获取用户登陆时的用户信息；202、检测本地是否存储签名用户信息对应的签名文件；203、当本地未存储签名用户信息对应的签名文件时，向服务器发送签名文件获取请求；204、当签名服务器存储有签名用户信息对应的签名文件时，接收签名服务器返回的下载地址及密码信息；205、根据签名下载地址下载对应的签名文件；206、基于签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。
其中，201、获取用户登陆时的用户信息。
为了兼容多用户，本实施例提供了用户登陆机制，以保证用户信息与签名文件对应。用户在对应用程序签名之前，可先进行登陆，本实施例对此不作具体限定。如果用户没有用户名，此时可以注册一个用户名。用户登录流程和用户注册流程可参考当下通用过程，本实施例对此不作具体限定。
需要说明的是，之所以有用户登录这个过程，其核心目的是为了唯一标记一个用户，方便多用户签名对于不同用户进行区分。
另外，用户登录成功后，服务器可以为这个用户生成一个唯一的token码。该token码用于后期该用户和服务器进行交互时，唯一标识该用户。相应地，用户在与服务器进行交互时，可同时将token码发送至服务器，本实施例对此不作具体限定。如此，服务器就能够根据token码区分是哪一个用户发出的服务请求操作。
其中，202、检测本地是否存储签名用户信息对应的签名文件。
由于.net开发框架提供了一套io操作的函数集，这个集合中有一个函数可以用于判断某一个文件是否存在。基于上述内容，在本步骤中，可通过调用system.io.directory.exists这个函数来判断系统上签名文件是否存在，本实施例对此不作具体限定。
当签名文件存在时，system.io.directory.exists这个函数就会返回true值。当签名文件不存在时，system.io.directory.exists这个函数就会返回false值。
其中，203、当本地未存储签名用户信息对应的签名文件时，向服务器发送签名文件获取请求。
在本步骤中，客户端可通过http(hypertexttransferprotocol，超文本传输协议)与服务器进行通信。需要说明的是，由于服务器需要分辨出是哪一个用户发送的获取请求，从而用户在向服务器发送获取请求时，可携带上述步骤201中提到的token码，本实施例对此不作具体限定。
服务器接收到客户端发过来的请求后通过token码来找到对应的用户信息，然后去数据库查询是否存在该用户的签名文件。如果存在签名文件，服务器将返回签名文件的下载地址及对应的密码信息。
需要说明的是，当本地存储有签名用户信息对应的签名文件时，可基于本地存储的签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。
第一预设脚本在功能上与android开发工具中提供的一个工具jarsigner一样，即对应用程序进行签名。在本实施例中为了将签名过程与window程序进行分离，将分离出的签名过程单独编写成一个bat脚本文件，即第一预设脚本。该脚本文件的具体内容如下：
jarsigner-verbose-keypass888888-keystoreit-homer.keystore-signedjarnotepad_signed.apknotepad.apkit-homer.keystore
接下来对该第一预设脚本进行相关说明：
1、jarsigner是工具名称，-verbose表示将签名过程中的详细信息打印出来，显示在dos窗口中；
2、-keypass888888：设置签名密码为888888
3、keystoreit-homer.keystore表示签名所使用的数字证书所在位置，这里没有写路径，表示在当前目录下；
4、signedjarnotepad_signed.apknotepad.apk表示给notepad.apk文件签名，签名后的文件名称为notepad_signed.apk；
5、最后面的it-homer.keystore表示证书的别名，对应于生成数字证书时-alias参数后面的名称。
需要说明的是，上述脚本只是一个通用的模板文件。在使用过程中，window程序可修改其中的密码项目。在本实施例中，会先从文件中读取签名的密码信息，然后再将此脚本中-keystore的密码信息进行修改后再进行签名操作。
其中，204、当签名服务器存储有签名用户信息对应的签名文件时，接收签名服务器返回的下载地址及密码信息。
通过上述步骤203，服务器在返回下载地址及对应的密码信息之后，客户端可接收签名服务器返回的下载地址及密码信息。
其中，205、根据签名下载地址下载对应的签名文件。
客户端在接收到服务器返回的下载地址及密码信息后，可根据签名下载地址下载对应的签名文件。为了校验下载签名文件的正确性，服在上述步骤203中，服务器在返回下载地址的同时，还可以返回签名文件的md值，本实施例对此不作具体限定。相应地，客户端可接收签名服务器发送的md值。通过签名md值，对签名文件进行校验。由于windows系统提供了md5校验的接口函数，从而在本步骤中可调用system.security.cryptography.md5cryptoserviceprovider这个函数，将文件路径传入到此函数中，这个函数就能够返回md5的校验信息。将该函数返回的md5校验信息与服务器返回的md5值比对。当两者一致时，客户端可将签名文件与对应的密码信息保存至本地。当两者不一致时，客户端可根据下载地址重新下载签名文件，本实施例对此不作具体限定。
需要说明的是，由于服务器中可能没有存储该用户的签名文件，从而服务器可返回没有签名文件的信息给客户端。相应地，客户端可提示用户是否要生成签名文件，本实施例对此不作具体限定。具体地，当签名服务器未存储签名用户信息对应的签名文件时，通过第二预设脚本自动生成签名文件，获取用户输入的密码信息。
由于jdk开发套件中提供了一个生成秘钥的工具keytool，这个keytool工具的核心功能是能够生成一个签名文件。因此，可基于该工具，通过编写第二预设脚本让window应用程序调用该第二预设脚本来生成签名文件，本实施例对此不作具体限定。
第二预设脚本的具体内容如下：
keytool-genkey-aliasandroid.keystore-keyalgrsa-validity20000-keystoreandroid.keystore
接下来对该第二预设脚本进行相关说明：
1、-genkey：表示生成签名文件；
2、-alias：指定密钥对的别名，该别名是公开的；
3、android.keystore：别名名称，也就是最后生成的签名文件的名称；
4、-keyalg：指定加密算法，本例中的采用通用的ras加密算法；
5、rsa：rsa加密算法；
6、-validity：签名文件有效天数，此处设定的是20000天；
7、-keystore：密钥库的路径及名称，不指定的话，默认在操作系统的用户目录下生成一个".keystore"的文件。
如此通过上面的脚本命令即可生成一个签名文件。
相应地，windows调用脚本方法可如下：
在windows的系统api中有一个process类，这个类具有执行bat脚本命令的能力。此处可通过process类的构造函数，将脚本路径传递给process类的构造函数来进行初始化。
需要说明的是，process的初始化过程中会有一个配置是否启动窗口的选项，process.startinfo.createnowindow＝true。此处可将这个配置选项打开，也就是通过上面的代码对其进行初始化，这样process在执行脚本命令的时候就会弹出一个脚本执行窗口。这个窗口是后续输入密码所必须的窗口。因此，上述配置选项需要被打开，否者脚本将无法正确输入密码信息。
最后调用process中的start方法，windows系统就会自动去执行第二预设脚本。脚本执行后会弹出一个窗口，窗口中提示用户输入密码信息，用户可按照提示将密码输入即可。输入的密码信息是和生成的签名文件一一对应的，后面使用签名文件对应用程序进行签名时，会用到密码信息。在后续验证密码信息过程中，如果密码错误，会导致签名失败。
可选地，为了能够持久保存用户输入的密码信息，可将密码信息存储在文件中，本实施例对此不作具体限定。
另外，在自动生成签名文件及用户输入密码信息后，为了便于后续再次获取签名文件及密码信息，可将自动生成的签名文件及用户输入的密码信息备份至签名服务器，本实施例对此不作具体限定。如此以后用户无论在哪一台电脑上，都可以通过登陆的方式自动下载到对应的签名文件及密码信息。其中，签名文件和签名文件对应的密码信息可通过http协议中post方式进行上传，本实施例对此也不作具体限定。
206、基于签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。
本步骤签名过程可参考上述步骤203中的内容，此处不再赘述。另外，在对应用程序进行签名后，还可以对签名后的应用程序进行对齐优化，本实施例对此不作具体限定。具体地，android的sdk提供了一个工具zipalign，这个工具主要功能是优化apk的文件的，即将apk文件对齐。这种处理会使得android系统在执行apk的时候更快，提高apk的执行效率。
现对提高效率的过程进行分析：
在androidsdk中包含了一个工具名为zipalign，其可以优化apk程序包。由于apk的mime其实就是一个zip压缩文件，通过zipalign可以应用程序运行更快。
在android平台中，数据文件存储在apk文件中，可以多进程的访问。基于win32程序的粒度对齐问题，虽然不是pe格式的文件，在zip中一样，对资源进行访问时，可通过更好的对其优化(zipalign使用了4字节的边界对齐方式来影射内存)，从而通过空间换时间的方式提高执行效率。这个优化过程可通过bat脚本来实现的，即通过调用zipalign命令来对apk进行优化处理。
具体命令如下所示：
zipalign-v4source.apkdestination.apk
其中，-v代表详细输出，4代表对齐为4个字节。同时，-f参数如果添加则会覆盖存在的输出文件。通过上述脚本可生成对应的已优化好的apk文件destination.apk。
本发明实施例提供的方法，通过获取用户登陆时的用户信息，检测本地是否存储签名用户信息对应的签名文件。当本地未存储签名用户信息对应的签名文件时，向服务器发送签名文件获取请求，当签名服务器存储有签名用户信息对应的签名文件时，获取签名用户信息对应的签名文件及对应的密码信息。基于签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。由于对整个签名过程进行了封装，用户只需进行登陆等其它简单操作便可对应用程序进行签名，从而使得签名过程较简单，签名效率较高。另外，由于将签名文件及对应的密码信息备份至服务器，从而提高了签名文件及密码信息的安全性。最后，通过对签名的应用程序进行对齐优化，能够以空间换时间的方式来提高应用程序执行效率。
本发明实施例提供了一种应用程序签名装置，该装置用于执行上述图1或图2对应的实施例中所提供的应用程序签名方法。参见图3，该装置包括：
第一获取模块301，用于获取用户登陆时的用户信息；
检测模块302，用于检测本地是否存储签名用户信息对应的签名文件；
发送模块303，用于当本地未存储签名用户信息对应的签名文件时，向服务器发送签名文件获取请求；
第二获取模块304，用于当签名服务器存储有签名用户信息对应的签名文件时，获取签名用户信息对应的签名文件及对应的密码信息；
签名模块305，用于基于签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。
作为一种可选实施例，第二获取模块304，用于接收签名服务器返回的下载地址及对应的密码信息；根据签名下载地址下载对应的签名文件。
作为一种可选实施例，该装置还包括：
接收模块，用于接收签名服务器发送的md值；
校验模块，用于通过签名md值，对签名文件进行校验。
作为一种可选实施例，该装置还包括：
生成模块，用于当签名服务器未存储签名用户信息对应的签名文件时，通过第二预设脚本自动生成签名文件；
第三获取模块，用于获取用户输入的密码信息。
作为一种可选实施例，该装置还包括：
备份模块，用于将自动生成的签名文件及用户输入的密码信息备份至签名服务器。
本发明实施例提供的装置，通过获取用户登陆时的用户信息，检测本地是否存储签名用户信息对应的签名文件。当本地未存储签名用户信息对应的签名文件时，向服务器发送签名文件获取请求，当签名服务器存储有签名用户信息对应的签名文件时，获取签名用户信息对应的签名文件及对应的密码信息。基于签名文件及对应的密码信息，通过第一预设脚本对应用程序进行签名。由于对整个签名过程进行了封装，用户只需进行登陆等其它简单操作便可对应用程序进行签名，从而使得签名过程较简单，签名效率较高。另外，由于将签名文件及对应的密码信息备份至服务器，从而提高了签名文件及密码信息的安全性。最后，通过对签名的应用程序进行对齐优化，能够以空间换时间的方式来提高应用程序执行效率。
最后，本申请的方法仅为较佳的实施方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。