背景
在Android或iOS开发时经常会有打“马甲”包的场景,就是一套代码打出不同主题的包,一个公司的产品可能针对不同用户提供不同的应用,比如抖音有国内版也有国外版,滴滴有个人版还有企业版,同样的在鸿蒙平台也有类似的诉求,本文我们讨论鸿蒙平台的多产物构建。
HarmonyOS 工程配置文件说明
下面是一个最简单的鸿蒙工程截图:
工程 build-profile.json5
在一个标准的Android工程中,工程下的模块使用setting.gradle
来声明,对应的鸿蒙应用的模块配置在build-profile.json5
中:
{
"app": {
"signingConfigs": [],
"products": [
{
"name": "default",
"signingConfig": "default",
"compatibleSdkVersion": "5.0.0(12)",
"runtimeOS": "HarmonyOS",
}
],
"buildModeSet": [
{
"name": "debug",
},
{
"name": "release"
}
]
},
"modules": [
{
"name": "entry",
"srcPath": "./entry",
"targets": [
{
"name": "default",
"applyToProducts": [
"default"
]
}
]
}
]
}
modules列表中声明模块,其中:
- name:模块名
- srcPath:模块对应路径
- targets:构建目标
注意: 这里跟Android有两个不同:
- 一个工程中只允许有一个entry模块,比如一个SDK工程中想创建两个demo应用模块是不允许的;
- srcPath路径只能指向工程根目录和子目录,而不能指向不在工程目录下的模块,比如工程A想源码依赖另一个工程B中的模块是不允许的;
模块 build-profile.json5
{
"apiType": "stageMode",
"buildOption": {
},
"buildOptionSet": [
{
"name": "release",
"arkOptions": {
"obfuscation": {
"ruleOptions": {
"enable": true,
"files": [
"./obfuscation-rules.txt"
]
}
}
}
},
],
"targets": [
{
"name": "default"
},
{
"name": "ohosTest",
}
]
}
- apiType:API模型类型
- stageMode:长期演进的模型,官方推荐使用该模型
- faMode:FA模型
- buildOptionSet:编译配置集合,主要包含混淆配置规则等。
- targets:构建目标
module.json5
在模块/main/
下的module.json5
示例:
{
"module": {
"name": "entry",
"type": "entry",
"description": "$string:module_desc",
"mainElement": "EntryAbility",
"deviceTypes": [
"phone",
"tablet",
"2in1"
],
"deliveryWithInstall": true,
"installationFree": false,
"pages": "$profile:main_pages",
"abilities": [
{
"name": "EntryAbility",
"srcEntry": "./ets/entryability/EntryAbility.ets",
"description": "$string:EntryAbility_desc",
"icon": "$media:layered_image",
"label": "$string:EntryAbility_label",
"startWindowIcon": "$media:startIcon",
"startWindowBackground": "$color:start_window_background",
"exported": true,
"skills": [
{
"entities": [
"entity.system.home"
],
"actions": [
"action.system.home"
]
}
]
}
],
"extensionAbilities": [
{
"name": "EntryBackupAbility",
"srcEntry": "./ets/entrybackupability/EntryBackupAbility.ets",
"type": "backup",
"exported": false,
"metadata": [
{
"name": "ohos.extension.backup",
"resource": "$profile:backup_config"
}
],
}
]
}
}
主要作用类似于Android中的AndroidManifest,声明模块信息、deviceTypes等。
- name:标识当前Module的名称,确保该名称在整个应用中唯一。取值为长度不超过31字节的字符串,不支持中文。应用升级时允许修改该名称,但需要应用适配Module相关数据目录的迁移
- type:标识当前Module的类型。支持的取值如下:
- entry:应用的主模块。
- feature:应用的动态特性模块。
- har:静态共享包模块。
- shared:动态共享包模块。
- srcEntry:标识当前Module所对应的代码路径,取值为长度不超过127字节的字符串。
- description:标识当前Module的描述信息,取值为长度不超过255字节的字符串,可以采用字符串资源索引格式。
- deviceTypes:标识当前Module可以运行在哪类设备上。
- deliveryWithInstall:标识当前Module是否在用户主动安装的时候安装,即该Module对应的HAP是否跟随应用一起安装。
- true:主动安装时安装。
- false:主动安装时不安装。
- requestPermissions:标识当前应用运行时需向系统申请的权限集合。
- dependencies:标识当前模块运行时依赖的共享库列表。
- targetModuleName:标识当前包所指定的目标module,确保该名称在整个应用中唯一。取值为长度不超过31字节的字符串,不支持中文。配置该字段的Module具有overlay特性。仅在动态共享包(HSP)中适用。
更多具体说明参考文档:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/module-configuration-file-V5
官方推荐模块结构
由于平级目录进行模块管理有两个缺陷不利于开发及后期维护:
- 工程逻辑结构混乱
- 模块间的依赖关系不够清晰
官方推荐common、features、product三层工程结构:
/application
├── common # 公共特性目录
│
├── features # 功能模块目录
│ ├── feature1 # 子功能
│ ├── feature2 # 子功能2
│ └── ... # 子功能n
│
└── product # 产品层目录
├── wearable # 智能穿戴泛类目录
├── default # 默认设备泛类目录
└── ...
product与target介绍
在介绍多目标产物构建前先介绍下target和product的概念:
- target:工程内的每一个Entry/Feature模块,对应的构建产物为HAP,HAP是应用/服务可以独立运行在设备中的形态。由于在不同的业务场景中,同一个模块可能需要定制不同的功能或资源,因此引入target的概念。一个模块可以定义多个target,每个target对应一个定制的HAP,通过配置可以实现一个模块构建出不同的HAP。
- product:一个HarmonyOS工程的构建产物为APP包,APP包用于应用/服务发布上架应用市场。由于不同的业务场景,需要定制不同的应用包,因此引入product概念。一个工程可以定义多个product,每个product对应一个定制化应用包,通过配置可以实现一个工程构建出多个不同的应用包。
最佳实践
目标
要开发一个SDK,这个SDK上面又封装了两个SDK,这两个SDK分别额外实现了ToB和ToC业务的功能,这三个SDK在一个工程中,开发调试时最方便的方式就是可以有三个Demo分别调试这三个不同的SDK。
方案
由于HarmonyOS工程中只能有一个可运行的entry模块,所以创建三个demo分别运行的方式无法跑通。
"modules": [
{
"name": "app",
"srcPath": "./app",
"targets": [
{
"name": "default",
"applyToProducts": [
"default"
]
}
]
},
{
"name": "app_c",
"srcPath": "./app_c",
"targets": [
{
"name": "default",
"applyToProducts": [
"default"
]
}
]
},
{
"name": "app_b",
"srcPath": "./app_b",
"targets": [
{
"name": "default",
"applyToProducts": [
"default"
]
}
]
}
]
虽然在build_profile中声明了三个带targets模块,但是只有第一个可以运行。
方案一
可以通过把其他两个配置注释掉,使用运行哪个打开哪个的方式调试,这样的缺点就是每次调试不同模块都需要修改代码。
方案二
Biz2B和Biz2C模块合成一个模块,定义连个target,用不同代码路径区分2B或者2C,但是Biz2B和Biz2C是两个对外独立的SDK,合成一个模块无法对外差异化提供。
方案三
Biz2B和Biz2C模块各自创建两个target,分别是2B和2C,配置源码模块分别制定不同路径,Biz2B模块的2Ctarget指向空路径,这样demo工程虽然依赖了2B模块,但是调试2C的target不会有任何Biz2B的代码。可是使用模块级build_profile.json5中的sourceRoots属性,制定源码路径。
参考文档
- https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/ide-customized-multi-targets-and-products-guides-0000001731595144-V5#section2554174114463
- https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/ide-using-V5
本站资源均来自互联网,仅供研究学习,禁止违法使用和商用,产生法律纠纷本站概不负责!如果侵犯了您的权益请与我们联系!
转载请注明出处: 免费源码网-免费的源码资源网站 » HarmonyOS多目标产物构建最佳实践
发表评论 取消回复