@hmos-library-adapter/fast 0.0.17-beta.0 → 0.0.17-beta.2

package/node_modules/@ohos-agent/pc-adapter/skills/harmonyos-pc-resources/references/contribute/develop-guide//351/270/277/350/222/231/345/272/224/347/224/250/345/265/214/345/205/245Java/350/277/220/350/241/214/346/227/266-ArkTS/344/270/216JVM/346/267/267/345/220/210/345/274/200/345/217/221/345/256/236/346/210/230.md

@@ -0,0 +1,609 @@
+# 在鸿蒙应用中嵌入 Java 运行时：ArkTS + JVM 混合开发实战
+
+> 鸿蒙原生开发语言是 ArkTS，但 Java 生态积累了大量成熟的企业级库和业务代码。本文介绍如何在一个鸿蒙应用中嵌入完整的 JVM 运行时，让 ArkTS 负责应用壳和系统能力，Java 负责业务逻辑，并通过 JNA 的鸿蒙适配案例展示 Java 调用原生库的完整流程。
+
+---
+
+## 一、为什么要在鸿蒙上跑 Java
+
+鸿蒙应用开发使用 ArkTS + ArkUI，生态成熟度正在快速提升，但在以下场景中，Java 生态仍有不可替代的优势：
+
+| 场景 | 说明 |
+|------|------|
+| **遗留 Java 代码复用** | 企业内部大量 Java 业务逻辑、报表引擎、加密算法等，完全用 ArkTS 重写成本巨大 |
+| **Java 三方库依赖** | 部分专业领域库（如 Bouncy Castle 加密、Apache POI 文档处理）在 Java 生态中成熟可靠 |
+| **跨平台一致性** | 同一份 Java 业务代码在 Windows/Linux/macOS/鸿蒙上行为一致，降低维护成本 |
+| **渐进式迁移** | 先让 Java 应用在鸿蒙上跑起来，再逐步用 ArkTS 重写 UI 层和系统交互层 |
+
+核心思路：**ArkTS 做壳，JVM 做引擎，Java 做业务。**
+
+---
+
+## 二、整体架构
+
+```
+┌──────────────────────────────────────────────────┐
+│           HarmonyOS 应用 (.hap)                   │
+│                                                   │
+│  ┌──────────────────────────────────────────┐     │
+│  │  ArkTS 层                                │     │
+│  │  - 应用生命周期管理 (EntryAbility)        │     │
+│  │  - 权限申请、配置加载                     │     │
+│  │  - UI 界面                               │     │
+│  │  - 通过 NAPI 调用 C++ 桥接层             │     │
+│  └─────────────────┬────────────────────────┘     │
+│                    │ NAPI                          │
+│  ┌─────────────────▼────────────────────────┐     │
+│  │  C++ 桥接层 (liblauncher.so)             │     │
+│  │  - NAPI 接口暴露给 ArkTS                 │     │
+│  │  - JNI_CreateJavaVM() 创建 JVM 实例      │     │
+│  │  - 管理 JVM 生命周期                     │     │
+│  │  - 双向数据传递 (ArkTS ↔ Java)           │     │
+│  └─────────────────┬────────────────────────┘     │
+│                    │ JNI                           │
+│  ┌─────────────────▼────────────────────────┐     │
+│  │  Java 运行时层                            │     │
+│  │  ┌──────────────────────────────────┐    │     │
+│  │  │  BiSheng JDK 17 (libjvm.so)      │    │     │
+│  │  │  + JRE 核心类库 (rt.jar 等)       │    │     │
+│  │  │  + 用户 Java 应用 (jar)           │    │     │
+│  │  │  + Java 三方库 (JNA 等)           │    │     │
+│  │  └──────────────────────────────────┘    │     │
+│  └──────────────────────────────────────────┘     │
+│                                                   │
+│  entry/libs/arm64-v8a/                            │
+│  ├── jre/                     # 完整 JRE          │
+│  │   └── lib/aarch64/                             │
+│  │       ├── server/libjvm.so # JVM 核心          │
+│  │       ├── libjava.so       # Java 基础运行时    │
+│  │       ├── libnet.so        # 网络库             │
+│  │       ├── libnio.so        # NIO                │
+│  │       └── ...              # 其他 30+ 个 SO     │
+│  └── liblauncher.so           # NAPI-JNI 桥接库    │
+└──────────────────────────────────────────────────┘
+```
+
+**三层职责清晰分离：**
+
+| 层 | 技术 | 职责 |
+|----|------|------|
+| ArkTS 层 | ArkUI | 应用生命周期、权限、UI、系统能力调用 |
+| C++ 桥接层 | NAPI + JNI | ArkTS ↔ JVM 的双向通信 |
+| Java 运行时层 | JVM + JRE | 执行 Java 业务代码 |
+
+---
+
+## 三、项目结构
+
+下面是一个典型的 ArkTS + JVM 混合项目的目录结构：
+
+```
+ohos-app/
+├── AppScope/
+│   └── app.json5                     # 应用全局配置（环境变量）
+├── entry/
+│   ├── libs/arm64-v8a/               # 原生库目录
+│   │   ├── jre/                      # 完整 JRE 运行时
+│   │   │   └── lib/aarch64/
+│   │   │       ├── server/libjvm.so
+│   │   │       ├── libjava.so
+│   │   │       ├── libnet.so
+│   │   │       ├── libnio.so
+│   │   │       └── ...
+│   │   └── liblauncher.so            # NAPI-JNI 桥接库
+│   ├── src/main/
+│   │   ├── cpp/
+│   │   │   ├── CMakeLists.txt        # C++ 构建配置
+│   │   │   └── napi_init.cpp         # NAPI 入口
+│   │   ├── ets/
+│   │   │   ├── entryability/
+│   │   │   │   └── EntryAbility.ets  # 应用入口：启动 JVM
+│   │   │   └── pages/
+│   │   │       └── Index.ets         # 主页面
+│   │   ├── resources/
+│   │   │   ├── rawfile/
+│   │   │   │   └── config.json5      # Java 应用配置
+│   │   │   └── resfile/
+│   │   │       ├── app.jar           # 要运行的 Java 应用
+│   │   │       ├── lib/              # Java 三方库
+│   │   │       │   └── jna.jar       # 如 JNA 等
+│   │   │       └── JarLoader/
+│   │   │           └── HmJarBootloader.class  # Java 引导类
+│   │   └── module.json5              # 模块配置（权限等）
+│   └── build-profile.json5           # 构建配置
+├── build-profile.json5
+└── oh-package.json5
+```
+
+---
+
+## 四、关键配置详解
+
+要让 JVM 在鸿蒙应用中正常运行，需要在多处进行正确配置。
+
+### 4.1 module.json5 — 模块配置
+
+```json5
+{
+  "module": {
+    "name": "entry",
+    "type": "entry",
+    "deviceTypes": ["2in1"],
+    "extractNativeLibs": true,  // ⭐ 关键！JVM 的 SO 必须解压到文件系统
+    "abilities": [/* ... */],
+    "requestPermissions": [
+      {
+        // JVM JIT 编译需要可写可执行内存权限
+        "name": "ohos.permission.kernel.ALLOW_WRITABLE_CODE_MEMORY"
+      },
+      {
+        // Java 网络库需要网络权限
+        "name": "ohos.permission.INTERNET"
+      }
+    ]
+  }
+}
+```
+
+**`extractNativeLibs: true` 是最关键的配置。** 鸿蒙默认可能不解压 HAP 中的 SO 库（直接从 HAP 中 mmap 加载），但 JVM 的 `libjvm.so` 需要以 `dlopen` 方式动态加载，必须存在于文件系统上。设置为 `true` 后，安装时所有 SO 会被解压到 `/data/storage/el1/bundle/entry/libs/` 目录。
+
+### 4.2 app.json5 — 应用全局配置
+
+```json5
+{
+  "app": {
+    "bundleName": "com.example.javatest",
+    "appEnvironments": [
+      {
+        "name": "FONTCONFIG_FILE",
+        "value": "/data/storage/el1/bundle/entry/resources/resfile/etc/fonts/fonts.conf"
+      }
+    ]
+  }
+}
+```
+
+通过 `appEnvironments` 可以设置 JVM 运行时所需的环境变量，如字体配置路径。
+
+### 4.3 build-profile.json5 — 构建配置
+
+```json5
+{
+  "buildOption": {
+    "nativeLib": {
+      "collectAllLibs": true  // ⭐ 收集 libs/ 下所有 SO 到 HAP 包
+    },
+    "externalNativeOptions": {
+      "path": "./src/main/cpp/CMakeLists.txt",
+      "cppFlags": "--std=c++17"
+    }
+  }
+}
+```
+
+`collectAllLibs: true` 确保 `entry/libs/arm64-v8a/` 下的所有 JRE SO 库都被打包进 HAP，而不仅仅是 CMake 构建的产物。
+
+---
+
+## 五、核心实现
+
+### 5.1 EntryAbility：启动 JVM
+
+`EntryAbility.ets` 是应用的生命周期入口，负责在应用启动时初始化 JVM：
+
+```typescript
+import launcher from "liblauncher.so";  // 导入 NAPI 桥接模块
+
+export default class EntryAbility extends UIAbility {
+
+  async onCreate(want, launchParam) {
+    // 1. 申请必要权限（文件读写等）
+    if (await this.requestNecessaryPermission()) {
+      // 2. 初始化日志系统
+      let bundleName = this.launchWant.bundleName;
+      launcher.initLog(bundleName);
+    }
+  }
+
+  async onWindowStageCreate(windowStage) {
+    // 3. 加载 Java 应用配置
+    this.configStr = await this.loadConfig(this.context);
+    
+    // 4. 启动 JVM 并加载 Java 应用
+    launcher.jreStart(this);  // 传入 Ability 上下文
+  }
+
+  async loadConfig(context) {
+    let data = await context.resourceManager.getRawFileContent('config.json5');
+    return util.TextDecoder.create().decodeToString(data);
+  }
+}
+```
+
+**执行流程：**
+
+```
+应用启动 → onCreate()
+  ├── requestNecessaryPermission()
+  └── launcher.initLog(bundleName)
+
+窗口创建 → onWindowStageCreate()
+  ├── loadConfig()
+  └── launcher.jreStart(this)    ← 启动 JVM 核心
+```
+
+`launcher.jreStart(this)` 传入了 Ability 上下文，C++ 层通过它可以获取 `resfile` 目录路径，进而定位 `app.jar` 和 JRE。
+
+### 5.2 C++ 桥接层：liblauncher.so
+
+`liblauncher.so` 是 ArkTS 与 JVM 之间的纽带，核心职责：
+
+1. **暴露 NAPI 接口**：`initLog()`、`jreStart()` 供 ArkTS 调用
+2. **创建 JVM 实例**：调用 `JNI_CreateJavaVM()` 
+3. **加载 Java 应用**：通过 JNI 调用 `HmJarBootloader` 引导类，加载用户 jar
+4. **双向通信**：ArkTS → NAPI → JNI → Java，以及反向的数据传递
+
+`jreStart` 的内部流程大致如下：
+
+```cpp
+static napi_value JreStart(napi_env env, napi_callback_info info) {
+    // 1. 从 NAPI 参数获取 Ability 上下文
+    // 2. 获取 resfile 路径，定位 JRE 和 jar 文件
+    // 3. 构造 JVM 启动参数
+    JavaVMInitArgs vm_args;
+    vm_args.version = JNI_VERSION_1_8;
+    JavaVMOption options[] = {
+        {"-Djava.home=<resfile_path>/jre"},
+        {"-Djava.class.path=<resfile_path>/app.jar"},
+    };
+    vm_args.options = options;
+    vm_args.nOptions = sizeof(options) / sizeof(options[0]);
+    
+    // 4. 创建 JVM
+    JavaVM *jvm;
+    JNIEnv *jniEnv;
+    JNI_CreateJavaVM(&jvm, (void**)&jniEnv, &vm_args);
+    
+    // 5. 加载引导类并执行 main 方法
+    jclass bootClass = jniEnv->FindClass("JarLoader/HmJarBootloader");
+    jmethodID mainMethod = jniEnv->GetStaticMethodID(
+        bootClass, "main", "([Ljava/lang/String;)V");
+    // ...调用 main
+}
+```
+
+### 5.3 Java 引导类
+
+`HmJarBootloader.class` 是由 C++ 层通过 JNI 首先加载的 Java 引导类，它负责：
+
+1. 解析 `config.json5` 中的配置
+2. 构建完整的 classpath（用户 jar + 三方库）
+3. 使用 `URLClassLoader` 加载用户应用
+4. 调用用户应用的 `main` 方法
+
+### 5.4 Java 应用配置
+
+`config.json5` 用于向 Java 应用传递运行时配置：
+
+```json5
+{
+  "classPath": "",
+  "nc.jstart.server": "example.com",
+  "nc.jstart.protocol": "http",
+  "nc.jstart.port": "80",
+  "nc.client.location": "/storage/Users/currentUser/Documents"
+}
+```
+
+---
+
+## 六、案例：在鸿蒙上构建和使用 JNA
+
+> [JNA (Java Native Access)](https://github.com/java-native-access/jna) 是 Java 生态中使用最广泛的原生库调用框架，它通过 libffi 在运行时动态生成函数调用桥接，**无需编写任何 JNI C 代码**就能直接调用系统 .so 库中的函数。
+
+JNA 的成功适配证明了：**Java 生态中依赖 JNI 的库，完全可以在鸿蒙上运行。**
+
+### 6.1 前置条件：BiSheng JDK
+
+鸿蒙平台使用华为自研的 [BiSheng JDK](https://gitee.com/openeuler/bishengjdk-17) 作为 Java 运行时。它基于 OpenJDK 17，针对 aarch64 架构优化。
+
+**一个关键问题：ELF 签名。**
+
+鸿蒙系统要求所有可执行的 ELF 文件（包括 .so 动态库）必须经过数字签名。系统自带的 BiSheng JDK 使用系统级签名，当你尝试 `System.load()` 加载自己编译的 JNI 库时，会因为签名不匹配而报 `Permission denied`。
+
+**解决方案**：将 JDK 拷贝到用户可写路径，然后对整个 JDK 和你的 JNI 库统一做自签名（self-sign）：
+
+```bash
+# 1. 拷贝系统 JDK 到用户目录
+cp -a /data/service/hnp/bishengjdk17* ~/usr/local/bishengjdk17
+
+# 2. 全量自签名（JDK 中 65 个 ELF 文件 + 你的 JNI 库）
+binary-sign-tool -selfSign 1 -i ~/usr/local/bishengjdk17/bin/java
+binary-sign-tool -selfSign 1 -i ~/usr/local/bishengjdk17/lib/aarch64/server/libjvm.so
+# ... 批量签名所有 ELF 文件
+```
+
+签名后，JVM 和 JNI 库使用同一签名体系，`System.load()` 就能正常工作。
+
+已有预编译的自签名 JDK 可直接使用，无需手动操作：
+
+```bash
+# 使用预编译包安装
+tar xzf bishengjdk17-ohos-aarch64-runtime.tar.gz -C ~/usr/local/
+export JAVA_HOME=~/usr/local/bishengjdk17
+```
+
+### 6.2 JNA 编译过程
+
+JNA 由 Java 层和 Native 层两部分组成：
+
+- **Java 层**：平台检测、类型映射、调用接口
+- **Native 层**：`dispatch.c` + `callback.c`，通过 libffi 实现动态函数调用和回调
+
+#### Step 1: 环境验证
+
+```bash
+java -version   # BiSheng JDK 17.0.13
+javac -version
+# 验证 JNI 头文件完整 (jni.h + jni_md.h)
+# 验证 libffi 8.2.0 (已适配鸿蒙)
+# 验证 dlopen/dlsym 可用
+```
+
+#### Step 2: 获取源码
+
+```bash
+git clone --depth 1 https://github.com/java-native-access/jna
+```
+
+#### Step 3: 编译 Java 层
+
+```bash
+# 修改版本号（JNA 源码中是 TEMPLATE 占位符）
+sed -i 's/VERSION = "TEMPLATE"/VERSION = "5.19.0"/' src/com/sun/jna/Version.java
+
+# 编译 Java 源码，同时生成 JNI 头文件
+javac -d build/classes -h build/jni-headers \
+  -sourcepath src $(find src/com/sun/jna -name "*.java")
+```
+
+#### Step 4: 编译 Native 层
+
+```bash
+# 编译 dispatch.c
+clang -O2 -fPIC -fno-omit-frame-pointer -fno-strict-aliasing \
+  -D_REENTRANT -DHAVE_PROTECTION -DNO_JAWT \
+  -DJNA_JNI_VERSION='"5.19.0"' -DCHECKSUM='"0"' \
+  -I$JAVA_HOME/include -I$JAVA_HOME/include/linux \
+  -I$FFI_HOME/include -Ibuild/jni-headers -Inative/ \
+  -c native/dispatch.c -o build/dispatch.o
+
+# 编译 callback.c
+clang -O2 -fPIC ... -c native/callback.c -o build/callback.o
+
+# 链接：静态链接 libffi，生成 libjnidispatch.so
+clang -shared -o build/libjnidispatch.so \
+  build/dispatch.o build/callback.o \
+  $FFI_HOME/lib/libffi.a
+```
+
+**关键点：**
+- `-DNO_JAWT`：禁用 AWT 相关的 JAWT 接口（鸿蒙上不需要）
+- `-DHAVE_PROTECTION`：启用内存保护
+- **静态链接 libffi**：`libjnidispatch.so` 内嵌 libffi，部署时无额外依赖（仅依赖 libc.so）
+
+#### Step 5: 签名
+
+```bash
+# 对 libjnidispatch.so 自签名
+binary-sign-tool -selfSign 1 -i build/libjnidispatch.so
+```
+
+#### Step 6: 打包
+
+```bash
+# 将 libjnidispatch.so 嵌入 JAR 的平台特定目录
+mkdir -p build/classes/com/sun/jna/harmonyos-aarch64/
+cp build/libjnidispatch.so build/classes/com/sun/jna/harmonyos-aarch64/
+
+# 打包 JAR
+cd build/classes
+jar cf ../../dist/jna.jar com/sun/jna/
+```
+
+JNA 的平台检测会识别鸿蒙为 `harmonyos-aarch64`（而非 `linux-aarch64`），所以 native 库必须放在 JAR 内的 `com/sun/jna/harmonyos-aarch64/` 路径下，JNA 运行时会自动解压加载。
+
+#### Step 7: 验证测试
+
+```java
+import com.sun.jna.*;
+import com.sun.jna.ptr.*;
+
+public class TestJNA {
+    public interface CLibrary extends Library {
+        CLibrary INSTANCE = Native.load("c", CLibrary.class);
+        int getpid();
+        String getenv(String name);
+        double cos(double x);  // 来自 libm
+    }
+
+    public static void main(String[] args) {
+        // libc 调用
+        System.out.println("PID: " + CLibrary.INSTANCE.getpid());
+        System.out.println("HOME: " + CLibrary.INSTANCE.getenv("HOME"));
+
+        // libm 调用
+        CLibrary libm = Native.load("m", CLibrary.class);
+        System.out.println("cos(0.0) = " + libm.cos(0.0));  // 1.0
+
+        // Pointer 内存操作
+        Pointer p = new Memory(4);
+        p.setInt(0, 42);
+        System.out.println("Value: " + p.getInt(0));  // 42
+
+        // ffi_closure 回调 (qsort)
+        CLibrary libm2 = Native.load("c", CLibrary.class);
+        // qsort 比较函数回调... 正常工作 ✅
+    }
+}
+```
+
+**验证结果：**
+
+| 功能 | 状态 |
+|------|------|
+| libc 调用 (puts/getpid/abs/getenv) | ✅ |
+| libm 调用 (cos/sqrt) | ✅ |
+| Pointer 内存操作 (malloc/setInt/getInt/free) | ✅ |
+| 动态加载 (NativeLibrary.getInstance) | ✅ |
+| ffi_closure 回调 (qsort 排序) | ✅ |
+
+### 6.3 在鸿蒙应用中使用 JNA
+
+编译好的 `jna.jar`（283KB）可以嵌入到鸿蒙应用中：
+
+```
+entry/src/main/resources/resfile/
+├── app.jar              # 你的 Java 应用
+└── lib/
+    └── jna.jar          # JNA 库（内含 harmonyos-aarch64 的 native 库）
+```
+
+Java 引导类在构建 classpath 时加入 `jna.jar`，Java 应用即可直接使用 JNA 调用系统原生库。
+
+---
+
+## 七、开发指南
+
+### 7.1 准备 JRE 运行时
+
+你需要一个为鸿蒙 aarch64 编译的 JDK/JRE。推荐使用 [BiSheng JDK 17](https://gitee.com/openeuler/bishengjdk-17)。
+
+将完整的 JRE 放入：
+
+```
+entry/libs/arm64-v8a/jre/
+```
+
+JRE 大小约 100MB+，包含 `libjvm.so`（JVM 核心）、30+ 个 JNI 本地库和核心类库。
+
+如果需要加载自定义 JNI 库，务必使用自签名的 JDK 副本（见 6.1 节）。
+
+### 7.2 编写 C++ 桥接库
+
+这是技术难度最高的部分。你需要编写一个 C++ 动态库（如 `liblauncher.so`），同时：
+
+1. 通过 NAPI 暴露接口给 ArkTS（如 `initLog()`、`jreStart()`）
+2. 通过 `JNI_CreateJavaVM()` 创建 JVM 实例
+3. 通过 JNI 调用 Java 引导类，加载用户 jar 并执行
+
+CMakeLists.txt 示例：
+
+```cmake
+cmake_minimum_required(VERSION 3.5.0)
+project(launcher)
+
+add_library(launcher SHARED napi_init.cpp)
+target_link_libraries(launcher PUBLIC libace_napi.z.so)
+# 可能还需要链接 libhilog_ndk.z.so 等
+```
+
+### 7.3 编写 Java 应用
+
+编写你的 Java 应用并打包为 jar。纯 Java 应用（不依赖 GUI）可以直接使用标准 Java API，包括：
+
+- 网络（java.net, java.nio）
+- 加密（javax.crypto, java.security）
+- JSON/XML 处理
+- 数据库（JDBC）
+- 通过 JNA 调用系统原生库
+
+```java
+public class MyApplication {
+    public static void main(String[] args) {
+        System.out.println("Hello from HarmonyOS JVM!");
+        
+        // 正常使用 Java API
+        try {
+            var url = new java.net.URL("https://example.com/api");
+            var conn = (java.net.HttpURLConnection) url.openConnection();
+            // ...
+        } catch (Exception e) {
+            e.printStackTrace();
+        }
+    }
+}
+```
+
+```bash
+javac MyApplication.java
+jar cvf app.jar MyApplication.class
+```
+
+将 `app.jar` 放入 `entry/src/main/resources/resfile/`。
+
+### 7.4 编写 Java 引导类
+
+需要一个 Java 引导类（如 `HmJarBootloader`），由 C++ 层通过 JNI 首先加载，再由它加载用户应用：
+
+```java
+public class HmJarBootloader {
+    public static void main(String[] args) throws Exception {
+        // 读取配置
+        String classPath = System.getProperty("java.class.path");
+        // 构建 URLClassLoader 加载用户 jar
+        // 调用用户 jar 的 main 方法
+    }
+}
+```
+
+### 7.5 ArkTS 端配置
+
+确保 `module.json5` 和 `build-profile.json5` 按第四节进行正确配置。
+
+---
+
+## 八、经验总结与注意事项
+
+### 8.1 ELF 签名是最大门槛
+
+鸿蒙的安全模型要求所有 ELF 文件必须签名。BiSheng JDK 的 `System.load()` 会校验 SO 库的签名，必须与 JVM 使用同一签名体系。**解决方案是拷贝 JDK 并全量自签名。**
+
+### 8.2 extractNativeLibs 必须为 true
+
+JVM 需要通过 `dlopen` 动态加载 SO 文件。如果 `extractNativeLibs` 为 false，SO 库不会从 HAP 中解压出来，JVM 启动会失败。
+
+### 8.3 Java 平台检测差异
+
+JNA 将鸿蒙识别为 `harmonyos-aarch64`（而非 `linux-aarch64`）。如果你的 Java 库依赖平台检测（如 `System.getProperty("os.name")`），需要注意这个差异。`Platform.getOSType()` 返回 -1（未知），因为 HarmonyOS 不在 JNA 的已知操作系统列表中。
+
+### 8.4 包体积优化
+
+完整 JRE 约 100MB+，对移动端不够友好。可以裁剪 JRE 来优化：
+
+- 移除不需要的模块（如 `libjsound.so` 音频库、`libsplashscreen.so` 等）
+- 移除不需要的扩展 JAR（`nashorn.jar` JavaScript 引擎、`cldrdata.jar` 等）
+- 使用 `jlink` 工具创建最小化 JRE（BiSheng JDK 17 支持 jlink）
+
+### 8.5 纯 Java 库 vs JNI 库
+
+| 类型 | 适配难度 | 说明 |
+|------|---------|------|
+| 纯 Java 库（无 native 依赖） | 低 | 直接将 jar 放入 classpath 即可 |
+| JNI 库（含 .so） | 中 | 需要为鸿蒙 aarch64 重新编译 native 层，并做 ELF 签名 |
+| 通过 JNA 调用系统库 | 低 | 只要 JNA 本身适配好了，调用任意系统 .so 无需额外编译 |
+
+---
+
+## 九、总结
+
+通过在鸿蒙应用中嵌入 JVM 运行时，可以实现 **ArkTS + Java 的混合开发模式**，让鸿蒙应用直接复用 Java 生态的成熟代码。
+
+**核心要点回顾：**
+
+1. **架构**：ArkTS（壳）→ C++ NAPI（桥接）→ JVM（引擎）→ Java（业务）
+2. **关键配置**：`extractNativeLibs: true`、`collectAllLibs: true`、ELF 签名统一
+3. **JNA 案例**：证明 Java 生态中依赖 JNI 的库可以在鸿蒙上运行，静态链接 libffi 实现零外部依赖
+4. **适用场景**：遗留 Java 代码迁移、Java 三方库复用、跨平台业务逻辑
+
+这种模式为 Java 开发者进入鸿蒙生态提供了一条务实的技术路径，也为鸿蒙生态带来了整个 Java 世界的可能性。