android1加到100的代碼

android是一個平臺，我編程語言還是用java

創(chuàng)新互聯(lián)是一家專注于網(wǎng)站設(shè)計制作、做網(wǎng)站與策劃設(shè)計,臥龍網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)10多年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:臥龍等地區(qū)。臥龍做網(wǎng)站價格咨詢:028-86922220

int i=0;

for(int j=1;j101;j++){

i=i+j;

}

最后循環(huán)結(jié)束之后i的值就是從1加到100的值

Android知識點(diǎn)解析（1）

Activity生命周期

什么是activity：提供給用戶交互的接口，實(shí)現(xiàn)點(diǎn)擊、滑動等操作的界面。

4種狀態(tài)：runningpausestoppedkilled

Activity啟動-onCreate()-onStart()-onResume() onResume()和onStart()均為前臺可見

點(diǎn)擊Home按鍵返回到主界面(Activity不可見)-onPause()-onStop()

當(dāng)再次回到原Activity時-onRestart()-onStart()-onResume()

退出當(dāng)前Activity時-onPause()-onStop()-onDestroy() Destroy：銷毀和資源回收

進(jìn)程優(yōu)先級（優(yōu)先級：高-----低）：前臺/可見/服務(wù)/后臺/空

任務(wù)棧（Task）

棧結(jié)構(gòu)：后進(jìn)先出 一個Task包含Activity的集合，通過Task管理每一個Activity，可以結(jié)合Activity的啟動模式去理解。實(shí)例：退出APP時，需要將Task種的Activity完全地移除，才能安全并且完全地退出應(yīng)用。一個APP當(dāng)中可能不止一個Task，但一個Activity可以獨(dú)享一個Task

啟動模式

1.Standard/標(biāo)準(zhǔn)模式：每啟動一個Activity，則不會考慮當(dāng)前Task中是否已經(jīng)存在Activity的實(shí)例，直接創(chuàng)建并放置棧頂，缺點(diǎn)是比較消耗資源。

2.SingleTop棧頂復(fù)用模式：如果棧頂存在當(dāng)前Activity的實(shí)例，則不去創(chuàng)建，直接復(fù)用棧頂?shù)腁ctivity。若不是，則創(chuàng)建。

3.SingleTask棧內(nèi)復(fù)用模式：單例，檢測整個任務(wù)棧是否存在Activity的實(shí)例，如果存在則移除銷毀實(shí)例以上的Activity，并回調(diào)onNewIntent()方法。

4.SingleInstance：ActivityA獨(dú)享一個Task，且App中有且只有一個ActivityA的實(shí)例。

Schema跳轉(zhuǎn)協(xié)議

頁面內(nèi)跳轉(zhuǎn)協(xié)議，通過定義自己的Schema協(xié)議，可以方便地跳轉(zhuǎn)到app的各個頁面。應(yīng)用場景：服務(wù)端可以定制化告訴App跳轉(zhuǎn)到相應(yīng)頁面；可以通過通知欄消息定制化跳轉(zhuǎn)頁面；通過H5頁面跳轉(zhuǎn)等

Android V1及V2簽名原理簡析

Android為了保證系統(tǒng)及應(yīng)用的安全性，在安裝APK的時候需要校驗(yàn)包的完整性，同時，對于覆蓋安裝的場景還要校驗(yàn)新舊是否匹配，這兩者都是通過Android簽名機(jī)制來進(jìn)行保證的，本文就簡單看下Android的簽名與校驗(yàn)原理，分一下幾個部分分析下：

簽名是摘要與非對稱密鑰加密相相結(jié)合的產(chǎn)物，摘要就像內(nèi)容的一個指紋信息，一旦內(nèi)容被篡改，摘要就會改變，簽名是摘要的加密結(jié)果，摘要改變，簽名也會失效。Android APK簽名也是這個道理，如果APK簽名跟內(nèi)容對應(yīng)不起來，Android系統(tǒng)就認(rèn)為APK內(nèi)容被篡改了，從而拒絕安裝，以保證系統(tǒng)的安全性。目前Android有三種簽名V1、V2（N）、V3（P），本文只看前兩種V1跟V2，對于V3的輪密先不考慮。先看下只有V1簽名后APK的樣式：

再看下只有V2簽名的APK包樣式：

同時具有V1 V2簽名：

可以看到，如果只有V2簽名，那么APK包內(nèi)容幾乎是沒有改動的，META_INF中不會有新增文件，按Google官方文檔：在使用v2簽名方案進(jìn)行簽名時，會在APK文件中插入一個APK簽名分塊，該分塊位于zip中央目錄部分之前并緊鄰該部分。在APK簽名分塊內(nèi)， 簽名和簽名者身份信息會存儲在APK簽名方案v2分塊中，保證整個APK文件不可修改 ，如下圖：

而V1簽名是通過META-INF中的三個文件保證簽名及信息的完整性：

V1簽名是如何保證信息的完整性呢？V1簽名主要包含三部分內(nèi)容，如果狹義上說簽名跟公鑰的話，僅僅在.rsa文件中，V1簽名的三個文件其實(shí)是一套機(jī)制，不能單單拿一個來說事，

如果對APK中的資源文件進(jìn)行了替換，那么該資源的摘要必定發(fā)生改變，如果沒有修改MANIFEST.MF中的信息，那么在安裝時候V1校驗(yàn)就會失敗，無法安裝，不過如果篡改文件的同時，也修改其MANIFEST.MF中的摘要值，那么MANIFEST.MF校驗(yàn)就可以繞過。

CERT.SF個人覺得有點(diǎn)像冗余，更像對文件完整性的二次保證，同繞過MANIFEST.MF一樣，.SF校驗(yàn)也很容易被繞過。

CERT.RSA與CERT.SF是相互對應(yīng)的，兩者名字前綴必須一致，不知道算不算一個無聊的標(biāo)準(zhǔn)?？聪翪ERT.RSA文件內(nèi)容：

CERT.RSA文件里面存儲了證書公鑰、過期日期、發(fā)行人、加密算法等信息，根據(jù)公鑰及加密算法，Android系統(tǒng)就能計算出CERT.SF的摘要信息，其嚴(yán)格的格式如下：

從CERT.RSA中，我們能獲的證書的指紋信息，在微信分享、第三方SDK申請的時候經(jīng)常用到，其實(shí)就是公鑰+開發(fā)者信息的一個簽名：

除了CERT.RSA文件，其余兩個簽名文件其實(shí)跟keystore沒什么關(guān)系，主要是文件自身的摘要及二次摘要，用不同的keystore進(jìn)行簽名，生成的MANIFEST.MF與CERT.SF都是一樣的，不同的只有CERT.RSA簽名文件。也就是說前兩者主要保證各個文件的完整性，CERT.RSA從整體上保證APK的來源及完整性，不過META_INF中的文件不在校驗(yàn)范圍中，這也是V1的一個缺點(diǎn)。V2簽名又是如何保證信息的完整性呢？

前面說過V1簽名中文件的完整性很容易被繞過，可以理解 單個文件完整性校驗(yàn)的意義并不是很大 ，安裝的時候反而耗時，不如采用更加簡單的便捷的校驗(yàn)方式。V2簽名就不針對單個文件校驗(yàn)了，而是 針對APK進(jìn)行校驗(yàn) ，將APK分成1M的塊，對每個塊計算值摘要，之后針對所有摘要進(jìn)行摘要，再利用摘要進(jìn)行簽名。

也就是說，V2摘要簽名分兩級，第一級是對APK文件的1、3 、4 部分進(jìn)行摘要，第二級是對第一級的摘要集合進(jìn)行摘要，然后利用秘鑰進(jìn)行簽名。安裝的時候，塊摘要可以并行處理，這樣可以提高校驗(yàn)速度。

APK是先摘要，再簽名，先看下摘要的定義：Message Digest：摘要是對消息數(shù)據(jù)執(zhí)行一個單向Hash，從而生成一個固定長度的Hash值，這個值就是消息摘要，至于常聽到的MD5、SHA1都是摘要算法的一種。理論上說，摘要一定會有碰撞，但只要保證有限長度內(nèi)碰撞率很低就可以，這樣就能利用摘要來保證消息的完整性，只要消息被篡改，摘要一定會發(fā)生改變。但是，如果消息跟摘要同時被修改，那就無從得知了。

而數(shù)字簽名是什么呢（公鑰數(shù)字簽名），利用非對稱加密技術(shù)，通過私鑰對摘要進(jìn)行加密，產(chǎn)生一個字符串，這個字符串+公鑰證書就可以看做消息的數(shù)字簽名，如RSA就是常用的非對稱加密算法。在沒有私鑰的前提下，非對稱加密算法能確保別人無法偽造簽名，因此數(shù)字簽名也是對發(fā)送者信息真實(shí)性的一個有效證明。不過由于Android的keystore證書是自簽名的，沒有第三方權(quán)威機(jī)構(gòu)認(rèn)證，用戶可以自行生成keystore，Android簽名方案無法保證APK不被二次簽名。

知道了摘要跟簽名的概念后，再來看看Android的簽名文件怎么來的？如何影響原來APK包？通過sdk中的apksign來對一個APK進(jìn)行簽名的命令如下：

其主要實(shí)現(xiàn)在 android/platform/tools/apksig 文件夾中，主體是ApkSigner.java的sign函數(shù)，函數(shù)比較長，分幾步分析

先來看這一步，ApkUtils.findZipSections，這個函數(shù)主要是解析APK文件，獲得ZIP格式的一些簡單信息，并返回一個ZipSections，

ZipSections包含了ZIP文件格式的一些信息，比如中央目錄信息、中央目錄結(jié)尾信息等，對比到zip文件格式如下：

獲取到 ZipSections之后，就可以進(jìn)一步解析APK這個ZIP包，繼續(xù)走后面的簽名流程，

可以看到先進(jìn)行了一個V2簽名的檢驗(yàn)，這里是用來簽名，為什么先檢驗(yàn)了一次？第一次簽名的時候會直接走這個異常邏輯分支，重復(fù)簽名的時候才能獲到取之前的V2簽名，懷疑這里獲取V2簽名的目的應(yīng)該是為了排除V2簽名，并獲取V2簽名以外的數(shù)據(jù)塊，因?yàn)楹灻旧聿荒鼙凰闳氲胶灻?，之后會解析中央目錄區(qū)，構(gòu)建一個DefaultApkSignerEngine用于簽名

先解析中央目錄區(qū)，獲取AndroidManifest文件，獲取minSdkVersion(影響簽名算法)，并構(gòu)建DefaultApkSignerEngine，默認(rèn)情況下V1 V2簽名都是打開的。

第五步與第六步的主要工作是：apk的預(yù)處理，包括目錄的一些排序之類的工作，應(yīng)該是為了更高效處理簽名，預(yù)處理結(jié)束后，就開始簽名流程，首先做的是V1簽名（默認(rèn)存在，除非主動關(guān)閉）：

步驟7、8、9都可以看做是V1簽名的處理邏輯，主要在V1SchemeSigner中處理，其中包括創(chuàng)建META-INFO文件夾下的一些簽名文件，更新中央目錄、更新中央目錄結(jié)尾等，流程不復(fù)雜，不在贅述，簡單流程就是：

這里特殊提一下重復(fù)簽名的問題： 對一個已經(jīng)V1簽名的APK再次V1簽名不會有任何問題 ，原理就是：再次簽名的時候，會排除之前的簽名文件。

可以看到目錄、META-INF文件夾下的文件、sf、rsa等結(jié)尾的文件都不會被V1簽名進(jìn)行處理，所以這里不用擔(dān)心多次簽名的問題。接下來就是處理V2簽名。

V2SchemeSigner處理V2簽名，邏輯比較清晰，直接對V1簽名過的APK進(jìn)行分塊摘要，再集合簽名，V2簽名不會改變之前V1簽名后的任何信息，簽名后，在中央目錄前添加V2簽名塊，并更新中央目錄結(jié)尾信息，因?yàn)閂2簽名后，中央目錄的偏移會再次改變：

簽名校驗(yàn)的過程可以看做簽名的逆向，只不過覆蓋安裝可能還要校驗(yàn)公鑰及證書信息一致，否則覆蓋安裝會失敗。簽名校驗(yàn)的入口在PackageManagerService的install里，安裝官方文檔，7.0以上的手機(jī)優(yōu)先檢測V2簽名，如果V2簽名不存在，再校驗(yàn)V1簽名，對于7.0以下的手機(jī)，不存在V2簽名校驗(yàn)機(jī)制，只會校驗(yàn)V1，所以，如果你的App的miniSdkVersion24(N)，那么你的簽名方式必須內(nèi)含V1簽名：

校驗(yàn)流程就是簽名的逆向，了解簽名流程即可，本文不求甚解，有興趣自己去分析，只是額外提下覆蓋安裝，覆蓋安裝除了檢驗(yàn)APK自己的完整性以外，還要校驗(yàn)證書是否一致只有證書一致（同一個keystore簽名），才有可能覆蓋升級。覆蓋安裝同全新安裝相比較多了幾個校驗(yàn)

這里只關(guān)心證書部分：

Android V1及V2簽名簽名原理簡析

僅供參考，歡迎指正