שלבי הכתיבה והביצועים
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
כש-Compose מעדכן פריים, הוא עובר שלושה שלבים:
- הרכב: התכונה 'יצירה' קובעת מה להציג. הוא מפעיל פונקציות שניתנות להרכבה ובונה את עץ ממשק המשתמש.
- פריסה: המערכת קובעת את הגודל והמיקום של כל רכיב בעץ ממשק המשתמש.
- ציור: התכונה Compose מעבדת בפועל את רכיבי ממשק המשתמש הנפרדים.
התכונה 'יצירה' יכולה לדלג באופן חכם על שלבים שלא נדרשים. לדוגמה, נניח שרכיב גרפי יחיד מתחלף בין שני סמלים באותו גודל. מכיוון שהגודל של הרכיב הזה לא משתנה, ולא מתווספים או מוסרים רכיבים מעץ ממשק המשתמש, Compose יכול לדלג על שלבי הקומפוזיציה והפריסה ולצייר מחדש רק את הרכיב הזה.
עם זאת, טעויות בתכנות יכולות להקשות על Compose לדעת אילו שלבים אפשר לדלג עליהם בבטחה. במקרה כזה, Compose מריץ את כל שלושת השלבים, מה שיכול להאט את ממשק המשתמש. לכן, הרבה מהשיטות המומלצות לשיפור הביצועים נועדו לעזור ל-Compose לדלג על השלבים שלא צריך לבצע.
מידע נוסף זמין במדריך שלבי Jetpack Compose.
עקרונות כלליים
יש כמה עקרונות כלליים שכדאי לפעול לפיהם כדי לשפר את הביצועים באופן כללי:
- כאשר אפשר, כדאי להעביר חישובים מחוץ לפונקציות שאפשר להרכיב.
יכול להיות שיהיה צורך להפעיל מחדש פונקציות שאפשר להרכיב בכל פעם שממשק המשתמש משתנה. כל קוד שמוסיפים לרכיב הניתן להרכבה מופעל מחדש, ויכול להיות שזה יקרה בכל פריים של אנימציה. כדאי להגביל את הקוד של הרכיב הניתן להרכבה רק למה שנדרש לבניית ממשק המשתמש.
- כדאי לדחות את קריאות המצב כמה שיותר. אם מעבירים את הקריאה של המצב לרכיב composable צאצא או לשלב מאוחר יותר, אפשר לצמצם את הפעולה של recomposition או לדלג על שלב ה-composition לגמרי. כדי לעשות את זה, מעבירים פונקציות למדא במקום ערך המצב עבור מצב שמשתנה לעיתים קרובות, ומעדיפים משנים שמבוססים על למדא כשמעבירים מצב שמשתנה לעיתים קרובות. דוגמה לטכניקה הזו מופיעה בקטע דחיית קריאות ככל האפשר במאמר שיטות מומלצות.
מקורות מידע נוספים
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-07-27 (שעון UTC)."],[],[],null,["# Compose phases and performance\n\nWhen Compose updates a frame, it goes through three phases:\n\n- **Composition:** Compose determines *what* to show. It runs composable functions and builds the UI tree.\n- **Layout:** Compose determines the size and placement of each element in the UI tree.\n- **Drawing:** Compose actually *renders* the individual UI elements.\n\nCompose can intelligently skip any of those phases if they aren't needed. For\nexample, suppose a single graphic element swaps between two icons of the same\nsize. Since this element isn't changing size, and no elements of the UI tree are\nbeing added or removed, Compose can skip over the composition and layout phases\nand redraw this one element.\n\nHowever, coding mistakes can make it hard for Compose to know which phases it\ncan safely skip, in which case Compose runs all three phases, which can slow\ndown your UI. So, many of the performance best practices are to help Compose\nskip the phases it doesn't need to do.\n\nFor more information, see the [Jetpack Compose Phases](/develop/ui/compose/phases) guide.\n\nGeneral principles\n------------------\n\nThere are a couple of broad principles to follow that can improve performance in\ngeneral:\n\n- **Whenever possible, move calculations out of your composable functions.** Composable functions might need to be rerun whenever the UI changes. Any code you put in the composable gets re-executed, potentially for every frame of an animation. Limit the composable's code to only what it needs to build the UI.\n- **Defer state reads for as long as possible.** By moving state reading to a child composable or a later phase, you can minimize recomposition or skip the composition phase entirely. You can do this by passing lambda functions instead of the state value for frequently changing state and by preferring lambda-based modifiers when you pass in frequently changing state. You can see an example of this technique in the [Defer reads as long as possible](/develop/ui/compose/performance/bestpractices#defer-reads) section of [Follow best practices](/develop/ui/compose/performance/bestpractices).\n\nAdditional Resources\n--------------------\n\n- **[App performance guide](/topic/performance/overview)**: Discover best practices, libraries, and tools to improve performance on Android.\n- **[Inspect Performance](/topic/performance/inspecting-overview):** Inspect app performance.\n- **[Benchmarking](/topic/performance/benchmarking/benchmarking-overview):** Benchmark app performance.\n- **[App startup](/topic/performance/appstartup/analysis-optimization):** Optimize app startup.\n- **[Baseline profiles](/baseline-profiles):** Understand baseline profiles."]]
