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

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

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

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

גודל ה-APK

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

צפיות בלבד תצוגות מעורבות וכתיבה כתיבה בלבד
גודל הורדה 2,252 KB 3,034 KB 2,966 KB

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

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

משך הזמן של תהליך ה-build

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

gradle-profiler --benchmark --project-dir . :app:assembleDebug
צפיות בלבד תצוגות מעורבות וכתיבה כתיבה בלבד
משך הזמן הממוצע ליצירת build 299.47 אלפיות השנייה 399.09 אלפיות השנייה 342.16 אלפיות השנייה

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

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

סיכום

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

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

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

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

הרכבים מחדש חכמים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Benchmark Compose

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

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

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

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

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