Seri SwiftUI 09｜Pengantar Animasi SwiftUI: Penggunaan animasi dan withAnimation

Animasi SwiftUI kemungkinan besar memberikan perasaan yang “tampaknya sederhana” kepada orang-orang:

• Tambahkan .animation
• Atau bungkus withAnimation

Halaman mulai bergerak.

Namun dalam proyek nyata, masalah paling umum dengan animasi justru ada di sini:

• Ini juga pindah ke sini.
• Benda-benda berpindah ke tempat yang seharusnya tidak dipindahkan.
• Tidak ada animasi untuk perubahan keadaan tertentu
• Animasinya menjadi sangat aneh ketika daftar disegarkan

Ini menunjukkan bahwa sering kali kita tidak mengetahuinya terlebih dahulu:

Haruskah animasi ini dilampirkan pada perubahan status tertentu, atau hanya mengakhiri proses perubahan tertentu?

1. Inti dari animasi SwiftUI adalah “membiarkan perubahan status diinterpolasi dan disajikan”

Hal ini sangat penting.

Jika Anda masih menggunakan ide UIKit untuk memahami animasi, secara default mudah untuk:

• Saya ingin melakukan gerakan kontrol tertentu

SwiftUI lebih suka melakukan:

• Saat keadaan berubah dari A ke B, gunakan animasi untuk mengekspresikan proses perubahan

Artinya, animasi secara alami bergantung pada perubahan keadaan. Jadi yang benar-benar perlu dinilai adalah:

• Perubahan negara bagian manakah yang layak untuk dianimasikan?
• Seberapa besar cakupan animasinya?

2. Perbedaan antara .animation dan withAnimation bukan hanya pada metode penulisannya, tetapi granularitas kontrolnya.

Pemahaman yang lebih praktis adalah:

• .animation lebih seperti melampirkan animasi pada jenis perubahan keadaan tertentu.
• withAnimation lebih seperti membungkus modifikasi keadaan tertentu secara eksplisit

Jadi saat menggunakan .animation, lebih seperti mengatakan:

Tampilan ini harus memiliki reaksi animasi secara default untuk perubahan keadaan tertentu.

Dan withAnimation lebih seperti mengatakan:

Saya akan mengubah keadaan ini sekarang, dan saya ingin perubahan ini dianimasikan.

Perbedaan ini sangat penting karena secara langsung mempengaruhi pengendalian animasi.

3. Banyak animasi halaman akan “bergerak bersamaan tanpa bisa dijelaskan”

Alasan paling umum adalah cakupan tindakan yang tidak tertutup.

Misalnya, saya awalnya hanya ingin blok yang diperluas untuk dianimasikan, tetapi hasilnya adalah:

• Teks lain pada lapisan yang sama juga bergerak sesuai
• Perubahan ketinggian wadah induk menyebabkan seluruh area dianimasikan
• Beberapa tata letak yang tidak relevan juga mulai bertransisi

Hal ini biasanya terjadi ketika animasi dilampirkan pada perubahan status atau hierarki tampilan yang terlalu besar.

Jadi ketika animasinya kacau, yang paling sering saya periksa kembali adalah:

• Perubahan apa yang saat ini menjadi tanggung jawab lapisan ini?
• Apakah animasi terkait dengan tampilan yang terlalu besar?
• Apakah perubahan status mempengaruhi terlalu banyak hasil tata letak secara bersamaan?

4. Banyak “animasi yang tidak bagus” karena pemodelan keadaannya tidak jelas.

Beberapa animasi terlihat janggal dan adalah:

• Negara itu sendiri tidak dirancang dengan jelas
• Satu perubahan mengubah terlalu banyak nilai secara bersamaan
• Tingkat tata letak halaman tidak stabil

Misalnya, sebuah klik terpicu secara bersamaan:

• Perluas
• Peralihan copywriting
• Ketinggian berubah
• Penataan ulang daftar

Hal ini akhirnya terlihat berantakan, sering kali dengan terlalu banyak perubahan semantik yang berbeda dimasukkan ke dalam transisi keadaan yang sama.

5. Kapan lebih cocok menggunakan withAnimation

Saya lebih suka menggunakannya dalam skenario berikut:

• Tindakan pengguna memicu peralihan status eksplisit
• Aku hanya ingin perubahan keadaan dianimasikan kali ini
• Saya ingin mengontrol secara eksplisit “apakah perubahan ini harus dipindahkan atau tidak”

Misalnya:

• Perluas / Tutup
• Memasukkan/menghapus sebagian blok
• Ganti status presentasi tertentu setelah mengklik

Keuntungannya adalah semantiknya lebih jelas: Ketahuilah bahwa animasi terikat langsung dengan tindakan ini.

6. Kapan .animation mungkin lebih berbahaya?

.animation sangat mudah menyebabkan halaman “bergerak sedikit ke mana-mana” ketika cakupan pengaruh status tidak dipikirkan dengan jelas terlebih dahulu.

Terutama dalam tata letak yang kompleks, jika perubahan keadaan mempengaruhi:

• Dimensi
• Penyelarasan
• penulisan salinan
• Hirarki kontainer

Menggantung animasi langsung di atasnya dapat dengan mudah menyebabkan seluruh area bertransisi.

Jadi .animation lebih cocok untuk:

• Cakupan pengaruhnya relatif jelas
• Semantik sederhana dari perubahan keadaan
• Stabilitas wilayah setempat

adegan.

7. Penilaian yang lebih praktis: Apakah animasi ini mengekspresikan “suatu tindakan” atau memodifikasi “suatu jenis perubahan” secara default?

Jika Anda menyatakan tindakan eksplisit:

• Klik untuk membuka
• tutup
• Sisipkan
• Hapus

Lalu saya biasanya mempertimbangkan withAnimation terlebih dahulu.

Jika Anda memodifikasi perubahan keadaan lokal yang stabil, lebih mudah untuk mempertimbangkan .animation.

Penilaian ini sangat berguna karena memungkinkan Anda untuk tidak hanya fokus pada nama API, tetapi juga benar-benar kembali ke “semantik animasi” itu sendiri.

8. Kesimpulan: Yang benar-benar perlu dibedakan dalam animasi SwiftUI adalah batas perubahan keadaan dan batas efek animasi.

Singkatnya, saya akan mengatakan:

Hal terpenting tentang animasi SwiftUI adalah membedakannya terlebih dahulu: apakah animasi ini mengekspresikan tindakan tertentu, atau menambahkan efek transisi ke beberapa jenis perubahan keadaan lokal.

Ketika kedua batasan ini jelas, animasi akan lebih terkendali; Jika batasannya tidak jelas, halaman tersebut dapat dengan mudah menjadi “bergerak ke mana-mana, tetapi tidak ada satu tempat pun yang bergerak ke kanan”.