Tips performa MVVM untuk aplikasi WinUI

Topik ini membahas beberapa pertimbangan performa untuk aplikasi WinUI yang terkait dengan MVVM, pengikatan, dan komposisi tampilan.

Pola Desain Model-View-ViewModel (MVVM)

Pola Model-View-ViewModel (MVVM) umum terjadi di banyak aplikasi WinUI. (MVVM sangat mirip dengan deskripsi Fowler tentang pola Model-View-Presenter, tetapi disesuaikan dengan XAML). Masalah dengan pola MVVM adalah bahwa itu secara tidak sengaja dapat menyebabkan aplikasi yang memiliki terlalu banyak lapisan dan terlalu banyak alokasi. Motivasi untuk MVVM adalah ini.

  • Pemisahan tanggung jawab. Selalu membantu untuk membagi masalah menjadi bagian-bagian yang lebih kecil, dan pola seperti MVVM atau MVC adalah cara untuk membagi aplikasi (atau bahkan satu kontrol) menjadi bagian yang lebih kecil: view yang sebenarnya, model logis dari tampilan (view-model), dan logika aplikasi yang independen dari tampilan (model). Secara khusus, ini adalah alur kerja populer di mana desainer mengendalikan tampilan menggunakan satu alat, pengembang mengendalikan model menggunakan alat lain, dan integrator desain mengendalikan model tampilan menggunakan kedua alat.
  • Pengujian unit. Anda dapat menguji model tampilan (dan akibatnya model) terlepas dari tampilan, sehingga tidak mengandalkan pembuatan jendela, input mengemudi, dan sebagainya. Dengan menjaga tampilan tetap kecil, Anda dapat menguji sebagian besar aplikasi Anda tanpa harus membuat jendela.
  • Ketangkasan terhadap perubahan pengalaman pengguna. Tampilan cenderung melihat perubahan yang paling sering, dan perubahan yang paling terlambat, karena pengalaman pengguna diubah berdasarkan umpan balik pengguna akhir. Dengan memisahkan tampilan, perubahan ini dapat diakomodasi lebih cepat dan hanya memerlukan sedikit penyesuaian pada aplikasi tersebut.

Ada beberapa definisi konkret dari pola MVVM, dan kerangka kerja pihak ke-3 yang membantu mengimplementasikannya. Tetapi kepatuhan yang ketat terhadap variasi pola apa pun dapat menyebabkan aplikasi dengan lebih banyak overhead daripada yang dapat dibenarkan.

  • Pengikatan data XAML (ekstensi markup {Binding}) dirancang sebagian untuk mengaktifkan pola model/tampilan. Tetapi {Binding} membawa set kerja yang tidak sepele dan overhead CPU. Membuat {Binding} menyebabkan serangkaian alokasi, dan memperbarui target pengikatan dapat menyebabkan refleksi dan pengepakan. Di WinUI, masalah ini diatasi dengan ekstensi markup {x:Bind}, yang mengkompilasi pengikatan pada waktu build dan banyak digunakan dalam sampel WinUI dan aplikasi produksi. Rekomendasi: gunakan {x:Bind}.
  • Populer dalam MVVM untuk menghubungkan Button.Click ke model tampilan menggunakan ICommand, seperti pembantu DelegateCommand atau pembantu RelayCommand. Namun, perintah tersebut adalah alokasi tambahan, termasuk pendengar acara CanExecuteChanged, menambah beban kerja, dan menambah waktu startup/navigasi halaman. Rekomendasi: Sebagai alternatif untuk menggunakan antarmuka ICommand yang nyaman, pertimbangkan untuk menempatkan penanganan aktivitas di kode Anda, melampirkannya ke peristiwa tampilan, dan memanggil perintah pada model tampilan Anda saat peristiwa tersebut dinaikkan. Anda juga perlu menambahkan kode tambahan untuk menonaktifkan Tombol saat perintah tidak tersedia.
  • Dalam konteks MVVM, umum untuk membuat Page dengan semua konfigurasi UI yang mungkin, lalu menciutkan bagian pohon dengan mengaitkan properti Visibility dengan properti di VM. Ini menambahkan waktu startup yang tidak perlu dan mungkin untuk set kerja (karena beberapa bagian pohon mungkin tidak pernah terlihat). Rekomendasi: Gunakan fitur atribut x:Load untuk menunda bagian pohon yang tidak perlu dari proses mulai. Selain itu, buat kontrol pengguna terpisah untuk berbagai mode halaman dan gunakan code-behind untuk hanya menyimpan kontrol yang diperlukan yang dimuat.

Konten terkait

  • Last updated on