ohpm探索：不只是第三方库管理工具

在根据方舟运行时使用指南进行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

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

/*
 * 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

// [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：

- **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。