前言
签名，打包，发布作为一个APP面向市场的最后步骤，应该作为一个android开发者必须掌握的技能。难不成你的应该是留给自己玩的？
一、签名的优点
- 签名是开发者的身份标识，可以防止交易抵赖的发生；
- 防止开发商或个人混淆替换已经安装的程序，以保证签名不同的包不被替换；
- 保证应用的无缝持续升级，签名不同的应用不能覆盖升级；
- 利于应用的模块化开发部署和程序间数据共享；
- APK如果使用一个key签名，发布时另一个key签名的文件将无法安装或覆盖老的版本，这样可以防止你已安装的应用被恶意的第三方覆盖或替换掉；
- 避免一些第三方SDK，因为签名文件导致的无法使用，如微信；
二、签名的方式
2.1 方法1
本地Android开发的时候，默认使用的是debug版本，可以参考我的另一篇简书【eclipse修改签名替换debug.keystore】,里面有介绍使用debug签名的一些缺点，因此上传应用到一些应用市场的时候需要正式的release版本的签名文件。
以Android Studio工具为例：
打开AS的菜单栏，Build->Generate signed APK,将红色框框中的信息填写好。
上述文件是已经被建立好的签名文件，如果没有，可以在Generate Signed APK界面中新建一个，如下
生成以后，就按照上述的方式进行填写即可。
2.2 方法2
通过AS中的gradle进行配置可以达到自动打包的目的，效率更高。通过快捷键Ctrl+Alt+Shift+S，或者点击菜单栏File->Project Structure：
至此，即可完成签名配置，当然为了更加便捷的自动打包，我们还可以继续对gradle文件进行配置，如下新建一个type，默认的name是release，选中Signing Config，选择在Signing界面配置好的config，如上图。
到这一步，我们就有了包含debug和release两种版本的打包方式，可以根据需要自行选择。选中需要编译的工程文件，如app，选择即可。
现在，每次使用AndroidStudio构建发布版本时，工具将自动使用你指定的签名配置为APK文件进行签名。你可以在/app/build/outputs/apk/工程模块目录下找到已签名的APK文件。
注意：如果没有在Build Types里设置Signing Config文件，则AS会使用默认的debug版本的签名文件。
三、隐藏签名文件的敏感信息
如上述使用签名后，AS会在工程文件的build.gradle文件中，以代码的形式展示出来签名文件的详细信息，如图
如果将项目上传到github，可能会造成信息的泄漏。如何解决这一问题呢？
3.1 隐藏敏感信息
1）在项目根目录下新建一个文件，命名为：keystore.properties，输入刚才建立的签名文件中的信息，如下
storePassword=123456
keyPassword=123456
keyAlias=mytest
storeFile=F:/test.jks
2）在工程文件的build.gradle中添加如下代码
// Create a variable called keystorePropertiesFile, and initialize it to your
// keystore.properties file, in the rootProject folder.
def keystorePropertiesFile = rootProject.file("keystore.properties")
// Initialize a new Properties() object called keystoreProperties.
def keystoreProperties = new Properties()
// Load your keystore.properties file into the keystoreProperties object.
keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
注意其代码的位置，如图示
3）在build.gradle的android{}属性中，添加代码
android {
signingConfigs {
config {
keyAlias keystoreProperties['keyAlias']
keyPassword keystoreProperties['keyPassword']
storeFile file(keystoreProperties['storeFile'])
storePassword keystoreProperties['storePassword']
}
}
}
所有的敏感信息都被保存在了keystore.properties文件中了，保存好这个文件即可，不需要将它上传到github上。
四、通过设置Flavor实现不同的打包资源替换
在开发中，为了区别debug与release版本，也同时满足个性化的需求，如实现不同的应用市场的发布，如发布的APP的图片不同，适配不同的SDK版本等，logo不同，某些代码不同等，该如何去做呢？
4.1 设置Flavor
在AS中通过设置Flavor，译“风味”，即可实现个性化的发布需求。打开Project Structure，默认的flavor配置下图：
手动添加flavor，根据需求进行资源配置，如下图
看看根据需求，进行多次配置，重复以上步骤即可。
4.2 设置替换的资源
打开项目的根目录，/src/main，只有一个文件夹，
右击src,新建一个
会出现我们建立的flavor的文件选择，以debug为例
会默认建立java文件夹，在其中可以进行部分代码的更改操作，以完成个性化需求，当然我们也可以建立res、layout、values、mipmap文件等，以替换APP图标为例，
为避免与main文件夹下的ic_launcher名字重复，可以进行修改名称，图标，背景颜色等属性。
选择需要创建的资源目录，选择debug
成功创建后，如图
在不同的打包签名版本中切换编译，会出现以下的提示，签名更改了，需要重新安装。
为了在视觉上能够更直观的看到因为更改了flavor所带来的个性化的资源替换，在工程APP下build.gradle的buildTypes中添加如下代码：
buildTypes {
release {
// 这里的作用是选择是否混淆代码
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.config
/*这里是在 applicationId 中添加了一个后缀，其作用是在不改变默认程序包名的情况下，添加后缀，
当要区分debug和release的时候，添加后缀，则包名就会变成com.**.**.release
*/
applicationIdSuffix ".release"
}
debug {
signingConfig signingConfigs.config
applicationIdSuffix ".debug"
}
}
再次运行结果如下，注意在重新运行的时候，要在Build Varint中选择debug
