Berikan tanda tangan fungsi berikut di UICollectionView.

open func performBatchUpdates(_ updates: (() -> Void)?, completion: ((Bool) -> Void)? = nil)

Ada beberapa opsi melalui Internet, penutupan opsional selalu melarikan diri. Tapi, saya benar-benar tidak yakin itu benar, atau ini masih bisa diperdebatkan.

  1. https://forums.swift.org/t/allowing-escaping-for-optional-closure-in-method-signature/27556.27556.
  2. https://gist.github.com/gringoiredm/1f18f3bb4e74e2d914a748d89486db56.

Untuk kasus di atas, apakah kita pernah membutuhkan [weak self], atau [unowned self] di blok 1, dan 2 hitam?

func controllerDidChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) {
    collectionView!.performBatchUpdates({ () -> Void in
        for operation: BlockOperation in self.blockOperations {
            operation.start()
        }
    }, completion: { (finished) -> Void in
        self.blockOperations.removeAll(keepingCapacity: false)

        self.collectionView.reloadData()
    })
}
2
Cheok Yan Cheng 2 April 2021, 20:54

1 menjawab

Jawaban Terbaik

Menurut kompiler (yang memiliki satu-satunya "pendapat" yang penting untuk sesuatu seperti ini), parameter penutupan opsional selalu secara implisit @escaping. Uji ini sendiri dengan menulis fungsi yang mengambil penutupan opsional dan menandai itu sebagai @escaping. Kompiler akan memberi tahu Anda bahwa itu sudah melarikan diri.

Adalah apakah Anda harus menangkap self sebagai weak atau unowned, itu tergantung. Pertama saya akan menjauh dari menangkap self sebagai unowned, kecuali jika Anda ingin program Anda macet jika Anda salah tentang seumur hidup self - dan Anda mungkin. Saya lebih suka program saya crash daripada diam-diam melakukan hal yang salah.

Tapi itu pergi apakah akan menangkap sebagai weak. Pendapat saya adalah ya, jika Anda ragu menangkap referensi yang kuat membuat siklus referensi yang akan mencegahnya dari deinitialisasi yang benar. Tetapi saya tidak akan pergi sejauh mengatakan selalu atau tidak pernah melakukan sesuatu. Jika Anda dapat beralasan tentang waktu hidup objek Anda sehingga Anda tahu penutupan akan dijalankan dan dibuang sebelum objek biasanya harus didefinisialisasi, maka hanya menangkap sebagai referensi yang kuat. Juga menangkap dengan referensi yang kuat jika Anda sengaja ingin memperpanjang usia objek Anda demi penutupan dan Anda tahu bahwa penutupan akan dieksekusi dan dibuang.

Juga ada kasus di mana Anda tahu bahwa meskipun secara implisit @escaping bahwa itu tidak benar-benar melarikan diri. Biasanya itu untuk fungsi yang didefinisikan dalam basis kode Anda sehingga Anda dapat melihat implementasinya, tetapi benar-benar kapan saja penutupan hanya titik kustomisasi untuk pekerjaan yang harus dilakukan sebelum fungsi yang Anda panggil kembali, Anda dapat menyimpulkannya. tidak benar-benar melarikan diri. Itu tidak terjadi pada penangan penyelesaian, tetapi mungkin untuk hal-hal lain.

Itu pendapat saya. Saya suka berpikir itu yang terinformasi, tetapi yang lain mungkin tidak setuju.

4
Chip Jarred 2 April 2021, 21:27