【开源软件移植】鸿蒙 PC 三方库适配实战：从 7-Zip Native 编译到 ArkTS 调用完整跑通

一、写在前面

欢迎加入开源鸿蒙PC社区：https://harmonypc.csdn.net/

这篇文章记录的是把 7-Zip 的 .7z 压缩、校验、解压能力适配成 HarmonyOS / OpenHarmony PC 可复用三方库的完整过程。

sevenzip-ohos 不是把一个前端页面塞进 HAP，也不是处理静态资源路径，而是一次完整的 Native 三方库适配：

• 固定 7-Zip 上游源码版本
• 裁剪 reduced 版 .7z 能力
• 用 CMake 交叉编译鸿蒙 Native .so
• 通过 Node-API 暴露给 ArkTS
• 打成 HAR / OHPM 可复用库
• 写一个 entry Demo 在鸿蒙 PC 真机上完成压缩、测试、解压烟测

最终实测结果如下：

compress: ok=true, code=0, message=Everything is Ok
test: ok=true, code=0, message=Everything is Ok
extract: ok=true, code=0, message=Everything is Ok

也就是说，这条链路已经在鸿蒙 PC 设备上跑通：

ArkTS Demo
  -> HAR Library
  -> libsevenzip_napi.so
  -> Node-API
  -> C++ bridge
  -> 7-Zip 26.01 reduced core
  -> 应用沙箱文件系统

本文不会把它包装成“很简单”。7z 适配真正麻烦的地方不在按钮页面，而在 Native 编译、7-Zip 内部静态注册机制、NAPI 异步任务、签名安装、SDK 环境和文件权限。本文按实战踩坑顺序展开，尽量让下一次复现少走弯路。

本项目开源仓库：https://atomgit.com/weixin_52908342/sevenzip-ohos

---

二、适配目标和边界

本次适配目标是做一个可被 ArkTS 项目引用的 7z 三方库，而不是做一个完整的压缩软件。

首版边界如下：

• 只支持 .7z 格式
• 使用 7-Zip reduced 版源码，不引入 RAR
• 支持压缩、解压、归档测试
• 支持密码参数预留
• 只验证应用沙箱路径
• 首版串行执行任务，不承诺多任务并发
• 不引入汇编优化
• 不改 7-Zip 上游源码，只新增 bridge、NAPI、工程配置

为什么不直接把 7zr 可执行文件塞进应用里？

因为三方库更适合走 .so + ArkTS wrapper + d.ts 的形态。子进程调用可执行文件会带来路径、权限、进度回调、错误码和 ABI 分发问题；同进程 Native 库更符合鸿蒙三方库交付方式。

最终方案是：

7-Zip 26.01 源码
  -> CMake 编译为 Native 对象
  -> libsevenzip_napi.so
  -> ArkTS Promise API
  -> HAR / OHPM 引用

三、环境信息

本次实战环境如下：

系统：Windows
IDE：DevEco Studio
SDK：HarmonyOS 6.0.0 Beta3 / API 20
目标设备：鸿蒙 PC
Native ABI：arm64-v8a
7-Zip 源码：ip7z/7zip tag 26.01

项目路径示例：

C:\Users\24190\Desktop\Harmony\sevenzip-ohos

DevEco Studio 中 SDK 路径要注意。实战中如果把 SDK 指到 default 层级，可能出现：

00303168 Configuration Error
SDK component missing.

命令行或 IDE 中建议 SDK 根路径使用：

E:\DevEco Studio\sdk

而不是：

E:\DevEco Studio\sdk\default

命令行构建时还需要补上 DevEco 自带 JBR：

$env:DEVECO_SDK_HOME='E:\DevEco Studio\sdk'
$env:JAVA_HOME='E:\DevEco Studio\jbr'
$env:PATH='E:\DevEco Studio\jbr\bin;' + $env:PATH

---

四、工程结构

适配完成后的工程结构如下：

sevenzip-ohos/
├── AppScope/
│   ├── app.json5
│   └── resources/
├── entry/                         # 真机烟测 Demo
│   ├── build-profile.json5
│   ├── oh-package.json5
│   └── src/main/
│       ├── module.json5
│       ├── ets/
│       │   ├── entryability/
│       │   └── pages/Index.ets
│       └── resources/
├── library/                       # 可复用 HAR 三方库
│   ├── build-profile.json5
│   ├── oh-package.json5
│   └── src/main/
│       ├── module.json5
│       ├── ets/
│       │   ├── Index.ets
│       │   └── types/SevenZipOptions.ets
│       └── cpp/
│           ├── CMakeLists.txt
│           ├── sevenzip_sources.cmake
│           ├── include/sevenzip_ohos.h
│           ├── bridge/sevenzip_command_bridge.cpp
│           ├── bridge/sevenzip_command_bridge.h
│           ├── napi/sevenzip_napi.cpp
│           ├── types/libsevenzip_napi/index.d.ts
│           └── third_party/7zip/
├── scripts/
│   ├── gen-sevenzip-sources.cjs
│   └── verify-sevenzip-sources.cjs
├── NOTICE
└── README.md

其中 library 是真正要交付的三方库，entry 只是为了在鸿蒙 PC 上跑烟测。

---

五、创建鸿蒙工程和 Library 模块

先创建普通 ArkTS Stage 工程，然后新增一个 Library 模块，模块名建议使用：

library

library/oh-package.json5 中配置三方库包名：

{
  "name": "@your-scope/sevenzip-ohos",
  "version": "0.1.0",
  "description": "7z archive compression library for OpenHarmony / HarmonyOS PC.",
  "main": "src/main/ets/Index.ets",
  "types": "src/main/cpp/types/libsevenzip_napi/index.d.ts",
  "license": "LGPL-2.1-or-later",
  "dependencies": {}
}

entry/oh-package.json5 中引用本地 Library：

{
  "name": "entry",
  "version": "0.1.0",
  "dependencies": {
    "@your-scope/sevenzip-ohos": "file:../library"
  }
}

项目级 build-profile.json5 要同时声明两个模块：

{
  "modules": [
    {
      "name": "entry",
      "srcPath": "./entry"
    },
    {
      "name": "library",
      "srcPath": "./library"
    }
  ]
}

实战中如果忘了给 AppScope/app.json5 加图标，会直接在 PreBuild 阶段失败：

must have required property 'icon'

需要补：

{
  "app": {
    "bundleName": "com.example.sevenzipohos",
    "vendor": "example",
    "versionCode": 1000000,
    "versionName": "0.1.0",
    "label": "$string:app_name",
    "icon": "$media:app_icon"
  }
}

entry/src/main/module.json5 中也要给 Ability 补启动窗口资源：

{
  "abilities": [
    {
      "name": "EntryAbility",
      "srcEntry": "./ets/entryability/EntryAbility.ets",
      "label": "$string:EntryAbility_label",
      "icon": "$media:app_icon",
      "startWindowIcon": "$media:app_icon",
      "startWindowBackground": "$color:start_window_background",
      "exported": true
    }
  ]
}

否则会报：

must have required property 'startWindowIcon'
must have required property 'startWindowBackground'

截图占位：DevEco Studio 工程目录，展示 entry 和 library 两个模块。

---

六、引入 7-Zip 源码

本次固定使用官方 ip7z/7zip 仓库 tag：

git clone --depth 1 --branch 26.01 https://github.com/ip7z/7zip.git library/src/main/cpp/third_party/7zip

实际记录版本：

tag: 26.01
commit: 8c63d71ff886bda90c86db28466287f977374237

和本次适配关系最紧密的是：

CPP/7zip/Bundles/Alone7z/makefile.gcc

这个 makefile 对应 7zr reduced 版，只处理 7z 格式，正好适合作为三方库首版基线。

注意不要直接把整个 7-Zip 工程无脑编进去。首版不需要：

• RAR
• GUI
• Windows resource
• 汇编优化
• 外部 codec 插件

---

七、生成 CMake 源文件清单

7-Zip reduced 版依赖的 C/C++ 文件很多，手写源文件清单非常容易漏。

因此工程中增加脚本：

scripts/gen-sevenzip-sources.cjs

核心思路是从官方 Alone7z/makefile.gcc 读取对象文件分组，再映射到真实源码路径，生成：

library/src/main/cpp/sevenzip_sources.cmake

生成命令：

node scripts/gen-sevenzip-sources.cjs

实战中基于 7-Zip 26.01 生成了 158 个源码文件。

这里要排除两个内容：

MainAr.cpp
resource.rc

原因是：

• MainAr.cpp 里有 console 程序入口 main()
• 三方库最终是 .so，不能带独立可执行程序入口
• resource.rc 是 Windows resource，鸿蒙 Native 不需要

生成后可以再跑校验脚本：

node scripts/verify-sevenzip-sources.cjs

目标是确认 MainAr.cpp 没进 CMake 清单，并且 7zRegister.cpp、LzmaRegister.cpp 这类注册文件都在。

---

八、Native C ABI 设计

Native 层对外不暴露 7-Zip 内部类型，而是提供一个稳定的 C ABI：

#pragma once

#ifdef __cplusplus
extern "C" {
#endif

typedef enum SevenZipResultCode {
  SEVENZIP_OK = 0,
  SEVENZIP_WARNING = 1,
  SEVENZIP_FATAL_ERROR = 2,
  SEVENZIP_USER_ERROR = 7,
  SEVENZIP_MEMORY_ERROR = 8,
  SEVENZIP_NATIVE_ERROR = 1000
} SevenZipResultCode;

typedef struct SevenZipOptions {
  int level;
  int threads;
  int solid;
  const char *password;
} SevenZipOptions;

int SevenZip_Compress(
  const char *archivePath,
  const char **inputPaths,
  int inputCount,
  const SevenZipOptions *options
);

int SevenZip_Extract(
  const char *archivePath,
  const char *outputDir,
  const char *password
);

int SevenZip_Test(
  const char *archivePath,
  const char *password
);

const char *SevenZip_GetLastError();

#ifdef __cplusplus
}
#endif

这样做有两个好处：

1. ArkTS / NAPI 不依赖 7-Zip 内部 COM-like 类型
2. 后续如果把 console bridge 换成更底层 archive API，对外接口可以保持稳定

---

九、Command bridge：把 7zr 命令变成库函数

7-Zip 的 UI/Console/Main.cpp 中提供了：

int Main2(int numArgs, char *args[]);

所以 bridge 层做的事情是把 C ABI 参数转成 7zr 风格命令：

压缩：

7zr a -t7z -mx=1 -ms=off -y archive.7z input.txt

测试：

7zr t archive.7z -y

解压：

7zr x archive.7z -ooutput_dir -y

bridge 层必须自己定义 7-Zip console 使用的全局 stream：

extern CStdOutStream g_StdOut;
extern CStdOutStream g_StdErr;

CStdOutStream *g_StdStream = nullptr;
CStdOutStream *g_ErrStream = nullptr;

并且要加互斥锁：

std::mutex g_sevenZipMutex;

原因是 7-Zip console 路径有全局状态。首版如果让多个压缩任务并发进入 Main2，风险很高。

实战中还遇到一个编译错误：

error: unknown type name 'CMessagePathException'

解决方式是在 bridge 中引入：

#include "CPP/7zip/UI/Common/EnumDirItems.h"

此外还需要把 7-Zip 的异常收口到 SevenZip_GetLastError()，否则页面只能看到：

Native bridge error

调试时增加了这些捕获：

catch (const CNewException &)
catch (const CMessagePathException &)
catch (const CSystemException &)
catch (NExitCode::EEnum exitCode)
catch (const UString &message)
catch (const AString &message)
catch (const char *message)
catch (const wchar_t *message)
catch (int value)
catch (const std::exception &error)
catch (...)

这个改动非常关键。没有它，Native 层报错很难定位。

---

十、CMake 最关键的一处：必须使用 OBJECT library

最开始 CMake 写法是：

add_library(sevenzip_core STATIC ${SEVENZIP_SOURCES})

add_library(sevenzip_napi SHARED
  bridge/sevenzip_command_bridge.cpp
  napi/sevenzip_napi.cpp
)

target_link_libraries(sevenzip_napi PRIVATE
  sevenzip_core
  libace_napi.z.so
  libhilog_ndk.z.so
)

这能编译，但真机运行压缩时报：

compress: ok=false, code=2, message=Unsupported archive type

这个问题很隐蔽。原因不是 -t7z 写错，也不是 .7z 后缀错，而是 7-Zip 的归档格式和 codec 依赖静态对象构造注册：

7zRegister.cpp
LzmaRegister.cpp
BcjRegister.cpp
CopyRegister.cpp
...

这些对象文件如果先被打进静态库，再由 .so 链接器按需拉取，可能因为没有显式符号引用而被丢掉。结果就是 CCodecs::Formats 里没有 7z 格式，ParseOpenTypes(*codecs, "7z", types) 失败，最终抛出：

Unsupported archive type

修复方式是把 sevenzip_core 改成 OBJECT library，强制把所有 7-Zip 对象文件并入 libsevenzip_napi.so：

cmake_minimum_required(VERSION 3.16)
project(sevenzip_ohos)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_C_STANDARD 99)
set(CMAKE_C_STANDARD_REQUIRED ON)

set(SEVENZIP_ROOT ${CMAKE_CURRENT_SOURCE_DIR}/third_party/7zip)

include(${CMAKE_CURRENT_SOURCE_DIR}/sevenzip_sources.cmake)

add_library(sevenzip_core OBJECT ${SEVENZIP_SOURCES})

target_include_directories(sevenzip_core PUBLIC
  ${SEVENZIP_ROOT}
  ${SEVENZIP_ROOT}/C
  ${SEVENZIP_ROOT}/CPP
  ${SEVENZIP_ROOT}/CPP/Common
  ${SEVENZIP_ROOT}/CPP/Windows
  ${SEVENZIP_ROOT}/CPP/7zip
)

target_compile_definitions(sevenzip_core PUBLIC
  Z7_PROG_VARIANT_R
  Z7_ST
  _FILE_OFFSET_BITS=64
  _LARGEFILE_SOURCE
)

target_compile_options(sevenzip_core PRIVATE
  -fPIC
  -Wno-unused-parameter
  -Wno-sign-compare
  -Wno-unused-variable
  -Wno-missing-field-initializers
)

add_library(sevenzip_napi SHARED
  $<TARGET_OBJECTS:sevenzip_core>
  bridge/sevenzip_command_bridge.cpp
  napi/sevenzip_napi.cpp
)

target_include_directories(sevenzip_napi PRIVATE
  ${CMAKE_CURRENT_SOURCE_DIR}/include
  ${SEVENZIP_ROOT}
  ${SEVENZIP_ROOT}/C
  ${SEVENZIP_ROOT}/CPP
)

target_link_libraries(sevenzip_napi PRIVATE
  libace_napi.z.so
  libhilog_ndk.z.so
)

这是本次适配最关键的坑。

---

十一、NAPI 封装

Native 模块名、CMake target、ArkTS import 需要保持一致：

CMake target: sevenzip_napi
生成文件: libsevenzip_napi.so
NAPI nm_modname: sevenzip_napi
ArkTS import: libsevenzip_napi.so

NAPI 层对外暴露三个 Promise API：

compress(
  archivePath: string,
  inputPaths: string[],
  options?: CompressOptions
): Promise<SevenZipResult>

extract(
  archivePath: string,
  outputDir: string,
  password?: string
): Promise<SevenZipResult>

test(
  archivePath: string,
  password?: string
): Promise<SevenZipResult>

返回结构统一为：

export interface SevenZipResult {
  code: number;
  ok: boolean;
  message: string;
}

错误码映射：

0    -> 成功
1    -> 警告
2    -> 致命错误
7    -> 命令参数错误
8    -> 内存错误
1000 -> Native bridge 未捕获错误

压缩、测试、解压都是耗时任务，所以 NAPI 层使用 async work：

napi_create_async_work(...)
napi_queue_async_work(...)

这样 ArkTS 侧拿到的是 Promise，不会长时间阻塞 UI 线程。

---

十二、ArkTS 三方库包装

library/src/main/ets/Index.ets 对 Native 模块做轻包装：

import sevenzipNative from 'libsevenzip_napi.so';
import { CompressOptions, SevenZipResult } from './types/SevenZipOptions';

export { CompressOptions, SevenZipResult } from './types/SevenZipOptions';

export function compress(
  archivePath: string,
  inputPaths: string[],
  options: CompressOptions = {}
): Promise<SevenZipResult> {
  return sevenzipNative.compress(archivePath, inputPaths, options);
}

export function extract(
  archivePath: string,
  outputDir: string,
  password: string = ''
): Promise<SevenZipResult> {
  return sevenzipNative.extract(archivePath, outputDir, password);
}

export function test(
  archivePath: string,
  password: string = ''
): Promise<SevenZipResult> {
  return sevenzipNative.test(archivePath, password);
}

业务项目引用时只需要：

import { compress, extract, test } from '@your-scope/sevenzip-ohos';

Native .so 类型声明放在：

library/src/main/cpp/types/libsevenzip_napi/index.d.ts

library/oh-package.json5 中的 types 必须指向 .d.ts 文件，否则会有警告：

The value of types must be a .d.ts or .d.ets file.

---

十三、Demo 烟测页面

entry 模块不是三方库的一部分，只用于验证。

页面点击按钮后执行下面流程：

1. 获取应用沙箱目录 context.filesDir
2. 创建输入目录 sevenzip-input
3. 写入测试文件 hello.txt
4. 压缩为 sevenzip-smoke.7z
5. 调用 test 校验归档
6. 解压到 sevenzip-output
7. 将每一步结果显示到页面

关键路径示例：

base: /data/storage/el2/base/haps/entry/files
input: /data/storage/el2/base/haps/entry/files/sevenzip-input/hello.txt
archive: /data/storage/el2/base/haps/entry/files/sevenzip-smoke.7z
output: /data/storage/el2/base/haps/entry/files/sevenzip-output

Demo 页面输出：

compress: ok=true, code=0, message=Everything is Ok
test: ok=true, code=0, message=Everything is Ok
extract: ok=true, code=0, message=Everything is Ok

---

十四、构建和安装

14.1 DevEco Studio 运行

设备连接后，DevEco 顶部设备栏选择鸿蒙 PC 设备，然后点运行。

如果安装时报：

Install Failed: error: failed to install bundle.
error: no signature file.

说明装的是 unsigned HAP，需要打开签名配置。

DevEco Studio 中进入：

File / Project Structure / Signing Configs

或者点击报错里的：

Open signing configs

开启自动签名后重新运行。

14.2 命令行构建

PowerShell 中可以这样构建：

$env:DEVECO_SDK_HOME='E:\DevEco Studio\sdk'
$env:JAVA_HOME='E:\DevEco Studio\jbr'
$env:PATH='E:\DevEco Studio\jbr\bin;' + $env:PATH

& 'E:\DevEco Studio\tools\node\node.exe' `
  'E:\DevEco Studio\tools\hvigor\bin\hvigorw.js' `
  --mode module `
  -p module=entry@default `
  -p product=default `
  -p requiredDeviceType=2in1 `
  assembleHap `
  --analyze=normal `
  --parallel `
  --incremental `
  --daemon

构建成功后产物位于：

entry/build/default/outputs/default/entry-default-signed.hap

14.3 命令行安装和启动

先查看设备：

& 'E:\DevEco Studio\sdk\default\openharmony\toolchains\hdc.exe' list targets

卸载旧包：

& 'E:\DevEco Studio\sdk\default\openharmony\toolchains\hdc.exe' shell bm uninstall -n com.example.sevenzipohos

注意新版本 bm uninstall 必须带 -n：

bm uninstall -n <bundle-name>

安装新包：

$hdc = 'E:\DevEco Studio\sdk\default\openharmony\toolchains\hdc.exe'
$hap = 'C:\Users\24190\Desktop\Harmony\sevenzip-ohos\entry\build\default\outputs\default\entry-default-signed.hap'
$tmp = 'data/local/tmp/sevenzip-ohos-install'

& $hdc shell rm -rf $tmp
& $hdc shell mkdir $tmp
& $hdc file send $hap $tmp
& $hdc shell bm install -p $tmp
& $hdc shell rm -rf $tmp

启动应用：

& 'E:\DevEco Studio\sdk\default\openharmony\toolchains\hdc.exe' shell aa start -a EntryAbility -b com.example.sevenzipohos

成功输出：

install bundle successfully.
start ability successfully.

---

十五、实战问题和解决

15.1 app.json5 缺少 icon

报错：

Schema validate failed
missingProperty: 'icon'

解决：

"icon": "$media:app_icon"

同时在 AppScope/resources/base/media 下放 app_icon.svg。

15.2 Ability 缺少启动窗口资源

报错：

missingProperty: 'startWindowIcon'
missingProperty: 'startWindowBackground'

解决：

"startWindowIcon": "$media:app_icon",
"startWindowBackground": "$color:start_window_background"

15.3 安装失败：no signature file

报错：

Install Failed: error: failed to install bundle.
error: no signature file.

原因是 IDE 尝试安装 unsigned HAP。

解决：

• 打开 Signing Configs
• 配置自动签名
• 重新构建 signed HAP

15.4 CMessagePathException 未定义

报错：

error: unknown type name 'CMessagePathException'

解决：

#include "CPP/7zip/UI/Common/EnumDirItems.h"

15.5 页面只显示 Native bridge error

初版 bridge 只做了：

catch (...) {
  return SEVENZIP_NATIVE_ERROR;
}

这会导致 ArkTS 侧完全不知道 7-Zip 内部抛了什么。

解决方式：

• 增加 SevenZip_GetLastError()
• bridge 中捕获 7-Zip 常见异常类型
• NAPI async work 完成时把错误信息带回 ArkTS

修复后页面能显示：

message=Unsupported archive type

这才定位到真正问题。

15.6 SDK component missing

报错：

00303168 Configuration Error
SDK component missing.

实战中原因是 SDK 路径和 Hvigor daemon 缓存不一致。

处理方式：

& 'E:\DevEco Studio\tools\node\node.exe' `
  'E:\DevEco Studio\tools\hvigor\bin\hvigorw.js' `
  --stop-daemon

并确保：

$env:DEVECO_SDK_HOME='E:\DevEco Studio\sdk'

如果仍然失败，可以清理生成缓存：

.hvigor
entry/build
library/build
library/.cxx

15.7 Unsupported archive type

报错：

compress: ok=false, code=2, message=Unsupported archive type

这是本次最关键的问题。

原因是 sevenzip_core 用 STATIC 静态库时，7-Zip 的静态注册对象可能被链接器丢弃，导致运行时没有注册 7z archive handler。

解决：

add_library(sevenzip_core OBJECT ${SEVENZIP_SOURCES})

add_library(sevenzip_napi SHARED
  $<TARGET_OBJECTS:sevenzip_core>
  bridge/sevenzip_command_bridge.cpp
  napi/sevenzip_napi.cpp
)

修复后重新构建、安装，再运行烟测，压缩成功。

---

十六、最终验证结果

最终在鸿蒙 PC 上完成了沙箱内烟测。

页面显示：

build: diag-2026-05-20-2205
base: /data/storage/el2/base/haps/entry/files
input: /data/storage/el2/base/haps/entry/files/sevenzip-input/hello.txt
archive: /data/storage/el2/base/haps/entry/files/sevenzip-smoke.7z
output: /data/storage/el2/base/haps/entry/files/sevenzip-output
compress: ok=true, code=0, message=Everything is Ok
test: ok=true, code=0, message=Everything is Ok
extract: ok=true, code=0, message=Everything is Ok

这说明：

• libsevenzip_napi.so 能被 ArkTS 正确加载
• NAPI Promise 调用链路正常
• 7-Zip reduced core 能识别并创建 .7z
• 应用沙箱路径可读写
• 压缩成功
• 归档测试成功
• 解压成功

---

十七、复现步骤汇总

完整复现可以按下面顺序走：

1. 创建 ArkTS Stage 工程
2. 新增 library HAR 模块
3. 新增 entry Demo 模块
4. 配置 AppScope/app.json5 的 icon
5. 配置 entry/module.json5 的 startWindowIcon 和 startWindowBackground
6. 在 library/src/main/cpp/third_party 引入 7-Zip 26.01 源码
7. 从 Alone7z/makefile.gcc 生成 sevenzip_sources.cmake
8. 排除 MainAr.cpp 和 resource.rc
9. 编写 sevenzip_ohos.h
10. 编写 command bridge，调用 Main2
11. 编写 NAPI async work
12. ArkTS 包装 compress、extract、test
13. CMake 使用 OBJECT library 合入 7-Zip 对象文件
14. Demo 中使用 context.filesDir 做沙箱路径烟测
15. 配置签名
16. 构建 signed HAP
17. 安装到鸿蒙 PC
18. 点击按钮验证压缩、测试、解压

---

十八、后续可扩展方向

首版已经验证 .7z 基础能力。后续可以继续补：

• 进度回调
• 取消任务
• list 列表能力
• 多文件目录压缩 UI
• 密码压缩实测
• 大文件压缩稳定性测试
• 1000 小文件压缩测试
• 多 ABI 构建
• OHPM 发布流程
• 从 console bridge 改成更底层 archive API

其中最值得做的是进度回调和取消任务。当前复用 Main2 是最小可复现路径，但它更像 console 程序封装。真正要做成生产级基础库，后续可以绕过 console 层，直接使用 7-Zip archive API，这样更容易做并发、进度和取消。

---

十九、结语

这次 sevenzip-ohos 适配最有价值的地方，不是写了一个按钮页面，而是把 7-Zip Native 核心真正带进了鸿蒙 PC 应用运行时。

过程中几个关键经验非常明确：

• 7-Zip 源文件清单必须从官方 Alone7z 基准生成
• 不要编译 MainAr.cpp
• command bridge 可以复用 Main2，但要加互斥锁
• NAPI 必须把错误信息带回 ArkTS
• CMake 不能简单把 7-Zip 注册对象塞进 STATIC 静态库
• 鸿蒙 PC 真机验证要先走应用沙箱路径
• 签名、SDK 路径和 Hvigor daemon 缓存会影响最终运行

最终结果已经证明：

ArkTS -> HAR -> NAPI -> 7-Zip Native -> 沙箱文件系统

这条链路可以在鸿蒙 PC 上实际跑通。

---

参考资料

• 7-Zip LZMA SDK
• 7-Zip GitHub 源码
• OpenHarmony Node-API 开发流程
• OpenHarmony NDK CMake 构建说明
• OpenHarmony ArkTS 静态加载 Native 模块