Bagikan melalui

Optimalkan tangguhkan/lanjutkan

  • Artikel

Buat aplikasi Platform Windows Universal (UWP) yang menyederhanakan penggunaan sistem masa pakai proses untuk dilanjutkan secara efisien setelah penangguhan atau penghentian.

Launch

Saat mengaktifkan kembali aplikasi setelah ditangguhkan/dihentikan, periksa untuk melihat apakah waktu yang lama telah berlalu. Jika demikian, pertimbangkan untuk kembali ke halaman arahan utama aplikasi alih-alih menampilkan data kedaluarsa pengguna. Ini juga akan menghasilkan startup yang lebih cepat.

Selama aktivasi, selalu periksa PreviousExecutionState dari parameter args peristiwa (misalnya, untuk aktivasi yang diluncurkan, periksa LaunchActivatedEventArgs.PreviousExecutionState). Jika nilainya adalah ClosedByUser atau NotRunning, jangan buang waktu memulihkan status yang disimpan sebelumnya. Dalam hal ini, hal yang tepat adalah memberikan pengalaman baru - dan itu akan menghasilkan startup yang lebih cepat.

Alih-alih dengan bersemangat memulihkan status yang disimpan sebelumnya, pertimbangkan untuk melacak status tersebut, dan hanya memulihkannya sesuai permintaan. Misalnya, pertimbangkan situasi di mana aplikasi Anda sebelumnya ditangguhkan, status tersimpan untuk 3 halaman, lalu dihentikan. Setelah diluluskan kembali, jika Anda memutuskan untuk mengembalikan pengguna ke halaman ke-3, jangan dengan bersemangat memulihkan status untuk 2 halaman pertama. Sebaliknya, berpegang pada status ini dan hanya menggunakannya setelah Anda tahu Anda membutuhkannya.

Saat berjalan

Sebagai praktik terbaik, jangan menunggu acara ditangguhkan dan kemudian mempertahankan status dalam jumlah besar. Sebagai gantinya, aplikasi Anda harus secara bertahap mempertahankan jumlah status yang lebih kecil saat berjalan. Ini sangat penting untuk aplikasi besar yang berisiko kehabisan waktu selama penangguhan jika mereka mencoba menyimpan semuanya sekaligus.

Namun, Anda perlu menemukan keseimbangan yang baik antara penghematan inkremental dan performa aplikasi Anda saat berjalan. Tradeoff yang baik adalah melacak data yang telah berubah secara bertahap (dan oleh karena itu perlu disimpan) - dan menggunakan peristiwa yang ditangguhkan untuk benar-benar menyimpan data tersebut (yang lebih cepat daripada menyimpan semua data atau memeriksa seluruh status aplikasi untuk memutuskan apa yang harus disimpan).

Jangan gunakan jendela Kejadian diaktifkan atau VisibilityChanged untuk memutuskan kapan harus menyimpan status. Saat pengguna beralih dari aplikasi Anda, jendela dinonaktifkan, tetapi sistem menunggu waktu singkat (sekitar 10 detik) sebelum menangguhkan aplikasi. Ini untuk memberikan pengalaman yang lebih responsif jika pengguna beralih kembali ke aplikasi Anda dengan cepat. Tunggu peristiwa ditangguhkan sebelum menjalankan logika tangguhan.

Tangguhkan

Selama ditangguhkan, kurangi jejak aplikasi Anda. Jika aplikasi Anda menggunakan lebih sedikit memori saat ditangguhkan, sistem keseluruhan akan lebih responsif dan lebih sedikit aplikasi yang ditangguhkan (termasuk anda) akan dihentikan. Namun, seimbangkan ini dengan kebutuhan akan resume snappy: jangan mengurangi jejak begitu banyak sehingga resume melambat jauh saat aplikasi Anda memuat ulang banyak data ke dalam memori.

Untuk aplikasi terkelola, sistem akan menjalankan pass pengumpulan sampah setelah handler yang ditangguhkan aplikasi selesai. Pastikan untuk memanfaatkan ini dengan merilis referensi ke objek yang akan membantu mengurangi jejak aplikasi saat ditangguhkan.

Idealnya, aplikasi Anda akan selesai dengan logika tangguhan dalam waktu kurang dari 1 detik. Semakin cepat Anda dapat menangguhkan, semakin baik - yang akan menghasilkan pengalaman pengguna yang lebih cepat untuk aplikasi dan bagian sistem lainnya. Jika harus, logika tangguhan Anda dapat memakan waktu hingga 5 detik di perangkat desktop atau 10 detik di perangkat seluler. Jika waktu tersebut terlampaui, aplikasi Anda akan dihentikan secara tiba-tiba. Anda tidak ingin hal ini terjadi - karena jika terjadi, ketika pengguna beralih kembali ke aplikasi Anda, proses baru akan diluncurkan dan pengalaman akan terasa jauh lebih lambat dibandingkan dengan melanjutkan aplikasi yang ditangguhkan.

Lanjutkan

Sebagian besar aplikasi tidak perlu melakukan sesuatu yang istimewa saat dilanjutkan, jadi biasanya Anda tidak akan menangani peristiwa ini. Beberapa aplikasi menggunakan resume untuk memulihkan koneksi yang ditutup selama penangguhan, atau untuk menyegarkan data yang mungkin kedaluarsa. Alih-alih melakukan pekerjaan semacam ini dengan bersemangat, rancang aplikasi Anda untuk memulai aktivitas ini sesuai permintaan. Ini akan menghasilkan pengalaman yang lebih cepat ketika pengguna beralih kembali ke aplikasi yang ditangguhkan, dan memastikan bahwa Anda hanya melakukan pekerjaan yang benar-benar dibutuhkan pengguna.

Hindari penghentian yang tidak perlu

Sistem masa pakai proses UWP dapat menangguhkan atau mengakhiri aplikasi karena berbagai alasan. Proses ini dirancang untuk dengan cepat mengembalikan aplikasi ke statusnya sebelum ditangguhkan atau dihentikan. Ketika dilakukan dengan baik, pengguna tidak akan menyadari bahwa aplikasi pernah berhenti berjalan. Berikut adalah beberapa trik yang dapat digunakan aplikasi UWP Anda untuk membantu sistem menyederhanakan transisi dalam masa pakai aplikasi.

Aplikasi dapat ditangguhkan saat pengguna memindahkannya ke latar belakang atau ketika sistem memasuki status daya rendah. Saat aplikasi ditangguhkan, aplikasi akan meningkatkan peristiwa penangguhan dan memiliki waktu hingga 5 detik untuk menyimpan datanya. Jika penanganan aktivitas penangguhan aplikasi tidak selesai dalam waktu 5 detik, sistem mengasumsikan aplikasi telah berhenti merespons dan mengakhirinya. Aplikasi yang dihentikan harus melalui proses startup panjang lagi alih-alih segera dimuat ke dalam memori saat pengguna beralih ke aplikasi tersebut.

Serialisasi hanya jika diperlukan

Banyak aplikasi menserialisasikan semua data mereka pada penangguhan. Namun, jika Anda hanya perlu menyimpan sejumlah kecil data pengaturan aplikasi, Anda harus menggunakan penyimpanan LocalSettings alih-alih membuat serialisasi data. Gunakan serialisasi untuk data dalam jumlah yang lebih besar dan untuk data non-pengaturan.

Saat Anda melakukan serialisasi data, Anda harus menghindari reserialisasi jika belum berubah. Dibutuhkan waktu ekstra untuk membuat serialisasi dan menyimpan data, ditambah waktu tambahan untuk membaca dan mendeserialisasinya saat aplikasi diaktifkan lagi. Sebagai gantinya, kami menyarankan agar aplikasi menentukan apakah statusnya benar-benar berubah, dan jika demikian, serialisasi dan deserialisasi hanya data yang berubah. Cara yang baik untuk memastikan bahwa hal ini terjadi adalah dengan secara berkala menserialisasikan data di latar belakang setelah berubah. Ketika Anda menggunakan teknik ini, semua yang perlu diserialisasikan pada penangguhan telah disimpan sehingga tidak ada pekerjaan yang harus dilakukan dan aplikasi menangguhkan dengan cepat.

Menserialisasikan data di C# dan Visual Basic

Pilihan teknologi serialisasi yang tersedia untuk aplikasi .NET adalah kelas System.Xml.Serialization.XmlSerializer, System.Runtime.Serialization.DataContractSerializer, dan System.Runtime.Serialization.Json.DataContractJsonSerializer.

Dari perspektif performa, sebaiknya gunakan kelas XmlSerializer. XmlSerializer memiliki waktu serialisasi dan deserialisasi terendah, dan mempertahankan jejak memori yang rendah. XmlSerializer memiliki beberapa dependensi pada kerangka kerja .NET; ini berarti bahwa dibandingkan dengan teknologi serialisasi lainnya, lebih sedikit modul yang perlu dimuat ke dalam aplikasi Anda untuk menggunakan XmlSerializer.

DataContractSerializer mempermudah serialisasi kelas kustom, meskipun memiliki dampak performa yang lebih besar daripada XmlSerializer. Jika Anda membutuhkan performa yang lebih baik, pertimbangkan untuk beralih. Secara umum, Anda tidak boleh memuat lebih dari satu serializer, dan Anda harus lebih memilih XmlSerializer kecuali Anda memerlukan fitur serializer lain.

Mengurangi jejak memori

Sistem mencoba menyimpan sebanyak mungkin aplikasi yang ditangguhkan dalam memori sehingga pengguna dapat beralih dengan cepat dan andal di antara mereka. Ketika aplikasi ditangguhkan dan tetap berada dalam memori sistem, aplikasi dapat dengan cepat dibawa ke latar depan untuk berinteraksi dengan pengguna, tanpa harus menampilkan layar percikan atau melakukan operasi beban yang panjang. Jika tidak ada cukup sumber daya untuk menyimpan aplikasi dalam memori, aplikasi akan dihentikan. Ini membuat manajemen memori penting karena dua alasan:

  • Membebaskan memori sebanyak mungkin saat ditangguhkan meminimalkan kemungkinan aplikasi Anda dihentikan karena kurangnya sumber daya saat ditangguhkan.
  • Mengurangi jumlah keseluruhan memori yang digunakan aplikasi Anda mengurangi kemungkinan aplikasi lain dihentikan saat ditangguhkan.

Rilis sumber daya

Objek tertentu, seperti file dan perangkat, menempati sejumlah besar memori. Kami menyarankan agar selama penangguhan, rilis aplikasi menangani ke objek ini dan membuatnya kembali saat diperlukan. Ini juga saat yang tepat untuk membersihkan cache apa pun yang tidak akan valid saat aplikasi dilanjutkan. Langkah tambahan yang dijalankan kerangka kerja XAML atas nama Anda untuk aplikasi C# dan Visual Basic adalah pengumpulan sampah jika diperlukan. Ini memastikan objek apa pun yang tidak lagi dirujuk dalam kode aplikasi dirilis.

Lanjutkan dengan cepat

Aplikasi yang ditangguhkan dapat dilanjutkan saat pengguna memindahkannya ke latar depan atau ketika sistem keluar dari status daya rendah. Ketika aplikasi dilanjutkan dari status ditangguhkan, aplikasi berlanjut dari tempatnya ketika ditangguhkan. Tidak ada data aplikasi yang hilang karena disimpan dalam memori, bahkan jika aplikasi ditangguhkan untuk jangka waktu yang lama.

Sebagian besar aplikasi tidak perlu menangani peristiwa Resuming. Saat aplikasi Anda dilanjutkan, variabel dan objek memiliki status yang sama persis saat aplikasi ditangguhkan. Tangani peristiwa Melanjutkan hanya jika Anda perlu memperbarui data atau objek yang mungkin telah berubah antara waktu aplikasi Anda ditangguhkan dan ketika dilanjutkan seperti: konten (misalnya, memperbarui data umpan), koneksi jaringan yang mungkin telah usang, atau jika Anda perlu meminta kembali akses ke perangkat (misalnya, webcam).