אופטימיזציה של תצוגה בהתאמה אישית

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

האצה של התצוגה

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

בנוסף לשיפור היעילות של onDraw(), חשוב להקפיד לקרוא לפונקציה הזו בתדירות הנמוכה ביותר האפשרית. רוב השיחות אל onDraw() הן תוצאה של שיחה אל invalidate(), לכן כדאי לבטל שיחות מיותרות אל invalidate().

פעולה יקרה מאוד נוספת היא מעבר בין פריסות. כשמופעלת קריאה לתצוגה requestLayout(), מערכת ממשק המשתמש של Android עוברת על כל היררכיית התצוגה כדי לקבוע את הגודל של כל תצוגה. אם המערכת מוצאת מדידות סותרות, היא עשויה לעבור על ההיררכיה כמה פעמים. מעצבי ממשקי משתמש יוצרים לפעמים היררכיות עמוקות של אובייקטים מוטמעים מסוג ViewGroup. היררכיות עמוקות של תצוגות גורמות לבעיות בביצועים, ולכן חשוב ליצור היררכיות שטוחות ככל האפשר של תצוגות.

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

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