מפתח אומר: "האפליקציה מגמגמת במעבר בין מסכים." זה לא נתון בר-פעולה. פרופילינג של CPU באפליקציה ניידת באמצעות Instruments ו-Android Profiler נותן מספרים מדויקים במקום ניחושים. בכל פרויקט אחר שאנחנו בודקים יש בעיות ביצועי CPU ב-thread הראשי. בממוצע, אנחנו מוצאים 5–7 צווארי בקבוק לכל 1000 שורות קוד. תמונה טיפוסית: 80% מהזמן מושקע ב-20% מהמתודות — חוק פארטו בפעולה. בלי פרופילינג, למצוא את ה-20% האלה כמעט בלתי אפשרי. נתון מדויק הוא: "המעבר מ-HomeViewController ל-DetailViewController לוקח 380 אלפיות שנייה, מתוכן 240 אלפיות שנייה מושקעות ב-viewDidLoad של DetailViewController, ו-200 אלפיות שנייה מתוכן הן NSJSONSerialization.jsonObject סינכרוני ב-thread הראשי." זו רמת הדיוק שפרופילר CPU מספק. בלעדיו, 80% מה"אופטימיזציות" לא מניבות תוצאה.
למה פרופילינג CPU הוא הצעד הראשון לאפליקציה מהירה
הפעל את Instruments דרך Xcode → Product → Profile או ⌘I. עבור CPU אנחנו משתמשים ב-Time Profiler (פרופילר דגימה, מרווח של 1 אלפית שנייה כברירת מחדל) או ב-CPU Profiler (מבוסס אינסטרומנטציה, מדויק יותר אבל עם עד 30% תקורה). דגימה יעילה יותר לאבחון ראשוני: תקורה נמוכה יותר ועץ קריאות קל יותר לקריאה.
Time Profiler הוא הבחירה הראשונה לרוב המשימות. הוא מציג עץ קריאות עם זמן הביצוע של כל מתודה. הגדרות קריטיות:
- Hide System Libraries — הסר רעש ממסגרות מערכת, ראה רק את הקוד שלך.
- Separate by Thread — הבן באיזה thread מתרחש הגמגום.
- Invert Call Tree — מציג את "העלים" של עץ הקריאות, כלומר מתודות שבהן הזמן באמת מושקע.
תרחיש טיפוסי: הקלט 10 שניות של פעילות אפליקציה, פתח את עץ הקריאות. [MyImageProcessor processImage:] לוקח 67% CPU. הרחב — vImageScale_ARGB8888 נקרא ב-thread הראשי מ-didSelectRowAt. העבר אותו ל-DispatchQueue.global(qos: .userInitiated), החל תוצאה על DispatchQueue.main.async — הבעיה נפתרה. זמן הפעולה יורד פי 3–4, ומהירות הגלילה חוזרת.
Signposts ו-os_log למדידה מדויקת
לפרופילרים מערכתיים יש תקורה ורעש. למדידה מדויקת של פעולה ספציפית — השתמש ב-os_signpost:
import os.signpost
let log = OSLog(subsystem: "com.app", category: "Performance")
let id = OSSignpostID(log: log)
os_signpost(.begin, log: log, name: "Image Processing", signpostID: id)
processImage(data)
os_signpost(.end, log: log, name: "Image Processing", signpostID: id)ב-Instruments → רצועת Logging אתה רואה חותמות זמן מדויקות. זה מאפשר לך למדוד לא "איפה זה מגמגם בכלל", אלא "בדיוק כמה זמן הפעולה הזו לוקחת עם קלטים שונים". הוספת סימון signpost משתלמת בכל סשן פרופילינג עוקב.
איך לקרוא גרף להבה (Flame Graph)
Xcode Time Profiler המודרני מציג גרף להבה. מלבנים אופקיים רחבים הם מתודות שצורכות הרבה זמן. קינון מציג את מחסנית הקריאות. הכלל המרכזי: חפש רמות — בלוקים רחבים בלי מתודות ילד. אלה הם "התחתיות" של המחסנית שבהן הזמן באמת מושקע. לדוגמה, רמה על import os.signpost let log = OSLog(subsystem: "com.app", category: "Performance") let id = OSSignpostID(log: log) os_signpost(.begin, log: log, name: "Image Processing", signpostID: id) processImage(data) os_signpost(.end, log: log, name: "Image Processing", signpostID: id) ברוחב 200 אלפיות שנייה היא מועמדת ברורה להעברה לרקע.
Android Studio Profiler: CPU
Android Studio CPU Profiler תומך בשלושה מצבים:
| מצב | מתי להשתמש | תקורה |
|---|---|---|
| Sample Java/Kotlin Methods | אבחון ראשוני | נמוכה (1-5%) |
| Trace Java/Kotlin Methods | ניתוח מדויק, צריך מחסנית מלאה | גבוהה (עד 30%) |
| Sample C/C++ Functions | קוד native, NDK | נמוכה |
| System Trace | אירועי מערכת, פריימים מגמגמים | מינימלית |
System Trace הוא האינפורמטיבי ביותר לניתוח גמגום. הוא מציג NSJSONSerialization, Choreographer#doFrame, RenderThread, קריאות binder. אתה יכול לראות בדיוק איזה פריים התעכב ולמה.
הקלט דרך ממשק המשתמש או פרוגרמטית:
Debug.startMethodTracing("myapp_trace") // операция Debug.stopMethodTracing() קובץ ה-hwuiTask נפתח ב-Android Studio Profiler לניתוח.
ממצאים טיפוסיים באנדרואיד
הפרופילינג הראה: בפתיחת מסך הצ'אט, 180 אלפיות שנייה הושקעו ב-Debug.startMethodTracing("myapp_trace") // операция Debug.stopMethodTracing() — המפתח טען את כל ההגדרות בכל פעם כדי לבדוק דגל. .trace ב-thread הראשי עם קובץ של 2 MB (בגלל נתונים שמורים במטמון) — חוסם UI אמיתי. מעבר ל-SharedPreferences.getAll() עם קריאה ברקע דרך SharedPreferences ביטל לחלוטין את העיכוב הזה. זמן שנחסך: 180 אלפיות שנייה בכל פתיחה.
בעיות iOS נפוצות
NSJSONSerialization סינכרוני ב-thread הראשי, טעינת תמונות ללא מטמון ב-UITableViewCell, קריאות setNeedsDisplay מוגזמות — 3 הדפוסים האלה מופיעים ב-70% מפרויקטי iOS עם בעיות תגובתיות. תיקון השניים הראשונים מעלה את ה-FPS מ-30 ל-60 ללא שינויים ארכיטקטוניים.
איך אנחנו מבצעים פרופילינג: שלבים
- ניתוח — הגדר תרחישי משתמש מרכזיים (גלילת פיד, פתיחת מסך, טעינת תוכן).
-
עיצוב מדידה — הוסף
DataStore/Flowלפעולות קריטיות. - יישום — הקלט סשנים תחת עומס (מכשיר אמיתי, build release).
- בדיקה — נתח עץ קריאות וגרף להבה, תפוס 3 בעיות עיקריות.
- מסירה — מסור דוח וקוד עם תיקונים.
השוואת כלים:
| פרמטר | Instruments (iOS) | Android Profiler |
|---|---|---|
| שיטת איסוף | דגימה / אינסטרומנטציה | דגימה / Trace |
| תצוגת מחסנית | עץ קריאות + גרף להבה | Flame Chart + Top Down |
| תקורת הקלטה | 1-5% (דגימה) | 1-10% (דגימה) |
| דיוק עד | 1 אלפית שנייה (דגימה) | 0.1 אלפית שנייה (trace) |
תיעוד Google Developers מציין ש-System Trace הוא המדויק ביותר לגמגום.
מה כלול בעבודה
- הכנת סקריפטים לפרופילינג אוטומטי (אוטומציית UI + מצב Benchmark).
- הקלטת סשן ראשוני (10-15 דקות של שימוש פעיל באפליקציה).
- דוח PDF עם עץ קריאות, גרף להבה וצילומי מסך עם הערות.
- המלצות לתיקון עם דוגמאות קוד (Swift/Kotlin).
- פרופילינג חוזר לאחר שינויים לאישור תוצאות.
לוח זמנים: פרופילינג וניתוח — יום עד יומיים. פתרון בעיות — יומיים עד שבועיים בהתאם למורכבות. עלות ביקורת עם דוח נקבעת לאחר סקירת הקוד שלך. אנחנו מציעים הערכת פרויקט. אנחנו מבטיחים לפחות 30% הפחתה בעומס CPU ב-thread הראשי.
מעל 40 פרויקטים באופטימיזציית ביצועים וניסיון עמוק בפיתוח מובייל — המהנדסים שלנו יודעים למצוא ולחסל צווארי בקבוק.
קבל ייעוץ על אופטימיזציית ה-CPU של האפליקציה שלך — צור קשר. הזמן פרופילינג וקבל דוח עם המלצות ספציפיות.