快速定位iOS线上BUG在哪个控制器崩溃

快速定位iOS线上BUG在哪个控制器崩溃

快速定位iOS线上App崩溃在哪个控制器里面,需要和后台配合使用

  1. 下载本项目并添加手动添加到项目里

  2. 新建所有的页面都继承于YZViewController
  3. 在AppDelegate的didFinishLaunchingWithOptions方法里面写下如下代码:

    if ([[[NSUserDefaults standardUserDefaults] valueForKey:@"BUG"] isKindOfClass:[NSDictionary class]])
    {
    NSLog(@"%@",[[NSUserDefaults standardUserDefaults] valueForKey:@"BUG"]);
    [[NSUserDefaults standardUserDefaults] removeObjectForKey:@"BUG"];
    }

  4. 打印的字典内容即为崩溃的信息,与网上不同的是,这个可以直接显示在哪个控制器崩溃的,百分百准确,而且还可以手动把崩溃的用户其他信息给传送到后台,使BUG更容易重现和解决(前提是你的控制器必须继承YZViewController)
  5. 如图:
  6. 地址: https://github.com/YouZhiZheShiJingCheng/YZViewController

原文地址:http://blog.51cto.com/2254359459/2340125

时间: 2024-07-29 12:54:15

快速定位iOS线上BUG在哪个控制器崩溃的相关文章

利用友盟定位iOS线上版本项目的崩溃位置

引言 当我们的项目打包上传苹果商店之后,出现的崩溃问题不会想在XCode中那么明显了,那么我们就要对项目的crash日志进行分析,至此,友盟的崩溃分析作用就体现出来了. 前提 你的项目中集成了友盟 能获取到项目的dSYM文件 什么是 dSYM 文件 Xcode 编译项目后,我们会看到一个同名的 dSYM 文件,dSYM 是保存 16 进制函数地址映射信息的中转文件,我们调试的 symbols 都会包含在这个文件中,并且每次编译项目的时候都会生成一个新的 dSYM 文件,位于 /Users/<用户

Android线上bug热修复分析

针对app线上修复技术,目前有好几种解决方案,开源界往往一个方案会有好几种实现.重复的实现会有造轮子之嫌,但分析解决方案在技术上的探索和衍变,这轮子还是值得去推动的 关于Hot Fix技术 Hot Fix技术,简单来说就是针对线上已发布app出现了bug,在不推送新版本的情况下通过发布修复补丁进行修复.通常是刚上线的app,需要快速线上修复bug,类似的技术就叫做热修复或热补丁. 热修复技术能带来什么 让app具有了上线后被修复的可能性,增加事故风险可控性: 避免为修复bug而快速增发新版本,让

听说”双11”是这么解决线上bug的

--Android线上热修复的使用与原理 预备知识和开发环境 Android NDK编程 AndFix浅析 Android线上热修复的原理大同小异.这里仅仅针对眼下最火的框架AndFix进行解说.主要从AndFix的使用.原理以及优缺点三个方面进行阐述. 使用方式 介绍 AndFix是一个AndroidApp的在线热补丁框架. 使用此框架,我们可以在不反复发版的情况下,在线改动App中的Bug.AndFix就是 "AndroidHot-Fix"的缩写. 就眼下来说,AndFix支持An

【MySQL 线上 BUG 分析】之 多表同字段异常:Column ‘xxx’ in field list is ambiguous

一.生产出错! 今天早上11点左右,我在工作休息之余,撸了一下猫.突然,工作群响了,老大在里面说:APP出错了! 妈啊,这太吓人了,因为只是说了出错,但是没说错误的信息.所以我赶紧到APP上看看. 这果然是出错了,而且还是简单而粗暴的500,太吓人了. 二.本地赶紧调试起来! 既然线上出错了,我们又不能直接进行调试,那当然得马上在本地搞起来了! 1.代码是否有错? 立马启动本地的项目,访问对应的接口,看看是不是代码哪里出错了. 好了,本地的代码和 SQL 都是没错的! 2.SQL 是否有错? 那

记一次惨痛的线上bug

讲述背景,刚入职新公司2个月的时候,接手一个红包系统.资历尚浅,对业务也不是很熟悉.公司开发新的平台,需要使用红包功能来进行推广,按照产品的需求,进行开发...然而,问题就出在这里,红包接口比较陈旧,许多代码并有过多注释(甚至多出注释不全,注释出错),接口参数参差不齐,看的很累. 起先,将系统中所有调用红包的地方,都改成调用我的红包系统.和某端联调时,出现各种bug,参数无规约,返回参数不明确,(不知道要返回些啥,无明确需求文档),最后还是某端哥们,将原来的sql提供给我才得以解决此问题. 接着

在iOS 11上出现libsystem_kernel.dylib`__abort_with_payload崩溃问题的解决

crash日志内容 libsystem_kernel.dylib`__abort_with_payload: 0x11286b0a0 <+0>:  movl   $0x2000209, %eax          ; imm = 0x2000209 0x11286b0a5 <+5>:  movq   %rcx, %r10 0x11286b0a8 <+8>:  syscall ->  0x11286b0aa <+10>: jae    0x11286b0

对线上系统维护工作的总结与思考

背景描述:目前在一家网站公司工作,2015年初研发中心部门改革,小组重组,被分配到了网站平台的维护组.下面内容是对近期维护工作的一个总结: 个人感受:以前也在老东家的团队也做线上系统的维护和新产品的研发,由于大家的认真负责,Leader的管理也很到位,线上的系统很少有bug反馈,不管是UI上迭代,还是系统逻辑的升级都很顺畅. 目前负责的平台运行了3年多,可能由于当时逻辑设计问题,也可能是执行问题,发现近期反馈的问题多是逻辑问题,在此对这些问题的原因不做探讨和深究,只是想讲讲面对线上问题的维护工作

关于线上故障的思考

周末早上,一个哥们突然@我,问是否有线上故障处理和定级的规范或者模板,虽然手头有既有文档,但内容显的太具象了,跟我们的业务有很强的关联性,并不是那么好直接复制到他的团队中.因此,个人对过去的线上故障处理进行了回顾和思考,并进行了简要的归纳,望帮助到需要的同学.文本将按事中处理.事后总结和事前预防的顺序进行介绍,不足之处望大家不吝赐教. 换个角度来说,其实故障处理的过程,和小朋友发高烧的处理过程类似.首先mama会带孩子上医院,如果温度高医生会要求打退烧针,类似发布回滚,之后再通常吃对症的药物慢慢

chrome浏览器调试线上文件映射本地文件

通过ReRes让chrome拥有路径映射的autoResponse功能. 前端开发过程中,经常会有需要对远程环境调试的需求.比如,修改线上bug,开发环境不在本地等等.我们需要把远程css文件或者js映射到本地的文件上,通过修改本地文件进行调试和开发.通常我们可以通过以下方法来实现映射: 1.修改host文件——只能把域名映射到IP 2.使用Apache或者nginx搭建反向代理——需要装环境,配置相对繁琐 3.使用Fiddler中的AutoRespnose功能——不支持目录映射,mac.lin