告别JNI：Java 22 FFM API实战指南，安全高效调用C函数

“调 C 函数”，这个词在过去很长一段时间里就等于“写 JNI”：javac -h生成头文件，手写 C 包装函数，再处理jstring、jintArray这类类型搬运，最后还要祈祷运行时不崩。我早期做项目时，凌晨三点抱着 gdb，对着一个SIGSEGV查 Java 和 C 内存布局的画面，到现在都记忆犹新。所以 Java 22 把 Foreign Function & Memory API（FFM）从孵化器里转正之后，我的态度很直接：JNI 能不用就尽量不用了。

这篇不是 API 文档翻译，更像是我把几个项目从 JNI 迁到 FFM 之后的一份实操笔记。我会从“为什么值得换”讲起，把Linker、SymbolLookup、FunctionDescriptor、Arena、MemorySegment这几个核心角色拆开，再给可以直接抄的示例和我在实际使用中踩过的坑。适合两类人：已经被 JNI 折腾过的老伙计，以及刚入行、想直接走新路的新手。

1. 为什么是 FFM：JNI 的麻烦你不必再忍

1.1 JNI 到底烦在哪

JNI 的问题不是“能不能用”，而是“成本全藏在你没注意的地方”。表面上看流程很标准：Java 里声明native方法，javac -h生成 C 头文件，再用 C 实现这个函数，编译成.so或.dll，最后通过System.loadLibrary加载。但只要你多调几个函数，马上就会发现这套流程的笨重。

第一层麻烦是胶水代码。每暴露一个函数给 C，就要写一套Java_xxx_xxx命名的导出函数。如果这个函数要传字符串、数组、结构体，你还要在 Java 数据类型和 C 数据类型之间来回做转换。比如传一个字符串，JNI 层拿到的jstring不能直接被 C 使用，得调用GetStringUTFChars，用完记得ReleaseStringUTFChars。如果忘了释放，内存就慢慢漏。一个项目里的 JNI 代码多了以后，光这些“管家式”的搬运逻辑就占了大半。

第二层麻烦是编译和依赖。JNI 代码不能只写一次，你得维护每个平台的头文件路径、编译器参数、链接参数。换一个操作系统，或者换一个 C 编译器，可能又要重新配一遍构建脚本。更难受的是，如果调用的库本身有更新，JNI 层的签名也要同步改，改了之后还要重新编译，链路很长。

第三层麻烦才是真正让运维头疼的东西：运行时安全。C 代码里一个指针传错，JVM 直接崩掉，连 Java 的try-catch都帮不上忙。JNI 的互操作层缺乏“作用域控制”和“边界检查”的概念，你拿到的地址是裸地址，C 函数越界写坏内存，Java 侧完全感知不到。段错误、堆损坏，很多时候只能在事后看hs_err_pid日志定位。

1.2 FFM 是什么：从 Panama 项目走出的正规军

FFM 全称是 Foreign Function & Memory API，在 JDK 22 通过 JEP 454 转正，包名从孵化期的jdk.incubator.foreign转正为java.lang.foreign。它的目标很明确：让你在 Java 里以“声明式”的方式调用外部函数，并安全地访问外部内存，不需要写 C 包装层，也不需要头文件。

它其实是由 Panama 项目孵化多年的产物。这个项目解决的核心命题就是“跨语言互操作要像写 Java 一样自然”。你可以把它理解为 Java 和 C 之间的一位专业翻译：你告诉它 C 函数长什么样（签名），它负责生成调用指令、处理 ABI 对齐、安排参数传递。你在 Java 侧看到的还是一个MethodHandle，可以直接invoke调用。

优势在于，FFM 把“类型描述”和“内存管理”作为一等公民。FunctionDescriptor描述 C 函数签名，MemoryLayout描述结构体内存排布，Arena控制内存生命周期。这套体系比 JNI 的手工搬砖要严谨得多，很多原本会直接段错误的操作，在 Java 侧会因为作用域检查而抛异常，至少你能知道错在哪。

1.3 JNI vs FFM：一张表看清前后变化

这张表不是要否定 JNI 存在的价值。JNI 目前仍然是访问 JVM 内部机制的“官方通道”。但如果你只是想调用普通 C 函数、处理外部内存，FFM 是现代 Java 环境下更顺手的选择。

2. 核心概念：理解 FFM 的四个关键角色

2.1 Linker 与 SymbolLookup：去动态库里“捞”函数

第一次用 FFm 时，我发现它的模型比 JNI 清晰得多。你不需要让 Java 编译器生成什么头文件，也不用在 C 侧导出特定命名的函数。你只需要两样东西：函数的运行时地址，以及函数签名描述。

Linker是这个流程的入口。Linker.nativeLinker()会返回一个与当前平台 ABI 匹配的链接器。这个链接器知道怎么生成函数调用指令，也知道怎么处理结构体传参、寄存器分配等底层细节。SymbolLookup则负责“找符号”：linker.defaultLookup()返回的查找器能直接查 libc 动态库里的符号。

举个例子，我要找strlen这个 C 函数，代码很直接：

Linker linker = Linker.nativeLinker(); SymbolLookup libc = linker.defaultLookup(); MemorySegment strlenSymbol = libc.find("strlen").orElseThrow();

SymbolLookup.find()返回一个Optional<MemorySegment>，这个MemorySegment可以理解为一个“符号地址”。找不到符号时抛出异常，而不是像 JNI 那样等到调用时才莫名其妙失败。

如果你的库不在默认 libc 里，可以用SymbolLookup.libraryLookup("libfoo.so", arena)打开特定动态库。这个方法需要传入一个Arena，用于控制库句柄的关闭时机。

2.2 FunctionDescriptor：用 Java 声明 C 函数的“简历”

拿到符号地址之后，下一步是告诉Linker这个 C 函数长什么样。这就是FunctionDescriptor的职责。它描述两个东西：返回值的类型布局，以及参数列表的类型布局。

比如strlen的 C 签名是size_t strlen(const char *s)。对应到 FFM：

FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS);

ValueLayout.JAVA_LONG描述返回值，表示 C 层的size_t在大多数 64 位平台上对应 Java 的 8 字节长整型。ValueLayout.ADDRESS描述参数，表示const char*是一个地址类型。这里需要理解“布局”这个词，它不仅仅是“类型”，还包含了字节宽度、对齐方式、字节序等信息。这也是 FFM 比简单类型映射更严谨的地方。

FFM 中常用的ValueLayout常量有这些：JAVA_BYTE、JAVA_SHORT、JAVA_INT、JAVA_LONG、JAVA_FLOAT、JAVA_DOUBLE、ADDRESS。它们分别对应 Java 的byte、short、int、long、float、double和内存地址。当 C 函数返回void时，用FunctionDescriptor.ofVoid(...)。

2.3 Arena 与 MemorySegment：内存的分配、访问与回收

JNI 时代最折磨人的是内存管理。外部内存谁分配、谁释放、生命周期持续到什么时候，全靠自觉。FFM 用Arena概念把这块理顺了。

Arena可以理解为一个“内存作用域容器”。你可以通过Arena.ofConfined()创建一个单线程作用域的 Arena，也可以用Arena.ofShared()创建多线程共享的 Arena，还有Arena.global()这种永不关闭的全局 Arena。最常用的写法是结合 try-with-resources：

try (Arena arena = Arena.ofConfined()) { MemorySegment text = arena.allocateFrom("Hello, FFM!"); // 使用 text }

当退出 try 块时，这个 Arena 管理的所有内存都会被自动释放。如果你在释放之后还尝试访问对应的MemorySegment，FFM 会抛出IllegalStateException，而不是给你一个神秘的段错误。如果你要分配一块指定大小的原生内存，可以用arena.allocate(1024)。如果你需要按某个结构体布局分配，可以用arena.allocate(MEMORY_LAYOUT)。

MemorySegment是 FFM 对外部内存的统一抽象。它不像byte[]那样在 Java 堆里，而是在堆外原生内存中。你可以通过segment.set(ValueLayout.JAVA_INT, offset, value)往指定位置写值，通过segment.get(ValueLayout.JAVA_INT, offset)读值。这种“段 + 布局 + 偏移量”的方式，让结构体的读写变得很自然。

2.4 MethodHandle：调用 Native 代码的入口

FFM 调用 C 函数时，返回的是MethodHandle。MethodHandle是 Java 里已有的高性能方法调用抽象，这里被复用为“外部函数句柄”。

把符号地址和FunctionDescriptor交给Linker.downcallHandle()，就能得到一个可调用的MethodHandle：

MethodHandle strlen = linker.downcallHandle( libc.find("strlen").orElseThrow(), FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS) );

之后就可以像调用普通方法句柄一样invoke。MethodHandle在类型检查上非常严格，参数类型不匹配会抛WrongMethodTypeException，而不是到了 C 层才出问题。这也是迁移之后感觉“更踏实”的原因之一。

需要注意的是，每次创建MethodHandle都涉及符号查找、ABI 分析等开销，所以实际项目中应该把句柄缓存起来，而不是每次都创建。通常我会把它放在静态成员位置，初始化一次，后续复用。

3. 实操演练：三个经典场景快速上手

3.1 第一个 C 函数：调用 strlen 计算字符串长度

先写一个可以直接运行的完整示例。这个例子不需要头文件，不需要编译 C 代码，只要你的 JDK 是 22 及以后版本，代码可以直接跑：

import java.lang.foreign.*; import java.lang.invoke.MethodHandle; public class FfmStrlen { public static void main(String[] args) throws Throwable { Linker linker = Linker.nativeLinker(); SymbolLookup libc = linker.defaultLookup(); MethodHandle strlen = linker.downcallHandle( libc.find("strlen").orElseThrow(), FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS) ); try (Arena arena = Arena.ofConfined()) { MemorySegment text = arena.allocateFrom("Hello, FFM!"); long length = (long) strlen.invoke(text); System.out.println("strlen = " + length); } } }

输出结果是strlen = 11，字符串"Hello, FFM!"正好 11 个字符。

这里第一个关键点是arena.allocateFrom("Hello, FFM!")。这个方法会分配一块原生内存，把 Java 字符串按 UTF-8 编码写入，并在末尾自动补上\0终止符。strlen在 C 层看到的就是一个合法、完整的 C 字符串。

第二个关键点是strlen.invoke(text)直接传入MemorySegment。当FunctionDescriptor中参数布局是ValueLayout.ADDRESS时，对应的方法句柄参数类型就是MemorySegment，所以你不需要去取“地址数值”，直接把段传进去即可。这也是很多人初次接触时容易混淆的地方：不要再主动调用segment.address()去转long，除非你特意把布局改成JAVA_LONG，否则类型对不上。

3.2 与 C 互操作：分配原生内存并调用 malloc/free

调strlen这类只读函数还不过瘾，我们通常需要自己分配内存、写入数据、再交给 C 库处理。JNI 时代这块是重灾区。FFM 下手动分配同样可行，只是要注意“C 库分配的内存”和“Arena 分配的内存”不是一回事。

import java.lang.foreign.*; import java.lang.invoke.MethodHandle; public class FfmMallocFree { public static void main(String[] args) throws Throwable { Linker linker = Linker.nativeLinker(); SymbolLookup libc = linker.defaultLookup(); MethodHandle malloc = linker.downcallHandle( libc.find("malloc").orElseThrow(), FunctionDescriptor.of(ValueLayout.ADDRESS, ValueLayout.JAVA_LONG) ); MethodHandle free = linker.downcallHandle( libc.find("free").orElseThrow(), FunctionDescriptor.ofVoid(ValueLayout.ADDRESS) ); try (Arena arena = Arena.ofConfined()) { MemorySegment raw = (MemorySegment) malloc.invoke(128L); if (raw.address() == 0) { throw new OutOfMemoryError("malloc returned null"); } // 这里 raw 只是一个“不知道大小”的段，先用 reinterpret 按 128 字节重新解释 MemorySegment block = raw.reinterpret(128L, arena, null); block.set(ValueLayout.JAVA_INT, 0, 42); System.out.println(block.get(ValueLayout.JAVA_INT, 0)); // C 库分配的内存要主动释放，Arena 关闭不会帮你调 free free.invoke(raw); } } }

这里特别说明一下raw.reinterpret(128L, arena, null)。通过malloc返回的MemorySegment是一个地址，但 FFM 并不知道它具体指向多大范围的内存，所以它默认是个“零长度段”。如果直接对它调用set或get，会得到边界访问异常。reinterpret的作用就是告诉 FFM，这块区域按多大尺寸看待，同时可以绑定到一个Arena和清理动作。上述示例传入null作为 cleanup，因为我们自己会手动free。实际上更省心的方式是让Arena关闭时自动调用free：

MemorySegment block = raw.reinterpret(128L, arena, segment -> { try { free.invoke(segment); } catch (Throwable e) { throw new RuntimeException(e); } });

这样只要try块结束，free就会被自动调用。用不用这种写法取决于内存生命周期由谁掌控。我的习惯是：如果这段内存的存活范围和一个Arena完全重合，就让 Arena 负责；如果需要跨作用域传递，就自己管理，并保证不会重复free。

3.3 传递结构体数据：用 MemoryLayout 映射 C struct

结构体是 JNI 里最让人头大的部分。JNI 里没有直接映射 Cstruct的类型，你得先把结构体拆成基本字段，再把字段打包进 Java 对象，最后传到 C 层还要重新组装。FFM 用MemoryLayout.structLayout(...)把这个过程简化了。

假设 C 侧定义了一个二维坐标结构体：

typedef struct { int x; int y; } Point;

Java 侧对应的布局描述：

MemoryLayout POINT_LAYOUT = MemoryLayout.structLayout( ValueLayout.JAVA_INT.withName("x"), ValueLayout.JAVA_INT.withName("y") );

之后在一个 Arena 中分配一块符合这个布局的内存：

try (Arena arena = Arena.ofConfined()) { MemorySegment point = arena.allocate(POINT_LAYOUT); point.set(ValueLayout.JAVA_INT, 0, 10); point.set(ValueLayout.JAVA_INT, 4, 20); long x = point.get(ValueLayout.JAVA_INT, 0); long y = point.get(ValueLayout.JAVA_INT, 4); System.out.println("point = (" + x + ", " + y + ")"); }

注意字段偏移量：POINT_LAYOUT中x占 4 字节，y紧跟其后，偏移就是 4。这类简单结构体没有对齐缝，偏移可以手工算。如果字段里有double或者指针，最好用layout.byteOffset(MemoryLayout.PathElement.groupElement("x"))这种方式获取偏移，不要手算，因为结构体对齐规则有时会插入 padding，手算容易翻车。

如果要传给一个接受Point*的 C 函数，只需要把point这个MemorySegment作为参数传进 downcall handle 即可。ADDRESS 布局的参数天然允许传入结构体段的地址。

再进一步，如果你的 C 库需要 Java 回调，比如qsort的比较函数，那就涉及 upcall。Linker.upcallStub()可以把一个 Java 的MethodHandle包装成 C 函数指针：

MethodHandle compare = MethodHandles.lookup().findStatic( FfmQSort.class, "compare", MethodType.methodType(int.class, MemorySegment.class, MemorySegment.class) ); MemorySegment compareStub = linker.upcallStub( compare, FunctionDescriptor.of( ValueLayout.JAVA_INT, ValueLayout.ADDRESS.withTargetLayout(ValueLayout.JAVA_INT), ValueLayout.ADDRESS.withTargetLayout(ValueLayout.JAVA_INT) ), arena );

这样 C 侧qsort执行到“比较两个元素”时，会反向调用 Java 方法。JNI 时代这种回调玩法要写一堆静态 native 方法，还要处理JNIEnv传递，FFM 确实省掉了很多模板。

3.4 调用可变参数函数时的“特殊处理”

很多新手在第一次尝试 FFM 调printf时会碰壁：FunctionDescriptor要求参数列表完整，但 C 的printf是可变参数函数。FFM 本身没有专门声明“varargs”的语法，实际处理方式是，针对你想发起的某次调用，把这次调用中真实会用到的额外参数补进FunctionDescriptor。

比如调用printf("answer is %d\n", 42)，那就按两个参数描述：

MethodHandle printf = linker.downcallHandle( libc.find("printf").orElseThrow(), FunctionDescriptor.of( ValueLayout.JAVA_INT, ValueLayout.ADDRESS, ValueLayout.JAVA_INT ) ); try (Arena arena = Arena.ofConfined()) { MemorySegment format = arena.allocateFrom("answer is %d\n"); int result = (int) printf.invoke(format, 42); }

这种写法能不能成功，取决于底层平台 ABI 下可变参数在寄存器/栈上的传递约定。好在Linker已经帮我们把 ABI 差异封装掉了，你补充的参数只要类型完全匹配就好。如果参数类型给错了，比如把JAVA_INT写成了JAVA_LONG，运行结果很可能是一个毫无意义的输出，甚至触发段错误。所以，可变参数调用时务必让 descriptor 严格匹配实际入参。

4. 细节与排查：内存布局、生命周期和段错误的坑

4.1 类型映射表：Java 与 C 怎么对应

我在实际使用中整理了一张常用映射表，这不完全等同于 C 规范，但在主流的 x86_64 Linux/macOS 环境里，准确度足够：

这里要特别强调“C long不等于 Javalong”这个细节。在 x86_64 Linux 上，C 的long是 64 位，和size_t宽度一致，直接映射JAVA_LONG没问题。但 Windows 上 C 的long是 32 位，如果你写死JAVA_LONG，参数栈布局就会整体错位。所以我更推荐的做法是：在代码注释里写明目标平台，跨平台代码尽量用JAVA_INT对应 Cint，用显式宽度的布局去处理指针和size_t。

FFM 提供的VaList和AddressLayout.withTargetLayout等高级 API 也可以用于处理更复杂的指针语义。关于 ADDRESS 配合withTargetLayout，它能补充指针指向的对象布局，比如int*写成ValueLayout.ADDRESS.withTargetLayout(ValueLayout.JAVA_INT)，在 upcall 场景尤其有用。

4.2 内存生命周期：Arena 的作用域与释放时机

Arena 不是花架子，它解决的是 JNI 时代最头大的问题：“这些内存什么时候能释放”。我的建议是：保持一个 Arena 只服务于一个短任务。

try (Arena arena = Arena.ofConfined()) { // 短任务：分配、调用、读取 }

这种模式下，所有临时缓冲都随着任务结束一起释放，不会有跨线程的悬垂指针。Arena.ofConfined()表示该 Arena 只能被创建它的线程访问，简单场景下最安全、性能也最好。Arena.ofShared()适合多个线程共同使用同一块内存缓冲区，代价是内部会增加同步开销。

真正容易出问题的是把对象生命周期跨出了 Arena 作用域。比如你把一个MemorySegment存进了全局缓存，然后关闭了创建它的 Arena，之后再拿出来用，就会得到异常。FFM 的设计就是故意用这种检查，让悬垂指针问题在 Java 层暴露出来，而不是留到 C 层变成段错误。

如果你确实需要跨作用域长期保存一段 C 库返回的内存，两个选择：一是用Arena.global()，但这意味着内存要“手动”管理，因为全局 Arena 永不关闭；二是用reinterpret(..., customArena, cleanup)让新的 Arena 接管生命周期，并指明释放动作。我倾向于后者，因为至少释放逻辑是显式的。

4.3 段错误排查：地址、越界与生命周期

FFM 不可能彻底消灭段错误，因为它给了你一把能直接访问底层内存的钥匙。就我的经验，段错误集中在三种情况。

第一种，传给 C 函数的MemorySegment地址是有效的，但 C 函数自身对缓冲区长度假设错误，写越界了。比如你分配了 64 字节，C 函数却按 4KB 的缓冲区来写。这种问题 FFM 帮不了你，只能在调用前严格核对 C 库的 API 文档，必要时多分配一些内存作为余量。

第二种，把一个已经关闭的 Arena 的段地址传给了 C 函数，然后 C 函数去读写这块内存。此时 C 侧拿到的是一个“已失效”的指针。Java 侧会先尝试检查段作用域，但如果你通过address()拿裸地址传过去，Java 就无从保护了。我的底线是：调用 C 函数时优先传MemorySegment而不是long地址，让 FFM 至少保留检查能力。

第三种，C 库内部维护了一个指针，等它下次使用时候，Java 侧对应的 Arena 已经关闭。比如你调用某个库的set_callback_data(ptr)，传了一个 Arena 分配的缓冲区，之后这个 Arena 关了，但 C 库还持有这个指针。之后库内部再访问，轻则读到垃圾数据，重则段错误。对策是：确保 C 库持有引用期间，对应的 Arena 一直存活。

一旦真的崩了，先把hs_err_pid*.log中Java frames和Native frames对照看，确认崩在哪个库函数。再检查是不是最上面的三种情况之一。JNI 时代我只能靠 gdb 硬查，FFM 下至少错误通常还能定位到参数交互层面。

4.4 跨平台与 ABI 差异：不是所有 long 都一样

FFM 的Linker.nativeLinker()会自动选择当前平台对应的 ABI，这已经比 JNI 手工编译省心很多，但跨平台时仍要小心符号名差异。比如 Windows 的 C 运行库里，printf这类函数在符号层面可能有下划线前缀或不同名称。Linker.defaultLookup()在不同平台检索的库也不一样，不能假设所有 C 库函数都能直接找到。

当你需要调用某个特定第三方库时，要用SymbolLookup.libraryLookup("/path/to/libfoo.so", arena)显式加载。路径的处理最好走配置化，不要写死，否则项目换个部署环境就崩。Windows 下动态库后缀是.dll，Linux 是.so，macOS 是.dylib，区分这些是基础功课。

结构体对齐也要跨平台验证。C 编译器的默认对齐规则和 Java 的MemoryLayout.structLayout默认对齐规则在大多数平台是一致的，但如果你用了#pragma pack这类“紧凑结构体”，Java 侧就要手动给MemoryLayout加withByteAlignment或用填充字段手动补齐。我在一个项目里就遇到过：结构体字段顺序一致、位数一致，但 C 编译器按 4 字节对齐，Java 默认按 8 字节对齐，算出的字段偏移完全对不上。后来打印出两边sizeof/byteOffset一对比，马上定位到对齐策略差异。

5. 实战心得：常见问题速查表与排错实例

5.1 常见错误场景速查

把这些错误整理成表，方便大家快速对照：

5.2 一次真实排错过程

之前帮某个项目组排查过一个“调用第三方图像处理库返回结果偶尔错误”的问题。那位开发者已经在用 FFM 了，但一到并发场景，部分图片的数据就会错乱。

一开始怀疑是 C 库线程安全问题，后来发现不是。问题的实质是：C 库返回了一个指针，指向库内部分配的内存，开发者把它包装成MemorySegment后使用。但这个返回的段在 FFM 中被视为“零长度段”，开发者虽然用reinterpret指定了大小，却没有注意到reinterpret需要绑定正确的 Arena 生命周期。因为原始接口并没有把返回内存的释放职责交代清楚，他们用一个短生命周期 Arena 去绑定，结果图片处理异步任务还没结束，Arena 就已经关闭。后续访问时，Java 侧报异常倒还好，问题最诡异的是某些路径直接通过address()拿出了原始地址，绕过了 FFM 的检查，于是拿到了已释放内存，数据随机错乱。

排查过程其实不长：先跑单线程不出问题，加并发后偶发；把错误触发的图片反复跑，发现稳定复现后，往 FFM 的 Arena 生命周期上查；打印关闭时间点和异常发生时间点，一对照就明白了。解决办法是让承载图片数据的 Arena 生命周期覆盖整个异步任务，并在任务结束时显式关闭。这种问题如果发生在 JNI 时代，可能要排查数天，FFM 下因为作用域是显式对象，定位要快得多。

5.3 什么情况下你还是得用 JNI

说了这么多 FFM 的好处，还是要保持客观。有些场景 FFM 现在仍不能替代 JNI。

首先要访问 JVM 内部能力时，比如开发 Java 调试工具、Agent 工具、需要调用 JVMTI 接口，JNI 依然是官方通道。其次，你的现有代码库已经积累了大量 JNI 函数，全部重写成本很高，短期内维护旧代码可能是更现实的选择。另外，如果项目还停留在 JDK 21 或更早版本，又不想用孵化器 API，那也只能先用 JNI。FFM 在 JDK 22 前一直在jdk.incubator.foreign里，API 会有调整，生产环境用它需要一个明确的升级计划。

最后说一点个人体会。把现有项目从 JNI 迁到 FFM 的时候，我最大的感觉是，写 C 的互操作终于回到了“写 Java”的思维：类型描述、内存作用域、异常，这些都在语言和 API 层有明确表达。头文件、javac -h、C 包装层、平台编译脚本，这些旧时代的负担，能不背就不背。我建议你可以先从一两个低频小函数开始，比如从 C 库计算哈希、读系统时间这类无副作用操作试水，跑通之后再逐步扩大范围。你会明显感觉到，调试互操作代码的“心理成本”，真的比 JNI 时代低了很多。