Merencanakan performa

Pengguna mengharapkan aplikasi mereka tetap responsif, terasa alami, dan tidak menguras baterai mereka. Secara teknis, performa adalah persyaratan non-fungsional tetapi memperlakukan performa sebagai fitur akan membantu Anda memberikan harapan pengguna Anda. Menentukan tujuan, dan mengukur, adalah faktor utama. Tentukan apa skenario kritis performa Anda; menentukan arti performa yang baik. Kemudian ukur lebih awal dan cukup sering sepanjang siklus hidup proyek Anda untuk yakin Anda akan mencapai tujuan Anda.

Menentukan tujuan

Pengalaman pengguna adalah cara dasar untuk menentukan performa yang baik. Waktu mulai aplikasi dapat memengaruhi persepsi pengguna tentang performanya. Pengguna mungkin menganggap waktu peluncuran aplikasi kurang dari satu detik menjadi sangat baik, kurang dari 5 detik menjadi baik, dan lebih dari 5 detik menjadi buruk.

Metrik lain memiliki dampak yang kurang jelas pada pengalaman pengguna, misalnya memori. Kemungkinan aplikasi dihentikan saat ditangguhkan atau tidak aktif naik dengan jumlah memori yang digunakan oleh aplikasi aktif. Ini adalah aturan umum bahwa penggunaan memori yang tinggi menurunkan pengalaman untuk semua aplikasi pada sistem, sehingga memiliki tujuan pada konsumsi memori adalah wajar. Pertimbangkan ukuran kasar aplikasi Anda seperti yang dirasakan oleh pengguna: kecil, sedang, atau besar. Harapan sekeliling performa akan berkorelasi dengan persepsi ini. Misalnya, Anda mungkin menginginkan aplikasi kecil yang tidak menggunakan banyak media untuk mengonsumsi memori kurang dari 100MB.

Lebih baik menetapkan tujuan awal, dan kemudian merevisinya nanti, daripada tidak memiliki tujuan sama sekali. Tujuan performa aplikasi Anda harus spesifik dan terukur dan harus termasuk dalam tiga kategori: berapa lama waktu yang dibutuhkan pengguna, atau aplikasi, untuk menyelesaikan tugas (waktu); tingkat dan kelangsungan di mana aplikasi mengulangi dirinya sendiri sebagai respons terhadap interaksi pengguna (fluiditas); dan seberapa baik aplikasi menghemat sumber daya sistem, termasuk daya baterai (efisiensi).

Waktu

Pikirkan rentang waktu yang berlalu (kelas interaksi) yang dapat diterima yang diperlukan pengguna untuk menyelesaikan tugas mereka di aplikasi Anda. Untuk setiap kelas interaksi, tetapkan label, sentimen pengguna yang dirasakan, dan durasi ideal dan maksimum. Berikut adalah beberapa saran.

Label kelas interaksi	Persepsi pengguna	Ideal	Maksimum	Contoh
Cepat	Penundaan yang minimal terlihat	100 milidetik	200 milidetik	Memunculkan bilah aplikasi; tekan tombol (respons pertama)
Khas	Cepat, tapi tidak cepat	300 milidetik	500 milidetik	Mengubah ukuran; zoom semantik
Responsif	Tidak cepat, tapi terasa responsif	500 milidetik	1 detik	Menavigasi ke halaman lain; melanjutkan aplikasi dari status ditangguhkan
Launch	Pengalaman kompetitif	1 detik	3 detik	Luncurkan aplikasi untuk pertama kalinya atau setelah sebelumnya dihentikan
Berkelanjutan	Tidak lagi terasa responsif	500 milidetik	5 detik	Mengunduh file dari Internet
Tawanan	Lama; pengguna dapat beralih	500 milidetik	10 detik	Menginstal beberapa aplikasi dari Store

 

Sekarang Anda dapat menetapkan kelas interaksi ke skenario performa aplikasi Anda. Anda dapat menetapkan referensi point-in-time aplikasi, sebagian dari pengalaman pengguna, dan kelas interaksi ke setiap skenario. Berikut adalah beberapa saran untuk contoh aplikasi makanan dan makan.

Skenario	Titik waktu	Pengalaman pengguna	Kelas interaksi
Menavigasi ke halaman resep	Respons pertama	Animasi transisi halaman dimulai	Cepat (100-200 milidetik)
	Responsif	Daftar bahan dimuat; tidak ada gambar	Responsif (500 milidetik - 1 detik)
	Terlihat selesai	Semua konten dimuat; gambar yang ditampilkan	Berkelanjutan (500 milidetik - 5 detik)
Cari resep	Respons pertama	Tombol pencarian diklik	Cepat (100 - 200 milidetik)
	Terlihat selesai	Daftar judul resep lokal yang ditampilkan	Khas (300 - 500 milidetik)

Jika Anda menampilkan konten langsung, pertimbangkan juga tujuan kesegaran konten. Apakah tujuan untuk me-refresh konten setiap beberapa detik? Atau menyegarkan konten setiap beberapa menit, setiap beberapa jam, atau bahkan sekali sehari pengalaman pengguna yang dapat diterima?

Dengan tujuan yang ditentukan, Anda sekarang lebih dapat menguji, menganalisis, dan mengoptimalkan aplikasi Anda.

Fluiditas

Tujuan fluiditas terukur tertentu untuk aplikasi Anda mungkin meliputi:

• Tidak ada pemberhentian dan mulai redraw layar (gangguan).
• Animasi dirender pada 60 bingkai per detik (FPS).
• Saat pengguna menggeser/menggulir, aplikasi menyajikan 3-6 halaman konten per detik.

Efisiensi

Tujuan efisiensi terukur tertentu untuk aplikasi Anda mungkin meliputi:

• Untuk proses aplikasi Anda, persentase CPU berada di atau di bawah penggunaan N dan memori dalam MB berada di atau di bawah M setiap saat.
• Saat aplikasi tidak aktif, N dan M adalah nol untuk proses aplikasi Anda.
• Aplikasi Anda dapat digunakan secara aktif untuk X jam pada daya baterai; saat aplikasi Anda tidak aktif, perangkat mempertahankan dayanya selama Y jam.

Mendesain aplikasi Anda untuk performa

Anda sekarang dapat menggunakan tujuan performa untuk memengaruhi desain aplikasi Anda. Menggunakan contoh aplikasi makanan dan makan, setelah pengguna menavigasi ke halaman resep, Anda dapat memilih untuk memperbarui item secara bertahap sehingga nama resep dirender terlebih dahulu, menampilkan bahan-bahan ditangguhkan, dan menampilkan gambar ditangguhkan lebih lanjut. Ini mempertahankan responsivitas dan UI cairan saat panning/scrolling, dengan penyajian keakuratan penuh terjadi setelah interaksi melambat ke kecepatan yang memungkinkan utas UI mengejar ketinggalan. Berikut adalah beberapa aspek lain yang perlu dipertimbangkan.

UI

• Maksimalkan penguraian dan waktu pemuatan dan efisiensi memori untuk setiap halaman UI aplikasi Anda (terutama halaman awal) dengan mengoptimalkan markup XAML Anda. Singkatnya, tangguhkan pemuatan UI dan kode hingga diperlukan.
• Untuk ListView dan GridView, buat semua item berukuran sama dan gunakan teknik pengoptimalan ListView dan GridView sebanyak mungkin.
• Nyatakan UI dalam bentuk markup, yang dapat dimuat dan digunakan kembali kerangka kerja dalam gugus, daripada membangunnya secara imperatif dalam kode.
• Tunda pembuatan elemen UI hingga pengguna membutuhkannya. Lihat atribut x:Load.
• Lebih suka transisi dan animasi tema ke animasi papan cerita. Untuk informasi selengkapnya, lihat Gambaran umum Animasi. Ingatlah bahwa animasi storyboard memerlukan pembaruan konstan ke layar, dan menjaga alur CPU dan grafis tetap aktif. Untuk mempertahankan baterai, tidak memiliki animasi yang berjalan jika pengguna tidak berinteraksi dengan aplikasi.
• Gambar yang Anda muat harus dimuat pada ukuran yang sesuai untuk tampilan tempat Anda menyajikannya, menggunakan metode GetThumbnailAsync.

CPU, memori, dan daya

• Jadwalkan pekerjaan berprioritas lebih rendah untuk dijalankan pada utas dan/atau inti berprioritas lebih rendah. Lihat Pemrograman asinkron, properti Dispatcher, dan kelas CoreDispatcher.
• Minimalkan jejak memori aplikasi Anda dengan merilis sumber daya yang mahal (seperti media) saat ditangguhkan.
• Minimalkan set kerja kode Anda.
• Hindari kebocoran memori dengan membatalkan pendaftaran penanganan aktivitas dan mendereferensikan elemen UI jika memungkinkan.
• Demi baterai, konservatiflah dengan seberapa sering Anda melakukan polling untuk data, mengkueri sensor, atau menjadwalkan pekerjaan pada CPU saat diam.

Akses data

• Jika memungkinkan, isi prefetch. Untuk prefetching otomatis, lihat kelas ContentPrefetcher. Untuk prefetching manual, lihat namespace Windows.ApplicationModel.Background dan kelas MaintenanceTrigger.
• Jika memungkinkan, konten cache yang mahal untuk diakses. Lihat properti LocalFolder dan Local Pengaturan.
• Untuk kesalahan cache, tampilkan UI tempat penampung secepat mungkin yang menunjukkan bahwa aplikasi masih memuat konten. Transisi dari tempat penampung ke konten langsung dengan cara yang tidak dijalankan kepada pengguna. Misalnya, jangan ubah posisi konten di bawah jari pengguna atau penunjuk mouse saat aplikasi memuat konten langsung.

Peluncuran dan lanjutkan aplikasi

• Tangguhkan layar splash aplikasi, dan jangan perluas layar splash aplikasi kecuali diperlukan. Untuk detailnya, lihat Membuat pengalaman peluncuran aplikasi yang cepat dan lancar dan Menampilkan layar splash untuk waktu yang lebih lama.
• Nonaktifkan animasi yang terjadi segera setelah layar splash dimatikan, karena ini hanya akan menyebabkan persepsi penundaan waktu peluncuran aplikasi.

Antarmuka pengguna adaptif, dan orientasi

• Gunakan kelas VisualStateManager.
• Selesaikan hanya pekerjaan yang diperlukan segera, tangguhkan pekerjaan aplikasi intensif hingga nanti—aplikasi Anda memiliki antara 200 dan 800 milidetik untuk menyelesaikan pekerjaan sebelum pengguna melihat UI aplikasi Anda dalam status dipotong.

Dengan desain terkait performa, Anda dapat mulai mengkoding aplikasi Anda.

Instrumen untuk performa

Saat Anda membuat kode, tambahkan kode yang mencatat pesan dan peristiwa di titik tertentu saat aplikasi Anda berjalan. Nantinya, saat menguji aplikasi, Anda dapat menggunakan alat pembuatan profil seperti Windows Performance Recorder dan Windows Penganalisis Kinerja (keduanya disertakan dalam Toolkit Performa Windows) untuk membuat dan melihat laporan tentang performa aplikasi Anda. Dalam laporan ini, Anda dapat mencari pesan dan peristiwa ini untuk membantu Anda menganalisis hasil laporan dengan lebih mudah.

Platform Windows Universal (UWP) menyediakan API pengelogan, didukung oleh Pelacakan Peristiwa untuk Windows (ETW), yang bersama-sama menawarkan solusi pengelogan dan pelacakan peristiwa yang kaya. API, yang merupakan bagian dari namespace Layanan Windows.Foundation.Diagnostics, termasuk kelas FileLoggingSession, LoggingActivity, LoggingChannel, dan LoggingSession.

Untuk mencatat pesan dalam laporan pada titik tertentu saat aplikasi berjalan, buat objek LoggingChannel, lalu panggil metode LogMessage objek, seperti ini.

// using Windows.Foundation.Diagnostics;
// ...

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");

myLoggingChannel.LogMessage(LoggingLevel.Information, "Here' s my logged message.");

// ...

Untuk mencatat peristiwa mulai dan berhenti dalam laporan selama periode waktu tertentu saat aplikasi berjalan, buat objek LoggingActivity, lalu panggil konstruktor LoggingActivity objek, seperti ini.

// using Windows.Foundation.Diagnostics;
// ...

LoggingActivity myLoggingActivity;

// myLoggingChannel is defined and initialized in the previous code example.
using (myLoggingActivity = new LoggingActivity("MyLoggingActivity"), myLoggingChannel))
{   // After this logging activity starts, a start event is logged.
    
    // Add code here to do something of interest.
    
}   // After this logging activity ends, an end event is logged.

// ...

Lihat juga sampel Pengelogan.

Dengan instrumen aplikasi, Anda dapat menguji dan mengukur performa aplikasi.

Menguji dan mengukur terhadap tujuan performa

Bagian dari rencana performa Anda adalah menentukan poin selama pengembangan di mana Anda akan mengukur performa. Ini melayani tujuan yang berbeda tergantung pada apakah Anda mengukur selama prototipe, pengembangan, atau penyebaran. Mengukur performa selama tahap awal prototipe bisa sangat berharga, jadi kami sarankan Anda melakukannya segera setelah Anda memiliki kode yang melakukan pekerjaan yang bermakna. Pengukuran awal memberi Anda gambaran yang baik tentang di mana biaya penting berada di aplikasi Anda, dan menginformasikan keputusan desain. Ini menghasilkan aplikasi berkinerja tinggi dan menskalakan. Umumnya lebih mahal untuk mengubah desain lebih lambat dari sebelumnya. Mengukur performa terlambat dalam siklus produk dapat mengakibatkan peretasan menit terakhir dan performa yang buruk.

Gunakan teknik dan alat ini untuk menguji bagaimana aplikasi Anda ditumpuk terhadap tujuan performa asli Anda.

• Uji terhadap berbagai konfigurasi perangkat keras termasuk PC all-in-one dan desktop, laptop, ultrabook, dan tablet dan perangkat seluler lainnya.
• Uji terhadap berbagai ukuran layar. Meskipun ukuran layar yang lebih luas dapat menampilkan lebih banyak konten, membawa semua konten tambahan tersebut dapat berdampak negatif pada performa.
• Hilangkan variabel pengujian sebanyak yang Anda bisa.
  • Nonaktifkan aplikasi latar belakang pada perangkat pengujian. Untuk melakukan ini, di Windows, pilih Pengaturan dari layar Kunci Personalisasi>menu Mulai>. Pilih setiap aplikasi aktif dan pilih Tidak Ada.
  • Kompilasi aplikasi Anda ke kode asli dengan membuatnya dalam konfigurasi rilis sebelum menyebarkannya ke perangkat pengujian.
  • Untuk memastikan bahwa pemeliharaan otomatis tidak memengaruhi performa perangkat pengujian, picu secara manual dan tunggu hingga selesai. Di Windows, di menu Mulai cari Keamanan dan Pemeliharaan. Di area Pemeliharaan, di bawah Pemeliharaan Otomatis, pilih Mulai pemeliharaan dan tunggu hingga status berubah dari Pemeliharaan yang sedang berlangsung.
  • Jalankan aplikasi beberapa kali untuk membantu menghilangkan variabel pengujian acak dan membantu memastikan pengukuran yang konsisten.
• Uji untuk mengurangi ketersediaan daya. Perangkat pengguna Anda mungkin memiliki daya yang jauh lebih sedikit daripada komputer pengembangan Anda. Windows dirancang dengan perangkat berdaya rendah, seperti perangkat seluler, dalam pikiran. Aplikasi yang berjalan di platform harus memastikan mereka berperforma baik pada perangkat ini. Sebagai heuristik, harapkan bahwa perangkat daya rendah berjalan sekitar seperempat kecepatan komputer desktop, dan atur tujuan Anda.
• Gunakan kombinasi alat seperti Microsoft Visual Studio dan Windows Penganalisis Kinerja untuk mengukur performa aplikasi. Visual Studio dirancang untuk menyediakan analisis yang berfokus pada aplikasi, seperti penautan kode sumber. Windows Penganalisis Kinerja dirancang untuk menyediakan analisis yang berfokus pada sistem, seperti memberikan info sistem, info tentang peristiwa manipulasi sentuh, dan info tentang input/output disk (I/O) dan biaya unit pemrosesan grafis (GPU). Kedua alat ini menyediakan tangkapan jejak dan ekspor, dan dapat membuka kembali jejak bersama dan pasca-mortem.
• Sebelum Anda mengirimkan aplikasi ke Store untuk sertifikasi, pastikan untuk memasukkan ke dalam rencana pengujian Anda kasus pengujian terkait performa seperti yang dijelaskan di bagian "Pengujian performa" dari pengujian Kit Sertifikasi Aplikasi Windows dan di bagian "Performa dan stabilitas" dari kasus pengujian aplikasi UWP.

Untuk informasi selengkapnya, lihat sumber daya dan alat pembuatan profil ini.

• Penganalisis Performa Windows
• Toolkit Performa Windows
• Menganalisis performa menggunakan alat diagnostik Visual Studio
• Performa XAML sesi //build/
• Alat XAML Baru //build/ sesi di Visual Studio 2015

Menanggapi hasil pengujian performa

Setelah Anda menganalisis hasil pengujian performa, tentukan apakah ada perubahan yang diperlukan, misalnya:

• Haruskah Anda mengubah salah satu keputusan desain aplikasi, atau mengoptimalkan kode Anda?
• Haruskah Anda menambahkan, menghapus, atau mengubah instrumentasi apa pun dalam kode?
• Haruskah Anda merevisi salah satu tujuan performa Anda?

Jika ada perubahan yang diperlukan, buat dan kemudian kembali ke instrumenting atau pengujian dan ulangi.

Mengoptimalkan

Optimalkan hanya jalur kode penting performa di aplikasi Anda: jalur yang menghabiskan sebagian besar waktu. Pembuatan profil akan memberi tahu Anda yang mana. Seringkali, ada trade-off antara membuat perangkat lunak yang mengikuti praktik desain yang baik dan menulis kode yang berkinerja pada pengoptimalan tertinggi. Umumnya lebih baik memprioritaskan produktivitas pengembang dan desain perangkat lunak yang baik di area di mana performa tidak menjadi perhatian.