在參與鴻蒙應用開發的過程中，許多開發者都面臨一個共同的挑戰：如何縮短代碼修改到效果驗證的周期？尤其是在大型項目中，哪怕是很小的調整，完整的編譯和部署流程也可能耗費不少時間。我們都希望能夠更快地看到代碼變更所帶來的實際效果，提升迭代效率。DevEco Studio 提供了一些機制來應對這個問題，其中，“增量補丁修復”相關的技術，特別是 Hot Reload 和 Apply Changes 這兩個功能，值得我們深入了解。它們為加速鴻蒙應用的調試和驗證過程提供了有效的途徑。

增量補丁修復原理圖

增量更新：理解快速生效背后的邏輯

所謂“增量補丁修復”，簡單來說，就是一種避免全量編譯的技術思路。當開發者修改了代碼或資源后，系統只針對發生變化的部分進行構建，生成一個“補丁包”。然后，這個補丁包會被推送到設備上，更新正在運行的應用或準備下次啟動時加載。

這個過程根據應用是否需要重啟來使修改生效，可以大致分為兩種模式：

熱修復 :補丁應用后，修改能夠無需重啟應用就生效。這種方式的好處是能保持應用當前的狀態，比如用戶界面停留在哪個頁面，變量的當前值等。

冷修復:補丁應用后，需要重啟應用 (或 Ability)才能讓修改生效。這通常是因為修改涉及到了應用啟動時才初始化的組件或全局狀態，需要通過重啟來重新加載。

DevEco Studio 基于這套邏輯，提供了兩種具體的實現方式：Hot Reload 和 Apply Changes，它們各有側重，適用于不同的開發場景。

Hot Reload：ArkTS 開發的加速器

對于主要使用 ArkTS 進行 UI 和交互邏輯開發的場景，Hot Reload 是一個非常有用的功能。它結合了增量構建和熱修復的能力，目標是實現 ArkTS 代碼修改后的“即時”預覽。

Hot Reload使用位置

使用上，通常在 DevEco Studio 中選擇支持熱重載的運行模式啟動應用，然后在修改 ArkTS 代碼后，點擊工具欄的 Hot Reload 圖標（或使用快捷鍵）。IDE 還支持設置“保存時自動 Hot Reload”，進一步提升流暢性。

Hot Reload 的主要價值在于：及時反饋、 保持應用狀態和開發更流暢。

修改及時反饋：比如修改按鈕顏色、調整字體或者微調布局，以往我們都要重新編譯再運行，特別是大項目，每次重啟可能耗費好幾分鐘。但用了Hot Reload后，只要代碼改動一保存，點一下熱重載按鈕，幾乎秒生效，非常直觀。

保持應用狀態：另一個亮點是不用重啟應用，可以保留應用運行狀態。比如在應用里走到某個復雜場景（比如多步表單填寫），代碼改了之后還可以繼續從當前狀態看效果，不用再一遍遍地重頭操作，這一點確實提升了不少調試體驗。

開發更流暢：Hot Reload還支持保存時自動重載，開發時修改完代碼，保存后立刻看到效果，整體開發節奏更流暢。

不過，Hot Reload 主要服務于 ArkTS/TS 代碼。它的實現原理（基于首次構建的映射信息進行增量編譯和虛擬機字節碼更新）決定了其局限性：

不支持部分修改:如添加新的 import（如果該文件之前未被使用）、修改 @Entry 入口組件的結構（如增刪成員函數/變量）等。詳細限制可查閱官方文檔。

狀態可能異常:在某些復雜情況下，應用狀態可能無法完全正確地保留，尤其是在狀態管理本身不規范時。

范圍有限:它不能處理 C++、資源文件或 .so 庫的修改。

幾個關于Hot Reload的實用小Tips分享給大家：

小步快跑：分解更改為小塊，每次修改后使用Hot Reload查看效果。

結合狀態管理：使用狀態管理工具（如@State、@Prop）可以更好地控制狀態，確保Hot Reload后狀態的正確性。

定期重啟應用：在長時間開發后，建議偶爾完全重啟應用，以確保代碼和狀態的一致性。

Apply Changes：覆蓋更廣的多面手

當需要修改 C++ 代碼、原生庫 (.so)、資源文件，或者遇到了 Hot Reload 不支持的場景時，Apply Changes 便派上了用場。它同樣采用增量構建來提升速度，但為了支持更廣泛的文件類型和更底層的變更，它選擇了“冷修復”路線——修改生效前會重啟應用。

Apply Changes 的使用入口在 IDE 中也很明顯，通常位于標準運行配置旁邊。點擊后，IDE 會構建增量補丁，停止設備上的應用，應用補丁，然后重新啟動應用。

Apply Changes使用位置

Apply Changes 的優勢體現在：

一是支持更多樣的文件修改：

目前Apply Changes能夠同時支持C++、SO、資源文件的一種或多種修改快速生效，且修改場景限制較小。

二是僅需一次推包，關閉應用后也可直接進行Apply Changes：

關于C++、SO以及資源文件的增量編譯及打包都是與工程的運行狀態解耦的，只要設備中已經安裝工程對應的應用，那么無需運行工程，直接修改代碼點擊Apply Changes即可自動拉起應用，使修改生效，避免再一次全量構建。

三是穩定性更高：

由于Apply Changes能夠重啟應用，能夠及時進行增量補丁的重新加載，避免了潛在的狀態不一致問題，修復因狀態污染可能導致的邏輯異常。

Apply Changes 的工作流程涉及根據緩存信息進行差異比較和增量構建（如 C++ 修改觸發 CMake），然后通過停止、修復、重啟應用的步驟完成更新。

它的主要代價是丟失應用狀態。每次 Apply Changes 后，應用都會回到初始狀態，需要開發者手動操作才能恢復之前的場景。此外，目前 Apply Changes暫不支持 ArkTS/TS 代碼的增量更新，這部分仍需依賴 Hot Reload 或完整構建。

Apply Changes的幾個實用小Tips也分享一下：

優先 Hot Reload:當你主要跟 ArkTS 代碼打交道，特別是頻繁調整 UI 和前端邏輯時，用它來獲得最快的反饋。

切換 Apply Changes:當修改涉及 C++、.so、資源文件，或者進行 Hot Reload 不支持的復雜 ArkTS 修改時，使用 Apply Changes。雖然需要重啟，但比全量構建快得多。

定期全量運行:在長時間開發或進行重要節點測試前，進行一次完整的重新構建和運行，有助于暴露和清理潛在問題，確保應用的整體穩定性。

在日常開發中，Hot Reload 和 Apply Changes 是相輔相成的。理解并恰當運用 DevEco Studio 提供的這兩種增量更新機制，能實實在在地提升鴻蒙應用的開發調試效率，幫助開發者將更多精力聚焦于功能實現和體驗優化。