MVVM dan tips performa bahasa

Topik ini membahas beberapa pertimbangan performa yang terkait dengan pola desain perangkat lunak pilihan Anda, dan bahasa pemrograman.

Pola Model-View-ViewModel (MVVM)

Pola Model-View-ViewModel (MVVM) umum terjadi di banyak aplikasi XAML. (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 masalah. Selalu membantu untuk membagi masalah menjadi potongan-potongan yang lebih kecil, dan pola seperti MVVM atau MVC adalah cara untuk membagi aplikasi (atau bahkan satu kontrol) menjadi bagian yang lebih kecil: tampilan aktual, model logis tampilan (model tampilan), dan logika aplikasi yang independen tampilan (model). Secara khusus, ini adalah alur kerja populer untuk memiliki tampilan desainer menggunakan satu alat, pengembang memiliki model menggunakan alat lain, dan integrator desain memiliki 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.
• Kelincahan 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 dengan lebih sedikit churn ke aplikasi.

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 pantulan dan tinju. Masalah ini sedang diatasi dengan ekstensi markup {x:Bind}, yang mengkompilasi pengikatan pada waktu build. Rekomendasi: gunakan {x:Bind}.
• Ini populer di MVVM untuk menyambungkan Button.Klik ke model tampilan menggunakan ICommand, seperti pembantu DelegateCommand atau RelayCommand umum. Namun, perintah tersebut adalah alokasi tambahan, termasuk pendengar peristiwa CanExecuteChanged, menambahkan ke set kerja, dan menambahkan ke waktu startup/navigasi untuk halaman. Rekomendasi: Sebagai alternatif untuk menggunakan antarmuka ICommand yang nyaman, pertimbangkan untuk menempatkan penanganan aktivitas di kode Anda dan 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.
• Ini populer di MVVM untuk membuat Halaman dengan semua konfigurasi UI yang mungkin, lalu menciutkan bagian pohon dengan mengikat properti Visibilitas ke 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 atribut x:Load atau fitur atribut x:DeferLoadStrategy untuk menunda bagian pohon yang tidak perlu dari startup. Selain itu, buat kontrol pengguna terpisah untuk berbagai mode halaman dan gunakan code-behind untuk hanya menyimpan kontrol yang diperlukan yang dimuat.

Rekomendasi C++/CX

• Gunakan versi terbaru. Ada peningkatan performa berkelanjutan yang dilakukan pada pengkompilasi C++/CX. Pastikan aplikasi Anda sedang membangun menggunakan toolset terbaru.
• Nonaktifkan RTTI (/GR-). RTTI aktif secara default di pengkompilasi sehingga, kecuali lingkungan build Anda mematikannya, Anda mungkin menggunakannya. RTTI memiliki overhead yang signifikan, dan kecuali kode Anda memiliki dependensi mendalam padanya, Anda harus mematikannya. Kerangka kerja XAML tidak memiliki persyaratan bahwa kode Anda menggunakan RTTI.
• Hindari penggunaan ppltasks yang berat. Ppltasks sangat nyaman saat memanggil API WinRT asinkron, tetapi dilengkapi dengan overhead ukuran kode yang signifikan. Tim C++/CX sedang mengerjakan fitur bahasa – tunggu – yang akan memberikan performa yang jauh lebih baik. Sementara itu, seimbangkan penggunaan ppltasks Anda di jalur panas kode Anda.
• Hindari penggunaan C++/CX di "logika bisnis" aplikasi Anda. C++/CX dirancang untuk menjadi cara mudah untuk mengakses API WinRT dari aplikasi C++. Ini menggunakan pembungkus yang memiliki overhead. Anda harus menghindari C++/CX di dalam logika/model bisnis kelas Anda, dan memesannya untuk digunakan pada batas antara kode Anda dan WinRT.