Swift 3で再利用可能なセルをデキューするのが非常に遅い

Question

セルをデキューすると0.5〜1.0秒かかります。つまり、私のUITableViewは4行しかなくてもロードに2-3秒以上かかることを意味します。

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 
} 

デキューが08.38へ07.47から取る直接ショーの前と後のNSLog（）文。

2017年7月25日22：07：07.471898から0700のMyApp [10209：4507471]デキュー前に[0,0]

2017年7月25日22：07：07.679715から0700のMyApp [10209 ：4507471] [MC] systemgroup.com.apple.configurationprofilesのシステムグループコンテナのパスは/private/var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles

2017-07-25 22:07： 07.683843-0700 myapp [10209：4507471] [MC]実効的なユーザー設定を読む。

2017年7月25日22：07：08.386960から0700のMyApp [10209：4507471]は細胞が非常に簡単である

をデキュー。これにはUILabelとUITextFieldだけがあり、UITextFieldにはEditing Changedというアクションがあります。それでおしまい。一体、おそらくそれは、セルをデキューSO長く取るさせることができるもの

？システムグループコンテナに関する他の2つのシステムNSLog（）ですか？

このビューコントローラにセグをしようとすると、アプリケーションが4行を設定している間にアプリケーションが2〜4秒間ロックアップするように見えるため、私のアプリケーションはほとんど使用できなくなります。

Objective-Cで何百ものUITableViewControllerを作成しましたが、この問題は一度もありませんでした。スウィフト3について何か不思議なことがありますか？

Answer 1

2017年7月25日22：07：07.679715から0700のMyApp [10209：4507471] [MC]システムグループ systemgroup.com.apple.configurationprofilesパスのコンテナである /民間の/ var /コンテナ/共有/システムグループ/システムグループ.apple.configurationprofiles

2017-07-25 22：07：07.683843-0700 myapp [10209：4507471] [MC] 有効なユーザー設定。

⚠️これはログです。OS Levelです。あなたのデキューを遅らせるものUITableCell

xcodeの不要なログを無効にすることができます。 Xcodeのメニューオープンから

の1-以下のように：あなたの環境変数のProduct > Scheme > Edit Scheme

2 - 値にOS_ACTIVITY_MODEを設定disable

を設定あなたがデバッグしているときにのみ、この問題に直面するだろうアプリ 。 これは実際のデバイスで正常に動作します。

Answer 2

私はこのコードに問題はないと思います。そして、あなたがコードにいくつかの重要な問題を見落とさない限り、dequeueコードが本当に長く続くとは思わない。あなたのテーブルビューがあなたが言ったようにシンプルであれば、それほど時間がかかりません。しかし、あなたはこれらの点を考慮しなければならない、ということをデバッグします

• のNSLogはdequeueの時間をチェックするための信頼できるタイマーではありません。あなたは正確に時間を計算するために、次のコードを使用する必要がありますよう（indexPath：セルID、用withIdentifier）

  = CACurrentMediaTimeを（）
  は聞かせてセル= tableView.dequeueReusableCell始めましょう！ dequeue時間が許容される場合は、あなたのパフォーマンスの問題は、それが原因ではない

• - ：TextfieldTableViewCell
  はフィニッシュ= CACurrentMediaTime（）
  プリント（ "スタート）（終了デキュー時間"）をしましょう。

• dequeue時間がまだ許容できない場合。 1つの理由は、テーブルビューの行が4つしかなく、テーブルビューの方が上位のものがないことです。テーブルビューはバッファからセルを使用するのではなく、下から上にセルを作成します。そして、この操作は、バッファからのセルを使用するよりはるかに時間がかかります。しかし、このプロセスは避けられません。なぜなら、テーブルビューを使用するすべてのアプリケーションがそれに遭遇するからです。したがって、シミュレータ（シミュレータを使用していると仮定）がアプリを実行するには遅すぎるかどうかを検討する必要があります。シミュレータと実際のiPhoneとの間の速度がかなり異なるためです。

Answer 3

私はついにこの問題を見つけ出し、それはまったく私のせいでした。私は間違ってすべてのフィールドで最初のレスポンダーをリクエストしていました。

便宜上、setSelected(_:animated:)をオーバーライドしています。そのため、行のテキストフィールドが最初のレスポンダになる行が表示されるようになりました（フィールドをタップして見逃した場合）。問題は、becomeFirstResponder()コールの周りにifステートメントを置くのを忘れていたことでした。

悪いコード：

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

    self.textfield.becomeFirstResponder() 
} 

それがファーストレスポンダになることをしようとしてしまい、それがデフォルトで選択= falseに設定しますセルをデキューした後。それは私のところでは間違ったミスでした。

ここで私はやって意図したものです：

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

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