OpenHarmony开发者论坛

标题: ohpm探索：不只是第三方库管理工具 [打印本页]

作者: u8f-nKs9 时间: 2025-12-20 17:34
标题: ohpm探索：不只是第三方库管理工具
[md]在根据[方舟运行时使用指南](https://gitee.com/openharmony/ar ... 8%E6%8C%87%E5%8D%97)进行ArkCompiler编译的时候，发现编译过程中存在对ohpm的使用。然而无论官方还是民间文档都只提到过ohpm管理第三方库的作用，所以本人尝试探索了一下ohpm在这里的作用。

# 编译日志中的 `ohpm` 相关信息

编译脚本在构建开始前，首先启动了 `ohpm` 的初始化流程。具体信息按时间顺序如下：

| 阶段                | 信息类型       | 具体内容                                                                                                                                                                                                       |
| :------------------- | :-------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **初始化开始** | `[OHOS INFO]` | `Ohpm initialization started...`                                                                                                                                                                            |
| 版本检查          | `[OHOS INFO]` | `Current ohpm version is 5.0.8`                                                                                                                                                                            |
| 环境警告          | `ohpm WARN` | `Your "NodeJs" version is less than the recommended version "18.x.x", please upgrade it as soon as possible.`                                                                                              |
| **配置设置** | `ohpm DEBUG`  | 1.`config set registry https://repo.harmonyos.com/ohpm/` <br> 2. `config set strict_ssl false` <br> 3. `config set log_level debug`                                                                      |
| **审计失败** | `ohpm DEBUG`  | **`Audit failed, detail: the trace log file path is not exist! trace path: /home/ushio/Library/Caches/Huawei/DevEcoStudio5.0/TraceLogData`** <br> *（在每次 `config set`操作后均出现一次，共三次）* |
| **工具安装** | `[OHOS INFO]` | 1.`installing pnpm...` <br> 2. `installing hypium...`                                                                                                                                                    |
| **初始化完成** | `[OHOS INFO]` | `ohpm initialization successful!`                                                                                                                                                                            |

# 为什么运行时编译中会出现ohpm？

从日志判断，ohpm在构建开始前应该执行了一些**关键的环境初始化工作**：

* **设置包仓库源**：将 registry 指向华为官方仓 `https://repo.harmonyos.com/ohpm/`，这是后续下载任何依赖的基础。
* **安装构建工具**（是否由ohpm进行存疑）：安装了 `pnpm`（一个高性能的Node.js包管理器）和 `hypium`（OpenHarmony的测试框架）。这可能意味着 **`ohpm` 负责管理构建工具链本身的依赖**，而不仅仅是应用层的第三方库。
* **配置构建环境**：设置了日志级别和SSL验证等参数。

因此，`ohpm` 或许是**OpenHarmony构建系统的一个基础组件**，它确保编译所需的工具和依赖是正确的版本且可用。可以把它理解为OpenHarmony生态的“**基础设施包管理器**”。

# 管理第三方库是ohpm的唯一作用吗？

从这次编译过程来看，ohpm的作用不止“应用级第三方库管理”，也是**OpenHarmony 的官方包管理工具**。
**管理范围**：其管理的“包”包括：

- **应用开发库**：通常所说的“第三方库”（如UI组件、网络库等）。
- **构建工具链**：如日志中安装的 `pnpm`、`hypium`，以及其他编译、测试、调试工具。
- **系统组件/运行时依赖**：一些系统级的模块或运行时也可能通过 `ohpm` 来管理版本和依赖。
  **简单来说，`ohpm` 管理的是整个OpenHarmony开发生态（从系统构建到应用开发）中所需要的各种软件包。** 这就是为什么在编译Ark运行时这样的基础模块时，它也必须先行启动并完成配置。

## 为什么会出现这种角色差异？

这样的设计可能基于以下原因：

1. **统一依赖管理**：OpenHarmony可能希望用OHPM这一套工具来**统一管理所有依赖**，无论是应用层的功能库，还是构建系统本身的工具链。这能简化整个生态的包管理模型。
2. **动态环境准备**：构建像ArkJS这样的大型项目，需要一个特定版本的构建环境（如特定版本的Node.js包管理器）。让OHPM在编译开始时自动准备这些环境，可以确保**每次构建的环境都是一致且隔离的**。

# 相关代码证明

> 以下代码皆来自OpenHarmony开源仓库。

## build.sh

```bash
function init_ohpm() {
  TOOLS_INSTALL_DIR="${SOURCE_ROOT_DIR}/prebuilts/build-tools/common"
  pushd ${TOOLS_INSTALL_DIR} > /dev/null
OHPM_HOME=${TOOLS_INSTALL_DIR}/../../tool/command-line-tools/ohpm/bin
chmod +x ${OHPM_HOME}/ohpm
export PATH=${OHPM_HOME}

PATH
chmod +x ${OHPM_HOME}/init
${OHPM_HOME}/init > /dev/null
echo "[OHOS INFO] Current ohpm version is $(ohpm -v)"
ohpm config set registry https://repo.harmonyos.com/ohpm/
ohpm config set strict_ssl false
ohpm config set log_level debug
  popd > /dev/null
  if [[ -d "$HOME/.hvigor" ]]; then
rm -rf $HOME/.hvigor/daemon $HOME/.hvigor/wrapper
  fi
  mkdir -p $HOME/.hvigor/wrapper/tools
  echo '{"dependencies": {"pnpm": "7.30.0"}}' > $HOME/.hvigor/wrapper/tools/package.json
  pushd $HOME/.hvigor/wrapper/tools > /dev/null
echo "[OHOS INFO] installing pnpm..."
npm install --silent > /dev/null
  popd > /dev/null
  mkdir -p $HOME/.ohpm
  echo '{"devDependencies":{"@ohos/hypium":"1.0.6"}}' > $HOME/.ohpm/oh-package.json5
  pushd $HOME/.ohpm > /dev/null
echo "[OHOS INFO] installing hypium..."
ohpm install > /dev/null
  popd > /dev/null
}
```

`build.sh` 脚本是 OpenHarmony 构建系统的**主入口和前置环境准备脚本**，在这里能看到在编译过程中为什么会发生ohpm初始化。以上为ohpm初始化函数。

## oh-package-lock.json

```json
/*
* Copyright (c) 2025 Shenzhen Kaihong Digital Industry Development Co., Ltd.
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*    http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
{
  "meta": {
"stableOrder": true
  },
  "lockfileVersion": 3,
  "ATTENTION": "THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.",
  "specifiers": {
"@ohos/hypium@1.0.6": "@ohos/hypium@1.0.6"
  },
  "packages": {
"@ohos/hypium@1.0.6": {
   "name": "@ohos/hypium",
   "version": "1.0.6",
   "integrity": "sha512-bb3DWeWhYrFqj9mPFV3yZQpkm36kbcK+YYaeY9g292QKSjOdmhEIQR2ULPvyMsgSR4usOBf5nnYrDmaCCXirgQ==",
   "resolved": "https://ohpm.openharmony.cn/ohpm/@ohos/hypium/-/hypium-1.0.6.tgz",
   "shasum": "3f5fed65372633233264b3447705b0831dfe7ea1",
   "registryType": "ohpm"
}
  }
}
```

`test\xts\tools\sample\ui_compare\uiCompareTest_05\oh-package-lock.json5` 文件中可以看出，OpenHarmony的官方测试工具包 `@ohos/hypium` 和 `@ohos/hamock` 的下载地址是 `https://ohpm.openharmony.cn/ohpm/`。这直接证明ohpm管理的不仅是社区“第三方库”，还包括**华为/OpenHarmony官方的工具链和系统组件**。

## use-napi-load-module.md和arkts-dynamic-import.md

**docs\zh-cn\application-dev\napi\use-napi-load-module.md**

```c++
// [Start napi_load_module_napi_ohpm]
static napi_value loadModule(napi_env env, napi_callback_info info)
{
napi_value result;
// 1. 使用napi_load_module加载@ohos/axios
napi_status status = napi_load_module(env, "@ohos/axios", &result);
if (status != napi_ok) {
      return nullptr;
}

napi_value key;
std::string keyStr = "VERSION";
napi_create_string_utf8(env, keyStr.c_str(), keyStr.size(), &key);
// 2. 使用napi_get_property获取VERSION
napi_value defaultValue;
napi_get_property(env, result, key, &defaultValue);
return result;
}
// [End napi_load_module_napi_ohpm]
```

这段代码是 **ArkTS/JS运行时（NAPI接口）的C++扩展**，它演示了如何从原生侧动态加载一个由ohpm管理的模块。
底层C++ API可以直接加载 `@ohos/axios`、`@ohos/crypto-js` 等模块。结合文档和 `oh-package-lock.json` 可知，这些模块正是通过ohpm进行分发的官方包。这揭示了从应用层API调用到底层包管理（ohpm）的完整链路，表明ohpm是官方能力分发的渠道。

**docs\zh-cn\application-dev\arkts-utils\arkts-dynamic-import.md：**

```markdown
- **HAP常量动态import远程HAR模块名**

  ```typescript

  // HAP's src/main/ets/pages/Index.ets

  import('@ohos/crypto-js').then((ns:ESObject) => {

console.info('DynamicImport @ohos/crypto-js: ' + ns.CryptoJS.MD5(123456));

  });

  // HAP's oh-package.json5

  "dependencies": {

"@ohos/crypto-js": "2.0.3-rc.0"

  }
```

上下层对应：ArkTS的 `import('@ohos/xxx')` 在运行时，最终很可能就是通过底层类似于 `napi_load_module(env, “@ohos/xxx“, ...)` 的机制来实现的。

## 结论

将最后的2个文件与之前发现的 `oh-package-lock.json` 结合起来，可以尝试描绘出一个技术闭环：

1. **声明依赖（开发态）**：开发者在 `oh-package.json5` 中写入 `"@ohos/axios": "x.x.x"`。
2. **下载与管理（包管理态）**：**ohpm** 根据配置，从官方仓库下载该包，并将其信息（名称、版本、存储路径）记录在 `oh-package-lock.json` 中。
3. **通知构建（构建态）**：对于动态加载场景，通过 `runtimeOnly` 配置告知构建系统此包为运行时必需。
4. **动态加载（运行态）**：
- **应用层**：ArkTS代码执行 `import('@ohos/axios')`。
- **系统层**：C++/NAPI代码调用 `napi_load_module(env, “@ohos/axios“, ...)`。
- **运行时**：系统根据ohpm管理的模块解析路径，找到并加载对应的代码包，完成动态导入。
   由此可以看出，`@ohos/` **开头的官方包的其分发、管理和运行时加载，整个生命周期都与ohpm工具绑定**。这说明ohpm也是OpenHarmony官方生态的**基础包管理器**，而非仅用于社区第三方库。

# 附记与致谢

本文是笔者在大学课程中完成的作业结果之一。本文通过对ArkCompiler编译流程的跟踪与一些源码分析，尝试理解 `ohpm`工具在构建系统中的实际角色。感谢OpenHarmony开源项目提供的学习机会，也感谢课程老师的指导。文中观点仅为个人基于公开代码的分析，如有理解偏颇之处，欢迎指正。
本文同步发布在华为开发者社区和csdn。
[/md]

欢迎光临 OpenHarmony开发者论坛 (https://forums.openharmony.cn/)