在Swift 3中，脱队列可重用单元的速度非常慢

Question

去队列一个单元格需要0.5秒-1.0秒，这意味着我的UITableView需要超过2-3个完整的秒来加载，即使它只有4行。

override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    var cellid = "NumberCell"
    var isnumber = true
    if indexPath.row == 0 {
        cellid = "TextCell"
        isnumber = false
    }
    
    NSLog("before dequeue \(indexPath)")
    let cell = tableView.dequeueReusableCell(withIdentifier: cellid, for: indexPath) as! TextfieldTableViewCell
    NSLog("dequeued")
    
    // ...
    
    return cell
}

NSLog()语句在前面和后面直接显示了从07.47到08.38的去队列。

2017-07-25 22:07:07.471898-0700 myapp10209:4507471 2017-07-25 22:07:07.679715-0700 myapp10209:4507471 systemgroup.com.apple.configurationprofiles路径系统组容器为systemgroup.com.apple.configurationprofiles路径 2017-07-25 22:07:07.683843-0700 myapp10209:4507471来自公共有效用户设置的阅读。 2017-07-25 22:07:08.386960-0700 myapp10209:4507471

这个细胞很简单。它只有一个UILabel和一个UITextField，而UITextField有一个编辑更改的操作。就这样。

​

​

究竟是什么原因导致细胞排队这么长时间？是关于系统组容器的另外两个系统NSLog()吗？

这使得我的应用程序几乎无法使用，因为当我试图对此视图控制器进行检索时，应用程序在设置4行时似乎锁定了2-4秒。

我在Objective中制作了数百个UITableViewControllers，而且我从来没有遇到过这个问题。斯威夫特3有什么奇怪的地方吗？

Answer 1

2017-07-25 22:07:07.679715-0700 myapp10209:4507471 systemgroup.com.apple.configurationprofiles路径系统组容器为systemgroup.com.apple.configurationprofiles路径 2017-07-25 22:07:07.683843-0700 myapp10209:4507471来自公共有效用户设置的阅读。

这是OS Level的日志。在您的UITableCell去排队时，哪个延迟？

您可以在xcode中禁用不必要的日志。就像下面

打开Xcode菜单：Product > Scheme > Edit Scheme

2-在值集OS_ACTIVITY_MODE中设置disable的环境变量集

​

​

只有在调试应用程序时，您才会面临这个问题。这将在真正的设备上运行良好。

Answer 2

我终于解决了这个问题，这完全是我的错。我不小心要求每个领域的急救人员。

为了方便起见，我已经重写了setSelected(_:animated:)，以便如果我触摸该行的textfield将成为第一个响应程序(以防我试图点击某个字段而错过)。问题是我忘了在becomeFirstResponder()调用周围放一个if语句。

坏代码：

override func setSelected(_ selected: Bool, animated: Bool) {
    super.setSelected(selected, animated: animated)

    self.textfield.becomeFirstResponder()
}

去排队后，默认情况下，它会将其设置为selected=false，这将导致它尝试成为第一个响应程序。对我来说这是个愚蠢的错误。

我打算这样做：

override func setSelected(_ selected: Bool, animated: Bool) {
    super.setSelected(selected, animated: animated)

    if selected {
        self.textfield.becomeFirstResponder()
    }
}

Answer 3

我不认为这段代码有任何问题。我认为dequeue代码不会持续这么长时间，除非您忽略了代码中的一些重要问题。如果您的表视图如您所说的那样简单，那就不会花那么长时间了。但是要调试这一点，您必须考虑以下几点：

• NSLog不是检查dequeue持续时间的可靠计时器。您应该使用下面的代码来准确计算时间： 让开始= CACurrentMediaTime() 设单元格= tableView.dequeueReusableCell(withIdentifier: cellid，for: indexPath) as！TextfieldTableViewCell 设finish = CACurrentMediaTime() 打印(“排队时间：(完成-开始)”)
• 如果dequeue时间是可接受的，则性能问题不是由它引起的。
• 如果dequeue时间仍然不可接受的话。原因之一是您只有四行表视图，而且没有一行比表视图高，所以tableview将不使用缓冲区中的单元格，而是从下向上创建单元格。这个操作比使用缓冲区中的单元要耗时得多。但是这个过程是不可避免的，因为每个使用tableview的应用程序都会遇到它。因此，您应该考虑您的模拟器(假设您正在使用模拟器)是否太慢，无法运行您的应用程序。因为模拟器和真实iPhone之间的速度有很大的不同。