通过示例去看JNI中为什么使用extern “C“

2023-05-16

经验总结

在JNI开发过程中，我们使用C++去写一个动态库，由于C++编译器对于函数的符号的生成需要进行名字修饰处理，然后生成的函数符号不再跟源代码中定义的函数名一致
这样导致调用方通过函数名去调用我们的函数（用函数名充当函数符号去查找函数地址），将会找不到具体的实现，然后崩溃。
JVM调用我们写的native接口/接口，就是这种情况。
所以当我们使用C++去写navtive的接口时，需要用extern “C” 包住native接口，这样就显示告诉C++编译器，对于我们的接口/函数使用C语言的方式（函数符号即函数名称）去编译代码和生成函数符号。
如下是CPP源码中native接口的实现没有使用extern “C” 声明，运行时出现的崩溃栈

2020-06-30 18:45:22.522 10202-10202/? E/art: No implementation found for java.lang.String com.example.hellolibs.MainActivity.stringFromJNI() (tried Java_com_example_hellolibs_MainActivity_stringFromJNI and Java_com_example_hellolibs_MainActivity_stringFromJNI__)
2020-06-30 18:45:22.523 10202-10202/? E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.example.hellolibs, PID: 10202
    java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String com.example.hellolibs.MainActivity.stringFromJNI() (tried Java_com_example_hellolibs_MainActivity_stringFromJNI and Java_com_example_hellolibs_MainActivity_stringFromJNI__)
        at com.example.hellolibs.MainActivity.stringFromJNI(Native Method)
        at com.example.hellolibs.MainActivity.onCreate(MainActivity.java:31)
        at android.app.Activity.performCreate(Activity.java:6813)
        at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1119)
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2805)
        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2927)
        at android.app.ActivityThread.-wrap12(ActivityThread.java)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1650)
        at android.os.Handler.dispatchMessage(Handler.java:102)
        at android.os.Looper.loop(Looper.java:159)
        at android.app.ActivityThread.main(ActivityThread.java:6364)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1096)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:883)

如上案例，对应的so中的函数符号是

_Z53Java_com_example_hellolibs_MainActivity_stringFromJNIP7_JNIEnvP8_jobject

示例说明

本文使用的示例是google官方的JNI demo中的hello-libs跟hello-jni
另外使用llvm-readelf来查看so中的符号信息

示例分析

hello-jni示例

hello-jni的项目结构结下图所示，关键的hello-jni.c的代码如下
在这里插入图片描述

我们进去看下so中的符号，就是看到定义的native接口的名称跟函数符号是一致的

dw_luogongwu@dw-luogongwudeMacBook-Pro hello-jni$ ff *.so
./app/build/intermediates/cmake/arm8Debug/obj/armeabi-v7a/libhello-jni.so
./app/build/intermediates/cmake/arm8Debug/obj/arm64-v8a/libhello-jni.so
./app/build/intermediates/merged_native_libs/arm8Debug/out/lib/armeabi-v7a/libhello-jni.so
./app/build/intermediates/merged_native_libs/arm8Debug/out/lib/arm64-v8a/libhello-jni.so
./app/build/intermediates/stripped_native_libs/arm8Debug/out/lib/armeabi-v7a/libhello-jni.so
./app/build/intermediates/stripped_native_libs/arm8Debug/out/lib/arm64-v8a/libhello-jni.so

dw_luogongwu@dw-luogongwudeMacBook-Pro out$ llvm-readelf --symbols lib/arm64-v8a/libhello-jni.so | grep FUNC
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __cxa_finalize@LIBC
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __register_atfork@LIBC
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __cxa_atexit@LIBC
    11: 0000000000000608    64 FUNC    GLOBAL DEFAULT   10 Java_com_example_hellojni_HelloJni_stringFromJNI
    40: 00000000000005c0    12 FUNC    LOCAL  DEFAULT   10 __on_dlclose
    41: 00000000000005d0     4 FUNC    LOCAL  DEFAULT   10 __on_dlclose_late
    53: 00000000000005fc    12 FUNC    LOCAL  DEFAULT   10 pthread_atfork
    55: 00000000000005d4    12 FUNC    LOCAL  DEFAULT   10 __atexit_handler_wrapper
    59: 00000000000005e0    28 FUNC    LOCAL  DEFAULT   10 atexit
    60: 00000000000005cc     4 FUNC    LOCAL  DEFAULT   10 __emutls_unregister_key
    63: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __cxa_finalize@@LIBC
    64: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __register_atfork@@LIBC
    71: 0000000000000608    64 FUNC    GLOBAL DEFAULT   10 Java_com_example_hellojni_HelloJni_stringFromJNI
    72: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __cxa_atexit@@LIBC

总结：使用C来写动态库，不需要使用extern

hello-libs示例

hello-libs的项目结构，跟关键的代码如下图所示
在这里插入图片描述
如下图是hello-lib使用与去掉extern后，native接口对应的函数符号的对比

总结: 使用C++来写动态库，需要extern “C” 来声明我们实现的natvie的接口/函数

其它说明

通过函数符号调用函数

这个属于dlopen/dlsum的使用范畴，即运行时加载一个动态库，并通过符号找到函数地址，通过函数针指方式调用函数
具体可以看参考文档中的 C语言调用so动态库的两种方式

有关C++的名字修饰

在C/C++中，一个程序要运行起来，需要经历以下几个阶段：预处理、编译、汇编、链接。
名字修饰（Name Mangling）是一种在编译过程中，将函数、变量的名称重新改编的机制，
简单来说就是编译器为了区分各个函数，将函数通过一定算法，重新修饰为一个全局唯一的名称。

具体可以看篇文章 >> C+±-名字修饰

有关llvm-readelf的配置与使用

我使用的是ndk自带的llvm，我把llvm的bin目录放到了系统环境变量中，方便使用所有用llvm-xxx命令
在.bash_profile配置如下

# for android-ndk env
ANDROID_NDK_LLVM_BIN=${HOME}/Library/Android/sdk/ndk/21.2.6472646/toolchains/llvm/prebuilt/darwin-x86_64/bin
PATH=$PATH:$ANDROID_NDK_LLVM_BIN
export PATH

参考文档

jni中使用extern "C"的原因
C语言调用so动态库的两种方式
C+±-名字修饰
为什么C++支持重载而C语言不支持重载

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)