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

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

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

בקטע הזה נסביר על ההשפעה על גודל ה-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 הממוצע של גרסת ה-debug של 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 מנסה להרכיב מחדש רק את החלקים שצריך לעדכן. מידע נוסף בנושא הזה זמין בתיעוד בנושא מחזור החיים של פונקציות Composable ושלבים ב-Jetpack Compose.

פרופילים בסיסיים

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

ספריית Jetpack Compose כוללת פרופיל בסיסי משלה, ואתם מקבלים את האופטימיזציות האלה באופן אוטומטי כשאתם משתמשים ב-Compose באפליקציה. עם זאת, האופטימיזציות האלה משפיעות רק על נתיבי קוד בתוך ספריית Compose, ולכן מומלץ להוסיף פרופיל בסיסי לאפליקציה כדי לכסות נתיבי קוד מחוץ ל-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 שמקצרים את זמן ההפעלה ומפחיתים את הבעיות באפליקציות Compose.