ניתוח של ביצועי זמן ריצה

Kayce Basques

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

שנתחיל?

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

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

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

   https://googlechrome.github.io/devtools-samples/jank/

3. כדי לפתוח את DevTools, מקישים על Command+Option+I (ב-Mac) או על Control+Shift+I (ב-Windows או ב-Linux).

   

סימולציה של מעבד בנייד

עוצמת המעבד (CPU) של מכשירים ניידים נמוכה בהרבה מזו של מחשבים נייחים ומחשבים ניידים. בכל פעם שאתם יוצרים פרופיל של דף, כדאי להשתמש בויסות נתונים של מעבד (CPU Throttling) כדי לדמות את הביצועים של הדף במכשירים ניידים.

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

4. בשביל CPU, בוחרים באפשרות האטה פי 4. כלי הפיתוח מווסתים את המעבד (CPU) כך שהוא יהיה איטי פי 4 מהרגיל.

   

הגדרת הדגמה

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

1. ממשיכים ללחוץ על הוספת 10 עד שהריבועים הכחולים זזים לאט יותר באופן משמעותי מבעבר. במחשב מתקדם, התהליך עשוי להימשך כ-20 קליקים.

2. לוחצים על אופטימיזציה. הריבועים הכחולים אמורים לזוז מהר יותר ובצורה חלקה יותר.

3. לוחצים על ביטול האופטימיזציה. הריבועים הכחולים זזים לאט יותר ויותר, והם זזים שוב ושוב.

תיעוד הביצועים בזמן הריצה

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

1. ב-DevTools, לוחצים על Record (הקלטה) radio_button_checked. כלי הפיתוח מתעד את מדדי הביצועים בזמן שהדף פועל.

   

2. ממתינים מספר שניות.

3. לוחצים על הפסקה. DevTools מפסיק את ההקלטה, מעבד את הנתונים ומציג את התוצאות בחלונית ביצועים.

   

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

ניתוח התוצאות

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

ניתוח פריימים לשנייה

המדד העיקרי למדידת הביצועים של כל אנימציה הוא פריימים לשנייה (FPS). משתמשים נהנים כשהאנימציות פועלות במהירות של 60FPS.

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

   

2. מתחת לתרשים FPS מופיע התרשים CPU. הצבעים בתרשים CPU תואמים לצבעים בכרטיסייה Summary (סיכום), שבתחתית החלונית Performance (ביצועים). אם תרשים המעבד מלא בצבע, סימן שהמעבד הגיע למקסימום במהלך ההקלטה. אם המעבד עובד במלוא הקיבולת למשך תקופות ארוכות, כדאי למצוא דרכים לבצע פחות עבודה.

   

3. מעבירים את העכבר מעל התרשימים FPS,‏ CPU או NET. כלי הפיתוח מציגים צילום מסך של הדף בנקודת הזמן הזו. כדי להפעיל מחדש את ההקלטה, מזיזים את העכבר שמאלה וימינה. הפעולה הזו נקראת 'דילוג', והיא שימושית לניתוח ידני של התקדמות האנימציות.

   

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

   

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

בונוס: פתיחת המד FPS

כלי שימושי נוסף הוא מד ה-FPS, שמספק אומדנים בזמן אמת של FPS בזמן שהדף פועל.

1. מקישים על Command+Shift+P (Mac) או על Control+Shift+P (Windows, ‏ Linux) כדי לפתוח את תפריט הפקודות.
2. מתחילים להקליד Rendering בתפריט הפקודות ובוחרים באפשרות Show Rendering.

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

   

4. משביתים את מדד ה-FPS ומקישים על Escape כדי לסגור את החלונית עיבוד. לא נשתמש בה במדריך הזה.

איתור צוואר בקבוק

אחרי שמדדתם וווידאתם שהאנימציה לא מניבה ביצועים טובים, השאלה הבאה היא: למה?

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

   

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

   

3. יש הרבה נתונים בהקלטה. כדי להגדיל את התצוגה של אירוע Animation Frame Fired יחיד, לוחצים על Overview (סקירה כללית), שומרים על לחיצה על העכבר וגוררים אותו. הקטע הזה כולל את התרשימים FPS,‏ CPU ו-NET. בקטע עיקרי ובכרטיסייה סיכום מוצגים רק פרטים לגבי החלק שנבחר מההקלטה.

   

4. שימו לב למשולש האדום בפינה השמאלית העליונה של אירועי המשימה והפריסה. אם מופיע משולש אדום, סימן שיש אזהרה לגבי האירוע הזה. משולש אדום במשימה פירושו שהיא הייתה משימה ארוכה.

5. לוחצים על האירוע אנימציה של מסגרת הופעלה. עכשיו מוצג בכרטיסייה Summary מידע על האירוע הזה. לחיצה על הקישור שלצד Initiated by (האירוע הופעל על ידי) תגרום ל-DevTools להדגיש את האירוע שהפעיל את האירוע Animation Frame Fired (הוצגה מסגרת של אנימציה). שימו לב גם לקישור app.update @. לחיצה עליו תוביל אתכם לשורה הרלוונטית בקוד המקור.

   

6. מתחת לאירוע app.update יש כמה אירועים בצבע סגול. אם הן היו רחבות יותר, יכול להיות שכל אחת מהן הייתה כוללת משולש אדום. לוחצים על אחד מהאירועים הסגולים של פריסה. בכרטיסייה Summary (סיכום) ב-DevTools מוצג מידע נוסף על האירוע. אכן יש אזהרה לגבי אילוץ של הזרמה חוזרת (מילה נוספת לפריסה).

7. בכרטיסייה Summary, לוחצים על הקישור לצד app.update @ בקטע First Layout Invalidation. כלי הפיתוח מעבירים אתכם לשורת הקוד שאילצה את הפריסה.

   

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

בונוס: ניתוח הגרסה שעברה אופטימיזציה

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

השלבים הבאים

המודל RAIL הוא הבסיס להבנת הביצועים. המודל הזה מראה לכם אילו מדדי ביצועים הכי חשובים למשתמשים שלכם. מידע נוסף זמין במאמר מדידת הביצועים באמצעות מודל RAIL.

כדי להתרגל לחלונית הביצועים, מומלץ להתנסות בה. נסו ליצור פרופילים של הדפים שלכם ולנתח את התוצאות. אם יש לכם שאלות לגבי התוצאות, אתם יכולים לפתוח שאלה ב-Stack Overflow עם התג google-chrome-devtools. אם אפשר, כדאי לכלול צילומי מסך או קישורים לדפים שאפשר לשחזר.

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

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

• אופטימיזציה של ביצוע JS
• הפחתת ההיקף והמורכבות של חישובי סגנון
• הימנעות מפריסות גדולות ומורכבות ומטרהוש של פריסות
• פישוט המורכבות של הצביעה והקטנת אזורי הצביעה
• שימוש בנכסים של רכיב עיבוד גרפי בלבד וניהול מספר השכבות
• ניקוי נתוני ה-debounce של מנהלי הקלט