Bagikan melalui

Waktu Mulai Aplikasi

  • Artikel

Jumlah waktu yang diperlukan untuk memulai aplikasi WPF dapat sangat bervariasi. Topik ini menjelaskan berbagai teknik untuk mengurangi waktu mulai yang dirasakan dan aktual untuk aplikasi Windows Presentation Foundation (WPF).

Memahami Startup Dingin dan Startup Hangat

Startup dingin terjadi ketika aplikasi Anda dimulai untuk pertama kalinya setelah reboot sistem, atau ketika Anda memulai aplikasi Anda, menutupnya, dan kemudian memulainya lagi setelah jangka waktu yang lama. Ketika aplikasi dimulai, jika halaman yang diperlukan (kode, data statis, registri, dll) tidak ada dalam daftar siaga manajer memori Windows, kesalahan halaman terjadi. Akses disk diperlukan untuk membawa halaman ke dalam memori.

Startup hangat terjadi ketika sebagian besar halaman untuk komponen runtime bahasa umum (CLR) utama sudah dimuat dalam memori, yang menghemat waktu akses disk yang mahal. Itulah sebabnya aplikasi terkelola dimulai lebih cepat ketika berjalan untuk kedua kalinya.

Menerapkan Layar Splash

Dalam kasus di mana ada penundaan yang signifikan dan tidak dapat dihindari antara memulai aplikasi dan menampilkan UI pertama, optimalkan waktu startup yang dirasakan dengan menggunakan layar percikan. Pendekatan ini menampilkan gambar segera setelah pengguna memulai aplikasi. Ketika aplikasi siap untuk menampilkan UI pertamanya, layar splash memudar. Mulai dari .NET Framework 3.5 SP1, Anda dapat menggunakan SplashScreen kelas untuk mengimplementasikan layar percikan. Untuk informasi selengkapnya, lihat Menambahkan Layar Splash ke Aplikasi WPF.

Anda juga dapat mengimplementasikan layar splash Anda sendiri dengan menggunakan grafis Win32 asli. Tampilkan implementasi Anda sebelum Run metode dipanggil.

Menganalisis Kode Startup

Tentukan alasan startup dingin yang lambat. I/O Disk mungkin bertanggung jawab, tetapi ini tidak selalu terjadi. Secara umum, Anda harus meminimalkan penggunaan sumber daya eksternal, seperti jaringan, layanan Web, atau disk.

Sebelum Anda menguji, verifikasi bahwa tidak ada aplikasi atau layanan lain yang berjalan menggunakan kode terkelola atau kode WPF.

Mulai aplikasi WPF Anda segera setelah boot ulang, dan tentukan berapa lama waktu yang diperlukan untuk ditampilkan. Jika semua peluncuran aplikasi Anda berikutnya (startup hangat) jauh lebih cepat, masalah startup dingin Anda kemungkinan besar disebabkan oleh I/O.

Jika masalah startup dingin aplikasi Anda tidak terkait dengan I/O, kemungkinan aplikasi Anda melakukan beberapa inisialisasi atau komputasi yang panjang, menunggu beberapa peristiwa selesai, atau memerlukan banyak kompilasi JIT saat startup. Bagian berikut menjelaskan beberapa situasi ini secara lebih rinci.

Optimalkan Pemuatan Modul

Gunakan alat seperti Process Explorer (Procexp.exe) dan Tlist.exe untuk menentukan modul mana yang dimuat aplikasi Anda. Perintah Tlist <pid> menunjukkan semua modul yang dimuat oleh proses.

Misalnya, jika Anda tidak terhubung ke Web dan Anda melihat bahwa System.Web.dll dimuat, maka ada modul dalam aplikasi Anda yang mereferensikan rakitan ini. Periksa untuk memastikan bahwa referensi diperlukan.

Jika aplikasi Anda memiliki beberapa modul, gabungkan ke dalam satu modul. Pendekatan ini membutuhkan lebih sedikit overhead pemuatan rakitan CLR. Lebih sedikit rakitan juga berarti bahwa CLR mempertahankan lebih sedikit status.

Tangguhkan Operasi Inisialisasi

Pertimbangkan untuk menunda kode inisialisasi hingga setelah jendela aplikasi utama dirender.

Ketahuilah bahwa inisialisasi dapat dilakukan di dalam konstruktor kelas, dan jika kode inisialisasi mereferensikan kelas lain, itu dapat menyebabkan efek bertingkat di mana banyak konstruktor kelas dijalankan.

Hindari Konfigurasi Aplikasi

Pertimbangkan untuk menghindari konfigurasi aplikasi. Misalnya, jika aplikasi memiliki persyaratan konfigurasi sederhana dan memiliki tujuan waktu mulai yang ketat, entri registri, atau file INI sederhana mungkin merupakan alternatif startup yang lebih cepat.

Menggunakan GAC

Jika assembly tidak diinstal di Global Assembly Cache (GAC), ada keterlambatan yang disebabkan oleh verifikasi hash rakitan bernama kuat dan oleh validasi gambar Ngen jika gambar asli untuk rakitan tersebut tersedia di komputer. Verifikasi nama kuat dilewati untuk semua rakitan yang diinstal di GAC. Untuk informasi selengkapnya, lihat Gacutil.exe (Alat Singgahan Perakitan Global).

Gunakan Ngen.exe

Pertimbangkan untuk menggunakan Native Image Generator (Ngen.exe) pada aplikasi Anda. Menggunakan Ngen.exe berarti memperdagangkan konsumsi CPU untuk lebih banyak akses disk karena gambar asli yang dihasilkan oleh Ngen.exe kemungkinan lebih besar dari gambar MSIL.

Untuk meningkatkan waktu startup hangat, Anda harus selalu menggunakan Ngen.exe pada aplikasi Anda, karena ini menghindari biaya CPU kompilasi JIT dari kode aplikasi.

Dalam beberapa skenario startup dingin, menggunakan Ngen.exe juga dapat membantu. Ini karena pengkompilasi JIT (mscorjit.dll) tidak harus dimuat.

Memiliki modul Ngen dan JIT dapat memiliki efek terburuk. Ini karena mscorjit.dll harus dimuat, dan ketika pengkompilasi JIT berfungsi pada kode Anda, banyak halaman dalam gambar Ngen harus diakses ketika pengkompilasi JIT membaca metadata rakitan.

Ngen dan ClickOnce

Cara Anda berencana untuk menyebarkan aplikasi juga dapat membuat perbedaan dalam waktu muat. Penyebaran aplikasi ClickOnce tidak mendukung Ngen. Jika Anda memutuskan untuk menggunakan Ngen.exe untuk aplikasi Anda, Anda harus menggunakan mekanisme penyebaran lain, seperti Penginstal Windows.

Untuk informasi lebih lanjut, lihat Ngen.exe (Generator Gambar Asli).

Tabrakan Alamat Rebasing dan DLL

Jika Anda menggunakan Ngen.exe, ketahuilah bahwa rebasing dapat terjadi ketika gambar asli dimuat dalam memori. Jika DLL tidak dimuat pada alamat dasar pilihannya karena rentang alamat tersebut sudah dialokasikan, pemuat Windows akan memuatnya di alamat lain, yang dapat menjadi operasi yang memakan waktu.

Anda dapat menggunakan alat Virtual Address Dump (Vadump.exe) untuk memeriksa apakah ada modul di mana semua halaman bersifat privat. Jika demikian, modul mungkin telah di-rebase ke alamat yang berbeda. Oleh karena itu, halamannya tidak dapat dibagikan.

Untuk informasi selengkapnya tentang cara mengatur alamat dasar, lihat Ngen.exe (Native Image Generator).

Optimalkan Authenticode

Verifikasi Authenticode ditambahkan ke waktu mulai. Rakitan yang ditandatangani Authenticode harus diverifikasi dengan otoritas sertifikasi (CA). Verifikasi ini dapat memakan waktu, karena dapat memerlukan koneksi ke jaringan beberapa kali untuk mengunduh daftar pencabutan sertifikat saat ini. Ini juga memastikan bahwa ada rantai penuh sertifikat yang valid di jalur ke akar tepercaya. Ini dapat diterjemahkan ke beberapa detik penundaan saat perakitan sedang dimuat.

Pertimbangkan untuk menginstal sertifikat CA di komputer klien, atau hindari menggunakan Authenticode jika memungkinkan. Jika Anda tahu bahwa aplikasi Anda tidak memerlukan bukti penerbit, Anda tidak perlu membayar biaya verifikasi tanda tangan.

Mulai dari .NET Framework 3.5, ada opsi konfigurasi yang memungkinkan verifikasi Authenticode dilewati. Untuk melakukan ini, tambahkan pengaturan berikut ke file app.exe.config:

<configuration>  
    <runtime>  
        <generatePublisherEvidence enabled="false"/>
    </runtime>  
</configuration>

Untuk informasi selengkapnya, lihat <generatePublisherEvidence> Element.

Membandingkan Performa di Windows Vista

Manajer memori di Windows Vista memiliki teknologi yang disebut SuperFetch. SuperFetch menganalisis pola penggunaan memori dari waktu ke waktu untuk menentukan konten memori optimal untuk pengguna tertentu. Ini bekerja terus menerus untuk mempertahankan konten tersebut setiap saat.

Pendekatan ini berbeda dari teknik pra-pengambilan yang digunakan dalam Windows XP, yang memuat data ke dalam memori tanpa menganalisis pola penggunaan. Seiring waktu, jika pengguna sering menggunakan aplikasi WPF Anda di Windows Vista, waktu mulai dingin aplikasi Anda dapat meningkat.

Menggunakan AppDomains Secara Efisien

Jika memungkinkan, muat rakitan ke area kode netral domain untuk memastikan bahwa gambar asli, jika ada, digunakan di semua AppDomain yang dibuat dalam aplikasi.

Untuk performa terbaik, terapkan komunikasi lintas domain yang efisien dengan mengurangi panggilan lintas domain. Jika memungkinkan, gunakan panggilan tanpa argumen atau dengan argumen jenis primitif.

Menggunakan Atribut NeutralResourcesLanguage

NeutralResourcesLanguageAttribute Gunakan untuk menentukan budaya netral untuk ResourceManager. Pendekatan ini menghindari pencarian assembly yang gagal.

Menggunakan Kelas BinaryFormatter untuk Serialisasi

Jika Anda harus menggunakan serialisasi, gunakan BinaryFormatter kelas alih-alih XmlSerializer kelas . Kelas BinaryFormatter ini diimplementasikan di Pustaka Kelas Dasar (BCL) di perakitan mscorlib.dll. XmlSerializer diimplementasikan dalam rakitan System.Xml.dll, yang mungkin merupakan DLL tambahan untuk dimuat.

Jika Anda harus menggunakan kelas , XmlSerializer Anda dapat mencapai performa yang lebih baik jika Anda membuat perakitan serialisasi sebelumnya.

Mengonfigurasi ClickOnce untuk Memeriksa Pembaruan Setelah Startup

Jika aplikasi Anda menggunakan ClickOnce, hindari akses jaringan saat startup dengan mengonfigurasi ClickOnce untuk memeriksa situs penyebaran untuk pembaruan setelah aplikasi dimulai.

Jika Anda menggunakan model aplikasi browser XAML (XBAP), perlu diingat bahwa ClickOnce memeriksa situs penyebaran untuk pembaruan bahkan jika XBAP sudah ada di cache ClickOnce. Untuk informasi selengkapnya, lihat Keamanan dan Penyebaran ClickOnce.

Peringatan

XBAP memerlukan browser warisan untuk beroperasi, seperti Internet Explorer dan firefox versi lama. Browser lama ini biasanya tidak didukung pada Windows 10 dan Windows 11. Browser modern tidak lagi mendukung teknologi yang diperlukan untuk aplikasi XBAP karena risiko keamanan. Plugin yang mengaktifkan XBAP tidak lagi didukung. Untuk informasi selengkapnya, lihat Tanya jawab umum tentang aplikasi yang dihosting browser WPF (XBAP).

Mengonfigurasi PresentationFontCache Service untuk Memulai Secara Otomatis

Aplikasi WPF pertama yang dijalankan setelah reboot adalah layanan PresentationFontCache. Layanan ini menyimpan font sistem, meningkatkan akses font, dan meningkatkan performa keseluruhan. Ada overhead dalam memulai layanan, dan di beberapa lingkungan terkontrol, pertimbangkan untuk mengonfigurasi layanan untuk memulai secara otomatis ketika sistem dimulai ulang.

Mengatur Pengikatan Data Secara Terprogram

Alih-alih menggunakan XAML untuk mengatur DataContext secara deklaratif untuk jendela utama, pertimbangkan untuk mengaturnya secara terprogram dalam OnActivated metode .

Lihat juga