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

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

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

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

גודל APK

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

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

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

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

זמן היצירה

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

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

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

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

סיכום

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

מקרים נוספים לדוגמה מפורטים במאמר שימוש בכתיבה לצוותים.

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

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

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

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

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

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

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

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

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

הרחבה של התצוגה

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

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

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

כמה כרטיסים

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

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

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

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

כתיבת השוואה לשוק

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

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

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

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

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