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.
Semua Tugas Tidak Diciptakan Sama
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:
- Buat struktur folder.
- Dekompresi dan salin file senilai 1 GB.
- Buat entri registri.
- Buat entri menu awal.
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:
- Buat struktur folder. [Berat = 1]
- Dekompresi dan salin file senilai 1 GB. [Berat = 7]
- Buat entri registri. [Berat = 1]
- Buat entri menu awal. [Berat = 1]
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.
Hasil Masa Lalu Tidak Menjamin Kinerja Masa Depan
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:
- Kecepatan transfer untuk 60 detik sebelumnya diingat dengan nilai terbaru menggantikan yang tertua (misalnya nilai ke-61 menggantikan yang pertama).
- Kecepatan transfer efektif untuk tujuan perhitungan adalah rata-rata dari pengukuran ini.
- Sisa waktu dihitung sebagai: Ukuran Tersisa / Kecepatan Unduhan Efektif
Jadi dengan menggunakan skenario kami di atas (demi kesederhanaan, kami akan menggunakan 1 MB = 1.000 KB):
- Pada 75 detik dalam unduhan, 60 nilai yang kami ingat masing-masing akan menjadi 1.000 KB. Kecepatan transfer efektif adalah 1.000 KB (60.000 KB / 60) yang menghasilkan waktu tersisa 25 detik (25.000 KB / 1.000 KB).
- Pada 76 detik (di mana kecepatan transfer menjadi 500 KB), kecepatan pengunduhan efektif menjadi ~ 992 KB (59,500 KB / 60) yang menghasilkan waktu tersisa ~ 24,7 detik (24.500 KB / 992 KB).
- Pada 77 detik: Kecepatan efektif = ~ 983 KB (59.000 KB / 60) menghasilkan waktu tersisa ~ 24,4 detik (24.000 KB / 983 KB).
- Pada 78 detik: Kecepatan efektif = 975 KB (58,500 KB / 60) menghasilkan waktu tersisa ~ 24,1 detik (23.500 KB / 975 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 …
Anda Tidak Dapat Secara Akurat Menentukan Sesuatu yang Nondeterministic
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.
Pada akhirnya, itu benar-benar tidak masalah
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.
