tableView.dequeueReusableCellWithIdentifier()导致应用程序挂起 [英] tableView.dequeueReusableCellWithIdentifier() causes app to hang

查看:106
本文介绍了tableView.dequeueReusableCellWithIdentifier()导致应用程序挂起的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

原始帖子



我们最近将应用转换为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),%r​​11
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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆