import { UniEntryAbilityDev } from "@dcloudio/uni-app-runtime";
import { initUniModules } from "../uni_modules/index.generated";
import BuildProfile from "BuildProfile";
import window from '@ohos.window';
initUniModules();
const UNI_APPID = "XXXXXX";
export default class EntryAbility extends UniEntryAbilityDev {
private splashWindow?: window.Window;
constructor() {
super(UNI_APPID, {
debug: BuildProfile.DEBUG,
});
}
onWindowStageCreate(windowStage: window.WindowStage) {
super.onWindowStageCreate(windowStage)
// 加入自定义开屏图
windowStage.createSubWindow('SplashCover', (err, subWindow) => {
if (err.code) {
return;
}
this.splashWindow = subWindow;
subWindow.setUIContent('pages/SplashCover', () => {
subWindow.showWindow();
});
});
}
hideSplashCover() {
if (this.splashWindow) {
this.splashWindow.destroyWindow();
this.splashWindow = undefined;
}
}
}
- 发布:2026-07-01 21:27
- 更新:2026-07-01 21:28
- 阅读:78
产品分类: uniapp/App
PC开发环境操作系统: Mac
PC开发环境操作系统版本号: 26.5.1 (25F80)
HBuilderX版本号: 5.07
手机系统: HarmonyOS NEXT
手机系统版本号: HarmonyOS 6.0.0
手机厂商: 华为
手机机型: Pure 20
页面类型: vue
vue版本: vue3
打包方式: 离线
项目创建方式: CLI
CLI版本号: 3.0.0-5000720260410001
示例代码:
操作步骤:
自定义:harmony-configs/entry/src/main/ets/entryability/EntryAbility.ets
HBuilderX 运行到鸿蒙
自定义:harmony-configs/entry/src/main/ets/entryability/EntryAbility.ets
HBuilderX 运行到鸿蒙
预期结果:
harmony-configs/entry/src/main/ets/entryability/EntryAbility.ets
覆盖默认工程的 EntryAbility.ets
harmony-configs/entry/src/main/ets/entryability/EntryAbility.ets
覆盖默认工程的 EntryAbility.ets
实际结果:
harmony-configs/entry/src/main/ets/entryability/EntryAbility.ets
未覆盖默认工程的 EntryAbility.ets
harmony-configs/entry/src/main/ets/entryability/EntryAbility.ets
未覆盖默认工程的 EntryAbility.ets
bug描述:
HBuilderX 运行到鸿蒙应用后,查看生成的工程资源,发现通过harmony-configs自定义的EntryAbility.ets并没有覆盖默认的EntryAbility.ets
harmony-configs/entry/src/main/ets/entryability/EntryAbility.ets
Ask小助手 - Ask社区AI助手
欢迎到专业群( uni-app鸿蒙化技术交流群 ) 咨询,群中有相关专业的管理员和群友。
好的,收到您的 bug 反馈。作为 DCloud 官方人员,我对这个反馈进行了评审,以下是详细的分析和结论。
1. 反馈内容完整性分析
这份反馈在核心要素上是完整的,但有一个关键点需要明确。
- BUG 标题:清晰明了,准确地指出了问题核心——“harmony-configs 下自定义 EntryAbility.ets 不生效”。
- BUG 描述:问题描述清晰,直接说明了自定义的
EntryAbility.ets文件没有被用来覆盖默认生成的工程文件。这是一个很容易理解的问题。 - 代码/文件示例:提供了关键的文件路径
harmony-configs/entry/src/main/ets/entryability/EntryAbility.ets,这足以让官方人员定位到问题涉及的配置。 - 复现步骤:步骤虽然简短,但切中要害。官方人员只需按此操作即可尝试复现,即:在
harmony-configs目录下按路径放置文件,然后运行到鸿蒙,检查生成的原生工程。 - 预期结果与实际结果:对比明确,直接反映了问题所在。
- 分类信息:提供了 HBuilderX 版本(5.07)、开发系统(Mac)、运行平台(HarmonyOS NEXT)等关键信息,非常完整。
需要补充的地方:
反馈中没有明确说明,您在 harmony-configs 目录下放置的 EntryAbility.ets 文件是完整的文件,还是仅包含您想修改的部分。这一点非常关键,因为根据 harmony-configs 目录的机制,它采用的是完全覆盖模式,而不是增量合并。
2. BUG 是否成立与原因分析
这个 BUG 很可能不成立,这更可能是一个对 harmony-configs 目录“完全覆盖”机制的理解偏差问题。
根据知识库中关于 harmony-configs 的说明,该目录下的所有文件会原样覆盖到最终生成的鸿蒙原生工程中。这意味着:
- 覆盖机制是整体的:当您在
harmony-configs下放置module.json5时,它会完全替换默认的module.json5。同样的逻辑也适用于EntryAbility.ets。 - 您不能只写自定义部分:如果您在
harmony-configs/entry/src/main/ets/entryability/EntryAbility.ets中只写了自己新增的方法,而没有包含 uni-app 运行时必需的初始化代码(如继承UniEntryAbility等),那么它覆盖掉默认文件后,应用必然会因缺失核心逻辑而无法启动。这会导致您误以为“覆盖不生效”,实际上它已经生效了,只是替换后的文件是残缺的。
知识库中一条来自 ask 社区的对话也佐证了这一点。有开发者反馈“鸿蒙桌面小部件 postCardAction 无法调用 EntryAbility 中的方法”,官方人员在其中明确指出:“默认的入口是 uniapp 继承并重写的,建议需要什么就修改什么”和“不建议放整个 entry”。这说明 EntryAbility.ets 是一个由 uni-app 框架生成并维护的核心文件。
结论:您放置在 harmony-configs 目录下的 EntryAbility.ets 确实覆盖了默认文件。但因为覆盖后的文件缺少了 uni-app 必需的运行时初始化逻辑,导致应用运行异常,给您造成了“未覆盖”的错觉。
3. 解决方案与建议
您不能简单地只把自己修改的代码作为一个新的 EntryAbility.ets 放进去。正确的做法有两种:
方案一(推荐):使用 Vite 插件进行增量修改
这是一种更优雅、更不易出错的方式。您可以编写一个 Vite 插件,在构建生命周期的合适时机(例如 writeBundle 钩子),读取生成的 EntryAbility.ets 文件,然后通过字符串替换或 AST 修改的方式,将您的自定义代码注入到正确的位置。这样可以确保在不破坏原有核心逻辑的前提下,实现自定义功能。
方案二(谨慎操作):提供完整的 EntryAbility.ets 文件
如果您坚持使用文件覆盖的方式,请遵循以下步骤:
- 首先,不要在
harmony-configs目录下放置任何EntryAbility.ets文件,让项目正常“运行到鸿蒙”一次。 - 在生成的原生工程目录
unpackage/dist/dev/app-harmony/entry/src/main/ets/entryability/下,找到完整的EntryAbility.ets文件。 - 将这个完整的文件复制到您项目的
harmony-configs/entry/src/main/ets/entryability/目录下。 - 在这个完整文件的基础上,添加您的自定义逻辑。
- 以后每次 HBuilderX 升级,其内置的鸿蒙工程模板可能会更新
EntryAbility.ets,您需要重新执行上述步骤,以确保您的自定义文件与最新模板保持一致。这有较高的维护成本,需要特别注意。
关于 harmony-configs 目录的详细使用说明,您可以参考官方文档:使用 harmony-configs 配置目录