1. 找到编译时生成的*.app和生成的*.app.dSYM文件(需要备份好)方法在:http://blog.csdn.net/cococoolwhj/article/details/7459064 。
2. 找到崩溃日志 *.crash文件
如果你不确定*.app *.app.dSYM和*.crash是不是同一个App的 那就需要对比这三个文件的UUID。方法在http://hi.baidu.com/squirrelfly/item/b2ed784abe83a9086dc2f08c
3. 如果UUID相同你就可以进行下面的工作了
4. 先用symbolicatecrash命令或者xcode自带日志分析器 得到Crash 的内存地址,symbolicatecrash使用方法:symbolicatecrash *.crash *.app.dSYM
5. 然后用dwarfdump 命令如果运气好就能找出对于内存地址在代码中的位置,否则就悲惨了。(这个需要在命令行操作)
6. 最后就是找代码查看bug
PS:如果出现找不到symbolicatecrash 命令,请使用以下命令后就可以正常使用:
export DEVELOPER_DIR="/Applications/XCode.app/Contents/Developer"
这个blog只是理清楚分析Crash思路,具体怎么做google上面很多。
推荐一下几个网址:http://wangfei0206wl.blog.163.com/blog/static/2685049520122280755746/
希望对大家有用,需要工具或者需要讨论的请联系@Anselz0
使用起来很简单。分三步即可。
1> 根据crash log,得到App的UUID。UUID是个字符串,由32个字符组成。得到了UUID,你才能知道是你的哪个版本在用户的iPhone上出了问题。
2> 使用dwarfdump检查app,看哪个app是上面那个UUID。命令行格式:
dwarfdump --uuid YourApp.app/YourApp
3> 用dwarfdump检查dSYM文件是否是上面的UUID。命令行格式:
dwarfdump --uuid YourApp.app.dSYM
如果三者的UUID都是一致的,那么恭喜你,该crash log可以被正确解析出来,stack traces信息可以被正确地拿到。
-
程序崩溃: 可能是最常见的,经常发生于内存访问出错,异常,或者其他的程序错误
-
内存不足: 系统因为没有足够的内存满足程序需求从而杀死程序出现这种日志.它不同于其他日志的是它没有程序各线程的堆栈信息. Rather than be concerned about what part of your co
de was executing at the time of termination, you should investigate your memory usage patterns and your responses to low memory warnings. Memory usage of each process is reported in terms of number of memory pages, which as of this writing are 4KB each. -
强制退出:异常代码
0xdeadfa11. 这出现在用户在程序界面按下关机键知道出现"移动滑块关机",然后长按Home键.用户之所以这么做,很可能因为你的程序无响应,当然也不一定. -
响应超时: 异常代码
0x8badf00d -
ios应用crash的四种类型
3、如何分析
4、crash log分析原理
5、使用其他方法分析crash
当然正常情况下crash问题,我们可以在xcode下调试分析,这种最为直接,但如果终端的ios版本过高,我们的xcode不支持,就只能升级系统+xcode+SDK方式来进行调试分析。