Android Studio Instant Run的工作原理

Instant Run是Android Studio2.0以上版本引入的一個新特性，它可以顯著地減少應用編譯及部署的時間。

Instant Run是一個神奇的功能，為什麼這麼說呢？當第一次你點擊run或debug按鈕的時候，跟正常的編譯部署流程是一樣的；當你對代碼做了一些修改，然後再次點擊run或debug按鈕（這時旁邊會出現一個?標志），接下來就是見證奇跡的時候了，你甚至還沒來得及將注意力從Android Studio轉移到手機上來，應用已經編譯部署好了，這就是它的神奇之處。

接下來就是了解Instant Run的工作原理了，這裡有一個官方視頻連接：Instant Run:An Android Tool Time Deep Dive，有興趣的朋友可以直接點開看。

Instant Run的特點

上圖為應用程序一般的編譯和部署過程：

1. 編譯

2. 部署安裝

3. App啟動

4. Activity啟動

經過以上幾個步驟之後才能看到代碼修改的效果。

對比通用的編譯部署過程，Instant Run的目標就很清晰了：

1. 盡可能去掉上述過程中不必要的步驟

2. 讓剩下的必要步驟越快越好

上述兩點在實際中表現為：

• 僅對增量和變化做編譯和部署

• 盡量不要重新安裝App

• 盡量不要重啟App

• 甚至不要重啟Activity

Instant Run = Incremental build + Hot, Warm, or Cold swap

這裡寫圖片描述

由上圖可知，Instant Run可以理解為增量編譯和部署（分為Hot Swap、Warm Swap和Cold Swap三種方式）。

Hot Swap:此種方式不需要重啟App，甚至不需要重啟Activity就能看到代碼修改引起的變化，一般適用於某個方法實現中的微小改動，如Toast或某個String字串的內容修改。

Warm Swap:此種方式需要重啟Activity才能看到修改導致的變化，經常用於資源相關的代碼改變。

Cold Swap:此種方式需要App重啟，但並不需要App重新安裝，適用於結構性的代碼修改如繼承關系或方法簽名改變。

正常的構建流程

Manifest文件會被合並，然後與資源文件一起被AAPT工具打包；同時java文件也被編譯為字節碼，然後轉成dex文件，最終上述文件一起打包成APK。

使用Instant Run的構建流程

字節碼被添加到.class文件中，同時一個appserver類被注入到APK中。

另外還會添加一個新的Application類定義，它用來注入自定義的類加載器用來調起App Server，因此Manifest也會被修改以便可以使用它。如果你已創建了自己的Application類，Instant Run將會使用新的來代理你的Application。

現在Instant Run就跑起來了，所以當你修改了部分代碼，然後再次點擊run或者debug時，Instant Run將會使用Hot Swap、Warm Swap或者Cold Swap盡可能地縮短原來的構建過程。

Hot Swapping

在開發過程中，Android Studio會監控哪些文件發生了變化，並使用Gradle工具為那些變化的class文件生成dex文件。

這些新的dex文件被Android Studio挑選出來然後部署到我們應用上的App Server上。

由於原始版本的class文件已經存在於運行的App中，Gradle可以高效地將更新的文件替換掉以前的舊文件，這些新文件可以被App Server使用自定義的類加載器加載。

隨後，每次當應用中的一個方法被調用時，App Server會跟原始文件通信來檢查他們是否被更新了。如果是的話，更新文件中的修改過的新方法會被委托來執行。

如上圖，如果你設了斷點你將會看到被覆蓋的方法的調用棧情況。

對於方法實現的微小改變，使用重定向方法的方式可以很好地工作，但是某些需要Activity重啟才能加載的情況又如何呢？

Warm Swapping

Warm Swap會重啟Activity，資源會在Activity啟動時加載，因此對資源的修改會要求重啟Activity來實現資源的重新加載。

目前，對資源的任何修改將會導致資源重新打包與部署到App，Android Studio的技術人員也在研究資源的增量打包與部署技術。

需要注意的是當Manifest中引用的資源被修改時，或者Manifest文件本身被修改了，Warm Swap並不能工作，因為Manifest中的配置信息是在APK被安裝時讀取的。對Manifest的修改或其引用到的資源的修改將會觸發完整的編譯和部署流程。

不幸的是，重啟Activity並不能應用於結構變化。添加、刪除或者修改注記、靜態或實例方法簽名，或者修改父類、靜態初始化邏輯都將需要Cold Swap方式。

Cold Swapping

應用被部署時會被分割為多個部分，每一部分都有自己的dex文件，class文件根據它們的包名被分配到不同的部分。當使用Cold Swap部署時，一個修改過的類必須與其在同一dex中的其他類一起重新生成dex，然後才能部署到目標設備。

這種方式依賴於multidex機制，僅在Android5.0(API level 21)或更高設備上才支持。

對於低於API level 20的設備而言，使用的是Dalvik模式，因此不支持Instant Run，則會執行完整的APK安裝過程。

Instant Run很聰明，但它不能回退

由於Hot Swap和Warm Swap不會重啟應用，因此修改某些在應用啟動時才會初始化的代碼時，必須重啟App才能看到對應的效果。

其他

Instant Run是由Android Studio控制的，因此要從IDE中啟動run或debug，而不是從手機設備中啟動或重啟應用。

Instant Run目前僅在主線程上支持的最好，因此如果應用使用了多線程，在其他線程上使用Hot Swap與Warm Swap將會降級為Cold Swap，如果API level小於21的話直接轉為完整構建與部署。

Instant Run也在不斷改進，Android Studio團隊也在開發新技術讓更多的情況可以支持Hot Swap，減少Cold Swap甚至完整構建，相信Android Studio後面的版本越來越好用。