摘要：根據(jù)文件中的各個(gè)類(lèi)，計(jì)算出校驗(yàn)和，并臨時(shí)保存在主機(jī)的一個(gè)緩存數(shù)據(jù)庫(kù)中。通過(guò)對(duì)比新編譯的文件和之前的文件的校驗(yàn)和，可以在很短的時(shí)間內(nèi)找到更改過(guò)的類(lèi)。這次，它只獲取壓縮文件的，并保守估計(jì)相應(yīng)之間可能存在的差異。

原文地址：Android Studio Project Marble: Apply Changes
原文作者：Jon Tsao
譯文出自：掘金翻譯計(jì)劃
本文永久鏈接：github.com/xitu/gold-m…
譯者：qiuyuezhong
校對(duì)者：phxnirvana

Android Studio 團(tuán)隊(duì)有一系列深入探討 Project Marble 細(xì)節(jié)和幕后情況的文章，本文是其中的第一篇。從發(fā)布 Android Studio 3.3 開(kāi)始，Project Marble 就致力于保證 IDE 基本功能的穩(wěn)定性和流暢度。這篇文章是由 Apply Changes 團(tuán)隊(duì)的 Jon Tsao（產(chǎn)品經(jīng)理），Esteban de la Canal（技術(shù)負(fù)責(zé)人），F(xiàn)abien Sanglard（工程師）和 Alan Leung（工程師）共同完成。

Android Studio 的一個(gè)主要目標(biāo)是為你的 app 提供快速的代碼編輯和驗(yàn)證工具。當(dāng)我們創(chuàng)建 Instant Run 的時(shí)候，我們希望它能夠明顯加速你的開(kāi)發(fā)流程，但是現(xiàn)在看來(lái)它并沒(méi)有達(dá)到預(yù)期目標(biāo)。作為 Project Marble 的一部分，我們一直在重新思考 Instant Run，并提出了一個(gè)更實(shí)用的替代方案 Apply Changes。Apply Changes 作為一個(gè)可以加快開(kāi)發(fā)流程的新方法，最初在 Android Studio 3.5 的 Canary Channel 發(fā)布預(yù)覽。在這篇文章中，我們想深入聊聊它是如何工作的，以及迄今為止我們的工作。

通過(guò) Instant Run，我們想解決兩個(gè)問(wèn)題：1）節(jié)省構(gòu)建和部署應(yīng)用程序到設(shè)備上的時(shí)間，2）使應(yīng)用程序在不丟失運(yùn)行狀態(tài)的情況下部署更改。為了在 Instant Run 中做到這一點(diǎn)，我們?cè)跇?gòu)建的時(shí)候重寫(xiě)你的 APK 來(lái)注入鉤子，以便在運(yùn)行的時(shí)候進(jìn)行類(lèi)的替換。要更詳細(xì)的了解 Instant Run 背后的架構(gòu)，可以參考幾年前 Medium 上的這篇文章。

對(duì)于簡(jiǎn)單的 app，這個(gè)方案一般都表現(xiàn)很好，但是對(duì)于更復(fù)雜的 app 來(lái)說(shuō)，它可能會(huì)使構(gòu)建時(shí)間變長(zhǎng)，或者會(huì)由于 app 與 Instant Run 構(gòu)建過(guò)程之間有沖突而導(dǎo)致令人頭疼的錯(cuò)誤。隨著這些問(wèn)題的出現(xiàn)，我們?cè)诤罄m(xù)的版本中持續(xù)改進(jìn)提升 Instant Run。但是，我們無(wú)法完全解決這些問(wèn)題，讓它符合我們的期望。

我們后退了一步，決定從頭開(kāi)始構(gòu)建一個(gè)新的架構(gòu)，它就是 Apply Changes。和 Instant Run 不同，Apply Changes 不會(huì)在構(gòu)建的時(shí)候修改你的 APK。取而代之，我們用 Android 8.0（Oreo）上支持的 Runtime Instrumentation 以及更新的設(shè)備和模擬器在運(yùn)行時(shí)重定義類(lèi)。

對(duì)于運(yùn)行在 Android 8.0 或者更新版本上的設(shè)備和虛擬機(jī)，Android Studio 現(xiàn)在有三個(gè)按鈕來(lái)控制應(yīng)用程序重啟的程度：

Run 會(huì)部署所有的改動(dòng)并重啟應(yīng)用程序。

Apply Changes 會(huì)嘗試應(yīng)用資源和代碼的更改，并只重啟 Activity 而不是重啟應(yīng)用程序。

Apply Code Changes 會(huì)嘗試應(yīng)用代碼的更改，而不重啟任何東西。

通常只有方法體內(nèi)部的代碼更改才對(duì) Apply Changes 具有兼容性。

基于在 Instant Run 上的經(jīng)驗(yàn)和反饋，我們采用了一些原則來(lái)指導(dǎo)我們的架構(gòu)設(shè)計(jì)和決策：

將構(gòu)建/部署的速度和狀態(tài)丟失兩者獨(dú)立開(kāi)。我們想將節(jié)省構(gòu)建和部署的時(shí)間，與在不丟失運(yùn)行狀態(tài)的情況下部署更改這兩個(gè)目標(biāo)分開(kāi)。不管是一般的運(yùn)行或者調(diào)試，或者代碼的熱替換，快速構(gòu)建和部署應(yīng)該是所有部署類(lèi)型的目標(biāo)。作為構(gòu)建 Apply Changes 的一部分，我們發(fā)現(xiàn)了很多可以?xún)?yōu)化構(gòu)建和部署速度的領(lǐng)域，在后面的文章中，我們會(huì)詳細(xì)介紹它們。

穩(wěn)定性至關(guān)重要。即便在 100 次中這個(gè)功能以極快的速度運(yùn)行了 99 次，如果你的 app 因?yàn)檫@個(gè)功能而崩潰了一次，并且你花半個(gè)小時(shí)來(lái)嘗試找出原因，那么其他 99 次獲得的收益也就全部被抵消了。由于我們堅(jiān)持這一原則，Apply Changes 不會(huì)像 Instant Run 那樣在構(gòu)建期間修改你的 APK。帶來(lái)的副作用是，在我們進(jìn)行穩(wěn)定性?xún)?yōu)化的早期版本中，Apply Changes 會(huì)比 Instant Run 的平均速度稍慢，但是我們將繼續(xù)提高構(gòu)建和部署的速度。

透明。Instant Run 按鈕會(huì)自動(dòng)決定是否在必要時(shí)重啟你的 app 或者 Activity，對(duì)于這樣不可預(yù)測(cè)性和行為不一致性的反饋，我們也考慮了進(jìn)來(lái)。我們希望在任何時(shí)候你都能清楚透明的了解 Apply Changes 要做什么，如果你的代碼有不兼容的修改會(huì)發(fā)生什么。因此如果有檢測(cè)到與 Apply Changes 不兼容的修改，我們現(xiàn)在會(huì)明確提示你。

我們來(lái)深入研究下 Apply Changes 是如何工作的。在你修改 app 之后，當(dāng)前設(shè)備上已經(jīng)安裝或正在運(yùn)行的應(yīng)用程序和 Android Studio 剛剛編譯出來(lái)的應(yīng)用程序是有差異的，Apply Changes 需要弄清楚如何應(yīng)用這些差異。這個(gè)過(guò)程可以分成兩個(gè)步驟：1）弄清楚差異是什么，2）將差異發(fā)送到設(shè)備上并應(yīng)用它。

為了快速確定差異，Apply Changes 沒(méi)有從設(shè)備抓取完整的 APK，而是向設(shè)備發(fā)送一個(gè)快速的請(qǐng)求，去拉取已經(jīng)安裝 APK 的對(duì)應(yīng)目錄和簽名。將這兩部分信息和新 APK 進(jìn)行比較，Apply Changes 可以高效地找出自上次部署以來(lái)修改過(guò)的文件列表，而不需要檢查 APK 的所有內(nèi)容。需要注意的是，這個(gè)算法并不依賴(lài)于構(gòu)建系統(tǒng)，因?yàn)椴町惒⒉皇桥c上一次構(gòu)建相比較得到的，而是與安裝到設(shè)備上的 APK 比較得來(lái)。由于 Apply Changes 只針對(duì) APK 之間的差異進(jìn)行操作，因此它并不要求 Gradle 插件版本和 Gradle 同步。這樣，Apply Changes 可以運(yùn)行于所有的構(gòu)建系統(tǒng)上。

在生成更改過(guò)的文件列表之后，根據(jù)所更改的內(nèi)容，需要執(zhí)行不同的操作來(lái)將這些更改應(yīng)用到正在運(yùn)行的 app 上，這也決定了要使這些更改生效，app 需要重啟到什么程度：

更改 resource/asset 文件。 這種情況下會(huì)重新安裝應(yīng)用程序，但只會(huì)重啟 Activity，并獲取修改后的資源。只有修改過(guò)的資源才會(huì)被發(fā)送到設(shè)備上。

更改 .dex 文件。 Android 8.0 的 Android Runtime 提供了替換已加載類(lèi)的字節(jié)碼的能力，只要新的字節(jié)碼不會(huì)改變內(nèi)存中現(xiàn)有對(duì)象的布局。這意味著要想兼容 Apply Changes，更改的代碼會(huì)有一些限制：方法名，類(lèi)名，和簽名都不能更改，它們的成員變量也不能更改。

但這個(gè)機(jī)制不能在 .dex 級(jí)別，只能在類(lèi)級(jí)別工作。否則，如果 .dex 文件包含成千上萬(wàn)個(gè)類(lèi)，即便只有一個(gè)類(lèi)更改了，也需要對(duì)所有類(lèi)進(jìn)行替換，這樣效率太低。對(duì)于 .dex 文件，我們比較它的內(nèi)容來(lái)找出更改過(guò)的類(lèi)，只替換掉它們。如果替換成功（例如，類(lèi)的布局沒(méi)有改變），為了避免正在運(yùn)行和已安裝的 app 的版本不一致，會(huì)在后臺(tái)安裝 app。

更改 .dex 文件和資源文件。 這個(gè)情況是上面兩種情況的組合。先處理代碼的部分，如果成功了，會(huì)和新的資源一起安裝。為了加載新的資源，主 Activity 會(huì)被重啟。這是一個(gè)全做或全不做的操作，如果代碼的改變不能成功地應(yīng)用，正在運(yùn)行的 app 什么都不會(huì)改變。

更改其他東西。 這是最糟的情況，比如 AndroidManifest.xml 或者 native .so 這些文件被更改了。在這種情況下，是不可能不重啟應(yīng)用程序來(lái)應(yīng)用更改的?！癆pply Changes” 和 “Apply Code Changes”這兩個(gè)操作都不會(huì)試圖去部署它，它們會(huì)告訴用戶(hù)應(yīng)用程序需要重啟。

關(guān)于架構(gòu)的更多詳細(xì)信息，請(qǐng)收聽(tīng) Android Developers Backstage 播客的最新一集，技術(shù)負(fù)責(zé)人 Esteban de la Canal 對(duì) Apply Changes 進(jìn)行了深入探討。

前一個(gè)部分解釋了 Apply Changes 需要比較并確認(rèn)在設(shè)備上更改（修改/添加/刪除）了哪個(gè)具體的類(lèi)。為了不增加從設(shè)備獲取大量?jī)?nèi)容的開(kāi)銷(xiāo)，它在后臺(tái)使用了 D8 的 DEX 文件分析能力來(lái)檢查 Android Studio 部署到設(shè)備上的每個(gè) .dex 文件的內(nèi)容。根據(jù) .dex 文件中的各個(gè)類(lèi)，計(jì)算出校驗(yàn)和，并臨時(shí)保存在主機(jī)的一個(gè)緩存數(shù)據(jù)庫(kù)中。通過(guò)對(duì)比新編譯的 .dex 文件和之前的 .dex 文件的校驗(yàn)和，Apply Changes 可以在很短的時(shí)間內(nèi)找到更改過(guò)的類(lèi)。

如上所述，只有更改了的文件才會(huì)被發(fā)送到設(shè)備上，我們稱(chēng)之為 “ delta push”。與上面提到的 DEX 文件對(duì)比類(lèi)似，Apply Changes 計(jì)算已安裝的 APK 和最近構(gòu)建的 APK 之間的差異，而不需要從設(shè)備獲取所有內(nèi)容。這次，它只獲取壓縮文件的 Central Directory，并保守估計(jì)相應(yīng) APK 之間可能存在的差異。通過(guò)只傳輸已經(jīng)改變的部分，Android Studio 傳輸?shù)臄?shù)據(jù)比完整的 APK 上傳要少很多。在大多數(shù)情況下，總傳輸數(shù)據(jù)從幾 MiB 減少到幾 KiB。

現(xiàn)在可以在 Android Studio 3.5 的 Canary release channel 中使用 Apply Changes。我們歡迎下載最新的 Android Studio，將 Apply Changes 使用到你的項(xiàng)目中，并向我們提出早期的反饋。作為提醒，你可以同時(shí)運(yùn)行 Android Studio 的穩(wěn)定版本和 canary release 版本 。如果你在使用 Apply Changes 時(shí)遇到任何問(wèn)題，請(qǐng)?zhí)峤灰粋€(gè) bug 并附上對(duì)應(yīng)的 idea.log 文件。我們會(huì)持續(xù)優(yōu)化部署性能，修復(fù) bug，并聽(tīng)取你的建議和反饋。

如果發(fā)現(xiàn)譯文存在錯(cuò)誤或其他需要改進(jìn)的地方，歡迎到 掘金翻譯計(jì)劃 對(duì)譯文進(jìn)行修改并 PR，也可獲得相應(yīng)獎(jiǎng)勵(lì)積分。文章開(kāi)頭的 本文永久鏈接 即為本文在 GitHub 上的 MarkDown 鏈接。

掘金翻譯計(jì)劃 是一個(gè)翻譯優(yōu)質(zhì)互聯(lián)網(wǎng)技術(shù)文章的社區(qū)，文章來(lái)源為 掘金 上的英文分享文章。內(nèi)容覆蓋 Android、iOS、前端、后端、區(qū)塊鏈、產(chǎn)品、設(shè)計(jì)、人工智能等領(lǐng)域，想要查看更多優(yōu)質(zhì)譯文請(qǐng)持續(xù)關(guān)注 掘金翻譯計(jì)劃、官方微博、知乎專(zhuān)欄。