189 8069 5689
本篇文章为大家展示了Android中怎么利用JNI和Crash实现定位，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。
成都创新互联专业为企业提供玛多网站建设、玛多做网站、玛多网站设计、玛多网站制作等企业网站建设、网页设计与制作、玛多企业网站模板建站服务，10年玛多做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
1. 巧妇内为无米之炊，找到未strip的, 符号表完整的so库文件
在Android Studio 3.2.1:
strip之前的文件所在目录:
app/build/intermediaters/transforms/mergejniLibs/debug
或者根据Crash的APP是debug还是release版本选择
app/build/intermediates/cmake/debug/obj或app/build/intermediates/cmake/release/obj
如果依赖的是Native module或者aar, 那么
strip之前的文件所在目录:
yourNativeLibModule/build/intermediates/transforms/mergeJniLibs/debug
由于CMake/CXX_FLAGS的配置等原因，以上目录下的文件可能还是被strip了。如何准确判断so有没有被strip请参照文章下面提到的readelf工具。
如果发现so被strip，尝试在CMake添加如下配置：
# 这几行代码表示debug版本的so文件保留so保留符号库，这样会导致so文件很大，# 如果要让release版本保留符号库文件，就替换成CMAKE_C_FLAGS_RELEASE和CMAKE_CXX_FLAGS_RELEASE# 但务必在正式对外发布的时候去掉release 配置的-g选项，以免增加文件sizeset(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -g")set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g")# R16之前版本的NDK默认是编译时加-g的，新版本不确定，所以需要不strip的 so文件，最好在CMake里配置一下-g strip之后的文件所在目录:
app/build/intermediaters/transforms/stripDebugSymbol/debug
2. 打蛇要打七寸，确定发生Crash的设备对应的CPU架构
在JNI Crash的日志里
如果有lib/arm, 则是armeabi-v7a架构;
如果有lib/arm64, 则是arm64-v8a架构
然后根据CPU架构找相应的toolchain：
arm64-v8a对应的是aarch74-linux-android-4.9
armeabi-v7a对应的是arm-linux-androideabi-4.9
4. 工欲善其事必先利其器，使用add2line 和ndk-stack等工具分析JNI Crash的log
addr2line
作用是根据内存地址找到对应的报错代码的文件名和行号
所在目录是toolchain的bin文件夹,
比如 aarch74-linux-android-4.9对应的bin文件夹是
/Android/Sdk/ndk-bundle/toolchains/aarch74-linux-android-4.9/prebuilt/linux-x86_64/bin
arm-linux-androideabi-4.9,对应的bin文件夹是
/media/kyle/a393d005-ebe5-42a0-8c6a-c86fdfb185c1/Android/Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin
用法:
# -f表示显示函数名, -e表示execution，后面是包含符号库的文件 以及报错的内存地址（即Crash log里pc后的字段）arm-linux-androideabi-addr2line -f -e xxx.so 0x8eb09258
ndk-stack
作用是一键生成更可读的Crash 日志
所在目录是
/media/kyle/a393d005-ebe5-42a0-8c6a-c86fdfb185c1/Android/Sdk/ndk-bundle/ndk-stack
用法:
# -sym表示symbolsndk-stack -sym App/build/intermediates/transforms/mergeJniLibs/release/0/lib/对应的abi目录 -dump jniCrash.log
或者
adb logcat | ndk-stack -sym App/build/intermediates/transforms/mergeJniLibs/release/0/lib/对应的abi目录
------------------------分隔符------------------------
其他工具补充
toolchain下的:
arm-linux-androideabi-readelf
1. 有时候用addr2line发现能显示函数名但行号是乱码？？，有可能是因为这个so被strip了。被strip的so的
readelf结果里“section headers”的个数会比未strip后的少，所以可以根据readelf来判断so是否是真的被strip了
命令格式：
arm-linux-androideabi-readelf -S xx.so
2. 可以用于查看so文件中的所有函数。所以如果遇到JNI方法找不到的错误，就可以使用该工具查看so库中的所有函数，然后搜索对应的JNI方法，看到底有没有被编译到动态库中。
命令格式：
arm-linux-androideabi-readelf -a xx.so > fun.txt # 注意：仍需要使用未strip之前的so文件， 上面的命令会把结果写入fun.txt
arm-linux-androideabi-objdump
可以获取so文件的符号表信息，可以看到编译进来的所有方法以及调用堆栈的地址.
命令格式：
arm-linux-androideabi-objdump -dx xx.so > stacktrace.txt 或aarch74-linux-android-objdump -dx xx.so > stacktrace.txt
arm-linux-androideabi-nm
可以查看静态库中的符号，比如查看所有方法的声明。
如果在用静态库编译so动态库的过程中碰到undefined reference类型的错误， 或者
duplicated reference， 可以使用这条指令将对应静态库的所有方法都导出来， 然后看一下是否有某方法
命令格式：
arm-linux-androideabi-nm xx.a > symbol.txt
常用信号量的含义：
#define SIGABRT 6 // abort() 调用abort函数生成的信号，表示程序运行异常被中止#define SIGSEGV 11 // segmentation violation 指针所对应的地址是无效或非法地址，比如访问越界/stack overflow/文件操作不被允许( fault addr 0x0一般是空指针错误)#define SIGILL 4 // Illegal instruction 执行了非法指令，比如第三方库的兼容性问题，权限问题#define SIGSYS 31 // bad argument to system call 非法的系统调用#define SIGBUS 7 // 非法地址，包括内存地址对齐出错，比如访问一个4字节的整数, 但其地址不是4的倍数#define SIGFPE 8 // 进程执行了一个错误的算术操作，比如除0、溢出#define SIGKILL 9 // 强制结束程序，本信号不能被捕获#define SIGPIPE 13 // write on a pipe with no one to read it 管道破裂，通常在进程间通信产生
上述内容就是Android中怎么利用JNI和Crash实现定位，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注创新互联行业资讯频道。