去年我开始负责iOS崩溃治理的工作,从原来的万分之六崩溃率,一直到现在的万分之一左右的崩溃率,期间踩了很多坑,因此想和大家分享一下,希望能对大家有所帮助,也欢迎大家私信交流。 如果你打算开始治理崩溃的话,建议你先想一下以下的问题: 如何高效地去定位修复崩溃?修复线上收集到的崩溃,可以说这是无法避免的体力活,大部分的崩溃事实上并不复杂,都不难解决,但怎么快速定位是个问题。大部分的
转载 2023-07-26 08:33:40
167阅读
一、Crash类型crash 一般产生自 iOS 的微内核 Mach,然后在 BSD 层转换成 UNIX SIGABRT 信号,以标准 POSIX 信号的形式提供给用户。NSException 是使用者在处理 App 逻辑时,用编程的方法抛出。iOS 端的 crash 分为三类:Mach 异常:EXC_CRASHUNIX 信号:SIGABRT系统崩溃而引起的程序 NSException 异常退出常
崩溃统计分析,在APP中是非常常见一种优化APP,发现APP的BUG的方式。1.异常处理可通过try catch 方式处理,如果发生异常,会走catch ,最终走fianlly。对一些我们不想他崩溃的地方,可以采取这种方式去处理。但要注意的是,通过这种处理,使用的第三方崩溃将捕捉不到异常信息,不会上报。@try { <#Code that can potentially th
转载 2023-06-27 17:30:01
160阅读
  最近写的JKCrashProtect的两篇文章得到了一些小伙伴的响应,一些小伙伴已经开始使用JKCrashProtect这个库了,很是开心。我今天在这里重点给大家分享一下有KVO造成的crash。KVO产生crash的原因  相信大家用过KVO的应该比较多,KVO中的添加观察者,和移除观察者必须要成对出现,这个常识相信大家都是有的,所以某个人如果忘记了使用后移除已经添加的观察者造成了crash
转载 10月前
166阅读
APP崩溃分析※ 背景一、崩溃种类场景信号可捕捉的崩溃信号不可捕捉的崩溃二、崩溃日志1、什么情况下会产生崩溃日志?违反操作系统规则应用中有bug三、解析符号化后崩溃报告1、头部关键信息2、异常信息中的关键字段3、其他常见的异常4、线程回溯四、崩溃信号SIGTERMSIGSEGVSIGINTSIGILLSIGABRTSIGFPESIGBUSSIGTRAPEXC_BAD_ACCESSEXC_ARIT
Exception codes:0x8badf00d错误码:Watchdog超时,意为“ate bad food”。 0xdeadfa11错误码:用户强制退出,意为“dead fall”。 0xbaaaaaad错误码:用户按住Home键和音量键,获取当前内存状态,不代表崩溃。 0xbad22222错误码:VoIP应用(因为太频繁?)被iOS干掉。 0xc00
转载 8月前
0阅读
一、关于崩溃闪退估计是我们最不想看到的,对于用户而言,马上就能产生一种不悦,对于投资方而言,也会产生对技术实力的不信任感,所以,我们就需要对闪退进行处理,这里介绍一个不错的三方:AvoidCrash,写这个的大大也很牛逼,原文参照这里。这个三方可以处理例如插入空值到字典中或数组中引起的崩溃、数组越界引起的崩溃、unrecognized selector sent to instance等等的崩溃
转载 2023-07-16 21:40:37
97阅读
针对iOS客户端的Abort问题,进行根因定位分析,给出系统性解决方案 一、背景崩溃(Crash),即闪退,多指移动设备(如iOS、Android设备)在打开/使用应用程序的过程中,突然出现意外退出/中断的情况。如果App线上版本频繁发生崩溃,会极大地影响用户体验,甚至导致用户流失,以及收益减少。因此,崩溃问题是客户端稳定性团队需要重点解决的问题。然而,
我们团队做了个小的科研型项目,用来保护iOS开发工程中的疏忽引起崩溃的情况。 使用简单,import头文件,在appdelegate中加一句代码即可。 目前只是基本常见情况的处理。希望可以帮助到大家,也希望高手们吐槽指正提出意见。 解决方案放在git上开源了: https://github.com/vipshop/VDM/tree/master 防止崩溃:  1、UIControl依赖的
转载 11月前
163阅读
  Xcode支持崩溃日志自动符号化,前提是本地有当时Build/Archive生成的dSYM文件,iOS崩溃日志符号化后,可以帮助开发者更好的定位问题,但如果dSYM文件丢失或拿到的崩溃日志不是标准的crash log,如何定位crash呢,笔者结过尝试发现一样可以定位到具体函数。本文基于此完成解析目标。我们以测试程序CrashTest的崩溃为例,介绍一下具体解析步骤如图, &nbsp
IOS SDK中提供了一个现成的函数 NSSetUncaughtExceptionHandler 用来做异常处理,如果是在调试的过程中,异常的信息是一目了然,但是如果是在已经发布的程序中,获取异常的信息有时候是比较困难的, iOS提供了异常发生的处理API,我们在程序启动的时候可以添加这样的Handler,这样的程序发生异常的时候就可以对这一部分的信息进行必要的处理,适时的反馈给开发者。
转载 2023-07-26 16:40:44
106阅读
获取崩溃信息 在iOS中获取崩溃信息的方式有很多,比较常见的是使用友盟、百度等第三方分析工具,或者自己收集崩溃信息并上传公司服务器。下面列举一些我们常用的崩溃分析方式: 使用友盟、百度等第三方崩溃统计工具。 自己实现应用内崩溃收集,并上传服务器。 Xcode-Devices中直接查看某个设备的崩溃信息。 使用苹果提供的Crash崩溃收集服务。 收集崩溃信息 苹果给我们提供了异常处理的类,NS
转载 2023-08-03 15:43:40
87阅读
  一、什么情况下会产生崩溃日志?   两种主要情况会产生崩溃日志:   1.应用违反操作系统规则。 2.应用中有Bug。   违反iOS规则包括在启动、恢复、挂起、退出时watchdog超时、用户强制退出和低内存终止。  
应用异常崩溃是很正常的事情,但是应用异常崩溃信息对开发者非常重要。下面就介绍如何在iOS应用中捕获异常崩溃信息: 1. 程序启动中添加异常捕获监听函数,用来获取异常信息   NSSetUncaughtExceptionHandler (&UncaughtExceptionHandler);   官方文档介绍:Sets the top-level error-handli
项目(ARC)开发过程中,难免遇到内存泄漏和崩溃,特在这整理一下。(如果本文中有讲述不对或者不准确的地方欢迎大家提出来)一、内存泄漏1、EXC_BAD_ACCESS / KERN_INVALID_ADDRESS公司的项目接入了三方崩溃报告,最近出现了EXC_BAD_ACCESS / KERN_INVALID_ADDRESS这样的错误,崩溃报告堆栈信息一大堆,看的头晕。 How to fix it?
一、崩溃的类型APP的崩溃可以分为两类:信号可捕捉崩溃 和 信号不可捕捉崩溃。信号可捕捉的崩溃数组越界:取数据时候索引越界,APP发生崩溃。给数组添加nil会崩溃。多线程问题:多个线程进行数据的存取,可能会崩溃。例如有一个线程在置空数据的同时另一个线程在读取数据。野指针问题:指针指向一个已删除的对象访问内存区域时,会出现野指针崩溃。野指针问题是导致 App 崩溃的最常见,也是最难定位的一种情况。N
转载 2023-08-17 17:36:22
365阅读
iOS崩溃日志处理-- Crashlytics前言:在iOS开发的过程中和测试阶段会处理掉一些比较常的错误、和崩溃的信息。但是当我们的APP上线之后,如果发生了崩溃的事件。对于此事件的处理方式:1.可以通过appStore提供的信息,能查看我们的app是否有出错过崩溃,但是不能知道在哪里崩溃了。处理起来会很难复现2.使用第三方的崩溃日志处理,比如:友盟, Crashlytics。在这里主要讲一下C
转载 2023-07-20 16:20:44
80阅读
EXC_BAD_ACCESS 在访问一个已经释放的对象或向它发送消息时,EXC_BAD_ACCESS就会出现。造成EXC_BAD_ACCESS最常见的原因是,在初始化方法中初始化变量时用错了所有权修饰符,这会导致对象被释放。举个例子,在 viewDidLoad 方法中 UITableViewController 创建了一个包含元素的 NSMutableArray,却将该数组的所有权修
   用汇编语言编写的软件跟用脚本或标记语言编写的Web应用的差别在于,前者在出现问题时会崩溃,由于Web应用运行在浏览器环境中,所以Web应用很少会对内存的使用造成破坏或是导致浏览器崩溃。如果你以前使用的是高级开发语言,那么可能不太了解Xcode用来表示各种崩溃类型的术语。崩溃通畅是指操作系统向正在运行的程序发送的信号。1.EXC_BAD_ACCESS  
转载 2023-09-01 13:11:01
58阅读
# iOS 崩溃捕获与防崩溃策略 在开发 iOS 应用时,崩溃是不可避免的问题。崩溃不仅影响用户体验,还可能导致用户流失。因此,学会捕获和处理崩溃是每位开发者必须掌握的技能。本文将介绍如何在 iOS 中实现崩溃捕获,并提供一些防止崩溃的策略与代码示例。 ## 1. 崩溃捕获的必要性 崩溃如何影响应用?在众多统计中,数据显示,超过 70% 的用户在一次崩溃后不会再下载或使用该应用。因此,捕获崩
原创 13天前
39阅读
  • 1
  • 2
  • 3
  • 4
  • 5