Đối với hầu hết các phần, nó là sự thật rằng các thuật toán nguồn không biết những gì nó cần phải làm trước thời hạn. Tuy nhiên, việc xác định thời gian cần thiết để thực hiện từng bước là một nhiệm vụ rất khó, nếu không phải là hầu như không thể.
Tất cả công việc không được tạo bình đẳng
Cách đơn giản nhất để thực hiện thanh tiến trình là sử dụng một biểu diễn đồ họa của bộ đếm tác vụ. Trường hợp phần trăm hoàn thành được tính toán đơn giản là Công việc đã hoàn thành / Tổng số công việc. Trong khi điều này có ý nghĩa logic về suy nghĩ đầu tiên, điều quan trọng cần nhớ là (rõ ràng) một số nhiệm vụ mất nhiều thời gian hơn để hoàn thành.
Xem xét các tác vụ sau được trình cài đặt thực hiện:
- Tạo cấu trúc thư mục.
- Giải nén và sao chép 1 GB giá trị của các tập tin.
- Tạo mục đăng ký.
- Tạo mục trình đơn bắt đầu.
Trong ví dụ này, các bước 1, 3 và 4 sẽ hoàn thành rất nhanh trong khi bước 2 sẽ mất một thời gian. Vì vậy, một thanh tiến trình làm việc trên một số đơn giản sẽ nhảy đến 25% rất nhanh chóng, gian hàng cho một chút trong khi bước 2 đang làm việc, và sau đó nhảy đến 100% gần như ngay lập tức.
Kiểu triển khai này thực sự khá phổ biến trong các thanh tiến trình vì, như đã nói ở trên, nó rất dễ thực hiện. Tuy nhiên, như bạn có thể thấy, nó phụ thuộc vào các nhiệm vụ không cân xứng thực tế tỷ lệ phần trăm tiến độ vì nó liên quan đến thời gian còn lại.
Để giải quyết vấn đề này, một số thanh tiến trình có thể sử dụng các triển khai trong đó các bước được cân. Xem xét các bước ở trên, nơi chỉ định trọng số tương đối cho từng bước:
- Tạo cấu trúc thư mục. [Trọng lượng = 1]
- Giải nén và sao chép 1 GB giá trị của các tập tin. [Trọng lượng = 7]
- Tạo mục đăng ký. [Trọng lượng = 1]
- Tạo mục trình đơn bắt đầu. [Trọng lượng = 1]
Sử dụng phương pháp này, thanh tiến trình sẽ di chuyển theo mức tăng 10% (với tổng trọng số là 10) với các bước 1, 3 và 4 di chuyển thanh 10% khi hoàn thành và bước 2 di chuyển 70%. Mặc dù chắc chắn không hoàn hảo, các phương pháp như thế này là một cách đơn giản để thêm độ chính xác hơn một chút vào tỷ lệ phần trăm thanh tiến trình.
Kết quả trước đây không đảm bảo hiệu suất trong tương lai
Tuy nhiên, khi số lượng của bạn đạt đến 25, tôi bắt đầu ném những quả bóng tennis vào bạn. Có khả năng, điều này sẽ phá vỡ nhịp điệu của bạn khi nồng độ của bạn đã di chuyển từ số đếm nghiêm ngặt để né tránh bóng ném theo cách của bạn. Giả sử bạn có thể tiếp tục đếm, tốc độ của bạn chắc chắn đã chậm lại một chút. Vì vậy, bây giờ thanh tiến trình vẫn đang chuyển động, nhưng với tốc độ chậm hơn nhiều với thời gian ước tính còn lại hoặc bế tắc hoặc thực sự leo cao hơn.
Để có một ví dụ thực tế hơn về điều này, hãy xem xét tải xuống tệp. Bạn hiện đang tải xuống tệp 100 MB với tốc độ 1 MB / s. Điều này rất dễ dàng để xác định thời gian hoàn thành ước tính. Nhưng 75% con đường ở đó, một số truy cập tắc nghẽn mạng và tốc độ tải xuống của bạn giảm xuống còn 500 KB / s.
Tùy thuộc vào cách trình duyệt tính toán thời gian còn lại, ETA của bạn có thể ngay lập tức đi từ 25 giây đến 50 giây (chỉ sử dụng trạng thái hiện tại: Kích thước còn lại / Tốc độ tải xuống) hoặc, rất có thể, trình duyệt sử dụng thuật toán trung bình lăn sẽ điều chỉnh cho các biến động về tốc độ truyền mà không hiển thị các bước nhảy ấn tượng cho người dùng.
Ví dụ về thuật toán cuộn liên quan đến việc tải xuống tệp có thể hoạt động như sau:
- Tốc độ truyền trong 60 giây trước đó được ghi nhớ với giá trị mới nhất thay thế giá trị cũ nhất (ví dụ: giá trị 61 thay thế giá trị đầu tiên).
- Tỷ lệ chuyển giao hiệu quả cho mục đích tính toán là trung bình của các phép đo này.
- Thời gian còn lại được tính như sau: Kích thước tải xuống còn lại / hiệu quả
Vì vậy, sử dụng kịch bản của chúng tôi ở trên (vì mục đích đơn giản, chúng tôi sẽ sử dụng 1 MB = 1.000 KB):
- Sau 75 giây tải xuống, 60 giá trị được nhớ của chúng tôi sẽ là 1.000 KB. Tốc độ truyền tải hiệu quả là 1.000 KB (60.000 KB / 60), thời gian còn lại là 25 giây (25.000 KB / 1.000 KB).
- Tại 76 giây (khi tốc độ truyền tải giảm xuống 500 KB), tốc độ tải xuống hiệu quả trở thành ~ 992 KB (59.500 KB / 60), cho thời gian còn lại là ~ 24,7 giây (24.500 KB / 992 KB).
- 77 giây: Tốc độ hiệu quả = ~ 983 KB (59.000 KB / 60) cho thời gian còn lại là ~ 24,4 giây (24.000 KB / 983 KB).
- 78 giây: Tốc độ hiệu quả = 975 KB (58.500 KB / 60) cho thời gian còn lại là ~ 24.1 giây (23.500 KB / 975 KB).
Bạn có thể thấy mô hình đang nổi lên ở đây khi tốc độ nhúng trong tốc độ tải xuống từ từ được tích hợp vào mức trung bình được sử dụng để ước tính thời gian còn lại. Theo phương pháp này, nếu nhúng chỉ kéo dài trong 10 giây và sau đó trở về 1 MB / s người dùng không có khả năng nhận thấy sự khác biệt (tiết kiệm cho một gian hàng rất nhỏ trong thời gian đếm ngược ước tính).
Tìm đến các đinh đồng - đây là phương pháp đơn giản để chuyển tiếp thông tin đến người dùng cuối vì nguyên nhân cơ bản thực sự…
Bạn không thể xác định chính xác điều gì đó không xác định
Cuối cùng, thanh tiến trình không chính xác tóm lại thực tế là nó đang cố gắng xác định thời gian cho cái gì đó không xác định. Bởi vì máy tính xử lý các nhiệm vụ cả về nhu cầu và nền, hầu như không thể biết được tài nguyên hệ thống nào sẽ có sẵn tại bất kỳ điểm nào trong tương lai - và đó là sự sẵn có của tài nguyên hệ thống cần thiết cho bất kỳ tác vụ nào cần hoàn thành.
Sử dụng một ví dụ khác, giả sử bạn đang chạy nâng cấp chương trình trên máy chủ thực hiện cập nhật cơ sở dữ liệu khá chuyên sâu. Trong quá trình cập nhật này, người dùng sau đó gửi yêu cầu yêu cầu đến một cơ sở dữ liệu khác đang chạy trên hệ thống này. Bây giờ tài nguyên máy chủ, đặc biệt cho cơ sở dữ liệu, đang phải xử lý các yêu cầu cho cả nâng cấp của bạn cũng như truy vấn do người dùng khởi tạo - một kịch bản chắc chắn sẽ có hại lẫn nhau với thời gian thực thi. Cách khác, người dùng có thể bắt đầu một yêu cầu chuyển tập tin lớn để tính thuế thông lượng lưu trữ, điều này cũng sẽ làm giảm hiệu suất. Hoặc một tác vụ được lên lịch có thể khởi động thực hiện một quá trình chuyên sâu về bộ nhớ. Bạn có được ý tưởng.
Như, có lẽ, một ví dụ thực tế hơn cho người dùng hàng ngày - hãy xem xét chạy Windows Update hoặc quét vi-rút. Cả hai hoạt động này thực hiện các hoạt động chuyên sâu về tài nguyên trong nền. Kết quả là, sự tiến bộ của mỗi phụ thuộc vào những gì người dùng đang thực hiện tại thời điểm đó. Nếu bạn đang đọc email của bạn trong khi điều này chạy, rất có thể nhu cầu về tài nguyên hệ thống sẽ thấp và thanh tiến trình sẽ di chuyển nhất quán. Mặt khác, nếu bạn đang thực hiện chỉnh sửa đồ họa thì nhu cầu của bạn về tài nguyên hệ thống sẽ lớn hơn nhiều, điều này sẽ khiến cho thanh tiến trình chuyển động tâm thần phân liệt.
Nói chung, nó chỉ đơn giản là không có quả cầu pha lê. Ngay cả bản thân hệ thống cũng không biết tải trọng của nó sẽ ở bất kỳ thời điểm nào trong tương lai.
Cuối cùng, nó thực sự không quan trọng
Mục đích của thanh tiến trình là, tốt, cho biết tiến trình thực sự đang được thực hiện và quá trình tương ứng không được treo. Nó là tốt đẹp khi chỉ số tiến độ là chính xác, nhưng thường nó chỉ là một ít phiền toái khi nó không phải là. Đối với hầu hết các phần, các nhà phát triển sẽ không dành rất nhiều thời gian và công sức vào các thuật toán thanh tiến trình bởi vì, thẳng thắn, có nhiều nhiệm vụ quan trọng hơn để dành nhiều thời gian.
Tất nhiên, bạn có mọi quyền để được khó chịu khi một thanh tiến trình nhảy đến 99% hoàn thành ngay lập tức và sau đó làm cho bạn chờ đợi 5 phút cho một phần trăm còn lại. Nhưng nếu chương trình tương ứng hoạt động tốt tổng thể, chỉ cần nhắc nhở bản thân rằng nhà phát triển có ưu tiên của họ thẳng.
