app上线之后，一定会有线上的bug，可以通过符号化还原出来具体的奔溃栈，从而分析出来具体的问题所在
今天我也遇到了，因为是第一天改项目，然后不是特别懂，最后同事帮助我解决了这个问题.
总结:一定要去好公司，才会有一批的高手，教你很多东西
奔溃栈
要注意，就是Thread 0 Crashed:就是主线程的意思
这个就是具体的调用栈信息，然后我们就可以找了。
思路:
1.看看+200这个位置到底是是啥玩意
根据崩溃栈信息来看，问题直接定位在了[UIWindow _shouldAutorotateToInterfaceOrientation:checkForDismissal:isRotationDisabled:]函数,所以我们直接在这里设置断点.
注意，当我们设置断点到了这个函数，应该去找到奔溃点---+ 196,因为+200的时候已经执行完函数，此时的$x0寄存器已经发生了变化，看不到具体的参数了.
-[UIWindow _shouldAutorotateToInterfaceOrientation:checkForDismissal:isRotationDisabled:] + 200
然后定位到了+196（+200）的上一条指令位置，objc_sendmsg，奔溃位置!!!
通过打印出来x0,x21,x8,来确定出具体的东西，x21表示的是self,可以通过汇编代码查出来，也可以打印出来,x8表示的是ivar_offset，一个偏移值，也就是说，是一个window的变量，要去打印出来x8存的东西
register read x8
//获取的是一个比较小的数字，0xc8,后来经过鉴定，是delegate
//超哥教我看汇编
0x18b2b1f24 <+168>: adrp x8, 54619
0x18b2b1f28 <+172>: ldrsw x8, [x8, #0xf7c]
-> 0x18b2b1f2c <+176>: ldr x0, [x21, x8] //将x21（window）加上 x8的值，然后放回x0位置, window->delegate，此时的x8内部是一个比较小的数字
0x18b2b1f30 <+180>: adrp x8, 54571 //更新了x8数据
0x18b2b1f34 <+184>: nop
0x18b2b1f38 <+188>: ldr x1, [x8, #0x980]
0x18b2b1f3c <+192>: mov x2, x22
0x18b2b1f40 <+196>: bl 0x18b7bb708 //直接crash （ios8中，其他的并没有crash，模拟的时候，也没有crash）,打印出来的结果是SAKModalViewController
0x18b2b1f44 <+200>: mov x24, x0
(lldb) register read x8
x8 = 0x00000000000000c8
(lldb)
//打印寄存器的某个属性
(lldb) po [(id)$x21 delegate]
因为这个在我们这里并没有浮现出来，但是不是说不存在，我们的思路就是看看为甚会奔溃，然后解决
结论:
这里就可以断定，一定是SAKModalViewController这个对象已经释放了，导致了在+196这个位置crash了
-[UIWindow _shouldAutorotateToInterfaceOrientation:checkForDismissal:isRotationDisabled:] + 200
这个位置表示的是在这个函数里面crash的，但并不是因为调用了他crash的，
真正的元凶是SAKModalViewController没有了，此时打印寄存器x1，
现实的的这个方法 "M",因为这个问题，所以调用了“M”方法，导致了整个项目的crash。
结论
在SAKModalViewController释放的时候，我们没有设置window.delegate = nil,所以导致了野指针，项目发生了crash，这也就是为什么，在项目中我们经常看到别人的代码经常写到
xxx.delegate = nil
之所以我们这crash只有在ios8中发生，在其他的系统，和我们模拟的过程中没有发生crash，是因为ios8中的tableview.scrollview.collectionview.delegate都是用assign修饰的，当这个对象释放的时候，都会有 crash的可能，而之后，都是用weak修饰的，如果对象释放了，我们会将所有的weak指针指向nil，从而不会发生crash
解决方法
当SAKModalViewController控制器销毁的时候，将UIWindow的delegate设置为nil即可.
2.再看一步
根据上边的结论，我们就知道为甚了，就是看看接下来的crash的真实位置objc_msgSend + 16,看看这个+16位置到底做了什么,依旧使用符号断电
libobjc.A.dylib`objc_msgSend:
-> 0x196f6fbc0 <+0>: cmp x0, #0x0 ; =0x0
0x196f6fbc4 <+4>: b.le 0x196f6fc30 ; <+112>
0x196f6fbc8 <+8>: ldr x13, [x0]
0x196f6fbcc <+12>: and x9, x13, #0x1fffffff8
0x196f6fbd0 <+16>: ldp x10, x11, [x9, #0x10] //找到这个位置
0x196f6fbd4 <+20>: and w12, w1, w11
0x196f6fbd8 <+24>: add x12, x10, x12, lsl #4
从奔溃的地方往上分析
/***********************/
Exception Type: EXC_BAD_ACCESS (SIGBUS)
//这个是0x0000000000000010就是这个0x10，这个是呼应，切记
Exception Codes: KERN_INVALID_TASK at 0x0000000000000010
Crashed Thread: 0
/***********************/
//一.x10 = x9 + 0x10，但是在这里crash了.这个位置和奔溃栈呼应了
ldp x10, x11, [x9, #0x10] //找到这个位置
//二.x9和x13执行了与操作
0x196f6fbcc <+12>: and x9, x13, #0x1fffffff8
//三.从x0存的位置中取出来一个内容，给x13寄存器，应该是[x0] = nil，导致了问题.
0x196f6fbc8 <+8>: ldr x13, [x0]