Komponen Runtime Windows dan mengoptimalkan interop

Buat aplikasi Windows yang menggunakan Komponen Runtime Windows dan interop antara jenis asli dan terkelola sambil menghindari masalah performa interop.

Praktik terbaik untuk interoperabilitas dengan Komponen Runtime Windows

Jika Anda tidak berhati-hati, menggunakan Komponen Runtime Windows dapat berdampak besar pada performa aplikasi Anda. Bagian ini membahas cara mendapatkan performa yang baik saat aplikasi Anda menggunakan Komponen Runtime Windows.

Pendahuluan

Interoperabilitas dapat berdampak besar pada performa dan Anda mungkin menggunakannya tanpa menyadari bahwa Anda berada. Windows Runtime menangani banyak interoperabilitas untuk Anda sehingga Anda bisa lebih produktif dan menggunakan kembali kode yang ditulis dalam bahasa lain. Kami mendorong Anda untuk memanfaatkan apa yang dilakukan Windows Runtime untuk Anda, tetapi ketahuilah bahwa itu dapat memengaruhi performa. Bagian ini membahas hal-hal yang dapat Anda lakukan untuk mengurangi dampak yang dimiliki interoperabilitas pada performa aplikasi Anda.

Windows Runtime memiliki pustaka jenis yang dapat diakses dari bahasa apa pun yang dapat menulis aplikasi Platform Windows Universal. Anda menggunakan jenis Windows Runtime di C# atau Microsoft Visual Basic dengan cara yang sama seperti Anda menggunakan objek .NET. Anda tidak perlu melakukan panggilan metode pemanggilan platform untuk mengakses komponen Windows Runtime. Ini membuat penulisan aplikasi Anda jauh lebih kompleks, tetapi penting untuk menyadari bahwa mungkin ada lebih banyak interoperabilitas yang terjadi daripada yang Anda harapkan. Jika komponen Windows Runtime ditulis dalam bahasa selain C# atau Visual Basic, Anda melewati batas interoperabilitas saat Anda menggunakan komponen tersebut. Melintasi batas interoperabilitas dapat memengaruhi performa aplikasi.

Saat Anda mengembangkan aplikasi Platform Windows Universal di C# atau Visual Basic, dua set API paling umum yang Anda gunakan adalah API Runtime Windows dan API .NET untuk aplikasi UWP. Secara umum, jenis yang disediakan oleh Windows yang dibangun pada Windows Runtime di namespace yang dimulai dengan jenis "Windows." dan .NET berada di namespace layanan yang dimulai dengan "Sistem." Namun, ada pengecualian. Jenis di .NET untuk aplikasi UWP tidak memerlukan interoperabilitas saat digunakan. Jika Anda menemukan bahwa Anda memiliki performa buruk di area yang menggunakan Windows Runtime, Anda mungkin dapat menggunakan .NET untuk aplikasi UWP sebagai gantinya untuk mendapatkan performa yang lebih baik.

Perhatikan Sebagian besar komponen Windows Runtime yang dikirim dengan Windows 10 diimplementasikan di C++ sehingga Anda melewati batas interoperabilitas saat Anda menggunakannya dari C# atau Visual Basic. Seperti biasa, pastikan untuk mengukur aplikasi Anda untuk melihat apakah menggunakan komponen Windows Runtime memengaruhi performa aplikasi sebelum berinvestasi dalam membuat perubahan pada kode Anda.

Dalam topik ini, ketika kami menyebutkan "komponen Windows Runtime", kami berarti Komponen Runtime Windows yang ditulis dalam bahasa selain C# atau Visual Basic.

 

Setiap kali Anda mengakses properti atau memanggil metode pada komponen Windows Runtime, biaya interoperabilitas dikeluarkan. Bahkan, membuat komponen Windows Runtime lebih mahal daripada membuat objek .NET. Alasan untuk ini adalah bahwa Windows Runtime harus menjalankan kode yang beralih dari bahasa aplikasi Anda ke bahasa komponen. Selain itu, jika Anda meneruskan data ke komponen, data harus dikonversi antara jenis terkelola dan tidak terkelola.

Menggunakan Komponen Runtime Windows secara efisien

Jika Anda menemukan bahwa Anda perlu mendapatkan performa yang lebih baik, Anda dapat memastikan bahwa kode Anda menggunakan komponen Windows Runtime seefisien mungkin. Bagian ini membahas beberapa tips untuk meningkatkan performa saat Anda menggunakan komponen Windows Runtime.

Dibutuhkan sejumlah besar panggilan dalam waktu singkat agar dampak performa terlihat. Aplikasi yang dirancang dengan baik yang merangkum panggilan ke komponen Windows Runtime dari logika bisnis dan kode terkelola lainnya tidak boleh dikenakan biaya interoperabilitas yang besar. Tetapi jika pengujian Anda menunjukkan bahwa menggunakan komponen Windows Runtime memengaruhi performa aplikasi Anda, tips yang dibahas di bagian ini membantu Anda meningkatkan performa.

Pertimbangkan untuk menggunakan jenis yang disediakan oleh .NET untuk aplikasi UWP

Ada kasus tertentu di mana Anda dapat menyelesaikan tugas dengan menggunakan jenis Windows Runtime atau jenis yang disediakan oleh .NET untuk aplikasi UWP. Adalah ide yang baik untuk mencoba untuk tidak mencampur jenis .NET dan jenis Windows Runtime. Cobalah untuk tinggal di satu atau yang lain. Misalnya, Anda dapat mengurai aliran xml dengan menggunakan jenis Windows.Data.Xml.Dom.XmlDocument (jenis Windows Runtime) atau jenis System.Xml.XmlReader (jenis .NET). Gunakan API yang berasal dari teknologi yang sama dengan aliran. Misalnya, jika Anda membaca xml dari MemoryStream, gunakan jenis System.Xml.XmlReader, karena kedua jenis tersebut adalah jenis .NET. Jika Anda membaca dari file, gunakan jenis Windows.Data.Xml.Dom.XmlDocument karena API file dan XmlDocument keduanya diimplementasikan dalam komponen Windows Runtime asli.

Salin objek Window Runtime ke jenis .NET

Ketika komponen Windows Runtime mengembalikan objek Windows Runtime, mungkin bermanfaat untuk menyalin objek yang dikembalikan ke dalam objek .NET. Dua tempat di mana ini sangat penting adalah ketika Anda bekerja dengan koleksi dan streaming.

Jika Anda memanggil Windows Runtime API yang mengembalikan koleksi dan kemudian Anda menyimpan dan mengakses koleksi tersebut berkali-kali, mungkin bermanfaat untuk menyalin koleksi ke dalam koleksi .NET dan menggunakan versi .NET sejak saat itu.

Cache hasil panggilan ke komponen Windows Runtime untuk digunakan nanti

Anda mungkin bisa mendapatkan performa yang lebih baik dengan menyimpan nilai ke dalam variabel lokal alih-alih mengakses jenis Windows Runtime beberapa kali. Ini bisa sangat bermanfaat jika Anda menggunakan nilai di dalam perulangan. Ukur aplikasi Anda untuk melihat apakah menggunakan variabel lokal meningkatkan performa aplikasi Anda. Menggunakan nilai cache dapat meningkatkan kecepatan aplikasi Anda karena akan menghabiskan lebih sedikit waktu untuk interoperabilitas.

Menggabungkan panggilan ke komponen Windows Runtime

Cobalah untuk menyelesaikan tugas dengan jumlah panggilan terkecil ke objek UWP mungkin. Misalnya, biasanya lebih baik membaca sejumlah besar data dari aliran daripada membaca sejumlah kecil pada satu waktu.

Gunakan API yang berfungsi dalam panggilan seserang mungkin alih-alih API yang melakukan lebih sedikit pekerjaan dan memerlukan lebih banyak panggilan. Misalnya, lebih suka membuat objek dengan memanggil konstruktor yang menginisialisasi beberapa properti sekali alih-alih memanggil konstruktor default dan menetapkan properti satu per satu.

Membangun komponen Windows Runtime

Jika Anda menulis Komponen Runtime Windows yang dapat digunakan oleh aplikasi yang ditulis dalam C++ atau JavaScript, pastikan komponen Anda dirancang untuk performa yang baik. Semua saran untuk mendapatkan performa yang baik dalam aplikasi berlaku untuk mendapatkan performa yang baik dalam komponen. Ukur komponen Anda untuk mengetahui API mana yang memiliki pola lalu lintas tinggi dan untuk area tersebut, pertimbangkan untuk menyediakan API yang memungkinkan pengguna Anda melakukan pekerjaan dengan beberapa panggilan.

Jaga aplikasi Anda tetap cepat saat Anda menggunakan interop dalam kode terkelola

Windows Runtime memudahkan untuk beroperasi antara kode asli dan terkelola, tetapi jika Anda tidak berhati-hati, itu dapat dikenakan biaya performa. Di sini kami menunjukkan kepada Anda cara mendapatkan performa yang baik saat Anda menggunakan interop di aplikasi UWP terkelola Anda.

Widows Runtime memungkinkan pengembang menulis aplikasi menggunakan XAML dengan bahasa pilihan mereka berkat proyeksi WINDOWS Runtime API yang tersedia dalam setiap bahasa. Saat menulis aplikasi di C# atau Visual Basic, kenyamanan ini dikenakan biaya interop karena API Runtime Windows biasanya diimplementasikan dalam kode asli, dan pemanggilan Windows Runtime apa pun dari C# atau Visual Basic mengharuskan transisi CLR dari yang dikelola ke bingkai tumpukan asli dan parameter fungsi marshal ke representasi yang dapat diakses oleh kode asli. Overhead ini dapat diabaikan untuk sebagian besar aplikasi. Tetapi ketika Anda melakukan banyak panggilan (ratusan ribu, hingga jutaan) ke WINDOWS Runtime API di jalur kritis aplikasi, biaya ini bisa menjadi terlihat. Secara umum Anda ingin memastikan bahwa waktu yang dihabiskan dalam transisi antar bahasa relatif kecil terhadap eksekusi sisa kode Anda. Ini diilustrasikan oleh diagram berikut.

Jenis yang tercantum di .NET untuk aplikasi Windows tidak dikenakan biaya interop ini saat digunakan dari C# atau Visual Basic. Sebagai aturan praktis, Anda dapat mengasumsikan jenis tersebut di namespace layanan yang dimulai dengan "Windows." adalah bagian dari set WINDOWS Runtime API yang disediakan oleh Windows, dan jenis di namespace layanan yang dimulai dengan "Sistem." adalah jenis .NET. Perlu diingat bahwa bahkan penggunaan sederhana jenis Windows Runtime menimbulkan biaya interop untuk alokasi atau akses properti.

Anda harus mengukur aplikasi dan menentukan apakah interop mengambil sebagian besar waktu eksekusi aplikasi Anda sebelum mengoptimalkan biaya interop Anda. Saat menganalisis performa aplikasi dengan Visual Studio, Anda dapat dengan mudah mendapatkan batas atas pada biaya interop Anda dengan menggunakan tampilan Functions dan melihat waktu inklusif yang dihabiskan dalam metode yang memanggil ke Windows Runtime.

Jika aplikasi Anda lambat karena overhead interop, Anda dapat meningkatkan performanya dengan mengurangi panggilan ke WINDOWS Runtime API pada jalur kode panas. Misalnya, mesin game yang melakukan banyak perhitungan fisika dengan terus mengkueri posisi dan dimensi UIElements dapat menghemat banyak waktu dengan menyimpan info yang diperlukan dari UIElements ke variabel lokal, melakukan perhitungan pada nilai cache ini, dan menetapkan hasil akhir kembali ke UIElements setelah perhitungan selesai. Contoh lain: jika koleksi sangat diakses oleh kode C# atau Visual Basic, maka lebih efisien untuk menggunakan koleksi dari namespace System.Collections, daripada koleksi dari namespace Windows.Foundation.Collections. Anda juga dapat mempertimbangkan untuk menggabungkan panggilan ke komponen Windows Runtime; salah satu contoh di mana ini dimungkinkan adalah dengan menggunakan API Windows.Storage.BulkAccess.

Membangun komponen UWP

Jika Anda menulis komponen Windows Runtime untuk digunakan dalam aplikasi yang ditulis dalam C++ atau JavaScript, pastikan komponen Anda dirancang untuk performa yang baik. Permukaan API Anda menentukan batas interop Anda dan menentukan tingkat yang harus dipikirkan pengguna Anda tentang panduan dalam topik ini. Jika Anda mendistribusikan komponen Anda ke pihak lain maka ini menjadi sangat penting.

Semua saran untuk mendapatkan performa yang baik dalam aplikasi berlaku untuk mendapatkan performa yang baik dalam komponen. Ukur komponen Anda untuk mengetahui API mana yang memiliki pola lalu lintas tinggi, dan untuk area tersebut, pertimbangkan untuk menyediakan API yang memungkinkan pengguna Anda melakukan pekerjaan dengan beberapa panggilan. Upaya signifikan dimasukkan ke dalam merancang Windows Runtime untuk memungkinkan aplikasi menggunakannya tanpa sering melintasi batas interop.