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

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

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

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

גודל ה-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.

Build time

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

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

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

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

סיכום

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

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

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

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

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

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

פרופילים של Baseline

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

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

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

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

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

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

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

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

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

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

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

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

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

Benchmark Compose

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

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

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

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

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