摘要

随着鸿蒙（HarmonyOS / OpenHarmony）应用规模越来越大，单体工程已经很难支撑复杂业务。
不管是日志、网络、加密，还是硬件能力、分布式能力，第三方插件和模块化开发已经是必选项。

在实际开发中，很多同学会遇到这些问题：

• 第三方 SDK 到底该用 HAR 还是 HAP？
• npm 包能不能直接用？
• C/C++ 的库怎么给 ArkTS 调？
• 插件化到底是不是“多写几个 Ability”？

这篇文章就从工程角度出发，结合可运行 Demo，一步一步讲清楚：
鸿蒙中集成第三方插件的几种主流方式，以及在真实项目中该怎么选、怎么用。

引言

从 HarmonyOS NEXT 和 OpenHarmony 的发展来看，官方一直在强调三件事：

1. 模块化
2. 分层架构
3. 能力解耦

这也意味着一个趋势：
以后鸿蒙应用不再是“一个 entry 写到死”，而是多个模块、多个能力拼出来的。

而插件，本质上就是“可复用、可替换、可独立维护的能力模块”。

下面的内容，我会从最常见的方式讲起，再逐步过渡到更偏架构层面的插件化。

通过 HAR / HAP 模块集成第三方插件（最常用）

这是目前最稳、最推荐的一种方式，几乎适用于 80% 的场景。

适合什么情况？

• 第三方 SDK
• 公司内部公共库
• UI 组件库
• 日志、埋点、网络等基础能力

简单说一句：
只要这个插件是“随应用一起发布”的，用 HAR 基本不会错。

Demo 工程结构

MyHarmonyApp/
├── entry/
│   ├── src/main/ets/
│   │   └── pages/Index.ets
│   ├── libs/
│   │   └── logger.har
│   └── build-profile.json5

引入 HAR 模块

在 build-profile.json5 中声明依赖：

{
  "app": {
    "products": [
      {
        "name": "default",
        "modules": ["entry"],
        "dependencies": {
          "logger": {
            "path": "./entry/libs/logger.har"
          }
        }
      }
    ]
  }
}

这里本质上就是告诉构建系统：
这个模块是我项目的一部分。

ArkTS 中调用插件能力

import { Logger } from 'logger';

Logger.init({
  level: 'debug'
});

Logger.info('App started');

这一层用起来，和你平时 import 本地模块几乎没有区别。

实际场景举例

场景一：统一日志系统

在稍微复杂一点的项目中，日志一定不是 console.log 满天飞，而是统一封装。

Logger.info('page enter', { page: 'Home' });
Logger.error('network error', err);

后面你想：

• 换日志实现
• 接入埋点平台
• 分不同构建版本输出

都只需要动插件，不动业务代码。

通过 ohpm / npm 集成 JS 工具类插件

这类方式更偏前端生态，适合纯 JS / TS 工具库。

安装依赖

ohpm install dayjs

或者：

npm install lodash

使用示例

import dayjs from 'dayjs';

const time = dayjs().format('YYYY-MM-DD HH:mm:ss');
console.log(time);

使用时要注意什么？

这里说一句非常现实的话：

• 不是所有 npm 包都能在 ArkTS 跑
• 尤其是依赖 Node API 的，基本会翻车

所以我的建议是：

• 工具类、小而纯的库可以用
• 大而全的前端框架，慎重

实际应用场景

场景二：时间、数据处理工具

比如你在做：

• 日志时间格式化
• 数据统计
• 简单算法处理

这类场景用 npm 包很省事。

import _ from 'lodash';

const result = _.groupBy(dataList, 'type');

三、通过 Native 插件集成 C / C++ 能力

如果你做的是：

• 高性能计算
• 硬件相关能力
• 复用已有 C/C++ 库

那基本绕不开 Native 插件。

Native 模块结构

entry/src/main/cpp/
├── CMakeLists.txt
└── native-lib.cpp

C++ 导出接口示例

#include <napi/native_api.h>

napi_value Add(napi_env env, napi_callback_info info) {
    int32_t a = 3;
    int32_t b = 5;
    napi_value result;
    napi_create_int32(env, a + b, &result);
    return result;
}

NAPI_MODULE_INIT() {
    napi_value fn;
    napi_create_function(env, "add", NAPI_AUTO_LENGTH, Add, nullptr, &fn);
    napi_set_named_property(env, exports, "add", fn);
    return exports;
}

ArkTS 调用 Native 插件

import nativeLib from 'libnative.so';

const sum = nativeLib.add();
console.log(`sum = ${sum}`);

这一步完成之后，你就已经打通了：

ArkTS → Native → 底层能力

实际应用场景

场景三：设备端算法或加密

比如：

• 图片处理
• 数据校验
• 升级包校验（你之前做过这个）

const verified = nativeLib.verifyFile(path);

这些能力放在 Native 层，更安全、也更高效。

通过 Ability / Service 实现真正的插件化

前面几种方式，本质上都是“编译期集成”。

如果你希望：

• 插件可独立升级
• 插件像一个小应用
• 主应用只负责调能力

那就需要 Ability 级插件。

插件 Ability 示例

@Entry
@Component
struct PluginPage {
  build() {
    Column() {
      Text('This is plugin page')
    }
  }
}

主应用调用插件

let want = {
  bundleName: 'com.example.plugin',
  abilityName: 'PluginAbility'
};

this.context.startAbility(want);

适合什么场景？

• 插件市场
• 业务解耦
• 大型应用模块拆分

比如一个主应用，只负责：

• 登录
• 容器
• 权限控制

功能页面全部来自插件 Ability。

QA 环节

Q1：HAR 和 HAP 有什么本质区别？

一句话理解：

• HAR 更像“库”
• HAP 更像“应用模块”

大多数第三方插件，用 HAR 就够了。

Q2：插件能不能热更新？

• HAR / Native：不行（需要随应用更新）
• Ability 插件：可以通过应用升级间接实现

Q3：实际项目里最常用哪种？

真实情况是：

• 80% 用 HAR
• 15% 用 Native
• 5% 用 Ability 插件

总结

在鸿蒙里谈“插件”，不要一开始就想得太复杂。

你可以按这个顺序理解：

1. 普通能力 → HAR
2. 工具类 → npm / ohpm
3. 性能、硬件 → Native
4. 架构级插件 → Ability

从你目前的技术路线来看，HAR + Native 插件这一块非常值得深挖，
不管是做项目、写文章，还是以后面试，都非常加分。