在鸿蒙应用开发的快节奏赛道上，每一秒的开发效率提升都至关重要。如何更快地看到代码更改后的效果？如何尽可能缩短开发、调试和验证的周期？如何做到在某大厂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分享给大家：

• 小步快跑：分解更改为小块，每次修改后使用Hot Reload查看效果。
• 结合状态管理：使用状态管理工具（如@State、@Prop）可以更好地控制状态，确保Hot Reload后状态的正确性。
• 定期重启应用：在长时间开发后，建议偶尔完全重启应用，以确保代码和状态的一致性。

虽然Hot Reload能够给ArkTS代码开发带来愉快的体验，但它也有一些局限性，主要体现在如下几个方面：

一是无法应用某些更改，为保留应用状态以及更快速的编译，Hot Reload存在以下不支持场景：

• import新增未使用过的文件；
• @Entry修饰的入口文件内struct成员函数、成员变量的新增、修改；
• @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也分享一下：

• 优先使用HotReload快速验证UI和ArkTS代码逻辑；
• 遇到复杂修改，及非ArkTS代码修改时再使用ApplyChanges；
• 定期通过全量运行确保应用整体稳定性；

同样Apply Changes也有局限性，主要体现在如下两个方面：

首先是应用的状态无法保留，Apply Changes采用冷修复的技术路线，会进行应用重启行为，因此无法对应用状态进行保留，如丢失输入内容、路由栈会被重置到初始页面。然后是暂时无法支持ArkTS、TS代码文件的修改，目前Apply Changes未能做到同时支持ArkTS、TS代码的增量编译，无法支持ArkTS、TS代码的修改生效。

在鸿蒙应用开发中，Hot Reload和Apply Changes各有侧重，Hot Reload能够快速调整UI及ArkTS代码逻辑，同时能够保留应用状态，具有快而轻的特点。而Apply Changes是针对非ArkTS代码的修复利器，具有全而稳的特点，能够进行复杂的修改，同时避免长时间运行可能产生的错误。根据需求灵活选择，才能进一步提升开发效率，尽快为用户提供更好的体验。