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

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

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

גודל ה-APK

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

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

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

זמן היצירה

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

סיכום

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

מידע נוסף על מקרים לדוגמה זמין במאמר הטמעת Compose ל-Teams.

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

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

קומפוזיציות מחדש חכמות

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

פרופילים Baseline

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

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

השוואה למערכת View

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

כל הרכיבים מורחבים באמצעות View

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

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

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

כמה כרטיסים

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

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

הצגת ביצועי האפליקציה בזמן ההפעלה

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

Benchmark Compose

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

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

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

כתיבת התקנת פרופיל

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