不需要簽名的
生成apk最懶惰的方法是：
只要你執行過android專案，到工作目錄的bin資料夾下就能找到與專案同名的apk檔案，這種apk預設是已經使用debug使用者簽名的。
如果想要自己給apk簽名：
第二步：建立金鑰庫keystore,輸入金鑰庫匯出位置和密碼，記住密碼，下次Use existing keystore會用到。
第三步：填寫金鑰庫資訊，填寫一些apk檔案的密碼，使用期限和組織單位的資訊。
第四步：生成帶簽名的apk檔案，到此就結束了。
第五步：如果下次釋出版本的時候，使用前面生成的keystore再簽名。
第六步：Next,Next,結束！
方法三：使用IntelliJ IDEA匯出帶簽名的apk
方法步驟基本和Eclipse相同，大概操作路徑是：選單Tools->Andrdoid->Export signed apk。
4.簽名之後，用zipalign(壓縮對齊)最佳化你的APK檔案。
未簽名的apk不能使用，也不能最佳化。簽名之後的apk谷歌推薦使用zipalign.exe(位於android-sdk-windows\tools目錄下)工具對其最佳化：
D:\>zipalign -v 4 demo_signed.apk final.apk
如上，zipalign能夠使apk檔案中未壓縮的資料在4個位元組邊界上對齊（4個位元組是一個性能很好的值），這樣android系統就可以使用mmap()(請自行查閱這個函式的用途)函式讀取檔案，可以在讀取資源上獲得較高的效能，
PS:1.在4個位元組邊界上對齊的意思就是，一般來說，是指編譯器吧4個位元組作為一個單位來進行讀取的結果，這樣的話，CPU能夠對變數進行高效、快速的訪問（較之前不對齊）。
2.對齊的根源：android系統中的Davlik虛擬機器使用自己專有的格式DEX，DEX的結構是緊湊的，為了讓執行時的效能更好，可以進一步用"對齊"進一步最佳化，但是大小一般會有所增加。
5.簽名對你的App的影響。
你不可能只做一個APP，你可能有一個宏偉的戰略工程，想要在生活，服務，遊戲，系統各個領域都想插足的話，你不可能只做一個APP，谷歌建議你把你所有的APP都使用同一個簽名證書。
使用你自己的同一個簽名證書，就沒有人能夠覆蓋你的應用程式，即使包名相同，所以影響有：
1) App升級。 使用相同簽名的升級軟體可以正常覆蓋老版本的軟體，否則系統比較發現新版本的簽名證書和老版本的簽名證書不一致，不會允許新版本安裝成功的。
2) App模組化。android系統允許具有相同的App執行在同一個程序中，如果執行在同一個程序中，則他們相當於同一個App，但是你可以單獨對他們升級更新，這是一種App級別的模組化思路。
3) 允許程式碼和資料共享。android中提供了一個基於簽名的Permission標籤。透過允許的設定，我們可以實現對不同App之間的訪問和共享，如下：
AndroidManifest.xml：<permission android:protectionLevel="normal" />
其中protectionLevel標籤有4種值：normal(預設值),dangerous, signature,signatureOrSystem。簡單來說，normal是低風險的，所有的App不能訪問和共享此App。dangerous是高風險的，所有的App都能訪問和共享此App。signature是指具有相同簽名的App可以訪問和共享此App。signatureOrSystem是指系統image中App和具有相同簽名的App可以訪問和共享此App，谷歌建議不要使用這個選項，因為簽名就足夠了，一般這個許可會被用在在一個image中需要共享一些特定的功能的情況下。
不需要簽名的
生成apk最懶惰的方法是：
只要你執行過android專案，到工作目錄的bin資料夾下就能找到與專案同名的apk檔案，這種apk預設是已經使用debug使用者簽名的。
如果想要自己給apk簽名：
簽名的意義 為了保證每個應用程式開發商合法ID，防止部分開放商可能透過使用相同的Package Name來混淆替換已經安裝的程式，我們需要對我們釋出的APK檔案進行唯一簽名，保證我們每次釋出的版本的一致性(如自動更新不會因為版本不一致而無法安裝)。2.簽名的步驟 a.建立key b.使用步驟a中產生的key對apk簽名3.具體操作 方法一： 命令列下對apk簽名（原理） 建立key，需要用到keytool.exe (位於jdk1.6.0_24\jre\bin目錄下)，使用產生的key對apk簽名用到的是jarsigner.exe (位於jdk1.6.0_24\bin目錄下)，把上兩個軟體所在的目錄新增到環境變數path後，開啟cmd輸入D:\>keytool -genkey -alias demo.keystore -keyalg RSA -validity 40000 -keystore demo.keystore/*說明：-genkey 產生金鑰 -alias demo.keystore 別名 demo.keystore -keyalg RSA 使用RSA演算法對簽名加密 -validity 40000 有效期限4000天 -keystore demo.keystore */D:\>jarsigner -verbose -keystore demo.keystore -signedjar demo_signed.apk demo.apk demo.keystore/*說明：-verbose 輸出簽名的詳細資訊 -keystore demo.keystore 金鑰庫位置 -signedjar demor_signed.apk demo.apk demo.keystore 正式簽名，三個引數中依次為簽名後產生的檔案demo_signed，要簽名的檔案demo.apk和金鑰庫demo.keystore.*/ 注意事項：android工程的bin目錄下的demo.apk預設是已經使用debug使用者簽名的，所以不能使用上述步驟對此檔案再次簽名。正確步驟應該是:在工程點選右鍵->Anroid Tools-Export Unsigned Application Package匯出的apk採用上述步驟簽名。 方法二：使用Eclipse匯出帶簽名的apk Eclipse直接能匯出帶簽名的最終apk，非常方便，推薦使用，步驟如下： 第一步：匯出。第二步：建立金鑰庫keystore,輸入金鑰庫匯出位置和密碼，記住密碼，下次Use existing keystore會用到。
第三步：填寫金鑰庫資訊，填寫一些apk檔案的密碼，使用期限和組織單位的資訊。
第四步：生成帶簽名的apk檔案，到此就結束了。
第五步：如果下次釋出版本的時候，使用前面生成的keystore再簽名。
第六步：Next,Next,結束！
方法三：使用IntelliJ IDEA匯出帶簽名的apk
方法步驟基本和Eclipse相同，大概操作路徑是：選單Tools->Andrdoid->Export signed apk。
4.簽名之後，用zipalign(壓縮對齊)最佳化你的APK檔案。
未簽名的apk不能使用，也不能最佳化。簽名之後的apk谷歌推薦使用zipalign.exe(位於android-sdk-windows\tools目錄下)工具對其最佳化：
D:\>zipalign -v 4 demo_signed.apk final.apk
如上，zipalign能夠使apk檔案中未壓縮的資料在4個位元組邊界上對齊（4個位元組是一個性能很好的值），這樣android系統就可以使用mmap()(請自行查閱這個函式的用途)函式讀取檔案，可以在讀取資源上獲得較高的效能，
PS:1.在4個位元組邊界上對齊的意思就是，一般來說，是指編譯器吧4個位元組作為一個單位來進行讀取的結果，這樣的話，CPU能夠對變數進行高效、快速的訪問（較之前不對齊）。
2.對齊的根源：android系統中的Davlik虛擬機器使用自己專有的格式DEX，DEX的結構是緊湊的，為了讓執行時的效能更好，可以進一步用"對齊"進一步最佳化，但是大小一般會有所增加。
5.簽名對你的App的影響。
你不可能只做一個APP，你可能有一個宏偉的戰略工程，想要在生活，服務，遊戲，系統各個領域都想插足的話，你不可能只做一個APP，谷歌建議你把你所有的APP都使用同一個簽名證書。
使用你自己的同一個簽名證書，就沒有人能夠覆蓋你的應用程式，即使包名相同，所以影響有：
1) App升級。 使用相同簽名的升級軟體可以正常覆蓋老版本的軟體，否則系統比較發現新版本的簽名證書和老版本的簽名證書不一致，不會允許新版本安裝成功的。
2) App模組化。android系統允許具有相同的App執行在同一個程序中，如果執行在同一個程序中，則他們相當於同一個App，但是你可以單獨對他們升級更新，這是一種App級別的模組化思路。
3) 允許程式碼和資料共享。android中提供了一個基於簽名的Permission標籤。透過允許的設定，我們可以實現對不同App之間的訪問和共享，如下：
AndroidManifest.xml：<permission android:protectionLevel="normal" />
其中protectionLevel標籤有4種值：normal(預設值),dangerous, signature,signatureOrSystem。簡單來說，normal是低風險的，所有的App不能訪問和共享此App。dangerous是高風險的，所有的App都能訪問和共享此App。signature是指具有相同簽名的App可以訪問和共享此App。signatureOrSystem是指系統image中App和具有相同簽名的App可以訪問和共享此App，谷歌建議不要使用這個選項，因為簽名就足夠了，一般這個許可會被用在在一個image中需要共享一些特定的功能的情況下。