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

增量補(bǔ)丁修復(fù)是代碼修改快速生效的特性統(tǒng)稱，包含增量補(bǔ)丁構(gòu)建及補(bǔ)丁修復(fù)兩個過程。顧名思義，增量補(bǔ)丁構(gòu)建是在開發(fā)者修改代碼后，僅對代碼的修改部分進(jìn)行增量產(chǎn)物構(gòu)建并打成補(bǔ)丁包，而不是漫長的全量編譯，這一過程能夠節(jié)省開發(fā)者大量的時間。而補(bǔ)丁修復(fù)則是替換并更新運行時中對應(yīng)方法或文件并重載到應(yīng)用中，最后重新構(gòu)建界面渲染樹，根據(jù)生效場景不同，又可分為熱修復(fù)和冷修復(fù)，熱修復(fù)就是在補(bǔ)丁包完成修復(fù)后無需重啟應(yīng)用(ability)即可使修改生效，并可保持應(yīng)用當(dāng)前的運行狀態(tài)，如變量、頁面位置等，而冷修復(fù)則是需要重啟應(yīng)用(ability)才可使修改生效。是否需要重啟主要取決于修改的方法或?qū)傩允欠衲軌虮恢匦滤⑿?，即有些方法或?qū)傩缘纳芷谥粫趩討?yīng)用時初始化，并在應(yīng)用的整個生命周期中保持，如全局變量。

圖1 增量補(bǔ)丁修復(fù)原理圖

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

Hot Reload：ArkTS開發(fā)加速神器

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

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

圖2 Hot Reload使用位置

除此之外，Hot Reload還能夠與保存動作進(jìn)行關(guān)聯(lián)，修改后保存代碼即可自動執(zhí)行Hot Reload，能夠非常大程度提升開發(fā)的流暢度。

圖3 保存執(zhí)行Hot Reload開關(guān)位置

Hot Reload有三大顯著優(yōu)勢：及時反饋、保持應(yīng)用狀態(tài)、開發(fā)更流暢，下面將分別介紹這些優(yōu)勢。

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

圖4 使用Hot Reload快速調(diào)整樣式

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

圖5 可保留應(yīng)用狀態(tài)查看修改效果

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

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

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

圖7 Hot Reload流程概覽圖

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

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

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

3、定期重啟應(yīng)用：在長時間開發(fā)后，建議偶爾完全重啟應(yīng)用，以確保代碼和狀態(tài)的一致性。

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

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

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

2、@Entry修飾的入口文件內(nèi)struct成員函數(shù)、成員變量的新增、修改；

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

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

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

Apply Changes：神通廣大的多面手

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

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

圖8 Apply Changes使用位置

Apply Changes的顯著優(yōu)勢也有三個，具體如下：

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

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

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

二是僅需一次推包，關(guān)閉應(yīng)用后也可直接進(jìn)行Apply Changes：

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

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

三是穩(wěn)定性更高：

由于Apply Changes能夠重啟應(yīng)用，能夠及時進(jìn)行增量補(bǔ)丁的重新加載，避免了潛在的狀態(tài)不一致問題，修復(fù)因狀態(tài)污染可能導(dǎo)致的邏輯異常。

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

與Hot Reload類似，IDE在首次全量運行后會緩存部分信息用于后續(xù)差異比較，后續(xù)修改C++代碼后，點擊Apply Changes會基于緩存信息構(gòu)建增量補(bǔ)丁包，具體而言是，啟動SO的cmake流程構(gòu)建SO，通過與緩存信息比較，識別出差異SO再構(gòu)建增量包。構(gòu)建完成后IDE會關(guān)閉設(shè)備上的應(yīng)用，進(jìn)行修復(fù)更新，結(jié)束后再重新拉起應(yīng)用，完成代碼生效。

圖12 Apply Changes流程概覽圖

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

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

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

3、定期通過全量運行確保應(yīng)用整體穩(wěn)定性；

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

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

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