מערכת @אזכורים באפליקציית מובייל: ניתוח, השלמה אוטומטית

מדוע אזכורים נשברים בקנה מידה

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

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

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

זה מתוקן באמצעות מקור אמת יחיד: המפרסר מחזיר לא מחרוזת אלא רשימת טווחים "התחלה-סוף + מזהה משתמש", והרינדור ובניית הקישורים פועלים רק לפיו.

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

הפתרון — אינדקס מקומי של אנשי קשר תכופים ודיבאונס עם ביטול בקשות מיושנות, כדי שהתשובה ל-"@אנ" לא תדרוס את התשובה ל-"@אנה".

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

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

מה נותנת מערכת אזכורים בנויה היטב

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

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

דיוק הזיהוי נקבע על ידי ניתוח הטקסט, ולא על ידי ביטויים רגולריים. המנתח מתחשב בגבולות מילים, escaping, אזכורים מקוננים והבדלי פריסות מקלדת, ולכן «@иван» ו-«@Иван» מובילים לאותו פרופיל, וכתובת דואר אלקטרוני או כינוי בקישור אינם הופכים לאזכור שגוי.

שיעור הישויות שזוהו נכון על סט מסומן של הודעות מגיע לגבול העליון — השאר נובע משגיאות הקלדה, שאותן מכסה ההצעה «אולי התכוונת ל».

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

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

גישות לפרסינג ולהשלמה אוטומטית: השוואה

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

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

כיצד לבחור לפי הפרופיל שלך

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

מה נשבר בנקודת החיבור

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

כיצד אנו מיישמים מערכת אזכורים

את העבודה מתחילים בביקורת: בוחנים כיצד האפליקציה מתנהגת כעת בעת הקלדת «@» — היכן מופיעה ההשלמה האוטומטית, היכן הטקסט נשמר כפי שהוא, וכיצד נשמרים מזהי הישויות המוזכרות. בשלב זה מתעדים מקרי קצה: אזכור בראש השורה, לאחר סימן פיסוק, בתוך קישור, הדבקה מהלוח, הקלדה במקלדת חומרה. כל מקרה מקבל התנהגות צפויה — זהו הבסיס לקבלה, ולא ניחושים בעין.

לאחר מכן מתכננים את סכמת הניתוח ובונים אותה שלב אחר שלב.

1. ביקורת ההתנהגות הנוכחית. מריצים תרחישי קלט על האפליקציה החיה, אוספים פערים בין הפלטפורמות ומתעדים אילו ישויות ניתן בכלל להזכיר.
2. סכמת ניתוח הטקסט. מגדירים את הדקדוק של האזכור: תווים מותרים, גבולות הטוקן, כללי escaping. הניתוח מתבצע במעבר אחד על השורה, ולכן הקלדת טקסט ארוך אינה מאטה.
3. הגדרת ההשלמה האוטומטית. ההשלמה נשלפת בהשהיה לאחר הלחיצה האחרונה ומבטלת את הבקשה הקודמת אם המשתמש ממשיך להקליד. את הרשימה מדרגים לפי התאמה ותדירות — הרלוונטי מופיע ראשון.
4. קישור לנתונים. את האזכור שומרים כמזהה ישות ולא כטקסט: בעת שינוי שם של משתמש או ערוץ הקישור נשאר פעיל.
5. בדיקת תרחישים. מריצים את הניתוח על סט שורות מוכן מראש — עם אימוג'י, אלפביתים מעורבים, קטיעת קלט, מחיקת תו בתוך אזכור. בנפרד בודקים את ההתנהגות כאשר הרשת אינה זמינה.
6. בדיקת עומס. בוחנים כיצד מתנהגת ההשלמה מול בסיס משתמשים גדול ובמכשיר חלש: זמן תגובה וצריכת זיכרון.
7. מסירת התיעוד. מוסרים את תקנון הניתוח, תיאור פורמט אחסון האזכורים וצ'ק-ליסט קבלה, כדי שצוות הלקוח יוכל לפתח את המערכת בעצמו.

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

ארטיפקטים: קונפיגורציות, סכמות, מדיניות גישה

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

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

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

מקרה בוחן: האצנו את ההשלמה האוטומטית והסרנו כפילויות בהתראות

הלקוח — שירות לעבודה משותפת עם פיד דיונים. האזכורים עבדו, אך ההשלמות הופיעו באיחור, ובמהלך הקלדה מהירה ותיקונים המשתמשים קיבלו שתיים-שלוש התראות על אותו דבר בדיוק. מפרקים מקרה בוחן של אזכורים: מה נמדד, מה שינינו ואילו מדדים לפני/אחרי התקבלו.

מה היה לפני

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

מה שינינו

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

מדדים לפני/אחרי

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

במה שונה ניתוח בצד הלקוח מניתוח בצד השרת?

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

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

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

ניתוח בצד השרת מסיר את העומס מהמכשיר ותמיד עובד עם ספרייה מעודכנת — אין צורך לשמור דבר במטמון ולהסתנכרן. המחיר לכך — השהיית רשת על כל בקשה וזרם מתמיד של פניות ל-backend: בהקלדה פעילה מדובר בעשרות בקשות בשנייה למשתמש. בלי איחוד בקשות וקэш מושכל בצד השרת, העומס על התשתית גדל באופן ליניארי יחד עם קהל המשתמשים.

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

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

ספקות טכניים נפוצות

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

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

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

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

האם השלמה אוטומטית לא תיצור עומס שיא על השרת?

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

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

בואו נדון במשימה שלכם בנושא אזכורים

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

הנה מה שאנחנו מבררים בשיחה הראשונה:

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

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

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