Autolayout Breakpoints
Auto layout has become a crucial tool for iOS and OS X development. It makes creating layout for multiple screen sizes easy peasy. But sometimes it can drive you crazy, with verbose and misleading logs.
1
2
3
4
5
6
7
8
9
10
11
12
13
|
|
That’s a huge log! And I cut off the NSLayoutConstraint
part. Yet, the second last line is giving a clue in which direction to go to fix this issue. Symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints
.
All right, here’s what Xcode want’s you to do:
Honestly, that won’t help much, because basically it’ll just stop the execution and leave you up with LLDB
, alone in the dark.
But there’s a little trick you can do to enhance the preceding symbolic breakpoint. Adding po [[UIWindow keyWindow] _autolayoutTrace]
to it (for Obj-C projects) or expr -l objc++ -O -- [[UIWindow keyWindow] _autolayoutTrace]
(for Swift projects).
Now, on console, you’ll see all the UIView
hierarchy and exactly where it has ambiguity.
1
2
3
4
5
|
|
Note that as you hit continue it’ll stop at every ambiguous layout you may have. And if that’s not enough for you to find out your autolayout issue, try changing the view’s color, who knows?
1
2
|
|
Fear no more young Padawan, make symbolic breakpoints and LLDB
work for you!
I would like to thank Porter Hoskins for pointing out the correct LLDB
command for Swift.
南来地,北往的,上班的,下岗的,走过路过不要错过!
======================个性签名=====================
之前认为Apple 的iOS 设计的要比 Android 稳定,我错了吗?
下载的许多客户端程序/游戏程序,经常会Crash,是程序写的不好(内存泄漏?刚启动也会吗?)还是iOS本身的不稳定!!!
如果在Android手机中可以简单联接到ddms,就可以查看系统log,很容易看到程序为什么出错,在iPhone中如何得知呢?试试Organizer吧,分析一下Device logs,也许有用.