השוואה בין מדדי 'כתיבה' ו'צפייה'

‫Jetpack Compose מאיץ את פיתוח ממשק המשתמש ומשפר את פיתוח האפליקציות ל-Android. עם זאת, חשוב לקחת בחשבון איך הוספה של Compose לאפליקציה קיימת יכולה להשפיע על מדדים כמו גודל ה-APK של האפליקציה, הביצועים של ה-build וזמן הריצה.

גודל ה-APK וזמני הבנייה

בקטע הזה נסביר איך משפיע השימוש ב-Compose על גודל ה-APK ועל זמן הבנייה, באמצעות האפליקציה לדוגמה Sunflower – אפליקציה שמדגימה שיטות מומלצות להעברת אפליקציה מבוססת-View ל-Compose.

גודל ה-APK

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

כשמוסיפים את Compose ל-Sunflower בפעם הראשונה, גודל ה-APK גדל מ-2,252 KB ל-3,034 KB – עלייה של 782 KB. קובץ ה-APK שנוצר כלל את ה-UI שנבנה עם שילוב של Views ו-Compose. העלייה הזו צפויה כי נוספו תלויות נוספות ל-Sunflower.

לעומת זאת, כשבוצעה מיגרציה של Sunflower לאפליקציה שמבוססת על Compose בלבד, גודל ה-APK ירד מ-3,034KB ל-2,966KB – ירידה של 68KB. הירידה הזו נבעה מהסרה של תלות בתצוגה שלא נעשה בה שימוש, כמו AppCompat ו-ConstraintLayout.

Build time

הוספת Compose מאריכה את זמן ה-build של האפליקציה, כי קומפיילר Compose מעבד את הפונקציות הניתנות להרכבה באפליקציה. התוצאות הבאות התקבלו באמצעות הכלי העצמאי gradle-profiler, שמבצע build כמה פעמים כדי לקבל את זמן ה-build הממוצע של גרסת הניפוי באגים של Sunflower:

gradle-profiler --benchmark --project-dir . :app:assembleDebug

כשמוסיפים את Compose ל-Sunflower בפעם הראשונה, זמן הבנייה הממוצע עולה מ-299 אלפיות השנייה ל-399 אלפיות השנייה – עלייה של 100 אלפיות השנייה. המשך הזה נובע מכך שהקומפיילר של Compose מבצע משימות נוספות כדי לשנות את קוד Compose שמוגדר בפרויקט.

לעומת זאת, זמן הבנייה הממוצע ירד ל-342 אלפיות השנייה, ירידה של 57 אלפיות השנייה, כשההעברה של Sunflower ל-Compose הסתיימה. הקיצור הזה נובע מכמה גורמים שביחד מקצרים את זמן הבנייה, כמו הסרת קשירת נתונים, העברת תלויות שמשתמשות ב-kapt ל-KSP ועדכון של כמה תלויות לגרסאות העדכניות שלהן.

סיכום

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

אפשר לקרוא עוד מקרים לדוגמה במאמר איך משתמשים ב-Compose for Teams.

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

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

שינוי חכם של קומפוזיציות

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

פרופילים של Baseline

פרופילים בסיסיים הם דרך מצוינת להאיץ תהליכים נפוצים שעוברים משתמשים. הוספה של פרופיל Baseline לאפליקציה יכולה לשפר את מהירות הרצת הקוד ב-30% בערך מההפעלה הראשונה, כי היא מאפשרת להימנע משלבי פרשנות וקימפול just-in-time (JIT) לנתיבי הקוד הכלולים.

ספריית Jetpack Compose כוללת פרופיל Baseline משלה, ואתם מקבלים את האופטימיזציות האלה באופן אוטומטי כשאתם משתמשים ב-Compose באפליקציה. עם זאת, האופטימיזציות האלה משפיעות רק על נתיבי קוד בתוך ספריית Compose, ולכן מומלץ להוסיף פרופיל Baseline לאפליקציה כדי לכסות נתיבי קוד מחוץ ל-Compose.

השוואה למערכת התצוגה

ל-Jetpack Compose יש הרבה יתרונות בהשוואה למערכת View. השיפורים האלה מתוארים בקטעים הבאים.

הכול מרחיב את התצוגה

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

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

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

כמה מעברים של פריסה

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

‫Jetpack Compose אוכף מעבר פריסה יחיד לכל רכיבי הפריסה הקומפוזביליים באמצעות חוזה ה-API שלו. כך אפשר לטפל ביעילות בעצי ממשק משתמש עמוקים. אם צריך כמה מדידות, ב-Compose יש מדידות פנימיות.

צפייה בביצועי ההפעלה

מערכת התצוגה צריכה להרחיב פריסות XML כשמציגים פריסה מסוימת בפעם הראשונה. העלות הזו נשמרת ב-Jetpack Compose כי פריסות נכתבות ב-Kotlin ועוברות קומפילציה כמו שאר האפליקציה.

Benchmark Compose

ב-Jetpack Compose 1.0, יש הבדלים משמעותיים בין הביצועים של אפליקציה במצב debug לבין הביצועים שלה במצב release. כדי לקבל נתונים מייצגים של תזמונים, תמיד צריך להשתמש בגרסת build של release במקום בגרסת build של debug כשמבצעים פרופיל לאפליקציה.

כדי לבדוק את הביצועים של קוד Jetpack Compose, אפשר להשתמש בספרייה Jetpack Macrobenchmark. מידע על שימוש ב-Jetpack Compose זמין בפרויקט MacrobenchmarkSample.

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

יצירת פרופיל להתקנה

מכיוון ש-Jetpack Compose היא ספרייה לא מאוגדת, היא לא נהנית מ-Zygote שמעמיס מראש את המחלקות ואת רכיבי ה-UI של מערכת View. ‫Jetpack Compose 1.0 משתמש בהתקנת פרופיל לבניית גרסאות. קבצים להתקנת פרופילים מאפשרים לאפליקציות לציין קוד קריטי שיועבר קומפילציה מראש (AOT) בזמן ההתקנה. ‫Compose ships profile (פרופיל משלוח של Compose) מכיל כללי התקנה שמקצרים את זמן ההפעלה ומפחיתים את הבעיות בממשק (jank) באפליקציות של Compose.