האתגר הכפול של מוצר לביש
אפליקציה למוצר לביש נמדדת על דבר אחד לפני הכול: האם המשתמש מרגיש אותה בסוללה. וזה אתגר כפול — צמיד, שעון או חיישן לביש חיים על סוללה זעירה של עשרות עד מאות מיליאמפר-שעה, ובו זמנית אסור שהאפליקציה תופיע ברשימת "צרכני הסוללה" של הטלפון. משתמש שמגלה שהצמיד גמור אחרי יום, או שהטלפון נחלש בגללו, מסיר את המוצר ואת האפליקציה יחד. הפתרון אינו טריק אחד אלא ארכיטקטורת סנכרון שנבנית נכון מהיום הראשון.
עיקרון 1: המוצר צובר, האפליקציה מושכת
הטעות הקלאסית היא שידור רציף: המוצר שולח כל דגימה ברגע שנוצרה. שידור BLE הוא הפעולה היקרה ביותר לסוללת המוצר, ולכן הארכיטקטורה הנכונה הפוכה:
- המוצר דוגם ושומר מקומית — זיכרון פלאש קטן מכיל בקלות ימים של נתונים דחוסים.
- סנכרון באצווה — אחת לכמה דקות או שעות, או כשהאפליקציה מבקשת, המוצר משדר את כל מה שנצבר ברצף קצר אחד וחוזר לישון.
- סיכום במקום גולמי — אם המסך מציג ממוצע דופק לכל דקה, אין סיבה לשדר 60 דגימות בשנייה. עיבוד ראשוני על המוצר חוסך פי מאות בנפח השידור. זה נשען על קושחה שתוכננה לחיסכון — ראו מצבי שינה במיקרו-בקר.
עיקרון 2: לכוונן את פרמטרי ה-BLE
ב-BLE יש שלושה כפתורים שמזיזים את צריכת החשמל בסדרי גודל: מרווח הפרסום (Advertising Interval) כשהמוצר ממתין לחיבור, מרווח החיבור (Connection Interval) בזמן סנכרון, ו-Slave Latency שמאפשר למוצר לדלג על אירועי חיבור ריקים. מוצר לביש טוב מחליף פרופילים: מרווחים ארוכים וחסכוניים בשגרה, מרווחים קצרים ומהירים רק בזמן העברת אצווה או עדכון קושחה. איך כל זה עובד בפועל — באיך אפליקציה מתחברת למוצר בבלוטות'.
עיקרון 3: לכבד את מגבלות הרקע של הטלפון
מערכות ההפעלה בטלפון נלחמות באפליקציות רקע רעבתניות, ובצדק. אפליקציה שמנסה להחזיק חיבור BLE פתוח תמיד תיחנק על ידי המערכת או תרוקן את הטלפון. הגישה הנכונה:
- להשתמש במנגנוני הרקע הרשמיים — שחזור חיבור באירוע, סריקה מבוססת מערכת, משימות רקע מתוזמנות — ולא בלולאות סריקה עצמיות.
- לתכנן לניתוקים. הטלפון יהרוג את התהליך; המוצר ימשיך לצבור; בפתיחה הבאה מסנכרנים את הפער. המשתמש לא אמור להרגיש שהיה נתק.
- התראות דרך השרת כשאפשר — התראת Push מהענן זולה לטלפון מהחזקת קשר ישיר; המנגנון מוסבר בהתראות Push ממוצר חכם.
כאן גם נבחנת בחירת טכנולוגיית הפיתוח: עבודת BLE ברקע היא בדיוק המקום שבו פתרונות קרוס-פלטפורמה נמתחים — ראו React Native עם BLE לפני שמחליטים.
מה מודדים לפני שמשחררים
אי אפשר לנהל את מה שלא מודדים, ולכן לפני השקה בונים מבחן צריכה מסודר משני הצדדים. בצד המוצר: מד זרם על מחזור סנכרון מלא — התעוררות, חיבור, העברת אצווה, ניתוק — ומדידה נפרדת של צריכת השגרה בין סנכרונים; מכפילים בתדירות היומית ומקבלים תחזית חיי סוללה אמיתית. בצד הטלפון: כלי הפיתוח של שתי הפלטפורמות מציגים כמה אנרגיה האפליקציה צרכה ברקע, כמה יקיצות יזמה וכמה זמן החזיקה רדיו פעיל. קבעו תקציב מספרי — למשל, סנכרון יומי שצורך פחות מאחוז מסוללת המוצר ופחות מחצי אחוז מסוללת הטלפון — ובדקו אותו בכל גרסה, כדי שרגרסיה בצריכה תיתפס לפני שהיא מגיעה למשתמשים.
לסגור את המעגל עם החומרה
סנכרון חסכוני הוא החלטה משותפת של קושחה, אפליקציה וענן — פרוטוקול האצווה, פורמט הדחיסה ומדיניות הניסיונות החוזרים חייבים להיסגר יחד, לא כל צד לבד. זו אחת הסיבות שפיתוח מוצר לביש דורש צוות שרואה את כל התמונה, כמתואר בפיתוח מוצר לביש. וגם הצד הפיזי משפיע על התוכנה: מוצר שנוח לענוד נלבש יותר שעות, צובר יותר נתונים ומציב דרישות סנכרון אחרות — ראו עיצוב מוצר לביש.
מבחן הקבלה הסופי פשוט: שבוע שימוש אמיתי, בלי טעינה של המוצר מעבר למובטח, כשהאפליקציה לא מופיעה בין צרכני הסוללה הבולטים בטלפון. אם עמדתם בו — הסנכרון שלכם שקוף, וזה בדיוק מה שמשתמשים רוצים ממוצר לביש.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
