总结关于lldb的一些实际好用的调试方法
前言
关于lldb调试器网上有很多文章都有做了介绍, 自己也看了一些, 但是吧, 关于lldb的有些调试方法实在是太高大上了, 我个人用起来就很少, 虽然我承认那些不好记得命令确实有用, 但是在个人写项目的过程中用到了其中几个感觉还是比较实际和方便的用法, 特地来总结下.
第一个: po
po这个命令可以说是我自己用的最多了一个了, 这个命令的作用是什么呢? 就是只要是你程序中的东西都可以打印出来, 当程序运行到当前断点调试的地方的时候, lldb调试器就是出现在Xcode的控制台, 比如这样:
Xcode控制台
当Xcode遇到断点来到当前控制台时我们就可以进行lldb调试器的使用了, 直接输入po array 就可以打印我们初始化并且已经赋值的array对象
断点打印对象
在控制台我们可以看到打印出了这个对象的内存地址, 还有这个对象的初始化内容
如果打印的对象是控件的话,会变成这样:
打印控件
会看到这个控件的frame, 在进行微调的时候很好用, 还有其他一些调试的时候也好用, 最重要的我觉得就是你可以不用傻傻的一直NSLog了, 然后再运行一次程序, 这样节省很多时间了, 不然如果临时想打印一个东西就要重新运行一次那得多浪费时间啊. 而且如果是这个程序是比较大的话, 运行编译一次的时间很长, 那我想如果靠NSLog来进行调试会让这个开发者抓狂吧.
第二个: exp
exp这个命令是expression这个命令的缩写. 这个命令是我用的第二多的lldb命令了吧, 这个exp命令的作用是可以动态的修改属性, 在Xcode的控制台中, 注意: 这个命令不光是修改了运行时的属性值, 也会修改模拟器中属性的值(这样说怎么感觉有点runtime的味道了啊),比如我经常遇到的一个情况, 要设置一个视图的背景颜色, 就这个控制器的view的背景颜色吧, 设置完点击Run一下, 运行成功发现颜色不是自己想要的, 可能你就会在代码里改一下再运行一次, 再看看运行之后的颜色是不是和自己想要的一样, 这样一直下去.同样, 你不觉得这样非常的浪费时间吗, 每次都要修改代码重新运行, 好了, 现在就可以使用exp命令来拯救你了, 话不多说, 看下图:
未修改颜色
使用exp命令在控制台动态修改
修改之后
这个exp命令真的非常好用, 强烈安利一波啊, 谁用谁知道
第三个: image
这个第三个命令不要看它写的是image就以为是和图片操作相关的, 其实一点关系都灭有. 这个命令也超级强大, 怎么强大呢, 这么说吧, 可以直接定位追踪到Bug崩溃在哪一行, 你说这个强大不强大?
比如我们现在认为的搞个crash, 最简单的, 来个数组越界:
数组越界
可以看到在断点处我们访问了一个数组, 但是是越界的, 因为这个array数组的元素只有2个, 而我们访问的是第三个, 这个时候就会出现数组越界, 然后crash, 这个时候控制台会打印
2016-08-26 14:24:33.624 DemoAttriate[62619:3972635] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[__NSArrayI objectAtIndex:]: index 2 beyond bounds [0 .. 1]'
*** First throw call stack:
(
0 CoreFoundation 0x000000010ec23d85 __exceptionPreprocess + 165
1 libobjc.A.dylib 0x000000010e697deb objc_exception_throw + 48
2 CoreFoundation 0x000000010eb0c934 -[__NSArrayI objectAtIndex:] + 164
3 DemoAttriate 0x000000010e153f99 -[ViewController viewDidLoad] + 313
4 UIKit 0x000000010fc57984 -[UIViewController loadViewIfRequired] + 1198
5 UIKit 0x000000010fc57cd3 -[UIViewController view] + 27
6 UIKit 0x000000010fb2dfb4 -[UIWindow addRootViewControllerViewIfPossible] + 61
7 UIKit 0x000000010fb2e69d -[UIWindow _setHidden:forced:] + 282
8 UIKit 0x000000010fb40180 -[UIWindow makeKeyAndVisible] + 42
9 UIKit 0x000000010fab4ed9 -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 4131
10 UIKit 0x000000010fabb568 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1769
11 UIKit 0x000000010fab8714 -[UIApplication workspaceDidEndTransaction:] + 188
12 FrontBoardServices 0x00000001149e18c8 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 24
13 FrontBoardServices 0x00000001149e1741 -[FBSSerialQueue _performNext] + 178
14 FrontBoardServices 0x00000001149e1aca -[FBSSerialQueue _performNextFromRunLoopSource] + 45
15 CoreFoundation 0x000000010eb49301 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
16 CoreFoundation 0x000000010eb3f22c __CFRunLoopDoSources0 + 556
17 CoreFoundation 0x000000010eb3e6e3 __CFRunLoopRun + 867
18 CoreFoundation 0x000000010eb3e0f8 CFRunLoopRunSpecific + 488
19 UIKit 0x000000010fab7f21 -[UIApplication _run] + 402
20 UIKit 0x000000010fabcf09 UIApplicationMain + 171
21 DemoAttriate 0x000000010e15720f main + 111
22 libdyld.dylib 0x0000000111ee092d start + 1
23 ??? 0x0000000000000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)
可以在崩溃信息中的first throw call stack中看到第3个对应是我们运行的程序分配的内存地址, 好, 这个时候复制这个内存地址跟着我做:
(lldb) image lookup --address 0x000000010e153f99
Address: DemoAttriate[0x0000000100013f99] (DemoAttriate.__TEXT.__text + 75337)
Summary: DemoAttriate`-[ViewController viewDidLoad] + 313 at ViewController.m:25
(lldb)
我们可以在Summary中直接看到crash是在哪一个方法中产生的, 是在哪一行中产生的, 这不直接等于是告诉了我们该怎么解决Bug了吗? 多么好的一个lldb调试命令啊, 是吧, 再安利一波~
总结
关于lldb调试大法还有很多东西我没有说(总要我自己都没怎么用过也就不好说了), 上面3个总结的lldb命令用的好真的会事半功倍的.
