用 DevEco Studio 增量补丁修复功能，让鸿蒙应用的调试效率大增

在鸿蒙应用开发的快节奏赛道上，每一秒的开发效率提升都至关重要。如何更快地看到代码更改后的效果？如何尽可能缩短开发、调试和验证的周期？如何做到在某大厂 180 万行+项目中将代码修改即时生效？这些问题在 DevEco Studio 中得到了很好的解答，而增量补丁修复便是其中的核心特性之一。今天，我们要深入探讨鸿蒙应用增量补丁修复及其两个能够大幅加速开发进度的强大功能——Hot Reload 和 Apply Changes。它们就如同给你的开发旅程中加入了超级引擎，让你的代码更新效率大增。

增量补丁修复是代码修改快速生效的特性统称，包含增量补丁构建及补丁修复两个过程。顾名思义，增量补丁构建是在开发者修改代码后，仅对代码的修改部分进行增量产物构建并打成补丁包，而不是漫长的全量编译，这一过程能够节省开发者大量的时间。而补丁修复则是替换并更新运行时中对应方法或文件并重载到应用中，最后重新构建界面渲染树，根据生效场景不同，又可分为热修复和冷修复，热修复就是在补丁包完成修复后无需重启应用(ability)即可使修改生效，并可保持应用当前的运行状态，如变量、页面位置等，而冷修复则是需要重启应用(ability)才可使修改生效。是否需要重启主要取决于修改的方法或属性是否能够被重新刷新，即有些方法或属性的生命周期只会在启动应用时初始化，并在应用的整个生命周期中保持，如全局变量。

当前鸿蒙应用开发支持多种修改场景，包含 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 按钮即可使修改生效。

除此之外，Hot Reload 还能够与保存动作进行关联，修改后保存代码即可自动执行 Hot Reload，能够非常大程度提升开发的流畅度。

Hot Reload 有三大显著优势：及时反馈、保持应用状态、开发更流畅，下面将分别介绍这些优势。

及时反馈：在应用开发中，UI 的频繁调整是家常便饭。无论是修改按钮的颜色、调整字体大小，还是重新布局组件，传统的开发方式通常需要重新运行工程才能看到效果。在万行级 ArkTS 代码项目中，Hot Reload 修改生效速度能够比全量构建生效速度快 70%以上，而在十万行级以上 ArkTS 代码项目中，Hot Reload 修改生效速度能够比全量构建生效速度快 50%以上。Hot Reload 让这一切变得无比高效，无需频繁进行耗时长的重新运行工程，即刻就能看到逻辑、样式的更改效果，开发过程中的试错成本大幅降低。

保持应用状态：与完全重启应用不同，Hot Reload 的技术理念是热修复，无需重启应用即可使代码修改生效，这就使得 Hot Reload 在大多数情况下会保留应用的运行状态，这对于演示和分享应用进展、调试需要复杂导航（如登录后操作）等场景尤为重要，避免了重新启动应用后手动恢复状态的麻烦。

开发更流畅：通过开启保存自动执行 Hot Reload，无需感知生效方式和过程，保存后自动快速看到修改效果，大幅减少了开发过程中的间断感。基于仅对修改代码的增量构建，你可以像在纸上快速涂改一样，迅速调整代码，马上看到效果，而不用每次都重新绘制整张纸，减少等待时间意味着更多的开发时间。开发者可以更高效地完成任务，将时间花在真正重要的事情上。

Hot Reload 的原理从首次启动运行开始，DevEco Studio 会在应用首次编译构建时生成增量所需的 map 文件，记录首次全量编译的相关信息，基于这个 map 文件，针对后续的修改，IDE 能够识别修改的文件，调用方舟编译器只编译修改的文件，得到增量字节码文件，再打包通过 HDC 发送到设备，由包管理进行安装，虚拟机更新字节码，最后由 ArkUI 重建界面渲染树。

几个实用小 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 的按钮在普通运行配置下。

Apply Changes 的显著优势也有三个，具体如下：

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

目前 Apply Changes 能够同时支持 C++、SO、资源文件的一种或多种修改快速生效，且修改场景限制较小。

二是仅需一次推包，关闭应用后也可直接进行 Apply Changes：

关于 C++、SO 以及资源文件的增量编译及打包都是与工程的运行状态解耦的，只要设备中已经安装工程对应的应用，那么无需运行工程，直接修改代码点击 Apply Changes 即可自动拉起应用，使修改生效，避免再一次全量构建。

三是稳定性更高：

由于 Apply Changes 能够重启应用，能够及时进行增量补丁的重新加载，避免了潜在的状态不一致问题，修复因状态污染可能导致的逻辑异常。

与 Hot Reload 类似，IDE 在首次全量运行后会缓存部分信息用于后续差异比较，后续修改 C++代码后，点击 Apply Changes 会基于缓存信息构建增量补丁包，具体而言是，启动 SO 的 cmake 流程构建 SO，通过与缓存信息比较，识别出差异 SO 再构建增量包。构建完成后 IDE 会关闭设备上的应用，进行修复更新，结束后再重新拉起应用，完成代码生效。

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 代码的修复利器，具有全而稳的特点，能够进行复杂的修改，同时避免长时间运行可能产生的错误。根据需求灵活选择，才能进一步提升开发效率，尽快为用户提供更好的体验。

想要深入了解什么是技术共建，或与我们共同探讨技术创新。欢迎加入我们的技术共建交流群，我们将与志同道合的开发者一起交流、分享与成长！扫码加入群聊，开启技术共建之旅！