在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，享受即時編程。
參考資料
可以隨意轉發，也歡迎關注我的簡書，我會堅持給大家帶來分享。
