הזמן שנותר תקוע על שנייה אחת ולא זז הרבה זמן — האם זו תקלה?

התצוגה לבדה לא מספיקה כדי להחליט. צריך לבדוק בנפרד הערכת קצב שלא דייקה, שלב עבודה אחרון, מסך שלא מתעדכן ועצירה אמיתית. אפשר לבדוק שינויים במספר הפריטים ובלוגים, ולחפש חלון שמחכה לאישור. אין לסיים את התהליך בכוח רק בגלל המספר שנייה אחת.

אם מוצג 99%, האם גם הזמן שנותר הוא 1% מהכול?

לא. המשמעות משתנה לפי האם ה-99% מייצגים מספר פריטים, נפח נתונים או שלבי עבודה, והזמן לכל יחידה כזאת אינו בהכרח זהה. אחוז התקדמות הוא חלק מהעבודה, ולא הזמן שנותר עצמו.

אם אנימציה עגולה מסתובבת, האם העיבוד תקין?

זו לא הוכחה שהעיבוד מתקדם. בתכנון שבו האנימציה והעיבוד פועלים בנפרד, האנימציה יכולה להסתובב גם כשהעבודה ממתינה. מפרידים בינה לבין עדויות להשלמת עבודה — מספר פריטים, שלבים ולוגים.

אם אי אפשר להעריך את הזמן שנותר, אי אפשר להציג progress bar?

אפשר. אם הסך הכולל והכמות שהושלמה ידועים, אפשר להציג את היחס ביניהם, ואם הקצב לא יציב אפשר לתכנן כך שהזמן שנותר פשוט לא יוצג. כשהסך הכולל עצמו אינו ידוע, מציגים תצוגה לא מוגדרת יחד עם שם השלב ומספר הפריטים שהושלמו, בלי להמציא אחוז.

למה "נותרה שנייה אחת" לא נגמרת? — איך עובדים progress bar והזמן שנותר

8 Sep 2026 20:00 · עודכן בתאריך: 15 Sep 2026 · Go Komura · Windows, progress bar, זמן שנותר, UI, ביצועים

הסתכלת על “נותרה שנייה אחת” — ועברו כבר 30 שניות. בדיוק כשחשבת שזה נגמר, זה חזר ל”נותרו 2 דקות”.

העתקת קבצים, התקנת אפליקציה, ייצוא וידאו. progress bar הוא כלי שימושי, אבל לפעמים נראה שהוא פועל בעולם אחר מזה של השעון.

למעשה, progress bar אינו שעון. אחוז ההתקדמות מתאר כמה מהעבודה הושלמה, הזמן שנותר הוא הערכה של כמה עוד עשוי לקחת, והסיום פירושו שהפעולות הנדרשות הצליחו. ההפרדה בין שלושת הדברים האלה משנה את הדרך שבה רואים מצב שבו 99% לא נגמר.

המאמר הזה מסביר את המנגנונים הכלליים על סמך תיעוד של Windows API ו-UI. הוא לא מנתח את האלגוריתם הפנימי של גרסה מסוימת של סייר הקבצים. הדוגמאות המספריות וה-demo ההשוואה הם עומס עבודה פיקטיבי לצורכי הסבר, ולא מדידות של מחשב או של חיבור רשת.

1. קודם כל לבדוק: 100% של מה?

נניח שאתה בודק 100 מסמכים. אם 99 מהם הם פתקים קצרים ורק האחרון הוא חוזה עבה, “99 מסמכים הושלמו” הוא משפט נכון — אבל הוא לא אומר ש”99% מהזמן עבר”.

גם בתצוגת התקדמות המשמעות משתנה לפי מה שנבחר כמכנה.

בסיס התצוגה	מה המשמעות של 50%	מה שאי אפשר לדעת מהמספר הזה בלבד
מספר הקבצים	מחצית מהקבצים ביעד עובדו	הגודל של הקבצים שנותרו וזמן העיבוד שלהם
נפח הנתונים	מחצית מהבתים ביעד עובדו	הקצב בהמשך, ושלבים שאינם העברה
משקל של שלבים	התקדמנו עד מחצית מהחלוקה שנקבעה	האם החלוקה מתאימה למשך הזמן בפועל בסבב הזה

לדוגמה, ה-progress callback שבו משתמש CopyFileEx ב-Windows מקבל את מספר הבתים הכולל של הקובץ ואת מספר הבתים שהועברו. זהו מידע על כמות העבודה, והוא לא מוסר שניות עתידיות ישירות. ¹

flowchart TB
    accTitle: ההבדל בין אחוז התקדמות, זמן שנותר וסיום
    accDescr: התרשים מפריד בין יחס שמחושב מהכמות שהושלמה, הערכת זמן שנשענת על הנחת קצב, ובין סיום שנקבע לפי תוצאה מוצלחת.
    A["הכמות שהושלמה וסך העבודה"] --> B["אחוז התקדמות"]
    C["העבודה שנותרה וקצב חזוי"] --> D["זמן משוער שנותר"]
    E["הצלחה של הפעולות הנדרשות"] --> F["השלמת כל העבודה"]

איור 1: יחס, חיזוי ותוצאה אינם שלושה שמות לאותו מידע.

במאמר הזה נבדיל בין אחוז התקדמות — היחס של כמות העבודה המדידה שהושלמה, progress bar — הרצוע שמוצגת למשתמש, והערכת הזמן שנותר — החיזוי לפי שניות. גם אי אפשר להפיק הערכה, ההתקדמות שכבר נמדדה לא נעלמת.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 9, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. החישוב שבו “נותרו 10 שניות” הופך ל”נותרו 79 שניות”

ההערכה הפשוטה ביותר של הזמן שנותר היא הנוסחה הבאה.

זמן שנותר ≈ עבודה שנותרה ÷ הערכת קצב העיבוד בהמשך

הקושי אינו בחילוק, אלא בקצב העתידי, שעוד לא נצפה. לכן מנבאים אותו בעזרת קצב מהעבר. גם Raymond Chen מ-Microsoft הסביר בהסבר מ-2004 על הערכת זמני העתקה את הקושי הזה בניבוי העתיד. זה אינו מפרט של החישוב המשמש ב-Windows של היום. ²

נחשוב על העתקה פיקטיבית של 1,000 MiB. כאן MiB הוא 1,048,576 בתים. נניח שהיא מתקדמת בקצב קבוע של 80 MiB/s במשך 2.5 שניות, ורק בשנייה שאחר כך הקצב יורד ל-10 MiB/s.

נקודת התצפית	הועבר	נותר	הקצב שמשמש להערכה	זמן שנותר
2.5 שניות מההתחלה	200 MiB	800 MiB	80 MiB/s	800 ÷ 80 = 10 שניות
3.5 שניות מההתחלה	210 MiB	790 MiB	10 MiB/s	790 ÷ 10 = 79 שניות

במהלך אותה שנייה העבודה כן התקדמה. ובכל זאת, מכיוון שהקצב החזוי לעבודה שנותרה ירד לשמינית, ההערכה מתארכת. בדוגמה הזאת משתמשים בקצב של מרווח התצפית האחרון כפי שהוא.

flowchart TB
    accTitle: למה הזמן שנותר יכול לגדול גם כשהעבודה מתקדמת
    accDescr: כשהקצב החזוי יורד מספיק, ההשפעה שלו גדולה מהקטנת העבודה שנותרה, והזמן שנותר שמחושב גדל.
    A["10 MiB הושלמו בשנייה אחת"] --> B["נותרה פחות עבודה"]
    C["הקצב החזוי ירד בחדות"] --> D["הזמן שנותר יכול לגדול"]
    B --> D

איור 2: עלייה בהערכת הזמן שנותר היא דבר אחר מכך שהעיבוד חזר אחורה.

גם “נותרה שנייה אחת” עובד באותו אופן. כמות שהייתה מסתיימת בשנייה אחת לפי הקצב הקודם לא תסתיים בשנייה אם הפעולה הבאה איטית יותר. גם מרווחי התצפית ואופן עיגול השניות משפיעים על התצוגה. אבל אם אותו מספר נשאר לנצח, אין להסיק מכך שהכול תקין: נדרשת אותה הפרדה בין שלבי העבודה, עדכון המסך ועצירה אמיתית, כפי שמתואר בהמשך.

3. האם ממוצע יהפוך את ההערכה למדויקת?

אם מכניסים לתצוגה כל שינוי רגעי בקצב, המספר קופץ למעלה ולמטה. מצד שני, אם משתמשים רק בממוצע מתחילת העבודה, ההשפעה של התחלה מהירה נשארת, וההערכה מתקשה להדביק האטה מתמשכת שבאה אחריה.

אפשר להסביר את ההבדל לפי איך שמערבבים את התצפיות. אם נערבב חצי-חצי את הקצב הקודם 80 והקצב העדכני 10, הקצב החזוי יהיה 45. ההערכה תהיה חלקה יותר מאשר שימוש ב-10 בלבד, אבל אם הקצב באמת נשאר 10, היא תישאר אופטימית לזמן מה. חלקות והתאמה לשינויים הן שתי מטרות שונות.

flowchart TB
    accTitle: הפשרה כשמחליקים את הערכת הקצב
    accDescr: משקל גבוה לקצב העדכני הופך את ההערכה לרגישה לשינויים אך תנודתית, ומשקל גבוה לעבר הופך אותה לחלקה אך איטית בהתאמה.
    A["תצפיות של קצב"] --> B["משקל גבוה לנתון העדכני"]
    A --> C["משקל גבוה לעבר"]
    B --> D["רגיש לשינויים אך תנודתי"]
    C --> E["חלק אך מתאים את עצמו לאט"]

איור 3: מספר שנראה רגוע אינו בהכרח חיזוי מדויק.

זו דוגמה לחשיבה על שיטות הערכה, ולא תיאור של מימוש במוצר מסוים. ההמלצה התכנונית שלי במאמר הזה היא לא לכפות ספירה לאחור מיד אחרי ההתחלה או מיד אחרי מעבר שלב, אלא להמתין לתצפיות מספקות ואז להציג הערכה כמו “כדקה”. עדיף לומר שהזמן שנותר נמצא בחישוב מחדש מאשר להחזיק ב”נותרה שנייה אחת” בלי בסיס.

4. 99 קבצים הושלמו, אבל לפי נפח הנתונים רק 9.9%

הפעם הבעיה היא לא הקצב אלא היחידה שסופרים בה. נניח שיש 100 קבצים, ש-99 הראשונים הם 1 MiB כל אחד, והקובץ האחרון הוא 901 MiB. הסך הכולל הוא 1,000 MiB.

בנקודה שבה 99 הקבצים הראשונים הושלמו, לפי מספר הקבצים זה 99 ÷ 100 = 99%. אבל לפי נפח הנתונים זה 99 ÷ 1,000 = 9.9%. נשאר רק קובץ אחד, אבל 90.1% מהנתונים עוד לפנינו. שני החישובים נכונים — הם פשוט סופרים דברים שונים.

flowchart TB
    accTitle: כשהקובץ האחרון גדול
    accDescr: כשאחרי 99 קבצים קטנים נשאר קובץ גדול, ההתקדמות לפי מספר הקבצים מתרחקת מההתקדמות לפי נפח הנתונים.
    A["99 קבצים קטנים"] --> B["כמעט סיום לפי מספר הקבצים"]
    C["קובץ גדול נשאר לאחרון"] --> D["נפח גדול מהנתונים עוד נותר"]
    B --> E["אותה עבודה, תצוגות שונות"]
    D --> E

איור 4: 99% לפי מספר הקבצים לא מבטיח שרק 1% מזמן העיבוד נותר.

אז אולי מספיק להסתכל רק על מספר הבתים? גם זה לא. בהעברה של קבצים קטנים רבים דרך SMB יש overhead חוזר של יצירת קבצים ושל הלוך-חזור של בקשות. גם כשסך הבתים זהה לזה של קובץ גדול אחד, הזמן לא יהיה זהה. ³

לכן גם אם המדידה “נותרו 500 MiB” נכונה, אם ההרכב של אותם 500 MiB משתנה, משך הזמן יכול להשתנות. ההצגה של גם מספר הקבצים וגם מספר הבתים מועילה לא מפני שאחד מהם שגוי, אלא מפני שכל אחד מהם משלים את מה שהשני לא מראה.

5. “מכין” ממושך יכול להיות חיפוש אחרי המכנה

כדי להציג אחוז צריך מכנה — את הסך הכולל. אבל ברגע שנותנים הוראה “לעבד את כל התיקייה”, אין זה אומר שהמערכת כבר סיימה למנות את כל הקבצים שבתוכה.

נניח שהמערכת חשבה שיש 100 פריטים ועיבדה 80, ואז גילתה עוד 100. אותו מספר של 80 פריטים שהושלמו עובר מ-80/100 ל-80/200. התצוגה יורדת מ-80% ל-40%, אבל העבודה שהושלמה לא נעלמה. הצגה של סך זמני כערך סופי היא שיצרה את הפער מול הציפיות של המשתמש.

flowchart TB
    accTitle: תצוגה בשלב שבו הסך הכולל עוד לא ידוע
    accDescr: בזמן בירור היעדים אין לקבוע אחוז סופי, וכשהסך הכולל ידוע מציגים יחד איתו את הכמות שהושלמה כדי לקבל אחוז התקדמות.
    A["בירור היעדים"] --> B{"האם הסך הכולל ידוע?"}
    B -->|"עוד לא"| C["הצגת שם השלב ומספר הפריטים שהתגלו"]
    B -->|"כן"| D["הצגת האחוז"]

איור 5: מצב שבו אין מכנה הוא מצב שונה ממצב שבו ההתקדמות היא 0%.

גם לפקדי ההתקדמות של Windows יש תצוגה עם ערך ידוע, ותצוגה שמראה פעילות כשהערך אינו ידוע. ⁴ במקרה הזה ההמלצה שלי היא שבזמן המיון (enumeration) להציג “בודק את היעדים: נמצאו 1,200 פריטים”, ורק אחרי שהסך הכולל נקבע להציג אחוז. העובדה שלא מוצג מספר שניות שנותרו אינה ראיה לכך שלא קורה כלום.

6. “ההעברה הושלמה ב-100%” ו”הכול נגמר” הם שני גבולות שונים

6.1. בסוף נשארת לפעמים עבודה אחרת

לצורכי הסבר נחלק את העבודה של אפליקציה לשלושה שלבים: העברה → אימות → קיבוע התוצאה. אם התכנון דורש אימות של מה שהועבר, סיום ההעברה לא מסיים את העבודה כולה. זו דוגמה לתכנון של אפליקציה אחת, ולא טענה שכל העתקה או התקנה עוברת בסדר הזה.

flowchart TB
    accTitle: סיום ההעברה לעומת סיום כל העבודה
    accDescr: באפליקציה הפיקטיבית הזו יש אימות וקיבוע תוצאה אחרי ההעברה, ולכן מספר הבתים שהועברו לבדו אינו קובע שהכול הצליח.
    A["העברה"] --> B["אימות"] --> C["קיבוע התוצאה"] --> D["הצלחה כוללת"]
    A -.-> E["כאן מסתיים ה-100% של ההעברה"]

איור 6: ציון ברור של מה הושלם מאפשר להסביר למה אחרי 100% יש שלב נוסף.

במקרה הזה עדיף להחליף את הסטטוס ל”ההעברה הושלמה — בשלב האימות” מאשר להחזיק את הרצוע הכוללת על 99% עם “נותרה שנייה אחת”. גם מדריך ה-UI של Microsoft לשולחן העבודה מבקש לא להציג סיום כולל לפני שהעיבוד בפועל הסתיים. ⁵

6.2. גם לכתיבה יש יותר מגבול אחד

ב-Windows כתיבה לקבצים משתמשת בדרך כלל ב-cache. הגבול בין מה שהאפליקציה כתבה לבין ההעברה לאמצעי האחסון תלוי בהגדרות ובתנאים של ה-API. ⁶ FlushFileBuffers הוא API ששולח את המידע ה-buffered של קובץ מסוים להתקן. ⁷

flowchart TB
    accTitle: תרשים מושגי של כתיבה דרך buffer
    accDescr: כשעובדים עם buffer, אין להתייחס לכתיבה שהתקבלה מהאפליקציה ולכתיבה לצד אמצעי האחסון כאל אותו אירוע.
    A["כתיבה מהאפליקציה"] --> B["נשמר ב-buffer"] --> C["נכתב לאמצעי האחסון"]

איור 7: זהו תרשים מושגי של כתיבה דרך buffer, והוא לא מציג את תנאי הסיום של מוצר מסוים.

עם זאת, אי אפשר לומר שעצירה על 99% נגרמת תמיד מכתיבה של ה-cache. אם מדובר באימות, בכתיבה או בהמתנה למשהו אחר — צריך לבדוק את התכנון של האפליקציה או את הרישומים שלה. אין להסיק ממספר של התקדמות אם מותר לשלוף כונן USB או לכבות את החשמל.

7. האם זה באמת נתקע, או שרק התצוגה נתקעה?

באפליקציות WPF ב-Windows, ה-Dispatcher של ה-UI thread מטפל בעבודת המסך. תפיסה ממושכת של ה-thread הזה מאחרת את עדכוני המסך ואת התגובה לקלט. צריך להפריד בין העיבוד שמאחורי הקלעים לבין העיבוד שמציג את התוצאה על המסך. ⁸

flowchart TB
    accTitle: המסלול מהעיבוד בפועל ועד תצוגת ההתקדמות
    accDescr: גם אם העיבוד בפועל מדווח על התקדמות, בלי עיבוד העדכון בצד ה-UI הוא לא יופיע על המסך.
    A["העיבוד בפועל"] --> B["דיווח התקדמות"] --> C["עיבוד העדכון בצד ה-UI"] --> D["הצגה על המסך"]
    E["חסימת UI thread"] -.-> C

איור 8: עצירה של התצוגה אינה בהכרח עצירה של העיבוד בפועל.

לעומת זאת, בתכנון שבו האנימציה פועלת בנפרד מהעיבוד בפועל, ה-spinner העגול יכול להמשיך להסתובב גם כשהעבודה ממתינה. “זה זז, אז הכול תקין” מול “זה לא זז, אז יש תקלה” — זו הבחנה שלא מספיקה.

מה לצפות	איזה רמז מקבלים	מה אי אפשר לקבוע מכך לבדו
שינוי במספר או בנפח הפריטים שהושלמו, או בשם השלב	התקדמות של העבודה שדווחה	האם כל העבודה תסתיים בהצלחה
זמנים, יעדים ושגיאות בלוג	היכן ומה נרשם שקרה	האם עיבוד בלי רישום בלוג נתקע
CPU, דיסק ורשת של התהליך הרלוונטי	השימוש במשאבים באותה נקודה	האם ההתקדמות תקינה, המתנה, או לופ מיותר
חלון בקשה לאישור של המשתמש	האם נדרשת פעולה של המשתמש	כל הסיבות האפשריות לעצירה

סדר הבדיקה שאני ממליץ עליו: קודם לתעד את המסך ואת שעת ההתחלה, לבדוק אם יש חלון שמחכה לפעולה של המשתמש, ולהשוות אם מספר הפריטים או הלוג משתנים. את המספרים ב-Task Manager כדאי להשאיר כראיה עזר בלבד. אם שוקלים לסיים את התהליך, לבדוק את הליך הביטול של האפליקציה ואת היחס לתוצרים חלקיים.

גם הביטול ב-.NET אינו מנגנון שעוצר את העיבוד מיד עם הבקשה, אלא דרך שיתופית שבה צד העיבוד נענה לבקשה. ⁹ זו גם הסיבה שצריך להבדיל בין “מבטל” ל”בוטל”. מספר כללי של “אחרי כמה דקות מותר לסיים בכוח” אי אפשר לקבוע רק מהתצוגה הזאת.

8. השוואה של אותה עבודה בשלוש תצוגות

פתיחת demo ההשוואה של progress bar

ה-demo מקדם בלחיצת כפתור נקודות תצפית של עבודה פיקטיבית. אין צורך להמתין, והוא לא קורא, כותב או מעלה קבצים. המקרה הראשון הוא “99 קבצים קטנים וקובץ גדול אחד”. עבור אותה נקודת תצפית מוצגים זה לצד זה: רצוע לפי מספר הקבצים, רצוע לפי נפח ההעברה, ומצב העבודה הכולל.

בזמן ההעברה של הקובץ הגדול האחרון, הרצוע של מספר הקבצים נשארת על 99% בעוד הרצוע של נפח ההעברה ממשיכה לגדול. כשנפח ההעברה מגיע ל-100%, המצב הכולל הוא עדיין “בשלב האימות”. רק נקודת התצפית הבאה היא הצלחה. אפשר לראות שרק בגלל ההבדל בתצוגה, אותה עבודה יכולה להיראות תקועה או מתקדמת.

flowchart TB
    accTitle: איך לקרוא את demo ההשוואה
    accDescr: אותה תצפית של אותה עבודה פיקטיבית מוזנת לשלוש תצוגות: מספר הקבצים, נפח ההעברה ומצב העבודה הכולל.
    A["עבודה פיקטיבית אחת"] --> B["אותה נקודת תצפית"]
    B --> C["אחוז לפי מספר הקבצים"]
    B --> D["אחוז לפי נפח ההעברה"]
    B --> E["מצב העבודה הכולל"]

איור 9: ה-demo משווה שלוש דרכים להציג עבודה אחת, ולא שלוש עבודות שונות.

במקרה השני משוחזרת האטה של הקצב מסעיף 2 ומוצג החישוב שבו 10 שניות הופכות ל-79. החישוב שמשתמשים בו הוא הבא. זו הערכה פשוטה לצורכי לימוד, ולא מימוש של אפליקציה מעשית עם ניסיונות חוזרים, עיבוד מקבילי וחיזוי נפרד לכל שלב.

function estimateSeconds(remaining, rate) {
  if (!Number.isFinite(remaining) || remaining < 0) return null;
  if (remaining === 0) return 0;
  if (!Number.isFinite(rate) || rate <= 0) return null;
  const seconds = remaining / rate;
  return Number.isFinite(seconds) ? seconds : null;
}

מעבירים ל-remaining ול-rate יחידות תואמות, למשל MiB ו-MiB/s. החזרה של 0 כאן פירושה שלא נשארה עבודה שנמדדת, ולא שהאפליקציה כולה הצליחה. אם נשארה עבודה ממשית והקצב הוא 0 או לא ידוע, מחזירים null, כדי שלא להתבלבל בין זה לבין “נותרו 0 שניות”.

9. בצד שמפתחים, המטרה היא לא להיראות מדויק אלא לא להטעות

בתכנון של המאמר הזה, הייתי מחזיק במסך ההתקדמות בנפרד את השלב הנוכחי, הכמות שנמדדה, הערכת זמן רק כשיש לה בסיס, והתוצאה — הצלחה, כישלון או ביטול. גם כשמאחדים אחוזים של שלבים לרצוע אחת, חלוקה כמו “העברה 80%, אימות 20%” היא משקל תכנוני, ולא הבטחה לחלוקת הזמן בסבב הזה.

flowchart TB
    accTitle: הרכבת מסך התקדמות מהתצפיות
    accDescr: מציגים בנפרד את השלב הנוכחי, את הכמות שנמדדה, את הזמן שנותר כשאפשר להעריכו, ואת התוצאה הסופית.
    A["מידע מהעיבוד"] --> B["השלב הנוכחי"]
    A --> C["הכמות שנמדדה וסך העבודה"]
    A --> D["הערכה כשהתנאים מאפשרים"]
    A --> E["הצלחה, כישלון או ביטול"]

איור 10: גם במסך עצמו מפרידים בין מה שנצפה לבין מה שנחזה.

לדוגמה, אם אפשר להציג “בשלב האימות: 400 / 1,000 פריטים, הזמן שנותר בחישוב”, זה עוזר גם בלי ספירה לאחור. אם מציגים חותמת זמן, חשוב להבדיל בין “הפעם האחרונה שבה ההתקדמות גדלה” לבין “הפעם האחרונה שבה המסך הצליח לתקשר”. אסור לתכנן מצב שבו רק החותמת השנייה מתעדכנת, כך שהעבודה נראית מתקדמת כהלכה כשהיא בעצם תקועה.

אותו עיקרון חל גם על נגישות. הרכיב progress ב-HTML יכול לתאר מצב שבו ההתקדמות אינה ידועה, על ידי השמטה של הערך. ¹⁰ גם בתצוגת התקדמות מותאמת ב-ARIA, אם הערך אינו ידוע משמיטים את aria-valuenow, ומעניקים לה שם שמבהיר מה מתקדם. ¹¹ לא רק המראה, אלא גם מה שנקרא בקול צריך לשקף נאמנה את מה שידוע.

10. שאלות נפוצות

הזמן שנותר הוא שנייה אחת וזה לא נגמר — האם זו תקלה?

התצוגה לבדה לא יכולה להכריע. צריך לבדוק בנפרד הערכה שלא דייקה, שלב עבודה נוסף, עיכוב בעדכון המסך ועצירה אמיתית. גם להניח “זה קורה הרבה, אז אין בעיה” וגם להסיק “עברה יותר משנייה, אז יש תקלה” הם מסקנות נחפזות.

אם זה 99%, זה אומר שנשאר 1% מזמן העבודה?

לא. בין אם היחידה של האחוז היא קבצים ובין אם בתים, אין זה אומר שהזמן ליחידה קבוע. אי אפשר להכפיל את הזמן שחלף ב-1% כדי לקבל את הזמן שנותר.

אם אנימציה עגולה מסתובבת, זה אומר שהכול תקין?

תצוגה של פעילות וראיה לכך שהעיבוד התקדם הם שני דברים שונים. מסתכלים על השילוב של כמות שהושלמה, שלב ולוגים. אנימציה לבדה לא מבטיחה שהעבודה תגיע לסיום מוצלח.

אם אי אפשר לדעת את הזמן שנותר, אי אפשר להציג progress bar?

אפשר. אם הסך הכולל והכמות שהושלמה ידועים, אפשר להציג את היחס ביניהם. כשהחיזוי לא אמין, משמיטים רק את מספר השניות. אם הסך הכולל עצמו אינו ידוע, משתמשים בתצוגה לא מוגדרת יחד עם שם השלב ומספר הפריטים שהושלמו.

11. סיכום: הזמן שנותר הוא תחזית, והסיום הוא תוצאה

“נותרה שנייה אחת” נמשך זמן רב לא מפני שהמחשב לא יודע לספור שנייה. הוא נמשך זמן רב מפני שמהעבודה שנצפתה מעריכים זמן עיבוד שעוד לא קרה. מעבר לכך מצטברים גם היחידה שסופרים בה, חיפוש היעדים, שלב העבודה האחרון ועיכוב בעדכון המסך.

flowchart TB
    accTitle: סדר הבדיקה של תצוגת התקדמות שלא נגמרת
    accDescr: בודקים לפי הסדר מה האחוז מודד, אם הקצב החזוי השתנה, אם נשאר שלב נוסף, ואם מה שנתקע הוא התצוגה או העיבוד בפועל.
    A["אחוז של מה?"] --> B["האם הקצב החזוי השתנה?"] --> C["האם נשאר שלב נוסף?"] --> D["תקיעה בתצוגה או בעיבוד?"]

איור 11: מפרקים את התסכול ממספר לשאלות שאפשר לבדוק.

המשתמש מסתכל לא רק על המספרים אלא על השלבים ועל השינויים. המפתח לא מערבב בין כמות העבודה, החיזוי והתוצאה. מעבר לכך ש”נותרה שנייה אחת” יהיה נכון שוב ושוב, התפקיד של תצוגת התקדמות טובה הוא להסביר מה קורה עכשיו ומה עוד לא ידוע.

קישורי מקור

Microsoft Learn, LPPROGRESS_ROUTINE callback function. המשמעות של מספרי הבתים שמספק ה-callback של התקדמות ההעתקה. ↩
Microsoft, The Old New Thing, Why does the copy dialog give such horrible estimates?. הסבר מ-2004. הוא מובא כאן לא כמפרט של המימוש הפנימי ב-Windows של היום, אלא כדי לתאר את הקושי לחזות קצב עתידי. ↩
Microsoft Learn, Slow SMB files transfer speed. ה-overhead החוזר של יצירת קבצים ותקשורת בהעברה של קבצים קטנים. ↩
Microsoft Learn, Progress controls. פקדים למקרה שבו אפשר לקבוע את ההתקדמות ולמקרה שבו היא אינה ידועה. ↩
Microsoft Learn, Progress Bars. מדריך תכנון לתצוגת התקדמות באפליקציות שולחניות. ↩
Microsoft Learn, File Caching. ה-cache של קבצים והטיפול בכתיבה. ↩
Microsoft Learn, FlushFileBuffers function. ה-API ששולח את המידע ה-buffered של קובץ להתקן. ↩
Microsoft Learn, Threading model. ה-Dispatcher של WPF וההיענות של ה-UI thread. ↩
Microsoft Learn, Cancellation in Managed Threads. ביטול שיתופי (cooperative) ב-.NET. ↩
WHATWG, The progress element. רכיב ההתקדמות של HTML ומצב שבו הערך אינו ידוע. ↩
W3C, WAI-ARIA 1.2: progressbar. כללים לשם ולערך של מידע התקדמות שנקרא בקול. ↩

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

נושאים טכניים ב-Windows

שער לנושאי פיתוח Windows, חקירת תקלות וניצול נכסים קיימים.

לצפייה בנושא

תהליכון ה-UI וטיימרים

תהליכון ה-UI של WPF / WinForms, זרימות אסינכרוניות, Dispatcher ותכנון טיימרים.

לצפייה בנושא

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

פיתוח יישומי Windows

יישומים עסקיים, חיבור התקנים וכלי תקשורת, מהגדרת הדרישות ועד הפיתוח.

לצפייה בשירות צרו קשר

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

הזמן שנותר תקוע על שנייה אחת ולא זז הרבה זמן — האם זו תקלה?: התצוגה לבדה לא מספיקה כדי להחליט. צריך לבדוק בנפרד הערכת קצב שלא דייקה, שלב עבודה אחרון, מסך שלא מתעדכן ועצירה אמיתית. אפשר לבדוק שינויים במספר הפריטים ובלוגים, ולחפש חלון שמחכה לאישור. אין לסיים את התהליך בכוח רק בגלל המספר שנייה אחת.
אם מוצג 99%, האם גם הזמן שנותר הוא 1% מהכול?: לא. המשמעות משתנה לפי האם ה-99% מייצגים מספר פריטים, נפח נתונים או שלבי עבודה, והזמן לכל יחידה כזאת אינו בהכרח זהה. אחוז התקדמות הוא חלק מהעבודה, ולא הזמן שנותר עצמו.
אם אנימציה עגולה מסתובבת, האם העיבוד תקין?: זו לא הוכחה שהעיבוד מתקדם. בתכנון שבו האנימציה והעיבוד פועלים בנפרד, האנימציה יכולה להסתובב גם כשהעבודה ממתינה. מפרידים בינה לבין עדויות להשלמת עבודה — מספר פריטים, שלבים ולוגים.
אם אי אפשר להעריך את הזמן שנותר, אי אפשר להציג progress bar?: אפשר. אם הסך הכולל והכמות שהושלמה ידועים, אפשר להציג את היחס ביניהם, ואם הקצב לא יציב אפשר לתכנן כך שהזמן שנותר פשוט לא יוצג. כשהסך הכולל עצמו אינו ידוע, מציגים תצוגה לא מוגדרת יחד עם שם השלב ומספר הפריטים שהושלמו, בלי להמציא אחוז.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.

לצפייה בפרופיל צרו קשר

קישורים ציבוריים

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

חזרה לבלוג

למה "נותרה שנייה אחת" לא נגמרת? — איך עובדים progress bar והזמן שנותר

1. קודם כל לבדוק: 100% של מה?

2. החישוב שבו “נותרו 10 שניות” הופך ל”נותרו 79 שניות”

3. האם ממוצע יהפוך את ההערכה למדויקת?

4. 99 קבצים הושלמו, אבל לפי נפח הנתונים רק 9.9%

5. “מכין” ממושך יכול להיות חיפוש אחרי המכנה

6. “ההעברה הושלמה ב-100%” ו”הכול נגמר” הם שני גבולות שונים

6.1. בסוף נשארת לפעמים עבודה אחרת

6.2. גם לכתיבה יש יותר מגבול אחד

7. האם זה באמת נתקע, או שרק התצוגה נתקעה?

8. השוואה של אותה עבודה בשלוש תצוגות

9. בצד שמפתחים, המטרה היא לא להיראות מדויק אלא לא להטעות

10. שאלות נפוצות

הזמן שנותר הוא שנייה אחת וזה לא נגמר — האם זו תקלה?

אם זה 99%, זה אומר שנשאר 1% מזמן העבודה?

אם אנימציה עגולה מסתובבת, זה אומר שהכול תקין?

אם אי אפשר לדעת את הזמן שנותר, אי אפשר להציג progress bar?

11. סיכום: הזמן שנותר הוא תחזית, והסיום הוא תוצאה

קישורי מקור

למה האודיו נקטע כשה-CPU לא עסוק? — מבט דרך buffer ו-deadline

למה RDP איטי למרות חיבור מהיר? — להפריד בין input, rendering ורשת

אותו 1 GB, ובכל זאת תיקיית תמונות מועתקת לאט יותר מסרטון אחד — למה?

מה זה Hardware-Accelerated GPU Scheduling ב-Windows — האם On מאיץ את המחשב?

Win32 Thread Pool API — מקביליות בלי CreateThread, דרך CreateThreadpoolWork

נושאים קשורים

נושאים טכניים ב-Windows

תהליכון ה-UI וטיימרים

שירותים הקשורים לנושא הזה

פיתוח יישומי Windows

שאלות נפוצות

פרופיל הכותב

Go Komura

1. קודם כל לבדוק: 100% של מה?

2. החישוב שבו “נותרו 10 שניות” הופך ל”נותרו 79 שניות”

3. האם ממוצע יהפוך את ההערכה למדויקת?

4. 99 קבצים הושלמו, אבל לפי נפח הנתונים רק 9.9%

5. “מכין” ממושך יכול להיות חיפוש אחרי המכנה

6. “ההעברה הושלמה ב-100%” ו”הכול נגמר” הם שני גבולות שונים

6.1. בסוף נשארת לפעמים עבודה אחרת

6.2. גם לכתיבה יש יותר מגבול אחד

7. האם זה באמת נתקע, או שרק התצוגה נתקעה?

8. השוואה של אותה עבודה בשלוש תצוגות

9. בצד שמפתחים, המטרה היא לא להיראות מדויק אלא לא להטעות

10. שאלות נפוצות

הזמן שנותר הוא שנייה אחת וזה לא נגמר — האם זו תקלה?

אם זה 99%, זה אומר שנשאר 1% מזמן העבודה?

אם אנימציה עגולה מסתובבת, זה אומר שהכול תקין?

אם אי אפשר לדעת את הזמן שנותר, אי אפשר להציג progress bar?

11. סיכום: הזמן שנותר הוא תחזית, והסיום הוא תוצאה

קישורי מקור

מאמרים קשורים

נושאים קשורים

שירותים הקשורים לנושא הזה

שאלות נפוצות

פרופיל הכותב

Go Komura