在Instant Run剛出來的時候，反編譯原始碼寫過一篇Instant Run原理解析，但過於基於原始碼，感覺沒有寫清楚，這周Android Developers推出了Instant Run: An Android Tool Time Deep Dive來講解Instant Run原理，既然是官方推出的，當然要重點看看，整理了一下，算是對Instant Run有了更全面的瞭解。

完整構建和部署

首先我們來看下沒有使用Instant Run，程式碼改變之後的完整構建和部署的流程

我們可以看到，在沒有Instant Run時，程式碼變更之後執行，需要構建Application，你的Mainfest檔案被合併，和資原始檔一起被打包到APK裡面，類似的，Java檔案被編譯成位元組碼，然後轉換成DEX檔案，最後部署App，重新啟動App，重新啟動Activity，最終變更的程式碼才能變執行。之間需要花費大量的時間，工程小還好，一旦大了就需要花費幾分鐘甚至幾十分鐘時間，嚴重影響了我們開發的效率和心情（最重要的是心情！），還能不能愉快地程式設計了！Google真是急人之所急，我們的救世主呀，在Android Studio 2.0之後就推出了Instant Run功能，看字面意思就知道是即時執行的意思，本著工程師探索原理的精神，讓我們一探究竟。

Instant Run分類

我們可以看到，和完整構建、停止、重新安裝和載入App相比，Instant Run 只增量構建和部署程式碼改變的部分，在很大程度上縮短構建和部署的時間。Instant Run有3種交換型別，分別是Hot Swap、Warm Swap和Cold Swap，Instant Run會根據改變程式碼的型別，自動決定使用哪種型別。

Instant Run如何工作

Instant Run構建

根據上圖，我們可以看到Instant Run構建流程，首先增加位元組碼到你的Class檔案，用來讓我們之後進行替換，然後增加一個新的App Server Class執行在之後你的App裡面，用來傳輸之後在執行期變化的程式碼，Gradle也會將修改Mainfest進行合併，讓我們執行實時程式碼的改變。

App Server執行

當你在Android Studio點選Run按鈕時，首先會檢測在你的App裡是否有一個開啟Socket埠的Server在執行，來確定Instant Run是否可用，在傳送變化的程式碼之前它也會檢測App構建的ID來確定是期望的版本，當你在開發過程中，Android Studio會監控哪些檔案已經被改變，執行一個自定義的Gradle Task為那些改變的class檔案建立一個DEX檔案，這個新的DEX檔案會被Android Studio部署到我們執行的App Server裡面，App Server接收到之後就會載入和部署被更新的classes，使用之前注入到我們原始類，委託方法來呼叫我們剛才載入覆蓋的新classes裡的方法。

Hot Swap

Hot Swap主要用於改變現有方法的實現程式碼導致的程式碼改變，這是最快的一種交換方式，不需要重啟App或者Activity，在你下一次呼叫方法時，新的實現就能被呼叫。

Warm Swap

Warm Swap主要用於修改或者刪除已經存在的資原始檔，這個交換仍然非常快，但需要重啟Activity，因為載入這些被影響的資源，重啟是必須的。雖然改變的所有資源都需要被重新打包，但我們是增量開發，可以只打包和部署已經改變的資源，不過和Mainfest相關的資源改變或者Mainfest自身的改變，Warm Swap不會有任何作用，那是因為從Mainfest裡面讀取值，在APK被安裝的時候就已經被確定下來，所以那些改變就需要重新安裝才能看到。從這裡我們就能看出來，Instant Run並不支援改變定義App名稱的字串或者App圖示。

Cold Swap

Cold Swap支援新增、移除、修改註釋、例項或者靜態欄位，例項或者靜態方法簽名、改變父類classes或者類靜態初始化。這種交換會慢一點，雖然不需要完整構建一個新的APK，但需要重啟Application。原理就是傳送有效程式碼的DEX檔案到指定裝置，通過App載入多個DEX來實現程式碼的改變，這就需要ART，所以Cold Swap只在Android 5.0及以上的裝置才有效，那些Android 5.0以下的裝置就需要部署一個完整的APK。

總結

到目前為止，我想大家已經理解了這3種交換型別的原理，也能瞭解其中的侷限性，做到知其然，知其所以然。最後祝大家利用好Instant Run，享受即時程式設計。