Pada pemikiran pertama, tampaknya menghasilkan perkiraan waktu yang akurat seharusnya cukup mudah. Setelah semua, algoritma menghasilkan progress bar mengetahui semua tugas yang perlu dilakukan sebelumnya ... kan?
Untuk sebagian besar, memang benar bahwa algoritma sumber memang tahu apa yang perlu dilakukan sebelumnya. Namun, mencatat waktu yang diperlukan untuk melakukan setiap langkah adalah tugas yang sangat sulit, jika tidak benar-benar mustahil.
Cara paling sederhana untuk menerapkan bilah kemajuan adalah dengan menggunakan representasi grafis dari penghitung tugas. Di mana persen lengkap hanya dihitung sebagai Tugas Lengkap / Jumlah Total Tugas. Sementara ini masuk akal logis pada pikiran pertama, penting untuk mengingat bahwa (jelas) beberapa tugas membutuhkan waktu lebih lama untuk diselesaikan.
Pertimbangkan tugas-tugas berikut yang dilakukan oleh pemasang:
Dalam contoh ini, langkah 1, 3, dan 4 akan selesai dengan sangat cepat sementara langkah 2 akan memakan waktu. Jadi, progress bar yang bekerja pada hitungan sederhana akan melonjak hingga 25% dengan sangat cepat, berhenti sebentar sementara langkah 2 bekerja, dan kemudian lompat ke 100% dengan segera.
Jenis implementasi ini sebenarnya sangat umum di antara bilah kemajuan karena, sebagaimana dinyatakan di atas, mudah diterapkan. Namun, seperti yang Anda lihat, itu tunduk pada tugas yang tidak proporsional sebenarnya persentase kemajuan yang berkaitan dengan waktu yang tersisa.
Untuk mengatasi ini, beberapa bar kemajuan mungkin menggunakan implementasi di mana langkah-langkah tertimbang. Pertimbangkan langkah-langkah di atas di mana bobot relatif ditetapkan untuk setiap langkah:
Dengan menggunakan metode ini, progress bar akan bergerak dalam kelipatan 10% (karena berat total adalah 10) dengan langkah 1, 3, dan 4 memindahkan bar 10% saat selesai dan langkah 2 memindahkannya 70%. Meskipun tentu saja tidak sempurna, metode seperti ini adalah cara sederhana untuk menambahkan sedikit lebih banyak ketepatan pada persentase bilah kemajuan.
Pertimbangkan contoh sederhana dari saya yang meminta Anda untuk menghitung hingga 50 sementara saya menggunakan stopwatch ke waktu Anda. Katakanlah Anda menghitung hingga 25 dalam 10 detik. Akan masuk akal untuk mengasumsikan Anda akan menghitung jumlah yang tersisa dalam 10 detik tambahan, jadi bar kemajuan pelacakan ini akan menunjukkan 50% lengkap dengan 10 detik tersisa.
Setelah hitungan Anda mencapai 25, saya mulai melemparkan bola tenis ke arah Anda. Mungkin, ini akan mematahkan ritme Anda karena konsentrasi Anda telah berpindah dari menghitung jumlah yang ketat untuk menghindari bola yang dilemparkan ke arah Anda. Dengan asumsi Anda dapat terus menghitung, kecepatan Anda pasti melambat sedikit. Jadi sekarang progress bar masih bergerak, tetapi pada kecepatan yang jauh lebih lambat dengan perkiraan waktu yang tersisa baik di perhentian atau benar-benar naik lebih tinggi.
Untuk contoh yang lebih praktis tentang ini, pertimbangkan untuk mengunduh file. Anda sedang mengunduh file 100 MB dengan kecepatan 1 MB / dtk. Ini sangat mudah untuk menentukan perkiraan waktu penyelesaian. Tetapi 75% dari perjalanan ke sana, beberapa kemacetan jaringan terpukul dan tingkat unduhan Anda turun menjadi 500 KB / dtk.
Bergantung pada bagaimana peramban menghitung waktu yang tersisa, ETA Anda dapat langsung berubah dari 25 detik menjadi 50 detik (menggunakan keadaan sekarang saja: Ukuran Tersisa / Kecepatan Unduhan) atau, kemungkinan besar, browser menggunakan algoritme rata-rata bergulir yang akan menyesuaikan fluktuasi dalam kecepatan transfer tanpa menampilkan lompatan dramatis kepada pengguna.
Contoh algoritme bergulir terkait dengan pengunduhan file dapat berfungsi seperti ini:
Jadi dengan menggunakan skenario kami di atas (demi kesederhanaan, kami akan menggunakan 1 MB = 1.000 KB):
Anda dapat melihat pola yang muncul di sini karena penurunan kecepatan unduh secara perlahan dimasukkan ke dalam rata-rata yang digunakan untuk memperkirakan waktu yang tersisa. Dengan metode ini, jika kemiringan hanya berlangsung selama 10 detik dan kemudian kembali ke 1 MB / s, pengguna tidak akan melihat perbedaannya (kecuali kios yang sangat kecil dalam perkiraan waktu hitung mundur).
Mendapatkan paku payung kuningan - ini hanyalah metodologi untuk menyampaikan informasi kepada pengguna akhir untuk penyebab yang sebenarnya ...
Pada akhirnya, ketidakakuratan bar progres bermuara pada fakta bahwa ia mencoba menentukan waktu untuk sesuatu yang nondeterministic.Karena komputer memproses tugas baik pada permintaan dan di latar belakang, hampir tidak mungkin untuk mengetahui sumber daya sistem apa yang akan tersedia di mana saja di masa depan - dan itu adalah ketersediaan sumber daya sistem yang diperlukan untuk menyelesaikan tugas apa pun.
Dengan menggunakan contoh lain, misalkan Anda menjalankan program peningkatan pada server yang melakukan pembaruan basis data yang cukup intensif. Selama proses pembaruan ini, pengguna kemudian mengirim permintaan yang menuntut ke database lain yang berjalan pada sistem ini. Sekarang sumber daya server, khususnya untuk database, harus memproses permintaan untuk peningkatan Anda serta permintaan yang dimulai pengguna - skenario yang tentunya akan saling merugikan waktu eksekusi. Bergantian, pengguna dapat memulai permintaan transfer file besar yang akan membebankan throughput penyimpanan yang akan mengurangi kinerja juga. Atau tugas yang dijadwalkan bisa memulai yang melakukan proses intensif memori. Anda mendapatkan ide itu.
Sebagai, mungkin, contoh yang lebih realistis untuk pengguna sehari-hari - pertimbangkan untuk menjalankan Pembaruan Windows atau pemindaian virus. Kedua operasi ini melakukan operasi intensif sumber daya di latar belakang. Akibatnya, kemajuan masing-masing tergantung pada apa yang dilakukan pengguna pada saat itu. Jika Anda membaca email Anda saat ini berjalan, kemungkinan besar permintaan pada sumber daya sistem akan rendah dan progress bar akan bergerak secara konsisten. Di sisi lain, jika Anda melakukan editing grafis maka permintaan Anda pada sumber daya sistem akan jauh lebih besar yang akan menyebabkan gerakan progress bar menjadi skizofrenia.
Secara keseluruhan, hanya tidak ada bola kristal. Bahkan sistem itu sendiri tidak tahu apa yang memuatnya di bawah pada titik mana pun di masa depan.
Maksud dari progress bar adalah untuk, yah, menunjukkan bahwa kemajuan memang sedang dibuat dan proses masing-masing tidak digantung. Sangat menyenangkan ketika indikator kemajuan akurat, tetapi biasanya hanya gangguan kecil ketika tidak. Untuk sebagian besar, pengembang tidak akan mencurahkan banyak waktu dan upaya ke dalam algoritma bar kemajuan karena, terus terang, ada tugas yang jauh lebih penting untuk menghabiskan waktu.
Tentu saja, Anda memiliki hak untuk merasa terganggu ketika sebuah progress bar melompat hingga 99% selesai secara instan dan kemudian membuat Anda menunggu 5 menit untuk satu persen sisanya. Tetapi jika program masing-masing bekerja dengan baik secara keseluruhan, ingatkan diri Anda bahwa pengembang memiliki prioritas yang lurus.
