במאמר זה אנחנו נעבור על מספר עקרונות חשובים בנושא תכנות א-סינכרוני וכיצד זה נראה בדפדפנים וב-JavaScript. חשוב להבין עקרונות אלו לפני שממשיכים למאמרים הבאים במודול זה.
| ידע מוקדם: | Basic computer literacy, a reasonable understanding of JavaScript fundamentals. |
|---|---|
| מטרה: | הבנה של העקרונות הבסיסיים מאחורי תכנות א-סינכרוני וכיצד אלו באים לידי ביטוי בדפדפנים וב-JavaScript. |
באופן נורמלי, קוד של תוכנית רץ בצורה עצמאית, כאשר רק דבר אחד קורה בכל רגע נתון. אם פונקציה מסויימת נשנעת על התוצאה של פונקציה אחרת, היא חייבית לחכות לפונקציה האחרת לסיים ולהחזיר את התוצאה ועד שזה לא קורה, כל התוכנית עוצרת מנקודת מבטו של המשתמש.
Mac אלו המשתמשים ב-, לדוגמא, לפעמים רואים עיגול צבעוני... עיגול זה בעצם אומר למשתמש ״התוכנית הנוכחית שאתה מתמש בה הייתה צריכה לעצור ולחכות שמשהו הסתיים, וזה לוקח זמן..״
זו חווית שימוש מעצבנת, ולא ממש שימוש יעיל ביכולות המחשב, במיוחד בעידן שלמחשבים יש מספר ליבות מעבד זמינות. אין שום סיבה שאנחנו נחכה למשהו כשאנחנו יכולים להמשיך במקביל בעבודה שלנו בזמן שהמחשב עובד על אותה פעולה ויעדכן אותנו כשהפעולה הסתיימה. זה מאפשר לנו לבצע פעולות אחרות במקביל, וזה בעיקרון הבסיס של תכנות א-סינכרוני - asynchronous programming. זה תלוי בסביבת הפיתוח שבה אנחנו משתמשים (דפדני אינטרנט במקרה שלנו) להעניק למפתח APIs שיאפשרו לנו להריץ משימות באופן א-סינכרוני
טכניקות א-סינכרוניות הן שימושיות מאוד, במיוחד בפיתוח web. כאשר יישום web רץ בדפדפן ומריץ שורות קוד מבלי להחזיר את השליטה לדפדפן, הדפדפן יכול להיראות כאילו הוא ״קפא״. זה נקרא blocking. הדפדפן חסום מלהמשיך ולטפל בפעולות מצד המשתמש ולבצע פעולות נוספות עד אשר יישום ה-web מחזיר את השליטה למעבד.
נסתכל על מספר דוגמאות על מנת להסביר למה אנחנו מתכוונים ב- blocking
ב simple-sync.html דוגמא שלנו (או כ דף אינטרנט), הוספנו מאזין אירוע מסוג click לכפתור כך שבכל פעם שהכפתור יילחץ, הוא יריץ פעולה שלוקחת המון זמן (מחשבת 10 מיליון תאריכים ואז מחזירה את האחרון לקונסולה) ולאחר מכן מוסיפה פסקה ל-DOM:
const btn = document.querySelector('button');
btn.addEventListener('click', () => {
let myDate;
for(let i = 0; i < 10000000; i++) {
let date = new Date();
myDate = date
}
console.log(myDate);
let pElem = document.createElement('p');
pElem.textContent = 'This is a newly-added paragraph.';
document.body.appendChild(pElem);
});
כשאתם מריצים את הדוגמא למלעלה, פתחו את הקונסולה ואז לחצו על הכפתור - אתם תשימו לב שהפסקה אינה מופיעה עד אשר חישוב התאיריכים הסתיים והוצגה ההודעה לקונסולה. הקוד רץ בסדר שבה הוא מופיע בקוד המקור והפעולה האחרונה לא תרוץ עד אשר הפעולה הקודמת לא סיימה.
לתשומת לב: הדוגמא הקודמת דיי לא מציאותית. אנחנו לעול לא נחשב 10 מיליון תאריכים בתוכנית אמיתית. דוגמא זו נועדה לתת לכם רק את ההבנה של תכנות א-סינכרוני.
בדוגמא השנייה שלנו, simple-sync-ui-blocking.html (ראו כדף אינטרנט), אנחנו מנסים לדמות משהו קצת יותר ריאלי שאתם אולי תיתקלו בו בדף אמיתי. אנחנו חוסמים את האינטראקציה של המשתמש עם העיבוד של ממשק המשתמש. בדוגמא זו יש לנו שני כפתורים:
function expensiveOperation() {
for(let i = 0; i < 1000000; i++) {
ctx.fillStyle = 'rgba(0,0,255, 0.2)';
ctx.beginPath();
ctx.arc(random(0, canvas.width), random(0, canvas.height), 10, degToRad(0), degToRad(360), false);
ctx.fill()
}
}
fillBtn.addEventListener('click', expensiveOperation);
alertBtn.addEventListener('click', () =>
alert('You clicked me!')
);
אם תלחצו עלהכפתור הראשון ואז ישר לאחר מכן על השני אתם תראו שההודעה למשתמש לא מופיע עד אשר העיגולים לא סיימו להיות מעובדים. הפעולה הראשונה חוסמת את ביצוע הפעולה השנייה עד אשר הפעולה הראשונה תסתיים.
לתשומת לב: זהו אמנם נראה לא טוב, אך זוהי רק דוגמא למה שמפתחים נתקלים בה ביישומים אמיתיים.
מדוע זה קורה? התשובה נעוצה בכך ש-JavaScript היא single threaded. בנקודה, אנחנו נרצה להציג בפניכם את הרעיון של threads.
Thread הוא בעיקרון תהליך יחיד שתוכנית יכולה להשתמש בה על מנת להשלים משימות. כל תהליך כזה יכול לבצע משימה אחת בכל פעם:
Task A --> Task B --> Task C
כל משימה תרוץ באופן טורי, רציף, אך לא סימולטני. משימה צריכה להסתיים כדי שהבאה בתור תחל בריצה.
כפי שאמרנו מקודם, הרבה מחשבים הם בעלי מספר רב של ליבות, כך שהם יכולים לבצע מספר דברים בבת אחת. שפות תכנות שתומכות בליבות מרובות יכולות להתשמש בליבות אלו על מנת לבצע מספר פעולות באופן סימולטני ובמקביל:
Thread 1: Task A --> Task B Thread 2: Task C --> Task D
JavaScript היא single-threaded. אפילו אם יש מספר ליבות, אנחנו יכולים רק להריץ משימה על thread יחיד, שנקרא main thread. הדוגמא שלנו מלמעלה מורצת כך:
Main thread: Render circles to canvas --> Display alert()
לאחר זמן מסויים, JavaScript קיבלה מס׳ כלים על מנת להתמודד עם בעיות אלו. Web workers מאפשר לנו לשלוח חלק מהביצוע של JavaScript ל-thread נפרד שנקרא בשם worker, כך שאנחנו יכולים להריץ קודי JavaScript באופן סימולטני מקביל. בדרך כלל אנחנו נשתמש ב-worker להריץ תהליכי allow you to send some of the JavaScript processing off to a separate thread, called a worker, so that you can run multiple JavaScript chunks simultaneously. You'd generally use a worker to run expensive processes off the main thread so that user interaction is not blocked.
Main thread: Task A --> Task C Worker thread: Expensive task B
כעת, לאחר שאנחנו יודעים זאת, נסתכל על simple-sync-worker.html או כדף אינטרנט, ונפתח את הקונסולה. בקובץ זה כתבנו מחדש את הדוגמא שלנו לחישוב 10 מיליון תאריכים בworker thread נפרד. כעת כשאנחנו לוחצים על הכפתור, הדפדן מסוכל להציג את הפסקה לפני שחישוב התאיריכים הסתיימו. הפעולה הראשונה כבר לא חוסמת את הפעולה השנייה.
Web workers הם מאוד שימושיים, אבל יש להם הגבלות. אחת מהן היא שהם לא יכולים לגשת ל-{{Glossary("DOM")}} - אנחנו לא יכולים לגרום ל-worker לעשות שום דבר שיכול לעדכן את ממשק המשתמש, את ה-UI. אנחנו לא נוכל לעבד מיליון כדורים כחולים בתוך ה-worker שלנו. הוא בעיקרון יכול רק לעשות מניפולציות מספריות.
הבעיה השנייה היא שלמרות שהקוד שרץ בתוך ה-000000 לא חוסם, הוא עדיין בסופו של דבר סינכרוני. זה הופך לבעיה כשאר פונקציה מתבססת על התוצאה של חישובים של תהליכים שקדמו לפונקציה. הסתכלו על התרשים הבא:
Main thread: Task A --> Task B
במקרה זה, משימה A עושה משהו כמו הבאת תמונה מהשרת, ואז משימה B עושה משהו עם התמונה הזו, כגון החלת פילטר. אם אנחנו נתחיל את משימה A ואז ישר נריץ את משימה B , אנחנו נקבל שגיאה כי התמנוה עדיין לא זמינה, כי משימה A לא הסתיימה עדיין.
Main thread: Task A --> Task B --> |Task D| Worker thread: Task C -----------> | |
במקרה הזה לדוגמא, יש לנו את משימה D שמבצעת שימוש בתוצאות של משימה B ומשימה C. אם אנחנו יכולים להבטיח שהתוצאות של שתי משימות אלו יהיהו זמינות בואתו הזמן, אז זה יכול להיות תקין, אבל זה בדרך כלל לא קורה. אם משימה D תנסה לרוץ לפני שהערכים שהיא צריכה לקבל זמינים עבורה, זה יחזיר לנו רוב הסיכויים שגיאה.
על מנת לתקן בעיות שכאלו, דפדנים מאפשרים לנו להריץ מס׳ פעולות באופן א-סינכרוני. תכונות כמו Promises מאפשרות לנו לקבוע משימה שתרוץ, כמו לדוגמא הבאת תמונה מהשרת, ולחכות עד אשר התוצאה של אותה משימה תוחזר שנריץ פעולה מסויימת אחרת.
Main thread: Task A Task B
Promise: |__async operation__|
מאחר שהפעולה מתרחשת במקום אחר, ה-main thread לא חסום בזמן שהפעולה הא-סינכרונית מתרחשת.
אנחנו נסתכל כיצד אנחנו יכולים לרשום קוד א-סינכרוני במאמר הבא.
עיצוב תוכנה מודרני סובב יותר ויותר סביב שימוש בתכנות א-סינכרוני, כדי לאפשר לתוכניות לעשות יותר מדבר אחד בכל פעם. כאשר נשתמש ב-API חדשים ובעלי יכולות מתקדמות, אנחנו נמצא יותר מקרים שבהם הדרך היחידה לבצע משהו מסויים היא רק באופן א-סינכרוני. זה היה דיי קשה בעבר לכתוב קוד א-סינכרוני. אמנם עדיין לוקח זמן להתרגל לכך, אבל זה נעשה הרבה יותר קל. ביתר המאמרים במודול זה אנחנו נסביר מדוע קוד א-סינכרוני הוא רלוונטי וחשוב וכיצד נעצב את הקוד על מנת להימנע מחלק מהבעיות שסקרנו במאמר זה. יותר מדבר אחד בכל פעם. כשאתה משתמש בממשקי API חדשים וחזקים יותר, תמצא מקרים נוספים שבהם הדרך היחידה לעשות דברים היא בצורה אסינכרונית. פעם היה קשה לכתוב קוד אסינכרוני. זה עדיין לוקח להתרגל, אבל זה נעשה הרבה יותר קל. בשאר מודול זה נבדוק יותר מדוע חשוב קוד אסינכרוני וכיצד לתכנן קוד שנמנע מכמה מהבעיות שתוארו לעיל.