赞
踩
目前我所接触的android产品或项目,都是采用Java/JNI/C++的形式组织的。引擎或者数据处理的逻辑会通过C/C++处理,然后通过JNI封装,提供给Android UI(Java)调用。很多crash会发生在ndk这一层,crash后,logcat会疯狂的输出一堆信息,看着让人头疼,其实细看,还是能看出不少猫腻的。
下面我就结合自身情况,简单介绍下如何给crash增加更多有用的输出信息或在crash之后我们该如何定位!
工作环境:
JDK 版本: 1.6(64bit)
ANDROID SDK 版本: 4.2.2(64bit)
NDK 版本: r9(64bit)
l crash模块、线程定位:
现在的软件,大多都是众多模块的封装、拼接,非一人之力能够完成。模块越多、越复杂,出现问题的可能性就越大。可能单个模块运行都ok,整个产品release、run,crash了,这很正常,相信很多朋友都遇到过。
仔细观察logcat crash日志,会发现,一旦crash,会输出crash的pid、tid、以及thread name,其实这个thread name可以帮助非常明确的定位模块,后面是谁的问题就该谁去处理了。
Linux下设置线程名称从kernel 2.6.9就开始支持了,prctl(…),自行google去怎么用。
Eg:
l crash code定位:
方式一:
arm-linux-androideabi-addr2line.exe C -f -e libxxx.so 0x#####
说明:
1. arm-linux-androideabi-addr2line.exe位置: ndk安装路径下toolchains目录下
2. 执行该命令的当前目录位置: 以libhello.so为例,当前执行命令的目录必须在jni/../obj/local/armeabi目录下,在jni/../libs/目录下好像不行。
3. 0x#####的选取: crash log中,backtrace下面的第一个pc的值。
Eg:
说明crash的代码位于hello.c第32行。
方式二:
parse_stack.py asm_code crash_log
说明:
1. parse_stack.py(https://code.google.com/p/android-ndk-stacktrace-analyzer/),google 提供的一个python脚本.
2. asm_code 生成方式: arm-linux-androideabi-objdump.exe–S libxxx.so > xxx.asm
3. crash_log的获取途径: 直接把logcat里面爆的crash保存起来即可。
Eg:
如果有更好的办法欢迎提出来,让crash不在那么畏惧。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。