tableView.dequeueReusableCellWithIdentifier()导致应用程序挂起 [英] tableView.dequeueReusableCellWithIdentifier() causes app to hang
问题描述
原始帖子
我们最近将应用转换为Swift 2.0和iOS9。我看到的一个奇怪问题是调用tableView.dequeueReusableCellWithIdentifier()会导致应用程序在模拟器中挂起。
代码
func tableView (tableView:UITableView,viewForHeaderInSection section:Int) - > UIView的? {
//挂在
下面的行让headerection:HeaderSectionCell = tableView.dequeueReusableCellWithIdentifier(SectionHeader)为! HeaderSectionCell
...
返回headerection
}
标题单元格
class HeaderSectionCell:UITableViewCell {
@IBOutlet var label1 :UITextView!
@IBOutlet var labelTwo:UITextView!
@IBOutlet var textView:UITextView!
}
模拟器CPU使用率挂钩为100%
以下是一些iOS在循环中循环的例程。
最后,我们的Swift调用dequeueReusableC ellWithIdentifier()
这个特殊的挂起实例来自函数 tableView(tableView :UITableView,viewForHeaderInSection section:Int)
,但我们也挂在对 tableView(tableView:UITableView,cellForRowAtIndexPath indexPath:NSIndexPath)的调用中
,有同样的问题。
我试过在故事板编辑器中使用单元格属性,但没有什么比其他工作正常的视图有所不同。
编辑
基金会之间似乎存在无限循环libobjc.A.dylib,在dequeReusableCellWithIdentifier()调用之下。我最终确保在任何其他框架之前导入Foundation,并将违规的UITableViewCell抽象到自己的类中(正在被重用)。有问题的原始呼叫现在正在运行,但是还有另一个仍然在我正在努力解决的Swift封面下循环。
在无限中暂停循环使我进入相同的汇编堆栈位置:
暂停后的堆栈跟踪:
libobjc.A.dylib`objc_msgSend:
0x107f6a800< + 0>:testq%rdi,%rdi
0x107f6a803< + 3>:jle 0x107f6a850; 1 + 80 GT;
0x107f6a805< + 5>:movq(%rdi),%r11
0x107f6a808< + 8>:movq%rsi,%r10
0x107f6a80b< + 11>:andl 0x18( %r11),%r10d
0x107f6a80f< + 15>:shlq $ 0x4,%r10
0x107f6a813< + 19>:addq 0x10(%r11),%r10
0x107f6a817< + 23>:cmpq(%r10),%rsi
0x107f6a81a< + 26>:jne 0x107f6a820; 1 + 32取代;
- > 0x107f6a81c< + 28>:jmpq * 0x8(%r10)
再次停顿后的堆栈跟踪:
Foundation`- [NSLocalizableString length]:
0x1071c5cbc< + 0>:pushq%rbp
0x1071c5cbd< + 1>:movq%rsp,%rbp
- > 0x1071c5cc0< + 4>:movq 0x80461(%rip),%rax; NSLocalizableString._developmentLanguageString
0x1071c5cc7< + 11>:movq(%rdi,%rax),%rdi
0x1071c5ccb< + 15>:movq 0x7436e(%rip),%rsi; 长度
0x1071c5cd2< + 22>:popq%rbp
0x1071c5cd3< + 23>:jmpq * 0x8ea77(%rip); (void *)0x0000000107f6a800:objc_msgSend
它只是在这两个较低级别的例程之间来回循环,消耗100%的模拟器CPU。
这是一个字符串本地化问题。 UITableViewCell包含UITextField,其Text属性的值为非空值,未在UITextView的Localization属性中检查英语。
检查英语
修复了问题。
什么痛苦!去图,为什么不能无限循环而不是抛出可理解的错误?
ORIGINAL POST
We have recently converted our app to Swift 2.0, and iOS9. One strange issue I am seeing is that calls to tableView.dequeueReusableCellWithIdentifier() cause the app to hang in the simulator.
The code
func tableView(tableView: UITableView, viewForHeaderInSection section: Int) -> UIView? {
//hangs on the line below
let headersection: HeaderSectionCell = tableView.dequeueReusableCellWithIdentifier("SectionHeader") as! HeaderSectionCell
...
return headersection
}
The header cell
class HeaderSectionCell: UITableViewCell {
@IBOutlet var labelOne: UITextView!
@IBOutlet var labelTwo: UITextView!
@IBOutlet var textView: UITextView!
}
The simulator CPU usage pegs at 100%
After hitting pause in Xcode, it shows me its hanging on this Swift function.
Here are some of the routines where iOS is looping under the covers.
Finally, our Swift call to dequeueReusableCellWithIdentifier()
This particular hanging instance is from the function tableView(tableView: UITableView, viewForHeaderInSection section: Int)
, but we're also hanging inside of a call to tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath)
, with the same issue.
I've tried playing around with the cell properties in storyboard editor, but nothing sticks out as anything different from other views that are working fine.
EDIT
It appears that there is an infinite loop between Foundation and libobjc.A.dylib, underneath that call to dequeReusableCellWithIdentifier(). I ended up making sure Foundation was imported before any other framework, and abstracted the offending UITableViewCell into its own class (was being reused). The original call in question is now working, but there is another one that is still looping under the Swift covers that I am working to figure out.
Hitting pause in the infinite loop puts me in the same assembly stack locations:
Top of stack trace after pause:
libobjc.A.dylib`objc_msgSend:
0x107f6a800 <+0>: testq %rdi, %rdi
0x107f6a803 <+3>: jle 0x107f6a850 ; <+80>
0x107f6a805 <+5>: movq (%rdi), %r11
0x107f6a808 <+8>: movq %rsi, %r10
0x107f6a80b <+11>: andl 0x18(%r11), %r10d
0x107f6a80f <+15>: shlq $0x4, %r10
0x107f6a813 <+19>: addq 0x10(%r11), %r10
0x107f6a817 <+23>: cmpq (%r10), %rsi
0x107f6a81a <+26>: jne 0x107f6a820 ; <+32>
-> 0x107f6a81c <+28>: jmpq *0x8(%r10)
Top of stack trace after another pause:
Foundation`-[NSLocalizableString length]:
0x1071c5cbc <+0>: pushq %rbp
0x1071c5cbd <+1>: movq %rsp, %rbp
-> 0x1071c5cc0 <+4>: movq 0x80461(%rip), %rax ; NSLocalizableString._developmentLanguageString
0x1071c5cc7 <+11>: movq (%rdi,%rax), %rdi
0x1071c5ccb <+15>: movq 0x7436e(%rip), %rsi ; "length"
0x1071c5cd2 <+22>: popq %rbp
0x1071c5cd3 <+23>: jmpq *0x8ea77(%rip) ; (void *)0x0000000107f6a800: objc_msgSend
It's just looping back and forth between these two lower level routines, consuming 100% of the simulator CPU.
It was a String localization issue. The UITableViewCell contained UITextField with a non-empty value for the Text property, that didn't have English checked in the Localization properties of the UITextView.
Checking English
fixed the issue.
What a pain! Go figure, why not infinitely loop instead of throw an intelligible error?
这篇关于tableView.dequeueReusableCellWithIdentifier()导致应用程序挂起的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!