【HarmonyOS Next之旅】DevEco Studio使用指南(三十六) -> 配置构建(三)

【HarmonyOS Next之旅】DevEco Studio使用指南(三十六) -> 配置构建(三)

目录

1 -> 定制HAR多目标构建产物

1.1 -> 定义产物的deviceType

1.2 -> 定义C++工程依赖的.so文件

1.3 -> 定义产物的资源

2 -> 配置APP多目标构建产物

2.1 -> 定义产物的APP包名和供应商名称

2.2 -> 定义product的bundleName

2.3 -> 定义product的bundleType

2.4 -> 定义product的签名配置信息

2.5 -> 定义product的icon和label

2.6 -> 定义product中包含的target

3 -> 多产物构建target


1 -> 定制HAR多目标构建产物

每一个HAR模块均支持定制不同的target,通过在模块中的build-profile.json5文件中实现差异化定制,当前支持设备类型(deviceType)、资源(resource)、buildOption配置项(如C++依赖的.so、混淆配置、abi类型、cppFlags等)、源码集(source)的定制。

说明

当前版本,在DevEco Studio中编译时,仅支持编译target为default的模块。若需指定其他target,需通过命令行来指定,并通过命令行来编译。

例如构建指定的自定义target:free的har,可参考执行以下命令:

hvigorw --mode module -p product=default -p module=library@free -p buildMode=debug assembleHar

1.1 -> 定义产物的deviceType

每一个target均可以指定支持的设备类型deviceType,也可以不定义。如果不定义,则该target默认支持config.json或module.json5中定义的设备类型。

同时,在定义每个target的deviceType时,支持的设备类型必须在config.json或module.json5中已经定义。例如,在上述定义的2个target中,分别定义default默认支持所有设备类型,free版本只支持2in1设备。

{ "apiType": 'stageMode', "buildOption": { }, "targets": [ { "name": "default" //未定义deviceType,默认支持config.json或module.json5中定义的设备类型 }, { "name": "free", "config": { "deviceType": [ //定义free支持的设备类型为2in1 "2in1" ] } } ] }

1.2 -> 定义C++工程依赖的.so文件

在 C++ 工程中,可以对每个target依赖的.so文件进行定制。例如某模块依赖了function1.so、function2.so和function3.so三个文件,其中target为default的产物依赖了function1.so和function2.so;其中target为vip的产物依赖了function1.so和 function3.so,则示例代码如下所示:

{ "apiType": 'stageMode', "buildOption": { "externalNativeOptions": { "path": "./src/main/cpp/CMakeLists.txt", "arguments": [], "abiFilters": [ "arm64-v8a", "x86_64" ], "cppFlags": "", } }, "targets": [ //定义不同的target { "name": "default", "config": { "buildOption": { "nativeLib": { "filter": { //按照.so文件的优先级顺序,打包最高优先级的function1.so文件 "pickFirsts": [ "**/function1.so" ], //排除不打包的function3.so文件 "excludes": [ "**/function3.so" ], //允许当.so中资源重名冲突时,使用高优先级的.so文件覆盖低优先级的.so文件 "enableOverride": true } } } } }, { "name": "vip", "config": { "buildOption": { "nativeLib": { "filter": { //按照.so文件的优先级顺序,打包最高优先级的function1.so文件 "pickFirsts": [ "**/function1.so" ], //排除不打包的function2.so文件 "excludes": [ "**/function2.so" ], //允许当.so中资源重名冲突时,使用高优先级的.so文件覆盖低优先级的.so文件 "enableOverride": true } } } } } ] }

1.3 -> 定义产物的资源

每个target使用的资源文件可能存在差异,在开发过程中,开发者可以将每个target所使用的资源存放在不同的资源目录下。其中,ArkTS工程支持对main目录下的资源文件目录(resource)进行定制;JS工程支持对main目录下的资源文件目录(resource)及Ability下的资源文件目录(res)进行定制。如下为ArkTS工程的资源文件目录定制示例:

{ "apiType": 'stageMode', "buildOption": { }, "targets": [ { "name": "default", "resource": { //定义默认版target使用的资源文件目录 "directories": [ "./src/main/resources_default" ] } }, { "name": "free", "config": { "deviceType": [ "2in1" ] }, "resource": { //定义免费版target使用的资源文件目录 "directories": [ "./src/main/resources_default", "./src/main/resources_free" ] } }, ] }

2 -> 配置APP多目标构建产物

APP用于应用/元服务上架发布,针对不同的应用场景,可以定制不同的product,每个product中支持对bundleName、bundleType、签名信息、icon和label以及包含的target进行定制。

定义目标产物product

每一个product对应一个定制的APP包,因此,在定制APP多目标构建产物前,应提前规划好需要定制的product名称。例如,定义productA和productB。工程级build-profile.json5文件示例如下:

在定制product时,必须存在"default"的product,否则编译时会出现错误。

"app": { "signingConfigs": [], "products": [ { "name": "default", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", }, { "name": "productA", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", }, { "name": "productB", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", } ], "buildModeSet": [ { "name": "debug", }, { "name": "release" } ] }

2.1 -> 定义产物的APP包名和供应商名称

每一个product均可以指定产物命名和供应商名称。

{ "app": { "signingConfigs": [], "products": [ { "name": "default", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "output": { "artifactName": "customizedProductOutputName-1.0.0" //产物名称为customizedProductOutputName-1.0.0 }, "vendor": "customizedProductVendorName" //供应商名称为customizedProductVendorName }, { "name": "productA", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "output": { "artifactName": "customizedProductOutputNameA-1.0.0" //产物名称为customizedProductOutputNameA-1.0.0 }, "vendor": "customizedProductVendorNameA" //供应商名称为customizedProductVendorNameA }, { "name": "productB", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "output": { "artifactName": "customizedProductOutputNameB-1.0.0" //产物名称为customizedProductOutputNameB-1.0.0 }, "vendor": "customizedProductVendorNameB" //供应商名称为customizedProductVendorNameB } ], "buildModeSet": [ { "name": "debug", }, { "name": "release" } ] }, }

如果已配置签名,product产物对应的APP包名为开发者定制的名称;如果未配置签名,product产物对应的APP包名为定制的名称+unsigned。

2.2 -> 定义product的bundleName

针对每个定义的product,均可以定制不同的bundleName,如果product未定义bundleName,则采用工程默认的bundleName。示例如下所示:

"app": { "signingConfigs": [], "products": [ { "name": "default", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example00.com" //定义default的bundleName信息 }, { "name": "productA", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example01.com" //定义productA的bundleName信息 }, { "name": "productB", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example02.com" //定义productB的bundleName信息 } ], "buildModeSet": [ { "name": "debug", }, { "name": "release" } ] }

2.3 -> 定义product的bundleType

针对每个定义的product,均可以定制不同的bundleType。开发者可以通过定义每个product的bundleType,分别定义产物类型:

  • bundleType值为app,表示产物为应用;
  • bundleType值为atomicService,表示产物为元服务。

如果product未定义bundleType,则采用工程的bundleType(即创建工程时选择的Application/Atomic Service)。示例如下所示:

"app": { "signingConfigs": [], "products": [ { "name": "default", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example00.com", "bundleType": "app" //定义default的bundleType信息 }, { "name": "productA", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example01.com", "bundleType": "atomicService" //定义productA的bundleType信息 }, { "name": "productB", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example02.com", "bundleType": "atomicService" //定义productB的bundleType信息 } ], "buildModeSet": [ { "name": "debug", }, { "name": "release" } ] }

2.4 -> 定义product的签名配置信息

针对每个定义的product,均可以定制不同的signingConfig签名文件,如果product未定义signingConfig,则构建生成未签名的APP包。

通常情况下,您首先需要在签名配置界面或工程的build-profile.json5文件中配置签名信息。例如在File > Project Structure > Project > Signing Configs界面,分别配置default、productA和productB的签名信息,如下图所示:

签名信息配置完成后,再添加各个product对应的签名文件,示例如下所示:

您也可以提前在product中定义签名文件信息,然后在签名界面对每个product进行签名,确保配置的product签名文件与签名界面配置的签名文件保持一致即可。

"app": { "signingConfigs": [], //此处通过界面配置签名后会自动生成相应的签名配置,本文略 "products": [ { "name": "default", "signingConfig": "default", //定义default的签名文件信息 "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example00.com" }, { "name": "productA", "signingConfig": "productA", //定义productA的签名文件信息 "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example01.com" }, { "name": "productB", "signingConfig": "productB", //定义productB的签名文件信息 "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example02.com" } ], "buildModeSet": [ { "name": "debug", }, { "name": "release" } ] }

2.5 -> 定义product的icon和label

针对每个定义的product,均可以定制不同的icon和label,如果product未定义icon和label,则采用工程默认的icon和label。示例如下所示:

说明

products中的icon和label字段在编译时会替换app.json5中对应的字段,app.json5和module.json5均可以配置这两个字段。

{ "app": { "signingConfigs": [], "products": [ { "name": "default", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "icon":"$media:default_icon", //定义default的icon "label":"$string:default_name", //定义default的label }, { "name": "productA", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "icon":"$media:productA_icon", //定义productA的icon "label":"$string:productA_name", //定义productA的label }, { "name": "productB", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "icon":"$media:productB_icon", //定义productB的icon "label":"$string:productB_name", //定义productB的label } ], "buildModeSet": [ { "name": "debug", }, { "name": "release" } ] }, ... }

2.6 -> 定义product中包含的target

可以选择需要将定义的target分别打包到哪一个product中,每个product可以指定一个或多个target。

同时每个target也可以打包到不同的product中,但是同一个module的不同target不能打包到同一个product中(除非该module的不同target配置了不同的deviceType或distributionFilter/distroFilter)。

例如,前面定义了default、free和pay三个target,现需要将default target打包到default product中;将free target打包到productA中;将pay target打包到productB中,对应的示例代码如下所示:

{ "app": { "signingConfigs": [], //此处通过界面配置签名后会自动生成相应的签名配置,本文略 "products": [ { "name": "default", "signingConfig": "default", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example00.com" }, { "name": "productA", "signingConfig": "productA", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example01.com" }, { "name": "productB", "signingConfig": "productB", "compatibleSdkVersion": "5.0.2(14)", "runtimeOS": "HarmonyOS", "bundleName": "com.example02.com" } ], "modules": [ { "name": "entry", "srcPath": "./entry", "targets": [ { "name": "default", //将default target打包到default APP中 "applyToProducts": [ "default" ] }, { "name": "free", //将free target打包到productA APP中 "applyToProducts": [ "productA" ] }, { "name": "pay", //将pay target打包到productB APP中 "applyToProducts": [ "productB" ] } ] } ] }

3 -> 多产物构建target

align target:编译构建时,优先级最高的target。工程配置align target后,如果模块中存在align target,那么将自动选择align target进行构建。align target作用范围是整个工程,只能配置一个,支持命令行和配置文件两种方式。

  • 命令行方式示例如下:
hvigorw -c properties.ohos.align.target=target1 assembleHap
  • 在hvigor-config.json5配置文件中添加ohos.align.target,示例如下:
"properties": { 'ohos.align.target': 'target1' },

fallback target:当模块不存在指定的target时会选用default进行构建,但如果不想用default进行构建,那么可以配置fallback target,当找不到指定target时,如果模块中存在fallback target,则使用fallback target进行构建。fallback target作用范围是整个工程,可配置多个,配置多个时按数组顺序先命中的生效。

  • 命令行方式示例如下:
hvigorw -c properties.ohos.fallback.target=target1,target2 assembleHap
  • 在hvigor-config.json5配置文件中添加ohos.fallback.target,示例如下:
"properties": { 'ohos.fallback.target': ['target1', 'target2'] }

说明

  • align target和fallback target配置方式命令行优先级高于配置文件。
  • 使用配置文件配置align target和fallback target,仅支持DevEco Studio界面Build菜单栏功能,不支持Run菜单栏功能,可通过hdc命令行工具进行推包运行、调试。

多个target的优先级顺序为:align target > 命令行指定模块target > 父级模块target > fallback target > default。

举例说明:

工程依赖entry->lib1->lib2,需要构建多个产品A、B、C,工程中target配置如下:

entry: A、B、default

lib1: B、C、default

lib2: A、C、default

指定align target为A,fallback target为C。那么构建hap时的编译命令为:

hvigorw --mode module -p module=entry -c properties.ohos.align.target=A -c properties.ohos.fallback.target=C assembleHap

编译的target选择就是:entry@A, lib1@C, lib2@A。

说明

以上所有说明仅针对非ohosTest模式。在ohosTest模式下,依赖的target固定为default,其他target均不生效。


感谢各位大佬支持!!!

互三啦!!!

Read more

JAVA IO流:从基础原理到实战应用

JAVA IO流:从基础原理到实战应用

JAVA IO流:从基础原理到实战应用 1.1 本章学习目标与重点 💡 掌握IO流的核心概念与分类,理解字节流与字符流的区别和适用场景。 💡 熟练使用字节流完成文件的读取与写入操作,解决文件拷贝等实际问题。 💡 掌握字符流的使用方法,处理文本文件的编码与解码问题。 💡 了解缓冲流、转换流、对象流等高级IO流的原理,提升IO操作效率。 ⚠️ 本章重点是 字节流与字符流的核心用法 和 高级IO流的实战应用,这是JAVA文件操作的必备技能。 1.2 IO流核心概念与分类 1.2.1 什么是IO流 💡 IO流(Input/Output Stream)是JAVA中用于处理设备之间数据传输的技术,主要负责数据的读取(Input)和写入(Output)。 常见的IO操作包括文件读写、网络通信数据传输等。IO流的核心思想是以流的方式处理数据,数据像水流一样从一个设备流向另一个设备,实现数据的传输与处理。 1.2.2 IO流的分类标准 JAVA中的IO流体系庞大,可按照不同标准进行分类,核心分类方式有以下三种: 1.

By Ne0inhk
Flutter 三方库 algolia_client_recommend 的鸿蒙化适配指南 - 打造 AI 驱动的个性化推荐引擎、助力鸿蒙端电商与内容应用转化率倍增

Flutter 三方库 algolia_client_recommend 的鸿蒙化适配指南 - 打造 AI 驱动的个性化推荐引擎、助力鸿蒙端电商与内容应用转化率倍增

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 algolia_client_recommend 的鸿蒙化适配指南 - 打造 AI 驱动的个性化推荐引擎、助力鸿蒙端电商与内容应用转化率倍增 前言 在 OpenHarmony 鸿蒙应用全场景连接的商业版图中,“信息找人”已成为提升流量价值的核心逻辑。无论是电商应用的“经常一起购买”,还是内容平台的“相关推荐”,高质量的个性化算法能显著降低用户的决策成本。algolia_client_recommend 作为一个连接 Algolia 顶尖 AI 推荐服务的专业客户端,为开发者提供了一套开箱即用的推荐逻辑封装。本文将详述如何在鸿蒙端利用此库构建“读懂用户”的智能化交互。 一、原原理分析 / 概念介绍 1.1 基础原理 algolia_client_recommend 的核心逻辑是 基于意图建模的异步推荐查询与联合过滤机制

By Ne0inhk
新一代 AI 编程工具 Google Antigravity 下载与安装指南

新一代 AI 编程工具 Google Antigravity 下载与安装指南

Google Antigravity 下载与安装指南 2025 年 11 月 18 日,Google 向开发者社区投下了一颗重磅炸弹:在发布 Gemini 3 最强大语言模型的同时,同步推出了 Antigravity——一款免费的「智能体化」开发平台。 这并不是一次临时起意的突袭。早在 2025 年 7 月,Google 就斥资 24 亿美元收购了 Windsurf 团队,CEO Varun Mohan 及核心工程人才悉数加入 Google DeepMind。Antigravity 正是这次战略布局的结晶——它不只是提供代码建议,而是能自主规划、编写、测试并验证整个应用程序。这意味着,开发者可以从繁琐的语法细节中解放出来,将精力聚焦于系统架构与核心业务逻辑。 接下来,我们将详细介绍如何在 Mac、

By Ne0inhk
【TRAE】AI 编程:AI 驱动下的 Vue 全栈实战——从 TRAE 工具入门到项目落地

【TRAE】AI 编程:AI 驱动下的 Vue 全栈实战——从 TRAE 工具入门到项目落地

目录 一、TRAE 简介 (1)产品愿景 (2)核心定位 (3)核心模式 ① SOLO 模式 / Builder 模式 ② IDE 模式 / Chat 模式 (4)核心功能与体验 ① 全场景开发支持 ② Cue 智能续写(升级) ③ 深度上下文感知 ④ 智能排查 Bug (5)智能体生态 ① 可自定义智能体 ② 工具自由装配 (via MCP) ③ Trae Rules ④ 智能体市场 (6)支持模型 (7)平台与获取 (8)隐私与安全 ① 原则 ② 数据隐私 ③ 安全控制 ④ 区域化部署 (9)核心价值 二、TRAE

By Ne0inhk