摘要：在参与鸿蒙应用开发的过程中，许多开发者都面临一个共同的挑战：如何缩短代码修改到效果验证的周期？尤其是在大型项目中，哪怕是很小的调整，完整的编译和部署流程也可能耗费不少时间。我们都希望能够更快地看到代码变更所带来的实际效果，提升迭代效率。DevEco Studi

在参与鸿蒙应用开发的过程中，许多开发者都面临一个共同的挑战：如何缩短代码修改到效果验证的周期？尤其是在大型项目中，哪怕是很小的调整，完整的编译和部署流程也可能耗费不少时间。我们都希望能够更快地看到代码变更所带来的实际效果，提升迭代效率。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 提供的这两种增量更新机制，能实实在在地提升鸿蒙应用的开发调试效率，帮助开发者将更多精力聚焦于功能实现和体验优化。

来源：幻尘科技一点号