一文搞懂JNI描述符：类、方法与字段签名规则及动态注册

你有没有见过这种场景：JNI 层调用 FindClass 返回空指针，或者 GetMethodID 直接让进程崩溃，日志里写着一行 JNI DETECTED ERROR IN APPLICATION: method not found。遇到这种问题，十有八九不是 Java 层代码的问题，而是你在 C/C++ 里写的那串“描述符”根本没对上号。说白了，JNI 是 Java 和 C/C++ 两套类型系统之间的桥梁，而描述符就是这座桥上的门牌号——写错了，两边都不知道你找的是谁。

这篇是 JNI 编程指南系列的第三篇，专门拆描述符。上一篇讲了 JNI 的整体结构和线程模型之后，我发现很多读者对“签名”“描述符”这类概念一直是懵的，甚至有人会把 java.lang.String 直接传进 FindClass 去跑，然后对着 UnsatisfiedLinkError 发呆。所以这篇我打算把类描述符、方法描述符、字段描述符一次讲透，并结合动态注册 RegisterNatives 实战演示怎么用，最后聊聊我在实际调试中踩过的那些坑。内容确实有点干，但看完能帮你省下大量排查时间。

1. 描述符不是给 JVM 看的，是给“中间人”看的

先说清楚一个很多人搞混的问题：JNI 描述符跟操作系统里的“文件描述符”、USB 设备里的“设备描述符”完全是两码事。它是 JNI 规范定义的一套类型编码规则，用一串 ASCII 字符代表某个 Java 类、方法或字段。之所以要搞这么一套编码，根本原因在于 Java 层和 Native 层没办法直接共享内存里的类型信息，C/C++ 编译器不认得 java.lang.String 这种带包名的类符号，JVM 也不理解 C 语言的 jstring 到底对应哪个 Java 类型。所以 JNI 规范想了一个办法：把类型信息编码成字符串，让 JVM 在运行时去解析这个字符串，找到对应的类、方法或字段。

这套规则其实不是 JNI 首创，它基本继承了 JVM 规范里的字段描述符（Field Descriptor）和方法描述符（Method Descriptor）体系。也就是说，不仅 JNI 在用，Java 字节码、反射 API、热修复框架、字节码插桩工具里也到处能看到类似结构。很多人只在写 JNI 时才碰到它，容易被绕晕，但如果理解了它本质上是 JVM 体系内通用的一种“类型序列化格式”，很多疑问就自然解开了。

JNI 层的类型系统其实分两大类：基本类型和引用类型。基本类型就是 byte、short、int、long、float、double、char、boolean 这八种，它们的描述符是单个大写字母，比较好记：

你可以发现几个特殊点：long 的字母是 J 而不是 L，因为 L 被对象类型占用了；boolean 是 Z 而不是 B，因为 B 给了 byte。这两个属于需要硬记的，我第一次学的时候就把 long 写成 L，然后 FindClass 一直报找不到类，排查了好一会儿才意识到是描述符编错了。

类描述符和方法描述符的规则，我会在后面两节分别展开。这里先建立一个整体认知：描述符里的每一个字符都对应一种明确含义，不能凭感觉省略或替换。字符串里多一个分号、少一个斜杠，JVM 根本不会帮你纠错，它会直接告诉你找不到对应元素，而且报错方式在不同 Android 版本上还不一样，有的直接 abort，有的只留一行 warning。

2. 类描述符：包名里的斜杠是最容易破防的地方

2.1 基本规则：点号换成斜杠，带上分号

类描述符的规则其实一句话就能概括：对于普通引用类型，把 Java 包名里的点号 . 全部替换成斜杠 /，然后在类名尾部补一个分号 ;。比如 java.lang.String，对应描述符就是：

text复制Ljava/lang/String;

注意，开头的大写 L 代表这是一个对象类型，结尾的分号表示这个类型的描述到此结束。如果去掉首尾这两个标记，中间那部分 java/lang/String 在 JNI 里被称为“类名”（binary name），FindClass 函数接收的参数就是这种类名格式，不需要首尾的 L 和 ;。很多初学者会把两者混淆：FindClass(env, "Ljava/lang/String;") 实际上是错误的写法，因为 FindClass 期望的参数是 "java/lang/String" 这种内部形式。

同样的道理，我们自己写的类 com.example.jniapp.NativeLib，在 FindClass 里要写成：

c复制jclass clazz = (*env)->FindClass(env, "com/example/jniapp/NativeLib");

如果这个类是在 Android 项目里用 Kotlin 写的，包名路径规则不变，依然是点号换斜杠，不用额外加别的后缀。

2.2 数组类型描述符：左括号加元素类型，对象数组要补分号

数组的类描述符规则是：一个 [ 加元素描述符。有多少维数组，就写多少个 [。比如：

注意 [Ljava/lang/String; 这种写法，末尾的分号是 java/lang/String 这个对象描述符自带的，不是多余的。我第一次写 String[] 的描述符时漏掉过末尾分号，结果运行时 FindClass 返回空，还以为是数组创建方式不对。 int[] 这种基本类型数组看起来只是元素描述符前加一个 [，没有任何分号，这跟对象数组的写法形成了鲜明对比——原因很简单，I 本身不是以 L 开头、以分号结尾的完整描述符，它就是一个单字母描述符。

在 JNI 里创建数组时，NewObjectArray 的第一个参数是数组长度，第二个参数是元素类型，需要用到元素类的 jclass。如果想获取 String[] 的 jclass，可以这样：

c复制jclass stringArrayClass = (*env)->FindClass(env, "[Ljava/lang/String;");

或者先拿到 String 的 jclass，再用 NewObjectArray 去创建。前者更直接，但前提是你确实需要数组本身的类对象引用。

2.3 内部类与匿名类的表示方式

如果类里有内部类，描述符中内部类和外部类之间使用美元符号 $ 连接而不是点号。比如外部类 Outer 的内部类 Inner，完整类描述符是：

text复制Lcom/example/Outer$Inner;

在 FindClass 里则要写成 "com/example/Outer$Inner"。这个规则同样适用于 Kotlin 的 companion object、内部类等编译后的字节码结构。匿名类的情况更特殊，类名里通常含有数字，比如 MainActivity$1$onClick 这类，实际写 JNI 时如果拿不到稳定类名，最好别用 FindClass 去硬编码，用 getClass().getName() 在 Java 层打印一次再搬到 Native 层更稳妥。

2.4 类描述符和“字段描述符”的关系

值得说明的是，类描述符同时被 JNI 里的字段查询函数使用。比如你想读取某个 Java 对象的 String name 字段，GetFieldID 的第三个实参就是该字段的描述符，而字段是对象类型时字段描述符正是对应的类描述符。看个例子：

c复制jfieldID fid = (*env)->GetFieldID(env, clazz, "name", "Ljava/lang/String;");

这里 Ljava/lang/String; 既是 java.lang.String 类的类描述符，也是在字段场景下的字段描述符。可见类描述符是更多复杂描述符的基础构件，把这个写好，后面都不会太吃力。

3. 方法描述符：括号加字母串起来的类型签名

3.1 方法描述符的完整格式：参数靠左，返回值靠右

方法描述符的通用格式是：

text复制(参数类型描述符序列)返回值描述符

括号里按顺序写每个参数的类型描述符，括号外紧跟返回值类型描述符。没有参数就写一个空括号 ()，返回值是 void 就用 V，返回值是对象就写对应的类描述符。

举几个实际例子：

注意泛型擦除这个点：List<String> 在运行时就是 java.util.List，方法描述符里只写 Ljava/util/List;，不会体现泛型参数。这一点很关键，因为很多人拿 Java 源码里的带泛型方法去推算描述符，总是对不上。JNI 只看擦除后的类型。

3.2 各种参数的描述符速查

参数如果带数组，按数组描述符规则写，比如：

函数指针如果不通过 JNI 描述符走，而是直接用 RegisterNatives 注册函数地址，那么在 Native 层方法签名里会看到 JNICALL 和 JNI 类型参数，这部分是另一套体系。但如果你需要从 Native 层反向调用 Java 方法，比如调用 Java 里的 onEvent(int type, String payload)，那就要在 GetMethodID 里传入它的方法描述符：

c复制jmethodID mid = (*env)->GetMethodID(env, clazz, "onEvent", "(ILjava/lang/String;)V");
if (mid == NULL) {
    return; // 方法描述符写错时 mid 会为空
}
(*env)->CallVoidMethod(env, obj, mid, type, jstr);

这段代码里最容易出问题的就是第三个实参 (ILjava/lang/String;)V。括号左括号和右括号都不能少，即使没有参数也要写 ()；参数之间不加逗号、不加空格；返回值 V 在括号外面并且放在最后。很多 C/C++ 程序员因为习惯了写函数声明，会下意识把 (int, String) 里的逗号写进去，这在 JNI 描述符里是致命的。

3.3 构造函数的方法描述符

构造函数在 JNI 里对应的方法名是 <init>，其方法描述符以 V 作为返回类型，因为构造函数本身不返回 Java 层可见的值。比如构造函数 public NativeBridge(String path, int mode)，方法描述符是：

text复制(Ljava/lang/String;I)V

通过 NewObject 创建 Java 对象时，需要先拿到构造函数的 jmethodID：

c复制jmethodID ctor = (*env)->GetMethodID(env, clazz, "<init>", "(Ljava/lang/String;I)V");
jobject obj = (*env)->NewObject(env, clazz, ctor, path, mode);

构造函数的名字永远是 <init>，静态初始化块 <clinit> 通常不由 JNI 层主动调用，JVM 会在类加载时自动执行。这里 <init> 这种写法属于 JVM 内部方法名的保留字，不能用 Java 源码里的其他名字替代。

3.4 静态方法、受保护方法都一样

GetStaticMethodID 和 GetMethodID 在描述符的编写上没有任何区别，区别只在于寻找的是静态方法还是实例方法。换句话说，public static native void nativeInit(Context context) 这种方法，如果要从 Native 层拿到它的 jmethodID（不推荐但你可能会需要），描述符就是 (Landroid/content/Context;)V。Android 的 Context 本身是一个抽象类，实际运行时类型可能是 ContextImpl，但描述符仍然以声明的参数类型 android/content/Context 为准。

写方法和字段 ID 相关代码时，有个通用技巧：用 javap 打印类的签名。javap -s -p 能直接显示所有成员和方法的方法描述符，不用自己手动推算。我曾经就因为手推方法描述符把返回类型写错，核对 javap 输出后一次就修正了。后面的章节我会专门演示这个用法。

4. 实战：用描述符完成动态注册 Native 方法

4.1 动态注册为什么值得学

JNI 注册 Native 方法有两种方式：静态注册和动态注册。静态注册是传统的 Java_包名_类名_方法名 命名规则，在 JNI 函数名前缀里隐含了类信息，不需要额外传描述符，看起来简单，但方法名一旦被混淆器改动或者包名较重命名，就很容易出错。动态注册则是在 JNI_OnLoad 里通过 RegisterNatives 显式地声明 Java native 方法对应到哪个 C/C++ 函数指针，同时需要提供方法名和方法描述符。

动态注册的核心优势在于：一是方法名和实现地址在运行时才绑定，Java 层怎么混淆都不影响；二是避免了静态注册那种又臭又长的方法名；三是在同一个类里重载的 native 方法可以共享同一个函数指针，然后根据方法描述符区分。这也是各大跨平台框架、热修复框架里普遍采用的方式。

4.2 动态注册的标准步骤

标准步骤分三步：先拿到目标类的 jclass；接着构造 JNINativeMethod 数组；最后调用 RegisterNatives 完成注册。

JNINativeMethod 结构体定义在 jni.h 里：

c复制typedef struct {
    const char* name;
    const char* signature;
    void*       fnPtr;
} JNINativeMethod;

其中 signature 字段就是方法描述符。注意它写的是整串 (参数)返回值，不是只写返回类型。假设 Java 层有这样一个类：

java复制package com.example.jni;

public class MathBridge {
    public static native int add(int a, int b);
    public static native String getVersion();
}

那么在 C/C++ 中可以这样动态注册：

c复制#include <jni.h>
#include <string>

extern "C" JNIEXPORT jint JNICALL
native_add(JNIEnv* env, jclass clazz, jint a, jint b) {
    return a + b;
}

extern "C" JNIEXPORT jstring JNICALL
native_getVersion(JNIEnv* env, jclass clazz) {
    return env->NewStringUTF("1.0.0");
}

static const JNINativeMethod kMathBridgeMethods[] = {
    { "add",        "(II)Ljava/lang/String;", reinterpret_cast<void*>(native_add) },
    { "getVersion", "()Ljava/lang/String;",    reinterpret_cast<void*>(native_getVersion) }
};

上面这段是我故意写错演示用的——native_add 的签名应该是 (II)I，不是 (II)Ljava/lang/String;。真实项目中这种错误从哪里来？很多是从 Java 源码里复制了带泛型的方法声明，然后手滑用错了返回类型。这也就是为什么一定要在写完签名后用工具核对。

正确的 kMathBridgeMethods 应该是：

c复制static const JNINativeMethod kMathBridgeMethods[] = {
    { "add",        "(II)I",                   reinterpret_cast<void*>(native_add) },
    { "getVersion", "()Ljava/lang/String;",    reinterpret_cast<void*>(native_getVersion) }
};

然后实现 JNI_OnLoad：

c复制extern "C" JNIEXPORT jint JNICALL
JNI_OnLoad(JavaVM* vm, void* reserved) {
    JNIEnv* env = nullptr;
    if (vm->GetEnv(reinterpret_cast<void**>(&env), JNI_VERSION_1_6) != JNI_OK) {
        return JNI_ERR;
    }
    jclass clazz = env->FindClass("com/example/jni/MathBridge");
    if (clazz == nullptr) {
        return JNI_ERR;
    }
    jint result = env->RegisterNatives(
        clazz,
        kMathBridgeMethods,
        sizeof(kMathBridgeMethods) / sizeof(kMathBridgeMethods[0])
    );
    if (result != JNI_OK) {
        return JNI_ERR;
    }
    return JNI_VERSION_1_6;
}

如果在 RegisterNatives 这一步返回负数，最常见的两个原因就是 FindClass 找不到类（类描述符错误）或者 JNINativeMethod 里的方法描述符跟 Java 层真实方法不匹配。

4.3 动态注册里描述符要匹配什么：方法名+签名，而不是返回类型单独匹配

JVM 在方法重载时是根据方法名和方法描述符联合匹配的。描述符里同时包含了参数类型和返回类型，所以你写出的方法描述符必须是 Java 方法声明在字节码层面的完整签名。例如一个类里有两个同名方法：

java复制public native void doWork(String input);
public native void doWork(int count);

对应两个 JNINativeMethod，签名分别是 (Ljava/lang/String;)V 和 (I)V。如果你把 (I)V 错写成 (Ljava/lang/String;)V，注册时不会直接报错，但 Java 层调用 doWork(int) 的时候可能调到的是期望处理 String 的 Native 实现，导致 Native 方法内部拿到错误的参数类型。这种错误非常隐蔽，因为它不在注册时报错，而在运行时会踩到参数解析错误引发的崩溃，所以注册前一定要仔细核对每个重载方法的描述符。

4.4 静态注册时为什么不太需要描述符，但函数名里其实也隐含了描述符逻辑

静态注册模式下，JVM 在首次调用 native 方法时，会根据类名和方法名去查找对应的 Java_xxx_xxx 函数。它并不需要你手写描述符，因为 JVM 可以通过 Java native 方法声明本身推导完整的方法签名，链接时按 (JNIEnv*, jclass/jobject, ...实际参数...) 的函数指针类型来匹配。静态注册的好处是 Native 函数头部的第二参数自动区分了静态方法和实例方法（jclass 还是 jobject），但坏处是如果方法是在 Java 层重载的，静态注册依然要求方法名里加上额外的编码规则，否则 JVM 无法确定到底对应哪个重载版本。

JNI 规范对重载的静态注册方法有额外名字编码，这比我记混淆表还难受。所以无论从工程可维护性还是未来做代码混淆的角度，动态注册都更可取。

4.5 字段描述符在动态注册场景中的变体

动态注册不只是方法，字段操作在 JNI 层也常见。字段 ID 的获取方式跟方法 ID 类似，但传入参数不是方法描述符而是字段描述符。举一个关键场景：你要在 Native 层访问 Java 对象的某个成员变量 private int mCount;，字段描述符是 I；如果是 static String TAG，字段描述符是 Ljava/lang/String;。

有些对象被混淆后字段名会变，这时直接通过 Java 层暴露 getter/setter 方法更保险，通过 GetMethodID 调用 getter 方法，而不是依赖 GetFieldID 的字段名。但如果出于性能考虑必须在 Native 层直接读写字段，那么字段名和字段描述符必须写成混淆后的字节码字段，这一点在开发和发布不同版本时要格外留意。

5. 最容易出错的描述符细节：从踩坑到根因

5.1 分号问题：为什么 String[] 描述符里两个分号不一样

描述符里分号的重要性再怎么强调都不过分。java.lang.String 对应 Ljava/lang/String;，重点在最后的 ;。很多方法描述符写错都跟分号有关：要么漏掉，要么多加。

有个反直觉的场景是数组的结束符。[Ljava/lang/String; 里，L 引入对象类型，java/lang/String 是类名，最后一个 ; 是对象描述符的结束符。而 int[] 对应的 [I 中没有分号，因为 I 是基本类型描述符，它不需要分号收尾。把这个规则换成逻辑记忆：只有以 L 开头的对象类型描述符才需要以 ; 结尾，基本类型描述符一律单字母完结。

5.2 包名与类名的分隔符：点号、斜杠和美元符

FindClass 和 GetMethodID 对类名路径的处理不同，同一份 JNI 代码里经常出现两种写法并存，容易写串：

• FindClass 接收的是内部类名格式：包名用斜杠，例如 "android/app/Activity"。
• GetMethodID 接收的 name 参数是 Java 方法名，例如 "onCreate"，和方法描述符无关。
• 方法描述符里包名同样用斜杠，例如 (Landroid/os/Bundle;)V。

我见过有人把 FindClass 的参数写成 "android.app.Activity"（点号形式），然后在 FindClass 返回空指针后各种怀疑人生。其实 JNI 规范里明确要求内部类名不带点号。反过来，如果是在 Java 层通过 Class.forName("android.app.Activity") 拿类，那才用点号。JNI 层和纯 Java 层的类名规则别混着用。

内部类的 $ 符号也一样。在 Java 源码里写 Outer.Inner，在内部类名里是 com/example/Outer$Inner。一个关键避坑点：不要在 C/C++ 的字符串里把 $ 当成普通字符写，$ 本身在 C 中不是转义符，不用额外处理，但在一些构建脚本里 $ 可能被 shell 展开，造成深层问题，所以建议动态拼接或直接硬编码为完整的内部类名。

5.3 C/C++ 字符串里的反斜杠与双引号不要想当然

JNI 描述符本质是 C 字符串，而 C/C++ 的字符串字面量里没有特殊转义需求，所以 Ljava/lang/String; 直接写成 "Ljava/lang/String;" 即可。但如果你所在项目是用 CMake 或脚本动态生成 JNI 源码，注意脚本语言里的转义规则。例如在有些 Python 脚本里生成 C 代码时，"\n" 会被 Python 转义成换行符，最终会破坏 C 源码的字符串字面量。正确的做法是在 Python 原始字符串或转义后再传给 C 编译器，或者在 CMake 中小心处理 ${...} 变量展开。

另外，在 Native 层返回值或参数里如果包含反斜杠或引号，和描述符没有关系，但容易在日志打印时混淆。建议调试时打印描述符字符串本身，确认实际传给 JNI 的字符序列，逐字符核对有没有多空格、漏分号。

5.4 大小写敏感：V 和 v、B 和 b 是十万八千里

JNI 描述符是大小写敏感的。V 代表 void，而 v 不是任何合法类型；B 是 byte，b 没有定义。写 Java 基本类型描述符时，最稳妥的办法是从 JNI 规范或 javap -s 输出里复制，而不是手打。肉眼扫一遍也许看不出问题，但 JVM 会严格按字节比较，错一个字符就是错。

历史上就出现过有人把 Z（boolean）错写成 B（byte）然后 GetMethodID 正常返回，但调用时参数解析崩掉的情况。因为 JNINativeMethod 注册时不会校验描述符对应的参数个数是否和 Native 函数指针的参数列表一致，只有到实际调用时 JVM 才根据描述符解析参数，并把栈上对应的 JNI 类型传入。参数个数不一致会直接导致 Native 层从错误的偏移处读取参数，崩溃现场往往很惨烈。

5.5 用 javap -s -p 核对描述符，比自己推算更稳妥

既然描述符是从 Java 字节码层面定义的，最权威的核对来源就是字节码本身。一个很实用的办法是编译完 Java 类后用 JDK 自带的 javap 查看签名：

bash复制javap -s -p com/example/jni/MathBridge.class

-s 表示打印内部类型签名也就是描述符，-p 表示显示 private 成员。输出大致长这样：

text复制Compiled from "MathBridge.java"
public class com.example.jni.MathBridge {
  public static native int add(int, int);
    descriptor: (II)I
  public static native java.lang.String getVersion();
    descriptor: ()Ljava/lang/String;
}

有了这种输出，你直接把 descriptor: 后面的内容复制进 C/C++ 代码就行，不用动脑子。实际项目里，只要把 Java 层 native 方法写好、编译完，再跑一次 javap -s -p，就能把描述符从源码里剥离出来，这是最不容易出错的路径。

在 Android Studio 的 Gradle 项目里，编译产物在 app/build/intermediates/javac/debug/classes/ 下（具体路径取决于 AGP 版本），进入对应目录再执行 javap 即可。从我个人经验看，能用工具生成的就别手写，手写描述符的时间加起来，早够写几百行业务代码了。

5.6 排查链路：当 FindClass 和 RegisterNatives 都返回空时，按什么顺序查

我在社区里回答过不少这类问题，总结出一个排查顺序。假设 RegisterNatives 返回了负数或者 FindClass 返回了空指针，按下面顺序逐项排查：

1. 确认类加载器：Java 层类和 Native 层 FindClass 是否处于同一个类加载器上下文。如果 Java 类是通过自定义类加载器加载的，Native 层直接调用 FindClass 可能找不到。动态注册时最好从 Java 层把 Class 对象传给 Native，而不是在 Native 层重新用 FindClass。这一点在 Android 插件化场景尤其突出。
2. 确认类名格式：把代码里 FindClass 的参数复制出来，手动替换包名点号为斜杠，检查有没有拼写错误。
3. 确认方法描述符格式：先判断方法是静态还是实例，然后核对方法名和 javap -s 输出。常见遗漏是把构造方法 "<init>" 的方法描述符写错，或忘记在构造函数描述符末尾写 V。
4. 确认返回值处理：FindClass 返回的是局部引用，注册结束后应当调用 DeleteLocalRef 释放，避免频繁注册时局部引用表溢出。很多 JNI 崩溃并不是描述符问题，而是引用表满了导致 FindClass 或 RegisterNatives 后续操作失败。
5. 检查异常状态：JNI 调用失败时，JVM 通常会抛出异常，比如 NoClassDefFoundError 或 NoSuchMethodError。在 C/C++ 里经常忽略 ExceptionCheck，导致异常遗留。可以在每次 JNI 调用后手动调用 ExceptionDescribe 打印异常信息，这比盯着一串奇怪的返回值更直观。

下面给一个简单的错误检查宏，可以放在开发期调试用，发布前再删掉：

c复制#define JNI_SAFE_CALL(env, call)                                        \
    do {                                                                \
        call;                                                           \
        if ((env)->ExceptionCheck()) {                                  \
            (env)->ExceptionDescribe();                                 \
            (env)->ExceptionClear();                                    \
        }                                                               \
    } while (0)

5.7 从 UnsatisfiedLinkError 到描述符的关联

很多刚接触 JNI 的人遇到 UnsatisfiedLinkError 就开始怀疑是不是 so 库没打包对、System.loadLibrary 路径不对。的确这可能是原因，但另一种可能是描述符写错导致 JVM 找不到对应的 native 方法。如果是动态注册，那么描述符不匹配时 JVM 在调用对应 Java native 方法时会抛出 UnsatisfiedLinkError，因为注册表里找不到匹配项。

我印象很深的一次是朋友项目里的 Java native 方法返回值是 boolean，他写的描述符返回是 Z，看起来没错。但他在 Java 方法声明里用了包装类型 Boolean，真正的字节码签名返回的是 Ljava/lang/Boolean;。由于编译器自动拆装箱是发生在调用方，而不是方法本身的签名里，这个 native 方法的实际方法描述符应该以 Ljava/lang/Boolean; 结尾。这种自动拆装箱引起的签名认知误区，就是为什么不能只看 Java 源码写描述符、必须以 javap -s 输出为准的原因。

6. 描述符进阶用法：JNI 函数查找、缓存和性能优化

6.1 为什么不能每次调用都走 GetMethodID

描述符最大的功能是让 JVM 根据字符串找到对应的 jmethodID 或 jfieldID。但注意，每次调用 GetMethodID 都是一次按字符串匹配的查找过程，开销不能忽略。在性能敏感的方法里，如果每帧都通过 GetMethodID 查找并调用 Java 方法，可能白费不少 CPU 周期。更推荐的做法是在 JNI_OnLoad 或首次使用时把 jmethodID 缓存到全局静态变量里。

缓存方案通常是这样：写一个初始化函数，只执行一次，把所有需要用到的方法 ID 和字段 ID 都查好存起来：

c复制static jmethodID sAddMethod = nullptr;

bool CacheMethodIDs(JNIEnv* env, jclass clazz) {
    sAddMethod = env->GetMethodID(clazz, "add", "(II)I");
    if (sAddMethod == nullptr || env->ExceptionCheck()) {
        env->ExceptionDescribe();
        env->ExceptionClear();
        return false;
    }
    return true;
}

这样后续调用时不再传描述符，而是直接使用缓存的 jmethodID。这里有个细节：缓存的 jclass 要用 NewGlobalRef 转换成全局引用，否则方法 ID 对应的类一旦被卸载，旧 ID 就失效了。单纯把 GetObjectClass 得到的局部引用存到全局变量、不转成全局引用，在函数返回后可能被 JVM 回收，再使用就是悬垂引用。

6.2 描述符里隐含的 JNI 类型与 C 类型的对应关系

描述符最终决定了 JNI 层函数指针或者 Call*Method 系列函数从 JVM 栈上取得什么类型：

如果一个方法的描述符是 (I[JLjava/lang/String;)[B，对应到 Native 函数指针就是：

c复制extern "C" jbyteArray
callSomeThing(JNIEnv* env, jobject thiz, jint count, jlongArray data, jstring name);

可以看到，描述符中参数从左到右的类型顺序，决定了 Native 函数指针中除前两个固定参数外的参数排列。写 RegisterNatives 时，函数指针的类型强制转换很容易掩盖类型不匹配的问题，因为 C/C++ 允许你把一个参数个数不同的函数指针强转成 void*。注册时 JVM 不会知道 Native 函数真正的参数个数，只有到方法被调用时才会从 JVM 栈上按描述符解析出的参数个数去取参数，然后传给那个函数指针。参数写错就是直接访问非法内存的级别。

6.3 描述符在跨线程和异步回调中的应用

JNI 描述符与线程模型没有直接关系，但异步回调中需要从后台线程调用 Java 方法时，还是要用到方法描述符。通常是先创建全局引用保存 Java 对象和 jmethodID，然后在后台线程里调用：

c复制void NativeCallbackOnBackgroundThread(void* data) {
    JNIEnv* env = nullptr;
    jint attachResult = gVm->AttachCurrentThread(&env, nullptr);
    if (attachResult == JNI_OK) {
        env->CallVoidMethod(gGlobalObj, sCallbackMethod, jintValue);
        gVm->DetachCurrentThread();
    }
}

在这个场景里，sCallbackMethod 是通过方法描述符预先获取并缓存的。如果描述符写错了，问题通常不会在注册阶段暴露，而是在异步回调触发时才崩溃，这种崩溃的排查成本更高。所以动态注册或 ID 缓存初始化时，对描述符做一次实际方法调用测试非常值得，别等到异步回调真的来了才发现注册的是错误方法。

6.4 性能敏感场景：用 JNI_OnLoad + RegisterNatives 替代反射式方法查找

JNI 里还有一种“反射式”的调用方式，比如通过 GetMethodID 和 CallXxxMethod 去调用 Java 的某个 private 方法。这种调用的开销核心包含两个部分：一次按描述符查找签名的成本，加上一次调用的成本。相比之下，如果你在 RegisterNatives 阶段就把 Native 实现函数和 Java native 方法绑定好了，Java 层调用 native 方法时是直接定位到 Native 函数的，没有额外的字符串查找开销。

所以凡是高频调用的方法，应该尽量通过 Java native 方法 + 动态注册实现，而不是在 Native 层每次通过描述符去找 Java 方法再反向调用。两者的性能差距可能达到一个数量级以上。这个原则在图像处理、音视频编解码、实时通信这类每帧要回调多次的场景尤其重要。描述符是一切的起点，但它不应是热路径上的常客。

7. 项目实践建议：建立属于你自己的描述符速查表

各种资料里都有 JNI 描述符速查表，但我觉得最有用的表，是你结合自己的项目整理出来的。比如你的项目里常用的 Java 回调方法就那么几个：onSuccess(String data)、onError(int code, String msg)、onProgress(int percent) 等。把它们的完整描述符提前写好，放到头部注释里或一个专门的头文件里，能省去日后反复推算的麻烦。

下面是我自己在项目里维护过的一种“描述符速查头文件”的写法，纯属个人习惯：

c复制// BridgeDescriptors.h
#ifndef BRIDGE_DESCRIPTORS_H
#define BRIDGE_DESCRIPTORS_H

// ---- 常用类名（用于 FindClass） ----
#define CLASS_MAIN_ACTIVITY   "com/example/app/MainActivity"
#define CLASS_BRIDGE          "com/example/app/Bridge"

// ---- 字段描述符 ----
#define FIELD_TAG_DESCRIPTOR  "Ljava/lang/String;"
#define FIELD_COUNT_DESCRIPTOR "I"

// ---- 方法描述符 ----
#define METHOD_ON_SUCCESS_DESCRIPTOR  "(Ljava/lang/String;)V"
#define METHOD_ON_ERROR_DESCRIPTOR    "(ILjava/lang/String;)V"
#define METHOD_ON_PROGRESS_DESCRIPTOR "(I)V"

#endif

这样写上几十个描述符之后，就算以后跳槽到别的项目，遇到 JNI 相关代码也能快速反应出描述符的规律。宏定义往往比自己敲字符串更快更安全。

另外建议所有用 FindClass 获取的类名、方法名、方法描述符都集中管理，而不是散落在多个 .c/.cpp 文件里。散落管理的坏处是你改了一处忘了另一处，排查时很难察觉。JNI native 方法的描述符本质上是 Java 层公开接口的一部分，任何 Java 层方法签名改动都必须同步修改 Native 层这些常量，所以集中维护相当于把契约放在了一个文件里，方便 code review 和未来的自动化校验。

如果哪天你在开发环境里加了一个混淆配置或者把 R8 打开了，发现原本正常的 native 调用突然断裂，请先查描述符对应的混淆映射，而不是怀疑 JNI 环境。反混淆后方法签名可能完全变了，之前保存的描述符字符串也要跟着更新。

最后有个实用小技巧，强烈建议在 JNI_OnLoad 里多加一行日志，把当前注册的方法数量打印出来，并且在每次调用 RegisterNatives 后检查返回值。这个习惯在动态注册方法数量变多后尤其有用，能帮你快速定位是哪个类的注册流程挂了。别问我怎么知道的——在我把一组重载方法描述符写反的那天，正是这行日志救了我一下午的时间。