我已经被困在这件事上好几个小时了,而且我也不知道还有什么可以搜索。
由于调试器没有显示任何错误但可以重现,因此我无法提供这些内容 - 我在表视图中点击了一个非常具体的项目,其行为应该是解雇那个模态,然后我的应用程序冻结。对于表格视图中的其他项目不会发生这种情况 - 模式完全解散并且应用程序继续运行。
我检查this answer怀疑它是一个死锁,但是:
layoutSubviews
方法中放置了断点,并且它一直被调用。它不会调用[super layoutSubviews]
,也不会对任何人调用setNeedsLayout
,只需设置其子视图的帧,因为我没有使用Autolayout。我该怎么调试这个东西?我一直在寻找Xcode Instruments,但我无法理解我所看到的数据。具体来说,系统跟踪模板似乎能够在冻结发生时立即停止,与其他继续记录的模式不同。
添加:我在系统跟踪
中看到的内容答案 0 :(得分:2)
仪器是您要诊断问题的工具。尝试使用Time Profiler
检查您的应用,执行您正在观察的任务以提高CPU使用率,然后分析结果,检查Invert Call Tree
和Hide System Libraries
。如果您要检查特定时间段,也可以设置时间标记。从这里,您可以看到哪些呼叫正在吸收CPU。
答案 1 :(得分:0)
@ Paulw11的评论有帮助 - Time Profiler模板比System Trace仪器更适合这项任务。
我使用了Time Profiler并导致了一系列指向UINavigationBar的痕迹,这些痕迹是我自定义UIControl layoutSubviews
的可疑重复调用者。为了进一步解释我的视图层次结构:
此处有以下交易:如果alloc-initWithFrame
我的自定义UIControl
的框架为CGRectZero
,该应用会冻结。如果我向框架提供垃圾初始值(因为UINavigationBar重塑了我的自定义UIControl,无论如何都会被忽略),如CGRectMake(0, 0, 10, 10)
,崩溃不会发生。
我猜测UINavigationBar对如何布局初始帧为(0, 0, 0, 0)
的自定义标题视图感到困惑。听起来像是一个苹果虫。
注意:我在iOS 8.2上运行。