iOS App Crash原理分析

预备知识:OS X系统分析

1.内核XNU是Darwin的核心,也是整个OS X的核心。XNU本身由以下几个组件构成:

Mach微核心

BSD层

libKern

I/O Kit

此外,内核是模块化的,允许根据需要动态加载插件形式的内核扩展。

2.Mach:XNU的核心,Mach仅能处理操作系统最基本的职责:

进程和线程抽象。

虚拟内存管理

任务调度

进程间通信和消息传递机制(例如:NSMachPort)

3.所以OS X是在Mach内核的基础上构建的,苹果不鼓励直接只用Mach的API,但是Mach系统调用仍然可以在用户态访问。而BSD层是对Mach内核的封装,任何额外的功能,比如文件和设备的访问,都是在BSD层实现的。

4.BSD: 是建立在Mach之上,提供更可靠的API,提供了POSIX兼容性。BSD层提供了更高层次的抽象,包括:

UNIX进程模型

POSIX线程模型及其相关的同步原语

网络协议栈

UNIX用户和组

文件系统访问

设备访问

iOS Crash原理分析

iOS系统的Exception Type项通常包含两个元素:Mach异常和Unix信号。

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Subtype: KERN_INVALID_ADDRESS 0x041a6f3

Mach的部分API暴露给用户态,用户态的开发者可以直接通过Mach API设置thread, task, host的异常端口来捕获异常,摘取Crash事件。所有的Mach异常都在host层被ux_exception转换成对应的Unix信号,并通过threadsignal将信号投递到出错的线程。那么就可以通过注册signalHandler来获取信号signal(SIGSEGV,signalHandler);

crash捕获途径:

1.Mach异常

2.Unix信号

优选Mach异常,因为Mach异常处理会先于Unix信号处理发生,如果Mach异常的handler让程序exit了,那么Unix信号就永远不会到达这个进程了。转换Unix信号是为了兼容更为流行的POSIX标准(SUS规范),这样不必了解Mach内核也可以通过Unix信号的方式来兼容开发。

总结:所以通常代码中的只捕获Exception是不够的。


作者:简单的快乐着链接:http://www.jianshu.com/p/c2212058161f來源:简书著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
时间: 2024-11-05 14:53:38

iOS App Crash原理分析的相关文章

iOS版PhoneGap原理分析

PhoneGap,著名的跨平台Hybrid框架,旨在让开发者使用HTML.Javascript.CSS开发跨平台的App. 最近的工作,就是做Hybrid方面的,很自然,方案就从PhoneGap入手. 下面就切入正题,分析下PhoneGap的原理,需要说明的是,我只针对iOS版本的PhoneGap做分析,android版本的原理大同小异. 安装PhoneGap 现在使用PhoneGap非常方便,只需要安装node,用简单的命令就能完成安装和使用的工作. 安装PhoneGap: 1 sudo np

苹果官方 Crash文件分析方法 (iOS系统Crash文件分析方法)

对于提交的苹果官方的app,在审核的时候会给我们一些crash文件,对于这些有用的文件,里面是关于我们的bug的一些信息,那么该如何去调试呢 第一步:在任意目录创建一个目录,用来调试crash,我这里创建一个crash目录 第二步:将之前Archive的文件copy到crash目录里面 其中包括两个文件.app和.app.dSYM 如果找不到的话可以按照下面的步骤进行 先到Organizer 1,找到提交那个时刻的Archive文件,选中,show in Finder 2,然后到达这里,然后再选

Xcode之Crash日志分析

从Crash文件出发解决bug的一般步骤,分三步: a, 获取设备上的崩溃日志. b, 分析崩溃日志,找到报错位置(定位到函数和代码行数). c, 打开代码,改bug. 1, 获取设备日志 1.在可以获取到运行app的手机,或者用户配合导出日志的情况下.可以将设备连接到电脑,然后与电脑上的iTunes同步,崩溃日志会同步到电脑上的指定文件夹.(上面博客有指明) 2.在可以直接获取到运行app的手机的情况下.可以将设备连接到电脑,然后打开xcode软件,选择Window->Devices,然后可以

一个可以实时跟踪分析iOS App视图的小工具

一个可以实时跟踪分析iOS App视图的小工具(已开源) GitHub入口:https://github.com/sx1989827/RunTrace 前言 作为iOS的开发者,常常为了UI界面搞得头破血流,你是不是经常遇到这样的痛点:这个view是从哪里来的,它的父视图是什么,它的子视图有哪些,它的frame会发生什么样的变化,它怎么突然隐藏了,它什么时候会被释放掉,对于像自动布局,错误常常如潮水般的涌来,我想动态获取一个view的约束怎么办,我想知道这个view此时此刻和其他哪些view产生

IOS Crash Log 分析

上架AppStroe 被打回来了,原因是: Your app crashed on iPad running iOS 11.3.1 connected to an IPv6 network when we tapped on profile image. We have attached detailed crash logs to help troubleshoot this issue. 崩溃日志 一.Crash文件结构 当程序运行Crash的时候,系统会把运行的最后时刻的运行信息记录下来,

iOS常见crash问题及crash日志分析

第一.iOS常见crash问题 1.插入空元素 对于NSMutableArray.NSMutableDictionary.NSMutableSet等可变的对象,插入空元素时crash 正确做法是加判断,sample code如下所示: NSDictionary *dic; NSMutableArray *arr=[NSMutableArray new]; if (dic) { [arr addObject:dic]; } NSLog(@"%@",arr); 加非空的判断条件: if(d

支付宝app支付java后台流程及原理分析

java版支付宝app支付流程及原理分析 本实例是基于springmvc框架编写     一.流程步骤         1.执行流程           当手机端app(就是你公司开发的app)在支付页面时,调起服务端(后台第1个创建订单接口)接口,后台把需要调起支付宝支付的参数返回给手机端,手机端拿到         这些参数后,拉起支付宝支付环境完成支付,完成支付后会调异步通知(第2个接口),此时需要给支付宝返回成功或者失败信息,成功后会调用同步通知(第3个接口)         返回支付成

iOS App稳定性指标及监测

一个App的稳定性,主要决定于整体的系统架构设计,同时也不可忽略编程的细节,正所谓"千里之堤,溃于蚁穴",一旦考虑不周,看似无关紧要的代码片段可能会带来整体软件系统的崩溃.尤其因为苹果限制了热更新机制,App本身的稳定性及容错性就显的更加重要,之前可以通过发布热补丁的方式解决线上代码问题,现在就需要在提交之前对App开发周期内的各个指标进行实时监测,尽量让问题暴漏在开发阶段,然后及时修复,减少线上出问题的几率 .针对一个App的开发周期,它的稳定性指标主要有以下几个环节构成,用一个脑图

Android 4.4 KitKat NotificationManagerService使用详解与原理分析(一)__使用详解

概况 Android在4.3的版本中(即API 18)加入了NotificationListenerService,根据SDK的描述(AndroidDeveloper)可以知道,当系统收到新的通知或者通知被删除时,会触发NotificationListenerService的回调方法.同时在Android 4.4 中新增了Notification.extras 字段,也就是说可以使用NotificationListenerService获取系统通知具体信息,这在以前是需要用反射来实现的. 转载请