#######问题
如果你需要一个url或者服务器传过来的parameter进行测试，但是这时候项目里暂时还没有这个url的宏定义或者服务器给的parameter是不完整(错误)的，但是还不得不用它测试自己开发的功能，这时候你会怎么办？？
。
。
。
。
。
LLDB几个命令
- p、po - 打印对象
默认格式
(lldb) p 16
16
十六进制:
(lldb) p/x 16
0x10
二进制 (t代表two)：
(lldb) p/t 16
0b00000000000000000000000000010000
(lldb) p/t (char)16
0b00010000
也可以使用p/c打印字符，或者p/s打印以空终止的字符串 (译者注：以 '\0' 结尾的字符串)
- e - 改变一个对象值，不仅会改变调试器中的值，实际上它 改变了程序中的值。expression的简写
定义变量
在 C 语言中你可以用int a = 0来定义一个变量，在 LLDB 中也可以做同样的事情。不过为了能使用声明的变量，变量必须以美元符$开头。
(lldb) e int $a = 2
(lldb) p $a * 19
38
(lldb) e NSArray *$array = @[ @"Saturday", @"Sunday", @"Monday" ]
(lldb) p [$array count]
2
(lldb) po [[$array objectAtIndex:0] uppercaseString]
SATURDAY
(lldb) p [[$array objectAtIndex:$a] characterAtIndex:0]
error: no known method '-characterAtIndex:'; cast the message send to the method's return typeerror: 1 errors parsing expression
LLDB 无法确定返回的类型，给个说明就好了：
(lldb) p (char)[[$array objectAtIndex:$a] characterAtIndex:0]
'M'
(lldb) p/d (char)[[$array objectAtIndex:$a] characterAtIndex:0]
77
crash日志分析
//1.闪退进程的相关信息
Incident Identifier: *********************
CrashReporter Key: *********
Hardware Model: iPhone4,1
Process: WYPatient [2066]
Path: ******
Identifier: ********
Version: 2510 (2.5.1)
Code Type: ARM (Native)
Parent Process: launchd [1]
/*
Incident Identifier 是崩溃报告的唯一标识符
CrashReporter Key是与设备标识相对应的唯一键值。
虽然它不是真正的设备标识符，但也是一个非常有用的情报:
如果你看到100个崩溃日志的CrashReporter Key值都是相同的，
或者只有少数几个不同的CrashReport值，
说明这不是一个普遍的问题，只发生在一个或少数几个设备上。
Hardware Model标识设备类型。 如果很多崩溃日志都是来自相同的设备类型，
说明应用只在某特定类型的设备上有问题。
Process是应用名称。中括号里面的数字是闪退时应用的进程ID。
*/
//基本信息
Date/Time: 2016-07-29 16:30:28.163 +0800
Launch Time: 2016-07-29 15:20:48.301 +0800
OS Version: iOS 8.1.1 (12B435)
Report Version: 105
//异常类型
/*在这部分，你可以看到闪退发生时抛出的异常类型。
还能看到异常编码和抛出异常的线程。
根据崩溃报告类型的不同，在这部分你还能看到一些另外的信息。*/
Exception Type: 00000020
Exception Codes: 0x000000008badf00d
Highlighted Thread: 0
Application Specific Information:
com.lvxian.guahao failed to exit in time
Elapsed total CPU time (seconds): 4.110 (user 4.110, system 0.000), 40% CPU
Elapsed application CPU time (seconds): 0.040, 0% CPU
//线程回溯
/*这部分提供应用中所有线程的回溯日志。
回溯是闪退发生时所有活动帧清单。它包含闪退发生时调用函数的清单*/
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
//帧编号 二进制库名称 调用方法的地址 基本地址和偏移量
0 libsystem_kernel.dylib 0x300be19c __semwait_signal + 24
1 libsystem_pthread.dylib 0x3013f6e2 pthread_join + 354
2 WYPatient 0x0095e15e 0xcb000 + 8991070
3 WYPatient 0x00963d4c 0xcb000 + 9014604
4 WYPatient 0x009140e4 0xcb000 + 8687844
5 WYPatient 0x00938d62 0xcb000 + 8838498
6 WYPatient 0x00936980 0xcb000 + 8829312
7 WYPatient 0x00905392 0xcb000 + 8627090
8 WYPatient 0x008fb208 0xcb000 + 8585736
9 WYPatient 0x008e3abc 0xcb000 + 8489660
10 WYPatient 0x00ebbf28 0xcb000 + 14618408
11 WYPatient 0x00ebbe02 0xcb000 + 14618114
12 WYPatient 0x00ebbf86 0xcb000 + 14618502
13 WYPatient 0x00eaf9de 0xcb000 + 14567902
14 WYPatient 0x00eb3a90 0xcb000 + 14584464
15 WYPatient 0x0093bfd4 0xcb000 + 8851412
16 Foundation 0x22efea40 __NSFireTimer + 60
17 CoreFoundation 0x221b0f04 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 12
18 CoreFoundation 0x221b0a84 __CFRunLoopDoTimer + 652
19 CoreFoundation 0x221aecee __CFRunLoopRun + 1414
20 CoreFoundation 0x220fbb2c CFRunLoopRunSpecific + 472
21 CoreFoundation 0x220fb93e CFRunLoopRunInMode + 102
22 GraphicsServices 0x294db04c GSEventRunModal + 132
23 UIKit 0x256f16ec UIApplicationMain + 1436
24 WYPatient 0x00679842 0xcb000 + 5957698
25 libdyld.dylib 0x2fff8aac start + 0
//线程状态
/*这部分是闪退时寄存器中的值。一般不需要这部分的信息，
因为回溯部分的信息已经足够让你找出问题所在
*/
Thread 0 crashed with ARM Thread State (32-bit):
r0: 0x00000000 r1: 0x00000000 r2: 0x00000000 r3: 0x00000000
r4: 0x00000006 r5: 0x39d5d000 r6: 0x38fb7304 r7: 0x001634e8
r8: 0x17e58ab0 r9: 0x225d88fc r10: 0xe88effc1 r11: 0x17e58ad4
ip: 0x00000148 sp: 0x001634dc lr: 0x22b59b47 pc: 0x22ab3c5c
cpsr: 0x00000010
//二进制映像
/*这部分列出了闪退时已经加载的二进制文件*/
Binary Images:
0x2c000 - 0x47fff Test1 armv7 <234afddbe98a3faeada9efd4393b21e9> /var/containers/Bundle/Application/74DA63F4-24A4-42C8-9B98-A2414E5BD24C/Test1.app/Test1
0x1febb000 - 0x1fee2fff dyld armv7s <fb3cc314bf8f3c12a366856040c7abb2> /usr/lib/dyld
0x22570000 - 0x22571fff libSystem.B.dylib armv7s <e8d2c57601e43570807fe2e576cb4a9e> /usr/lib/libSystem.B.dylib
0x22572000 - 0x225bdfff libc++.1.dylib armv7s <82abc45878c53dfd8e59d088ead88952> /usr/lib/libc++.1.dylib
0x225be000 - 0x225d8fff libc++abi.dylib armv7s <de59b366979034d88c4f5ac3e98abca4> /usr/lib/libc++abi.dylib
0x225dc000 - 0x22946fff libobjc.A.dylib armv7s <d4451e6d28c9339592c2e97f66c0e67b> /usr/lib/libobjc.A.dylib
0x22947000 - 0x2294bfff libcache.dylib armv7s <2b39436eaf1c3aa384dc88d909bb82ea> /usr/lib/system/libcache.dylib
0x2294c000 - 0x22955fff libcommonCrypto.dylib armv7s <39d4afd1f66738cd839cb5653496c3ee> /usr/lib/system/libcommonCrypto.dylib
怎么分析crash日志
在分析一份crash日志之前，开发人员要对常见的错误类型有所了解。crash日志的产生来源于两种情况：
****违反iOS系统规则
自身代码bug****
1. 违反IOS系统规则
违反iOS规则包括在启动、恢复、挂起、退出时watchdog超时、用户强制退出和低内存终止。下面我们详细了解一下。
(1) Watchdog 超时机制
如果我们的应用程序对一些特定的UI事件（比如启动、挂起、恢复、结束）响应不及时，Watchdog会把我们的应用程序干掉，并生成一份响应的crash报告。这些事件与下列UIApplicationDelegate方法相对应:
1. application:didFinishLaunchingWithOptions:
2. applicationWillResignActive:
3. applicationDidEnterBackground:
4. applicationWillEnterForeground:
5. applicationDidBecomeActive:
6. applicationWillTerminate:
上面所有这些回调，应用只有有限的时间去完成处理。如果花费时间太长，操作系统将终止应用。
****注意****:如果你没有把需要花费时间比较长的操作(如网络访问）放在后台线程上就很容易发生这种情况。关于如何避免这种情况，可以看下Grand Central Dispatch 和 NSOperations。。如果我们是在公司的Wifi环境下使用则一切顺利，但当应用程序发布出去面向很大范围的用户，在各种网络环境下运行，则不可避免地会出现一片Watchdog
超时报告。
(2) 低内存终止
在前台运行的应用拥有访问和使用内存的最高优化级。然而，这并不意味着该应用能使用设备的所有可用内存 ——每个应用只能使用一部分可用内存。
当内存使用达到一定程度时，操作系统将发出一个 UIApplicationDidReceiveMemoryWarningNotification通知。同时调用 didReceiveMemoryWarning方法。
此时，为了让应用继续正常运行，操作系统开始终止后台应用以释放一些内存,如果情况还没有改善，系统会将正在运行的应用也终止掉，并产生一个崩溃日志。所以，我们的应用应该合理地响应系统抛出来的低内存警告通知，对一些缓存数据和可重新创建的对象进行释放，同时要避免出现内存泄露等问题
(3) 用户强制退出
iOS 4.x开始支持多任务。如果应用阻塞界面并停止响应， 用户可以通过在主屏幕上双击Home按钮来终止应用。此时，改应用将生成一个崩溃日志。
常见错误类型和错误码
1、Exception Type
EXC_BAD_ACCES
此类型的Excpetion是我们最长碰到的Crash，通常用于访问了不改访问的内存导致。一般EXC_BAD_ACCESS后面的"( )"还会带有补充信息。
SIGSEGV: 通常由于重复释放对象导致，这种类型在切换了ARC以后应该 已经很少见到了。
SIGABRT: 收到Abort信号退出，通常Foundation库中的容器为了保护状态正常会做一些检测，例如插入nil到数组中等会遇到此类错误。
SEGV:（Segmentation Violation），代表无效内存地址，比如空指针，未初始化指针，栈溢出等；
SIGBUS：总线错误，与 SIGSEGV 不同的是，SIGSEGV 访问的是无效地址，而 SIGBUS 访问的是有效地址，但总线访问异常(如地址对齐问题)
SIGILL：尝试执行非法的指令，可能不被识别或者没有权限
EXC_BAD_INSTRUCTION
此类异常通常由于线程执行非法指令导致
EXC_ARITHMETIC
除零错误会抛出此类异常
2、Exception Code
异常编码以一些文字开头，紧接着是一个或多个十六进制值，此数值正是说明闪退根本性质的所在。 从这些编码中，可以区分出闪退是因为程序错误、非法内存访问或者是其他原因。
下面是一些常见的异常编码:
0x8badf00d: 读做 “ate bad food”! (把数字换成字母，是不是很像 :p)该编码表示应用是因为发生watchdog超时而被iOS终止的。 通常是应用花费太多时间而无法启动、终止或响应用系统事件。
0xbaaaaaad 此种类型的log意味着该Crash log并非一个真正的Crash，它仅仅只是包含了整个系统某一时刻的运行状态。通常可以通过同时按Home键和音量键，可能由于用户不小心触发
0xbad22222:该编码表示 VoIP 应用因为过于频繁重启而被终止。
0xdead10cc:读做 “dead lock”!该代码表明应用因为在后台运行时占用系统资源，如通讯录数据库不释放而被终止 。
0xc00010ff 程序执行大量耗费CPU和GPU的运算，导致设备过热，触发系统过热保护被系统终止
0xdeadfa11:读做 “dead fall”! 该代码表示应用是被用户强制退出的。根据苹果文档, 强制退出发生在用户长按开关按钮直到出现 “滑动来关机”, 然后长按 Home按钮。强制退出将产生 包含0xdeadfa11 异常编码的崩溃日志, 因为大多数是强制退出是因为应用阻塞了界面。
（注意:在后台任务列表中关闭已挂起的应用不会产生崩溃日志。 一旦应用被挂起，它何时被终止都是合理的。所以不会产生崩溃日志。）
2.代码中有Bug
比较常见的崩溃基本都源于代码bug，比如数组越界、插空、多线程安全性、访问野指针、发送未实现的selector等。
举个简单的例子：
假设你的app有一个添加关注的按钮，用户反应只要点击"添加关注"就会闪退。。。。。下面是闪退日志的一部分：
Incident Identifier: 91526C12-5072-407E-8C11-111F360D5F39
CrashReporter Key: 75f3a66d2bde1402cb36140b626177dbc5999f3f
Hardware Model: iPhone5,4
Process: Test1 [7531]
Path: /private/var/containers/Bundle/Application/74DA63F4-24A4-42C8-9B98-A2414E5BD24C/Test1.app/Test1
Identifier: com.guahao.Test1
Version: 1 (1.0)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2016-08-23 16:34:30.30 +0800
Launch Time: 2016-08-23 16:34:26.26 +0800
OS Version: iOS 9.3.2 (13F69)
Report Version: 105
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Filtered syslog:
None found
Last Exception Backtrace:
0 CoreFoundation 0x22e25b06 __exceptionPreprocess + 122
1 libobjc.A.dylib 0x225e2dfa objc_exception_throw + 34
2 CoreFoundation 0x22e2b450 -[NSObject(NSObject) doesNotRecognizeSelector:] + 184
3 CoreFoundation 0x22e290a6 ___forwarding___ + 698
4 CoreFoundation 0x22d53294 _CF_forwarding_prep_0 + 20
5 UIKit 0x2743b69c -[UIApplication sendAction:to:from:forEvent:] + 76
6 UIKit 0x2743b62c -[UIControl sendAction:to:forEvent:] + 60
7 UIKit 0x27423566 -[UIControl _sendActionsForEvents:withEvent:] + 462
8 UIKit 0x2743af4c -[UIControl touchesEnded:withEvent:] + 612
9 UIKit 0x273f4b92 _UIGestureRecognizerUpdate + 10930
10 CoreFoundation 0x22de72ac __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 16
11 CoreFoundation 0x22de55a2 __CFRunLoopDoObservers + 278
12 CoreFoundation 0x22de59e0 __CFRunLoopRun + 968
13 CoreFoundation 0x22d341c4 CFRunLoopRunSpecific + 512
14 CoreFoundation 0x22d33fb8 CFRunLoopRunInMode + 104
15 GraphicsServices 0x24350af4 GSEventRunModal + 156
16 UIKit 0x2746c430 UIApplicationMain + 140
17 Test1 0x0003cdfa 0x2c000 + 69114
18 libdyld.dylib 0x229e086e tlv_get_addr + 42
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x22ab3c5c __pthread_kill + 8
1 libsystem_pthread.dylib 0x22b59b46 pthread_kill + 62
2 libsystem_c.dylib 0x22a480c4 abort + 108
3 libc++abi.dylib 0x225be7dc __cxa_bad_cast + 0
4 libc++abi.dylib 0x225d76a0 default_unexpected_handler() + 0
5 libobjc.A.dylib 0x225e3098 _objc_terminate() + 192
6 libc++abi.dylib 0x225d4e16 std::__terminate(void (*)()) + 78
7 libc++abi.dylib 0x225d48f6 __cxa_rethrow + 102
8 libobjc.A.dylib 0x225e2f46 objc_exception_rethrow + 42
9 CoreFoundation 0x22d3424e CFRunLoopRunSpecific + 650
10 CoreFoundation 0x22d33fbc CFRunLoopRunInMode + 108
11 GraphicsServices 0x24350af8 GSEventRunModal + 160
12 UIKit 0x2746c434 UIApplicationMain + 144
13 Test1 0x0003cdfe 0x2c000 + 69118
14 libdyld.dylib 0x229e0872 start + 2
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x22ab52f8 kevent_qos + 24
1 libdispatch.dylib 0x229c7836 _dispatch_mgr_invoke + 254
2 libdispatch.dylib 0x229b9916 _dispatch_mgr_thread + 38
Thread 2:
0 libsystem_kernel.dylib 0x22ab4864 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x22b56e18 _pthread_wqthread + 1036
2 libsystem_pthread.dylib 0x22b569fc start_wqthread + 8
