如何通过设置 Instrumentation 的 nativeMethodPrefix 来进行本地方法 AOP 阻截？

本文共计870个文字，预计阅读时间需要4分钟。

不能。这是最常被误解的一点：

你如果在 Java Agent 中设置了 instrumentation.setNativeMethodPrefix(transformer, "prefix_")，却期待 prefix_JNI_OnLoad 被自动调用或原生函数被代理——那不会发生。JVM 只会在加载 native 库时，尝试按带前缀的符号名去查找函数（比如把 Java_com_example_Foo_bar 改查 prefix_Java_com_example_Foo_bar），仅此而已。

为什么 setNativeMethodPrefix 会被误认为能做 AOP？

因为文档模糊 + 示例缺失 + 与 JVMTI 的 SetNativeMethodPrefix 同名，导致开发者以为它和 Java Agent 的字节码增强能力打通了。实际上：

• Instrumentation.setNativeMethodPrefix() 仅影响后续通过 System.loadLibrary() 加载的 native 库的符号解析过程
• 它不修改任何 Java 方法的调用链，不触发 ClassFileTransformer，也不生成代理 stub
• 它对已加载的 native 库无效（比如 java.lang.Object 的 registerNatives）
• Android 上该方法直接抛 UnsupportedOperationException

真正可行的 native 方法 AOP 替代方案有哪些？

想对 native 方法做类似 AOP 的行为（如打日志、测耗时、改参数），目前只有以下几种实际可用路径：

• JVMTI + Native Agent：用 C/C++ 编写 JVMTI agent，在 JVMTI_EVENT_NATIVE_METHOD_BIND 或 JVMTI_EVENT_VM_INIT 中 hook 符号表，替换函数指针（例如把 Java_com_foo_Bar_baz 指向你自己的 wrapper）。这是最底层也最可靠的方式，但需跨语言开发、处理 ABI 兼容性、且无法热更新
• LD_PRELOAD（Linux） / DYLD_INSERT_LIBRARIES（macOS）：劫持 libc 或目标 so 的依赖，覆盖 dlsym、__libc_start_main 等关键入口，间接控制 native 函数分发。适合系统级监控，但侵入性强、易崩溃
• 在 Java 层封装 native 调用：把所有 native 声明包进一个抽象层（如 NativeBridge.call("foo", args)），再对这个 Java 方法做字节码增强。这是唯一纯 Java Agent 可控的方式，但要求你有源码或能重打包 APK/JAR
• 使用 ART/Hook 框架（Android 专用）：如 SandHook、Legend，它们在运行时 patch ART 的 ArtMethod::EntryPointFromJni，实现 native 方法的 inline hook。不依赖 nativeMethodPrefix，但只适用于 Android 并受限于 SELinux 和 targetSdkVersion

setNativeMethodPrefix 的唯一合法使用场景

它只在一种情况下有用：你想让 JVM 在加载 native 库时，**忽略默认 JNI 符号命名规则，转而查找带指定前缀的函数**。典型用途是避免符号冲突或做 native 层的简单路由隔离：

// Java static { System.loadLibrary("mylib"); } public static native void doWork();

对应 C 端本应实现 Java_com_example_MyClass_doWork，但你设了前缀：

instrumentation.setNativeMethodPrefix(transformer, "test_");

那么 JVM 会去查找 test_Java_com_example_MyClass_doWork —— 你必须在 so 里导出这个带前缀的符号，否则报 UnsatisfiedLinkError: No implementation found。这跟 AOP 完全无关，只是个符号映射开关。

真正难的从来不是加个前缀，而是如何在不修改 native 代码的前提下，把调用链引到你的逻辑里。这点 nativeMethodPrefix 连门都没摸到。