动态import

游戏技术分享

于 2025-04-28 10:09:08 发布

阅读量724

点赞数 21

分类专栏：鸿蒙游戏-引擎适配 # 鸿蒙系统能力接入文章标签：游戏 harmonyos 鸿蒙华为

本文链接：https://blog.csdn.net/2401_82404985/article/details/147575501

版权

鸿蒙游戏-引擎适配同时被 2 个专栏收录

17 篇文章

订阅专栏

鸿蒙系统能力接入

9 篇文章

订阅专栏

1 动态import

动态import常与包管理结合，根据场景按需导入对应模块，细节可参考动态加载官方文档。

1.1 典型案例——通过动态import实现包依赖解耦

游戏中台团队对于SDK模块间（这里指HAR模块）依赖解耦有很强的诉求，具体来讲：

提供给业务侧（游戏项目组）使用的一般只是个空包，里面包含了一些空实现等，没有实际的资源、方法（以下称之为main）。
具体的资源和方法都放在许多子包中（以下称之为sub），不同游戏需要使用不同sub的排列组合，但是都需要通过main来调起不同sub。比如：游戏1需要依赖main，然后实际使用的资源和方法在sub1和sub2中；游戏2需要依赖main，实际使用的资源和方法在sub2和sub3中。

这样就会遇到以下问题：

中台侧希望对业务侧呈现的依赖树是main + 需要的sub；但实际开发过程中，需要把sub全部添加到main的依赖中，main才能实现所有sub的调用逻辑，打出来的main也非常的臃肿，不满足中台的诉求。
如果按照不同的排列组合打出不同的main，维护起来会非常麻烦；

针对这种情况，系统侧提供了overrideDependencyMap和动态import两种机制，来满足开发者在不同场景下，动态变更依赖的需求。

这里我们先准备三个Har包——main、library1、library2。其中library1和library2为对应上文的sub，里面分别暴露了获取包内资源的函数foo1、foo2。

library1：
library2：

main则对应中台需要提供给业务侧使用的包，main同时依赖library1和library2。为了便于管理，将三个包全部上传至私仓，以版本号形式依赖：

配置overrideDependencyMap

OHPM客户端在1.7.0版本开始支持使用overrideDependencyMap机制重写源码模块或三方库的依赖关系。开发者可在工程级oh-package.json5文件中新增overrideDependencyMap配置，在该配置对象中通过key-value形式配置依赖关系重写文件；其中，key为依赖标识符，value为依赖关系重写文件路径。在依赖安装时， ohpm会将依赖树中的某个依赖节点的所有直接子依赖替换为对应依赖关系重写文件中配置的依赖项，依赖关系重写文件中支持配置的依赖类型为dependencies、devDependencies、dynamicDependencies。

如下为业务侧实际接入中台SDK的工程，在工程根目录的oh-package.json5中，添加overrideDependencyMap配置，并配置main模块的实际依赖树由同目录下的main-dep.json5文件定义。

main-dep.json5为用户新增的文件，在其中的dependencies字段中仅配置依赖library1，表示改工程中只需要用到main来调用library1中的资源，不需要library2：

然后我们正常在工程的主模块entry中配置main和library1的依赖，并执行ohpm install，此时会发现工程级的oh-module/.ohpm中只拉取了main和library1。若不配置overrideDependencyMap，正常情况下ohpm会将main中的所有依赖都拉取下来。

这样我们初步完成了业务方接入SDK时更改依赖树，实现模块解耦的诉求。此时工程内时是没有library2模块的，如果main中按照常规引用模块的方法import xxx from "library2"，那么编译会报错。所以在main模块的开发过程中，不能直接引入子模块，需要使用动态import，让子模块按需加载。

实现动态import

在main模块中我们暴露一个SdkImport方法，这个方法支持传入模块名，根据传入的模块名来动态地加载不同模块中的方法，来获取foo1或foo2中的Resource：

同时在main模块的build-profile.json5中添加如下字段，配置main模块变量动态import的其他模块名

"buildOption": {
  "arkOptions": {
    "runtimeOnly": {
      "packages": [
        "library1",
        "library2"
      ]
    }
  }
},

这样在main模块中，我们并没有静态引入library1和library2中的任何方法和资源，编译和使用都不会报错。此时我们在业务侧主工程的ets文件中引用main模块中的方法，可以正确获取library1中的图片资源：

实际效果如下：

原文链接：华为开发者文章

更多问题可关注：

鸿蒙游戏官方网站：已有游戏移植-鸿蒙游戏-华为开发者联盟

公开课：华为开发者学堂