在鴻蒙應用開發的快節奏賽道上，每一秒的開發效率提升都至關重要。如何更快地看到代碼更改后的效果？如何盡可能縮短開發、調試和驗證的周期？如何做到在某大廠180萬行+項目中將代碼修改即時生效？這些問題在DevEco Studio中得到了很好的解答，而增量補丁修復便是其中的核心特性之一。今天，我們要深入探討鴻蒙應用增量補丁修復及其兩個能夠大幅加速開發進度的強大功能——Hot Reload和Apply Changes。它們就如同給你的開發旅程中加入了超級引擎，讓你的代碼更新效率大增。

增量補丁修復是代碼修改快速生效的特性統稱，包含增量補丁構建及補丁修復兩個過程。顧名思義，增量補丁構建是在開發者修改代碼后，僅對代碼的修改部分進行增量產物構建并打成補丁包，而不是漫長的全量編譯，這一過程能夠節省開發者大量的時間。而補丁修復則是替換并更新運行時中對應方法或文件并重載到應用中，最后重新構建界面渲染樹，根據生效場景不同，又可分為熱修復和冷修復，熱修復就是在補丁包完成修復后無需重啟應用(ability)即可使修改生效，并可保持應用當前的運行狀態，如變量、頁面位置等，而冷修復則是需要重啟應用(ability)才可使修改生效。是否需要重啟主要取決于修改的方法或屬性是否能夠被重新刷新，即有些方法或屬性的生命周期只會在啟動應用時初始化，并在應用的整個生命周期中保持，如全局變量。

圖1 增量補丁修復原理圖

當前鴻蒙應用開發支持多種修改場景，包含ArkTS、TS、C++、SO、資源文件的修改，相應的增量補丁修復也分別針對不同的修改場景，產生了兩種不同的增量補丁修復方式，分別為強力支持ArkTS開發的Hot Reload和支持能力更為廣泛的Apply Changes。那么這兩種補丁修復有哪些使用場景，又分別是何種原理？且聽下文分解。

Hot Reload：ArkTS開發加速神器

ArkTS是HarmonyOS應用開發的官方高級語言，在鴻蒙應用的界面和交互開發上具有天生優勢。而鴻蒙應用開發工具DevEco Studio中的Hot Reload特性則是針對ArkTS深度定制的開發效率提升能力，快速的增量補丁構建加無需重啟即可使修改生效，使得Hot Reload定位為ArkTS開發加速神器。

使用Hot Reload十分的便捷，在IDE右上角選擇熱重載運行配置及入口模塊后，運行項目并進行代碼修改，點擊Hot Reload按鈕即可使修改生效。

圖2 Hot Reload使用位置

除此之外，Hot Reload還能夠與保存動作進行關聯，修改后保存代碼即可自動執行Hot Reload，能夠非常大程度提升開發的流暢度。

圖3 保存執行Hot Reload開關位置

Hot Reload有三大顯著優勢：及時反饋、保持應用狀態、開發更流暢，下面將分別介紹這些優勢。

及時反饋：在應用開發中，UI的頻繁調整是家常便飯。無論是修改按鈕的顏色、調整字體大小，還是重新布局組件，傳統的開發方式通常需要重新運行工程才能看到效果。在萬行級ArkTS代碼項目中，Hot Reload修改生效速度能夠比全量構建生效速度快70%以上，而在十萬行級以上ArkTS代碼項目中，Hot Reload修改生效速度能夠比全量構建生效速度快50%以上。Hot Reload讓這一切變得無比高效，無需頻繁進行耗時長的重新運行工程，即刻就能看到邏輯、樣式的更改效果，開發過程中的試錯成本大幅降低。

圖4 使用Hot Reload快速調整樣式

保持應用狀態：與完全重啟應用不同，Hot Reload的技術理念是熱修復，無需重啟應用即可使代碼修改生效，這就使得Hot Reload在大多數情況下會保留應用的運行狀態，這對于演示和分享應用進展、調試需要復雜導航（如登錄后操作）等場景尤為重要，避免了重新啟動應用后手動恢復狀態的麻煩。

圖5 可保留應用狀態查看修改效果

開發更流暢：通過開啟保存自動執行Hot Reload，無需感知生效方式和過程，保存后自動快速看到修改效果，大幅減少了開發過程中的間斷感。基于僅對修改代碼的增量構建，你可以像在紙上快速涂改一樣，迅速調整代碼，馬上看到效果，而不用每次都重新繪制整張紙，減少等待時間意味著更多的開發時間。開發者可以更高效地完成任務，將時間花在真正重要的事情上。

圖6 Hot Reload支持對資源引用的修改

Hot Reload的原理從首次啟動運行開始，DevEco Studio會在應用首次編譯構建時生成增量所需的map文件，記錄首次全量編譯的相關信息，基于這個map文件，針對后續的修改，IDE能夠識別修改的文件，調用方舟編譯器只編譯修改的文件，得到增量字節碼文件，再打包通過HDC發送到設備，由包管理進行安裝，虛擬機更新字節碼，最后由ArkUI重建界面渲染樹。

圖7 Hot Reload流程概覽圖

幾個實用小Tips分享給大家：

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

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

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

雖然Hot Reload能夠給ArkTS代碼開發帶來愉快的體驗，但它也有一些局限性，主要體現在如下幾個方面：

一是無法應用某些更改，為保留應用狀態以及更快速的編譯，Hot Reload存在以下不支持場景：

1、 import新增未使用過的文件；

2、@Entry修飾的入口文件內struct成員函數、成員變量的新增、修改；

3、@Entry修飾的入口文件內枚舉鍵和值、接口對象的修改；

獲取更詳細的使用約束可見HotReload使用說明。

二是狀態保留的局限，某些復雜場景下，應用的狀態可能無法正確保留，尤其是當狀態管理不當時。另外還有使用范圍有限，Hot Reload僅支持ArkTS、TS代碼的更改，對于C++、資源文件、SO文件的更改，可選擇使用同樣快速但是需要重啟應用的Apply Changes或完全重啟。

Apply Changes：神通廣大的多面手

為滿足其他語言、文件快速開發的需要，Apply Changes特性應運而生，相較于Hot Reload，Apply Changes同樣針對修改的增量部分進行編譯，具有快速生效的優點，但是為支持C++、資源、SO等復雜的加載場景，Apply Changes還會進行重啟設備上應用的動作。即以犧牲應用狀態保持為代價，獲得更為廣泛的支持能力，Apply Changes目前能夠支持C++、SO、資源文件的修改，是當之無愧的多面手。

使用Apply Changes與使用Hot Reload類似，區別在于Apply Changes的按鈕在普通運行配置下。

圖8 Apply Changes使用位置

Apply Changes的顯著優勢也有三個，具體如下：

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

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

圖9 Apply Changes支持C++代碼修改生效

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

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

圖10 停止運行后無需再次運行，即可Apply Changes

三是穩定性更高：

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

圖11 Apply Changes支持資源文件修改生效

與Hot Reload類似，IDE在首次全量運行后會緩存部分信息用于后續差異比較，后續修改C++代碼后，點擊Apply Changes會基于緩存信息構建增量補丁包，具體而言是，啟動SO的cmake流程構建SO，通過與緩存信息比較，識別出差異SO再構建增量包。構建完成后IDE會關閉設備上的應用，進行修復更新，結束后再重新拉起應用，完成代碼生效。

圖12 Apply Changes流程概覽圖

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

1、優先使用Hot Reload快速驗證UI和ArkTS代碼邏輯；

2、遇到復雜修改，及非ArkTS代碼修改時再使用Apply Changes；

3、定期通過全量運行確保應用整體穩定性；

同樣Apply Changes也有局限性，主要體現在如下兩個方面：

首先是應用的狀態無法保留，Apply Changes采用冷修復的技術路線，會進行應用重啟行為，因此無法對應用狀態進行保留，如丟失輸入內容、路由棧會被重置到初始頁面。然后是暫時無法支持ArkTS、TS代碼文件的修改，目前Apply Changes未能做到同時支持ArkTS、TS代碼的增量編譯，無法支持ArkTS、TS代碼的修改生效。

在鴻蒙應用開發中，Hot Reload和Apply Changes各有側重，Hot Reload能夠快速調整UI及ArkTS代碼邏輯，同時能夠保留應用狀態，具有快而輕的特點。而Apply Changes是針對非ArkTS代碼的修復利器，具有全而穩的特點，能夠進行復雜的修改，同時避免長時間運行可能產生的錯誤。根據需求靈活選擇，才能進一步提升開發效率，盡快為用戶提供更好的體驗。

免責聲明：市場有風險，選擇需謹慎！此文僅供參考，不作買賣依據。