Seri Pengoptimalan Kinerja iOS 03｜Masalah Umum dengan Gagap Daftar iOS

Keterlambatan daftar adalah masalah kinerja yang paling umum dan paling mudah salah menilai dalam proyek iOS.

Begitu saya melihat situasi ini dan daftarnya tidak berjalan mulus, saya akan langsung berkata:

• Apakah SwiftUI List terlalu lambat?
• Apakah UICollectionView salah dikonfigurasi?
• Apakah kendali ini pada dasarnya macet?

Penilaian ini terkadang tidak sepenuhnya salah, namun seringkali dangkal. Pertanyaan sebenarnya yang lebih sentral biasanya adalah:

Dalam pengguliran, tindakan yang sangat bergantung pada respons tepat waktu dari thread utama, berapa banyak pekerjaan tambahan yang dilakukan sistem pada saat yang sama?

Oleh karena itu, meskipun UITableView, UICollectionView, dan SwiftUI List diimplementasikan dengan cara yang berbeda, sering kali keduanya mengalami masalah yang sangat mirip.

1. Daftar lebih cenderung mengungkap masalah kinerja dibandingkan banyak halaman.

Karena daftarnya adalah adegan berfrekuensi tinggi dan berkesinambungan yang sensitif terhadap setiap frame.

Saat pengguna menggulir, sistem perlu terus menyelesaikan hal-hal berikut:

• Hitung tata letak
• Siapkan unit yang terlihat
• Unit penggunaan kembali dan daur ulang
• menggambar konten
• Merespon isyarat

Jika thread utama juga diminta untuk melakukan banyak pekerjaan tambahan secara bersamaan, seperti:

• Penguraian gambar
• Perakitan teks kaya
• Penguraian JSON
• Perhitungan Tata Letak Otomatis berbiaya tinggi
• Perubahan status yang sering menyebabkan penyegaran penuh

Kelambatan ini hampir merupakan akibat yang tidak bisa dihindari.

Alasan mengapa daftar ini begitu populer adalah karena tampaknya misterius di permukaan, namun sebenarnya lebih dekat ke sana, yang memperkuat tekanan pada thread utama dengan sangat jelas.

2. Masalah paling umum adalah Anda melakukan sesuatu yang tidak boleh Anda lakukan saat ini saat menggulir.

Pendekatan umum saat mengoptimalkan adalah dengan hanya fokus pada panjang kode sel saat mengoptimalkan daftar. Namun dalam proyek nyata, alasan kartu daftar seringkali lebih seperti berikut:

• Gambar tidak diterjemahkan sampai ditampilkan
• Tinggi teks dihitung berulang kali selama pengguliran
• sel diformat ulang dan data dikonversi setiap kali muncul.
• Terlalu banyak pembaruan status lapisan induk yang dipicu saat menggulir daftar
• Perubahan kecil menyebabkan seluruh daftar digambar ulang atau perbedaannya menjadi terlalu mahal

Ciri-ciri umum dari permasalahan ini adalah: Hal tersebut dimaksudkan untuk menjadi “tidak boleh dilakukan pada saat pengguliran ini”.

Jadi ide terpenting untuk pengoptimalan daftar adalah:

• Tugas apa yang bisa diselesaikan sebelumnya?
• Pekerjaan mana yang dapat di-cache
• Tugas apa yang bisa ditunda
• Pembaruan mana yang dapat dilokalkan

3. Gambar sering kali menjadi penyebab kelambatan daftar. Di permukaan, mereka terlihat seperti unduhan, namun sebenarnya lebih dekat dengan decoding dan pemrosesan ukuran.

Banyak tim mengatakan “terlalu banyak gambar” ketika mereka menemukan kartu daftar. Terkadang arah kalimat ini benar, namun alasannya seringkali salah.

Yang sering memperlambat pengguliran adalah:

• Penguraian gambar
• Pembesaran gambar
• Ukuran pemuatan tidak sesuai
• Sering memicu pemrosesan gambar di thread utama

Meskipun demikian, hal yang paling menakutkan tentang masalah grafis adalah ia dapat dengan mudah memasukkan pekerjaan yang mahal ke jalur kritis sebuah roll.

Oleh karena itu, inti dari optimasi gambar dalam daftar biasanya bukan hanya caching, tetapi:

• Siapkan ukuran yang sesuai terlebih dahulu
• Kurangi tekanan decoding pada saat tampilan
• Hindari pemrosesan gambar yang berat saat menggulir

4. Pemrosesan data sering kali secara diam-diam menurunkan pengalaman pengguliran.

Ini lebih umum daripada yang diperkirakan.

Misalnya, item daftar perlu ditampilkan:

• Pemformatan waktu
• Pemformatan jumlah
• Kombinasi teks kaya
• Pemetaan tag
• Copywriting status yang kompleks

Jika hal ini dilakukan sementara selama fase konfigurasi sel, thread utama akan terus memakan biaya ini selama pengguliran.

Bagian yang paling menyusahkan dari masalah jenis ini adalah:

• Secara fungsional sepenuhnya benar
• Biaya tunggal tampaknya tidak berlebihan
• Namun dalam pengguliran frekuensi tinggi, itu akan diperbesar secara eksponensial

Oleh karena itu, prinsip yang sangat penting untuk pengoptimalan kinerja daftar adalah: **Biarkan lapisan tampilan mencoba menggunakan data tampilan yang telah disiapkan alih-alih melakukan banyak konversi saat menggulir. **

5. Jika metode pembaruan status salah, daftar akan macet dan sering disalahartikan sebagai masalah tata letak.

Beberapa masalah daftar sama sekali tidak rumit karena selnya, tetapi juga karena granularitas pembaruan status yang terlalu kasar.

Misalnya:

• Refresh seluruh daftar segera setelah kata kunci pencarian berubah
• Menyukai item dan seluruh pohon status halaman dibangun kembali
• Hasil paginasi muncul dan seluruh daftar dihitung ulang

Jenis masalah ini mudah salah didiagnosis sebagai:

• Komponen UI terlalu lambat
• Sistem tata letak tidak efisien

Faktanya, masalah sebenarnya sering kali adalah:

**Perubahan bisnis kecil memicu pembaruan UI yang jauh lebih besar dari yang diperlukan. **

Jadi ketika daftar pemecahan masalah tertinggal, satu hal yang sering saya tanyakan adalah:

Item mana saja yang terkena dampak perubahan status ini? Mengapa pada akhirnya hal itu mempengaruhi area yang begitu luas?

6. Apa masalah umum pada UITableView, UICollectionView, dan SwiftUI List?

Meskipun rincian implementasi ketiga sistem ini sangat berbeda, masalah kinerja frekuensi tinggi sebenarnya sangat mirip:

• melakukan terlalu banyak pekerjaan thread utama selama pengguliran
• Item daftar menunjukkan bahwa data terlambat disiapkan
• Pengolahan gambar dan teks ditempatkan pada jalur kritis
• Perincian penyegaran terlalu besar
• Tata letak atau hierarki tampilan tertentu terlalu rumit

Dengan kata lain, masalah umum mereka bukanlah:

**Bentuk interaktif dari daftar itu sendiri sangat sensitif terhadap waktu thread utama dan alokasi pekerjaan. **

Oleh karena itu, desain salah yang sama dapat menyebabkan kemacetan serupa di tiga kontrol daftar berbeda.

7. Urutan pemecahan masalah yang mendekati pertarungan sebenarnya

Jika saya ingin mengecek masalah list lag hari ini, biasanya saya tidak akan mengubah kodenya terlebih dahulu, tetapi menilai terlebih dahulu dengan urutan sebagai berikut:

1. Gagap terjadi saat layar pertama muncul, saat menggulir dengan cepat, atau saat terjadi penomoran halaman.
2. Apakah item daftar saat ini memiliki gambar, teks kaya, atau tata letak yang rumit.
3. Apakah banyak konversi real-time dilakukan sebelum sel ditampilkan.
4. Apakah perubahan negara bagian tertentu memicu penyegaran dalam skala besar.
5. Apakah ada decoding, penskalaan, atau penghitungan ulang yang disinkronkan selama pengguliran.

Nilai dari barisan ini adalah: Pertama-tama cari tahu “pekerjaan apa yang menempati thread utama dengan scrolling” daripada menebak-nebak masalah kerangkanya terlebih dahulu.

8. Kesimpulan: Inti dari list lag biasanya adalah terlalu banyak pekerjaan yang dimasukkan ke jalur kritis yang tidak seharusnya diisi.

Singkatnya, saya akan mengatakan:

Daftarnya macet, dan intinya biasanya bergulir. Dalam skenario frekuensi tinggi ini, thread utama membawa terlalu banyak tata letak, decoding, konversi, dan biaya penyegaran yang berlebihan pada saat yang bersamaan.

Jadi hal terpenting untuk optimasi daftar adalah:

• Letakkan pekerjaan terlebih dahulu
• Simpan hasilnya dalam cache
• Mengurangi granularitas penyegaran
• Hilangkan beban ekstra dari jalur kritis

Jika Anda melakukan empat hal ini dengan benar, pengalaman daftar biasanya akan lebih stabil daripada sekadar menyesuaikan beberapa parameter.