| Unity3D特效百例 | 案例项目实战源码 | Android-Unity实战问题汇总 |
|---|---|---|
| 游戏脚本-辅助自动化 | Android控件全解手册 | 再战Android系列 |
| Scratch编程案例 | 软考全系列 | Unity3D学习专栏 |
| 蓝桥系列 | ChatGPT和AIGC |
👉关于作者
专注于Android/Unity和各种游戏开发技巧，以及各种资源分享（网站、工具、素材、源码、游戏等）
有什么需要欢迎底部卡片私我，交流让学习不再孤单。
👉实践过程
😜问题
我们做 JNI 开发的时候，一旦触发 BUG 可能直接造成崩溃，当 Linux 应用程序在执行时如果发生严重错误，一般会导致程序 crash。Linux 专门提供了一类 crash 信号，在程序接收到此类信号时，缺省操作是将 crash 的现场信息及时记录到 core 文件，接着进行终止进程的操作。
而且崩溃不能在 Android Studio 的 Logcat 中直接查看出来。这就给定位问题产生了很大的阻碍。但这并不是无法定位。
😜解决
tombstones介绍
当 JNI 运行时候，系统就会注册一些信息连接到 debuggerd 的 signal handlers，这时候如果系统触发了 crash ，就会在/data/tombstones下生成一个 tombstone ，她就像墓碑一样记录了死亡了的进程的基本信息（例如进程的进程号，线程号），死亡的地址（在哪个地址上发生了 Crash），死亡时的现场是什么样的（记录了一系列的堆栈调用信息）等等。
console:/ # cat /data/tombstones/tombstone_00
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Allwinner/petrel_p1/petrel-p1:9/PPR1.181005.003/20210826-112106:eng/test-keys'
Revision: '0'
ABI: 'arm'
pid: 1893, tid: 2906, name: bonjour >>> /system/bin/ndktest <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xacc03064
r0 000003ff r1 acc0311c r2 00000004 r3 f3cec54f
r4 acbcb640 r5 000000b8 r6 000007c0 r7 ef57f3f8
r8 acbcc8b4 r9 acbd53fc r10 00000400 r11 acbc83d8
ip f3d32638 sp ef57f3b0 lr acb47c5f pc acb47c6a
backtrace:
#00 pc 000a8c6a /system/bin/ndktest
#01 pc 000532e5 /system/bin/ndktest
#02 pc 00063a25 /system/lib/libc.so (__pthread_start(void*)+22)
#03 pc 0001df95 /system/lib/libc.so (__start_thread+22)
stack:
ef57f370 00000000
ef57f374 00000000
ef57f378 00000000
ef57f37c 00010000
ef57f380 612709a0
大概就像上面那样。里面记录了产生问题的进程id（如上面的pid），也记录了崩溃的原因（如上面的signal 11…），同样也记录了更重要的信息——崩溃的地址（上面的backtrace）。
可即使到这了，我们还是无法直接看出错误在哪一行啊。
不要急，上面只是告诉我们日志在什么地方，通常我们是不会手动去查看日志的。我们借住工具可以直接输出出来错误行。
利用addr2line
addr2line 是 NDK 中的工具，我们需要他捕捉错误信息，然后进行地址转换，就能看见我们出错误的代码行数。
该工具在你的 sdk 文件夹下，如下面是我的 sdk 安装地址以及 NDK 版本号：
H:\studio\sdk\ndk\21.4.7075529\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\bin
这时候需要命令行工具，有三种形式：
- 直接在这个路径下，shift+右键 打开 Powershell
- 利用传统的 cmd 工具。
- 如果在安装 Adnroid Studio的时候配置好了环境变量，也可以在Studio的Terminal中进行操作。
我是利用的方式一。
我们继续操作：
-
用数据线将 Studio 和 设备进行连接，然后触发崩溃
-
在 Logcat 中查看错误信息。记住这些内存地址
-
找到你的项目这个 SO 文件的完整路径。集成这个 SO 的项目 或者 你用来编写 SO 的项目都可以。我是使用编写 SO 的项目详细地址
-
在命名行中敲如下代码：
红线表示 addr2line 工具的完整路径，绿线表示 so 的路径，黄线表示第二步中你记路的地址，空格可以输入多个。
其中-C -f ：表示打印错误行数所在的函数名称，-e：表示打印错误地址的对应路径及行数
然后回车。就能看到具体的错误行数了。
然后再具体问题具体分析。
😜注意
这里 在用add2line工具时，不要用.\libs\armeabi-v7a\ndktest，而是要用.\obj\local\armeabi-v7a\下的ndktest，因为libs下的文件已经去掉了调试信息，你可以对比下，libs下的ndktest比obj下的要小的多。
除此之外，如果嫌麻烦，我们还可以封装一个 Bat 工具。
@echo off
rem current direction
set cur_dir=%cd%
rem addr2line tool path
set add2line_path=E:\android-ndk-r16b-windows-x86_64\android-ndk-r16b\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\bin\aarch64-linux-android-addr2line.exe
rem debug file
set /p debug_file=请输入当前目录下debug文件名：
rem debug_file_path
set debug_file_path=%cur_dir%\%debug_file%
rem debug address
set /p debug_addr=请输入异常时PC寄存器值：
echo ----------------------- addr2line ------------------------
echo debug文件路径: %debug_file_path% PC=%debug_addr%
if exist %debug_file_path% (
%add2line_path% -e %debug_file_path% -f %debug_addr%
) else (
echo debug file is no exist.
)
echo ---------------------------------------------------------
pause
上面代码的set add2line_path=后面跟的就是那个addr2line工具路径。
然后将这个 bat 文件和 so 文件放置相同的文件夹下。触发下崩溃。
双击此脚本，然后输入库名和寄存器地址，然后就可以查到出错的行号了。
上面演示的是最最最幸运的效果，但实际中，第三方的so库一般都是不提供源码，又或者已加密了，所以此时得出的是行号为??:?或??:0
如果遇到 addr2line 得到??:?或??:0的情况，原因就是编译得到的so文件没有附加上符号表(symbolic)信息。
- 如果是同事或者自己开发的直接使用 debug 模式
- 如果是大厂出的SO，一般不会出现问题
- 如果是合作方的，就需要和他们联合开发调试了。这个方式是最麻烦的
👉其他
📢作者：小空和小芝中的小空
📢转载说明-务必注明来源：https://zhima.blog.csdn.net/
📢这位道友请留步☁️，我观你气度不凡，谈吐间隐隐有王者霸气💚，日后定有一番大作为📝！！！旁边有点赞👍收藏🌟今日传你，点了吧，未来你成功☀️，我分文不取，若不成功⚡️，也好回来找我。文章来源：https://www.toymoban.com/news/detail-745003.html
温馨提示：点击下方卡片获取更多意想不到的资源。
文章来源地址https://www.toymoban.com/news/detail-745003.html
到了这里，关于Android问题笔记四十三：JNI 开发如何快速定位崩溃问题的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
