יציבות בכתיבה

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

התכונה 'פיתוח נייטיב' משתמשת ביציבות של פרמטרים של תוכן קומפוזבילי כדי לקבוע אם אפשר לדלג על התוכן הקומפוזבילי במהלך הרכבה מחדש:

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

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

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

חפצים בלתי ניתנים לשינוי

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

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

data class Contact(val name: String, val number: String)

התוכן הקומפוזבילי ContactRow מכיל פרמטר מסוג Contact.

@Composable
fun ContactRow(contact: Contact, modifier: Modifier = Modifier) {
   var selected by remember { mutableStateOf(false) }

   Row(modifier) {
      ContactDetails(contact)
      ToggleButton(selected, onToggled = { selected = !selected })
   }
}

חשוב על מה שקורה כשהמשתמש לוחץ על המתג שינויים במצב selected:

  1. פיתוח נייטיב בודק אם הוא צריך להרכיב מחדש את הקוד בתוך ContactRow.
  2. נראה שהארגומנט היחיד של ContactDetails הוא מסוג Contact.
  3. מכיוון ש-Contact הוא סיווג נתונים שלא ניתן לשינוי, התכונה 'כתיבה' מוודאת שאף אחד הארגומנטים של ContactDetails השתנו.
  4. לכן, התכונה 'כתיבה' מדלגת על ContactDetails ולא יוצרת אותה מחדש.
  5. לעומת זאת, הארגומנטים של ToggleButton השתנו, וגם הרכבה מחדש את הרכיב הזה.

אובייקטים שניתנים לשינוי

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

data class Contact(var name: String, var number: String)

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

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

הטמעה בכתיבה

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

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

פונקציות

כשמשתמשים בכתיבה, אפשר לסמן פונקציות בתור skippable או restartable. לתשומת ליבכם: לסמן פונקציה כאחת, כשניהם או כאף אחת מהאפשרויות:

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

סוגים

סוגי סימני ההרכבה הם לא ניתנים לשינוי או יציבים. כל סוג הוא אחד other:

  • לא ניתן לשינוי: הכתיבה מסמן סוג שלא ניתן לשינוי אם הערך של מאפיינים אף פעם לא יכולים להשתנות, וכל השיטות שקופות מבחינת הפניות.
    • שימו לב שכל הסוגים של פרימיטיביים מסומנים ככאלה שלא ניתנים לשינוי. למשל, String, Int וגם Float.
  • יציב: מציין סוג שהמאפיינים שלו יכולים להשתנות לאחר הבנייה. אם וכאשר המאפיינים האלה משתנים במהלך זמן הריצה, התכונה 'כתיבה' מיידעת אותך לגבי את השינויים האלה.

יציבות ניפוי הבאגים

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

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

פתרון של בעיות ביציבות

למידע נוסף על שיפור היציבות של הטמעת הכתיבה: המדריך פתרון של בעיות ביציבות.

סיכום

באופן כללי, חשוב לשים לב לנקודות הבאות:

  • פרמטרים: 'כתיבה' קובעת את היציבות של כל פרמטר תכנים קומפוזביליים כדי לקבוע על אילו תכנים קומפוזביליים צריך לדלג חיבור מחדש.
  • תיקונים מיידיים: אם שמתם לב שלא מדלגים על התוכן הקומפוזבילי וגם היא גורמת לבעיה בביצועים, צריך לבדוק את הסיבות הברורות חוסר יציבות כמו var פרמטרים תחילה.
  • דוחות קומפילר: אפשר להשתמש בדוחות מהדר כדי כדי לקבוע את היציבות של המחלקות.
  • אוספים: כשיוצרים אוספים, תמיד מחשיבים את סיווגי האוספים כלא יציבים, למשל List, Set ו-Map. הסיבה לכך היא שלא ניתן להבטיח שהם לא ניתנים לשינוי. במקום זאת, אפשר להשתמש באוספים שלא ניתנים לשינוי של Kootlinx, או להוסיף הערות לכיתות בתור @Immutable או @Stable.
  • מודולים אחרים: התכונה 'פיתוח נייטיב' תמיד נחשבת לא יציבה מהמיקום שממנו הם מגיעים מודולים שבהם המהדר לכתיבה לא פועל. סיכום הכיתות בממשק המשתמש של סיווגי המודל, אם יש צורך.

קריאה נוספת