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

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

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

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

גודל ה-APK

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

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

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

זמן בנייה

הוספת 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 פיתוח נייטיב יש הרבה שיפורים בהשוואה למערכת View. השיפורים האלה מתוארים בקטעים הבאים.

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

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

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

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

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

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

ב-Jetpack פיתוח נייטיב, חוזה ה-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 פיתוח נייטיב 1.0 נעשה שימוש בהתקנת פרופילים בגרסאות הפצה. קבצים להתקנת פרופילים מאפשרים לאפליקציות לציין קוד קריטי שיועבר קומפילציה מראש (AOT) בזמן ההתקנה. ‫Compose שולח כללי התקנה של פרופילים, שמקצרים את זמן ההפעלה ומפחיתים את הבעיות באפליקציות של Compose.