其实,对于做移动 APP 开发的同学来说,质量和体验都是同等重要的.一个 APP 应用如果经常「闪退」,是产品质量很差的一个体现,那么用户体验就更不用再提了. *** 上面是笔者截取的国外一家公司对用户行为分析漫画的一个片段,从图中可以看到,有 80%的用户会因为网络错误和崩溃抛弃这个 APP,有 86% 的用户,如果体验太差,绝对不会第二次使用该 APP.所以开发一个优秀的 APP,性能即生死,一定尽量杜绝「闪退」. 诚然,iOS 上的 APP 闪退有各种各样的原因,像三方库不兼容.响应超时.

做iOS开发的时候,常常会遇到crash,需要分析call stack的时候.有时候App在别人的设备崩溃,把crash report在自己的机器上打开,Xcode没有自动的进行符号化.这时候就需要自己去把地址解析成符号.大前提是,必须有相同版本App对应的.dSYM文件.这时候打开Terminal,进入到build/Debug-iphoneos使用命令:$atos -arch arm7 -o XXX.app/XXX 0xabcdefXXX是你的App名字,用需要解析的地址替换上面的0xabcd

转自:http://weibo.com/p/230418702c2db50102vc2h Android 虽然已经有好几年了,但是NDK的开放速度却非常缓慢,所以目前网络上针对对Android NativeCrash的分析说明还比较少,尤其是非常详细的分析方式更难以查询.因此大部分程序员在遇到难以进行addr2line的crashlog时,会一筹莫展.事实上这份log中的其他部分同样提供了非常丰富的信息可供解读,所以在这里总结一下对在这方面的一些经验,在这里以Androidsamples中的he

概述: 为什么 crash log 内 Exception Backtrace 部分的地址(stack address)不能从 dsym 文件中查出对应的代码? 因为 ASLR(Address space layout randomization),因为 ASLR 引入了一个 slide (偏移) . symbol address = stack address - slide; slide 可以在运行时 由 API 获取到 dyld_get_image_vmaddr_slide() 也可以根据

今天突然发现了一个解析iOS crash log的好方法,忍不住来分享一下. 相信每个做iOS开发的TX都应该不会对symbolicatecrash陌生,我们第一次遇到真机上产生的崩溃日志时,在网上搜到的大部分教程都告诉我们说要用symbolicatecrash来解析crash log,我信了,所以相当长一段时间内,我都是用这个工具来解析crash log的. 每次都去敲命令来解析crash log本身就是一件很蛋疼的事情,但这还不是麻烦的,最麻烦的是用symbolicatecrash还经常遇到

一.问题简述: Xcode, window>Devices>DEVICES选中自已的设备,打开控制台:提示日志存量已达限制,这个是系统抛出的log."Not saving crash log because we have reached the limit for logs to store on disk. Sync or otherwise clear logs from /var/mobile/Library/Logs/CrashReporter to save new lo

1.IOS策略 1.1 低内存闪退 前面提到大多数crash日志都包含着执行线程的栈调用信息,但是低内存闪退日志除外,这里就先看看低内存闪退日志是什么样的.我们使用Xcode 5和iOS 7的设备模拟一次低内存闪退,然后通过Organizer查看产生的crash日志,可以发现Process和Type都为Unknown: 1.2 Watchdog超时Apple的iOS Developer Library网站上,QA1693文档中描述了Watchdog机制,包括生效场景和表现.如果我们的应用程序对一

前言:crash log 对 定位崩溃问题 ,并且不容易复现,尤其是及时对appstore 上正在运营的 app 的迭代改进来说 非常重要. 1 crash两种情况 1.1 测试环境下 追踪bug 1.2 App Store  上应用 追踪bug 我们主要讨论在App Store  上应用 追踪bug 的情况 2获取crash log信息途径 2.1自己收集,做错误分析 错误趋势: 收集崩溃信息 存储 上传服务器 (时机可以是再一次打开应用时候同步)  方法: // 将系统提供的获取崩溃信息函数

mogilefsd[15624]: crash log: Modification of a read-only value attempted at /usr/local/share/perl5/Sys/Syscall.pm line 227./usr/local/share/perl5/Sys/Syscall.pm 0.25版本的bug降级cpanm http://search.cpan.org/CPAN/authors/id/B/BR/BRADFITZ/Sys-Syscall-0.23.t

1.前言 本文主要介绍在XCode5环境下,如何根据App自己生成的crashlog来调试真机上运行时产生的crash问题. 2. 步骤 (1)构造一段会crash的代码,并放到viewDidLoad里面,如下图所示: 以上代码会在objectAtIndex处因为数组越界而crash (2)在程序中捕获crash,生成crashlog,并保存到程序自己的沙盒中,如果需要分析线上bug,也可以将log文件上传到自己的服务器中. 捕获crash很简单,主要是以下步骤: 在didFinishLaunc

iOS开发中,经常遇到App在开发及测试时不会有问题,但是装在别人的设备中会出现各种不定时的莫名的 crash,因为iOS设备会保存应用的大部分的 crash Log,所以可以通过 crash Log 来定位 crash 原因. 一. 获取iOS设备上的 crash log 1. 将iOS设备连接到电脑上,打开 Xcode -> Organizer -> Devices,找到该台设备,在 Device logs 中找到 crash log(后缀为 .crash 的 log 文件),将其导出即可

Android开发中,在Java层可以方便的捕获crashlog,但对于 Native 层的 crashlog 通常无法直接获取,只能通过系统的logcat来分析crash日志. 做过 Linux 和 Win32 开发的都知道,在pc上程序crash时可以生成 core dump 文件通过相关的工具分析函数调用堆栈及崩溃时的内存信息. 那么作为软件开发者有没有方法自己获取native层的crashlog呢?Android 系统是 Linux 内核,既然在Linux中crash时可以生成dump文

众所周知,在android系统上,有时候我们遇到so文件的crash仅仅能打log,可是非常多时候并不知道crash在什么地方,幸运的是crash后,一般能够产生一个.dmp文件. 我们能够依据这个文件来得到更为具体的statck trace. 主要用的就是google提供的一些方法,命令太复杂,非常easy出错,所以我写了一个python脚本,简化步骤. 详情能够參考 https://code.google.com/p/google-breakpad/wiki/LinuxStarterGuid

方法一: 1.xcode 有自带的symbolicatecrash,可以将.crash文件中的16进制地址转换成可读的函数地址. symbolicatecrash位于: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecras

1. iTunes同步获取 大部分用户会使用iTunes软件来管理iPhone,这样同步的Crash日志就会同步到电脑上,我们需要在特定的路径里面查找 Mac OS X:~/Library/Logs/CrashReporter/MobileDevice 2. 使用第三方软件 : itools等 使用itools第三方软件对iPhone设备管理,打开高级功能 --崩溃日志,然后将需要的日志导出到电脑里

一.BinderProxy@4479b390 is not valid; is your activity running? 原因分析: 因为使用了AsyncTask 异步线程在线程完成以后的onPostExecute方法里面操作UI.这个时候如果用户在onPostExecute调用之间跳转了页面,这时activity已经onDestory了,那么就会报出android.view.WindowManager$BadTokenException: Unable to add window -- t

注意:crash_log一定要和打包时的archive对应上: 方法1)在Orgnizer里找到某一个archive,即:/Users/handywang/Library/Developer/Xcode/Archives/2012-04-20/sohunews\ 4-20-12\ 3.07\ PM.xcarchive 找到/Users/handywang/Library/Developer/Xcode/Archives/2012-04-20/sohunews\ 4-20-12\ 3.07\ PM

iOS模拟器发生了崩溃,可以在如下地方找到崩溃日志: ~/Library/Logs/DiagnosticReports/

在近两个月的开发中,遇到了挺多问题的,几天加班加点,最后还是在年前发布并更新了一个版本,欢迎下载无觅下载. 最头疼的问题是提交app审核,之前的工程不太规范,导致一些文件icon没有设置好,直接validate就失败了几次.validate通过后 便upload,但upload过程中又出错了,原因是java版本不对(xcode使用java类库进行上传),解决方法在见stackoverflow上的回答. 一切搞定后,还得对付国内的龟速网络,一个15M不到的ipa竟然上传了快半个小时,算下来速度连1

一.使用流程 Windows下的程序运行崩溃时,往往可以利用pdb文件快速解析出程序崩溃的具体位置,甚至可以对应到源代码的具体行数.macOS下的symbolicatecrash也具备相应的功能.对应于Windows下的pdb文件,macOS下的crash文件解析需要用到dSYM文件.这个文件正常情况下可能不会生成,需要在XCode进行设置.当程序崩溃时,通过symbolicatecrash对crash文件和dSYM文件中的符号进行映射,即可将crash文件中的内存地址转换为可读的字符串.以前的