HarmonyOS 鸿蒙Next中如何实现热更新？

HarmonyOS 鸿蒙Next中如何实现热更新？ 我们希望在不发版的情况下修复线上 UI Bug。有没有官方热更新方案？能否动态下发 ArkTS 代码片段？

8 回复

不能，实测了。要么嵌套H5，要么嵌套react native。这两种方式都可以实现你的”热修复“

更多关于HarmonyOS 鸿蒙Next中如何实现热更新？的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


出于安全与稳定性考虑，鸿蒙禁止动态加载和执行远程 ArkTS/JS 代码（包括 eval、new Function 等）。但允许以下有限更新：

  • 资源热更：通过 ResourceManager 动态加载远程配置的 JSON、图片、字符串；
  • HSP（Harmony Shared Package）：预置可更新模块，在新版本 HAP 中替换；
  • Web 容器：将部分页面用 H5 实现，通过 CDN 更新。

关于鸿蒙（HarmonyOS）的热更新，核心结论是：出于安全性和稳定性考虑，鸿蒙官方并未提供传统意义上（无需用户操作、可更新代码逻辑）的热更新机制 在开发调试时，DevEco Studio 6.0提供了热更新（Hot Reload）调试模式，可以大幅缩短修改UI属性后的生效时间（通常比全量编译快50%-70%）-6。但这仅用于开发阶段提升效率，与生产环境的应用更新是两回事。或者说利用ArkUI的@State、@Prop等状态管理机制，数据更新后自动刷新界面

参考官方给出回复：

HarmonyOS不支持热修复，考虑到应用紧急故障快速修复的诉求，HarmonyOS应用市场提供了审核加急方案，通过该方案，可以快速审核，若您的应用符合上架条件，将在2小时之内完成上架。审核加急填写流程：

  1. 向AGC运营人员发送申请邮件，邮件标题：[申请使用HarmonyOS应用加急审核上架]-[应用名称]-[APPID]-[公司名称]-[Developer ID]。
  2. 填写是否加急：配置为“不加急”，您的应用将按照正常的流程进行审核上架。配置为“加急”，系统会优先处理该应用的上架审核任务。
  3. 加急类型：当前加急类型包括临时漏洞、临时活动和其他。若配置为“临时漏洞”，则表示您需要紧急修复缺陷；配置为“临时活动”表示正在进行一项商业类活动。
  4. 加急说明：您可在此对加急审核上架进行描述，以便运营人员快速处理审核任务。

另外，审核加急配置当前仅在中国大陆地区开放。在一个自然年内，一个应用有3次加急机会。

蹲答案，

下面是之前一位技术支持在2025-09-22号发的：原帖

HarmonyOS不支持热修复，考虑到应用紧急故障快速修复的诉求，HarmonyOS应用市场提供了审核加急方案，通过该方案，可以快速审核，若您的应用符合上架条件，将在2小时之内完成上架。审核加急填写流程：

向AGC运营人员发送申请邮件，邮件标题：[申请使用HarmonyOS应用加急审核上架]-[应用名称]-[APPID]-[公司名称]-[Developer ID]。
填写是否加急：配置为“不加急”，您的应用将按照正常的流程进行审核上架。配置为“加急”，系统会优先处理该应用的上架审核任务。
加急类型：当前加急类型包括临时漏洞、临时活动和其他。若配置为“临时漏洞”，则表示您需要紧急修复缺陷；配置为“临时活动”表示正在进行一项商业类活动。
加急说明：您可在此对加急审核上架进行描述，以便运营人员快速处理审核任务。
另外，审核加急配置当前仅在中国大陆地区开放。在一个自然年内，一个应用有3次加急机会。

你如果想不发版的情况下变更UI，建议你嵌套H5

鸿蒙Next不支持传统热更新，应用更新需通过应用市场分发。系统采用全场景协同机制，通过原子化服务实现动态功能加载。开发者可借助动态共享包技术实现部分模块更新，但需遵循安全规范。应用沙箱机制限制了代码动态替换能力，确保系统稳定性。

目前，HarmonyOS Next（API 12）没有官方支持的、可用于动态下发并执行ArkTS/JS代码的热更新方案。系统设计强调安全、性能和原生体验，因此对应用代码的动态性有严格限制。

核心原则与现状：

  1. 代码不可变性：已打包的HAP（Harmony Ability Package）中的ArkTS/JS等核心业务逻辑代码在安装后是只读的，无法被修改或替换。
  2. 无动态代码执行：应用无法从网络或本地动态下载并执行包含业务逻辑的ArkTS/JS代码脚本。这主要是出于安全考虑，防止代码注入攻击。

针对UI Bug的替代方案： 虽然不能热更新业务逻辑代码，但可以通过以下方式实现一定程度的“动态化”，以应对UI展示类问题：

  • 动态化UI与数据分离：将UI结构与数据、配置彻底解耦。

    • 使用声明式UI与数据绑定：UI界面通过ArkTS的声明式范式编写，其具体展示内容（如文本、图片URL、样式参数、组件显隐状态等）由数据模型驱动。
    • 配置/数据云端化：将驱动UI变化的数据、配置（如JSON格式的布局描述、样式参数、文案、图片资源链接等）存储在云端服务器。
    • 应用内更新机制：应用启动或定时拉取云端的最新配置数据，更新本地数据模型，从而在不修改代码的情况下，改变UI的渲染结果。这可以用于修复文案错误、调整布局参数、替换图片、控制功能入口的显隐等。

  • 使用WebView：对于需要高度动态化且非核心功能的页面，可以集成WebView组件，加载远程H5页面。但这属于混合开发，体验与原生有差异。

  • 分包与按需加载：HarmonyOS支持将应用功能模块拆分到不同的HAP中，并支持后续下载安装新的HAP（这需要用户交互确认，并非无感更新）。这适用于功能模块的增量更新，但不适用于快速修复线上小Bug。

总结： 在HarmonyOS Next上，无法实现类似“动态下发并执行ArkTS代码片段”的热更新。推荐的实践是采用 “声明式UI + 云端数据驱动” 的架构，将可能变化的UI描述转化为可下发的数据，通过更新数据来间接调整UI表现，以应对部分线上UI问题。对于重大的逻辑修复，仍需通过应用市场发布新版。

回到顶部