模块化设计与包管理

游戏开发 创建于:05-30 06:47

1、应用程序包

多Module设计机制

一个应用通常会包含多种功能,将不同的功能特性按模块来划分和管理是一种良好的设计方式。在开发过程中,我们可以将每个功能模块作为一个独立的Module进行开发,Module中可以包含源代码、资源文件、第三方库、配置文件等,每一个Module可以独立编译,实现特定的功能。这种模块化、松耦合的应用管理方式有助于应用的开发、维护与扩展。

Module类型

Ability类型的Module: 用于实现应用的功能和特性。每一个Ability类型的Module编译后,会生成一个以.hap为后缀的文件,我们称其为HAP(Harmony Ability Package)包。HAP包可以独立安装和运行,是应用安装的基本单位,一个应用中可以包含一个或多个HAP包,具体包含如下两种类型:

  • entry类型的Module:应用的主模块,包含应用的入口界面、入口图标和主功能特性,编译后生成entry类型的HAP。每一个应用分发到同一类型的设备上的应用程序包,只能包含唯一一个entry类型的HAP,也可以不包含。

  • feature类型的Module:应用的动态特性模块,编译后生成feature类型的HAP。一个应用中可以包含一个或多个feature类型的HAP,也可以不包含。即应用程序包 = entry包 + n * feature包 (n >= 0)。

Library类型的Module: 用于实现代码和资源的共享。同一个Library类型的Module可以被其他的Module多次引用,合理地使用该类型的Module,能够降低开发和维护成本。Library类型的Module分为Static和Shared两种类型,编译后会生成共享包。

  • Static Library:静态共享库。编译后会生成一个以.har为后缀的文件,即静态共享包HAR(Harmony Archive)。

  • Shared Library:动态共享库。编译后会生成一个以.hsp为后缀的文件,即动态共享包HSP(Harmony Shared Package)。

选择合适的包类型

 

更多应用程序包信息可参考:

2、版本与依赖管理

关键字段

工程级oh-package.json5 依赖配置字段说明,完整文档参考oh-package.json5

 

依赖配置优先级:overrides > resolve_conflict > overrideDependencyMap > oh_package.json5

ohpm私仓

ohpm-repo是一个搭建轻量级的HarmonyOS三方库私有仓服务的工具。它与ohpm包管理器兼容,用来存储和管理您独有的三方库,以保证这些三方包的私有性。同时,便于这些三方库能在开发团队内部共享复用,从而提升团队的开发效率。

下载ohpm-repo私仓工具包请前往ohpm-repo私仓工具包获取地址

更多信息与搭建流程参考ohpm-repo私仓搭建工具FAQ

3、常见问题

如何正确处理HAR/HSP包模块间的依赖关系?

  • 推荐方式:import { add } from "library"。

  • 不推荐方式:使用相对路径或绝对路径进行引用:虽然技术上可行,但这种做法不推荐。使用相对或绝对路径引用模块会破坏模块间的隔离性,增加团队开发的管理和沟通成本,且难以维护。例如:import { add } from "../../library/src/main/ets/page/Index"。

为了保持代码的模块化、提高可维护性以及降低团队协作的复杂度,推荐使用包名进行模块间的依赖引用。避免使用相对或绝对路径,以维护项目的结构清晰和高效的团队合作。

HSP模块找不到?

该场景常常存在于hap依赖hsp模块的工程中,直接通过IDE安装至手机不会有问题,但是通过build > build hap编出来的hap包无法安装,是因为hsp是独立存在的,hsp和hap需要同时安装。

类似的多模块调试问题,请按需勾选Deploy Multi Hap Packages、Auto Dependencies。

更多内容请参考安装多个模块自动安装依赖

是否允许HAR的循环依赖?

不允许循环依赖。

是否允许传递依赖?

不支持传递依赖。

间接依赖的版本是不可控的,如果代码里使用到某个版本的间接依赖,不同时间安装的依赖可能版本不一致,程序运行可能出现意想不到的错误。举例说明:依赖关系:project->A(1.0.0)->B(^1.0.0)->C (latest)。

在dependencies只声明了A,但是工程中import了B和C。而B和C的版本是不可控的,如果C的开发者发布了一个2.0.0的版本,下次安装依赖时,可能会安装C的2.0.0的版本。然后就有可能出现一些问题,例如:在代码没有任何改动的情况下,程序运行却出现报错,不同时间不同PC上构建的应用运行表现不一致等。

所以ohpm为了解决幽灵依赖的问题,设计了一个特殊的存储结构,从技术上进行限制、不允许引用间接依赖,从而避免出现幽灵依赖问题。在上述例子中表现是:代码里只能引用A,引用B或C就会编译报错,提醒用户修改依赖配置。

HarmonyOS NEXT SDK版本不一致的情况下覆盖安装会报错。那么用户通过应用商店更新时,SDK版本不一致的包是否也会影响用户安装?

应用更新包的检查逻辑为:当两个版本的versionCode相同时,会检查apiReleaseType、minAPIVersion、targetAPIVersion,如果不一致则会报错。

因此sdk版本变更后,在编译打包前升级app.json5文件下的versionCode,即可实现覆盖安装。

oh-package.json5中版本号前^和~符号的含义?

版本号分为major、minor、patch,分别对应第一、二、三位。

  • 主版本号(major):当做了不兼容的API修改。

  • 次版本号(minor):当做了向下兼容的功能性新增,理解为Feature版本。

  • 修订号(patch):当做了向下兼容的问题修正,理解为Bug fix版本。

^表示从左边起,第一位非0数字不变,后续位大于等于当前版本。例如:

^1.2.2 代表 1.2.2 <= v < 2.0.0

^0.1.2 代表 0.1.2 <= v < 0.2.0

^0.0.1 代表 0.0.1 <= v < 0.0.2

~表示如果有第二位,则第二位不变,第三位可变;如果没有第二位,则第一位不变,第二、三位可变,例如:

~1.2.0 代表 1.2.0 <= x < 1.3.0

~1.3 代表 1.3.0 <= x < 1.4.0

~2 代表 2.0.0 <= x < 3.0.0


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


 更多问题可关注:

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

公开课:华为开发者学堂

原文地址:https://my.oschina.net/u/9174168/blog/18452076

免责声明:本文来源于互联网,版权归合法拥有者所有,如有侵权请公众号联系管理员

* 本站提供的一些文章、资料是供学习研究之用,如用于商业用途,请购买正版。

游戏技术分享