יום ראשון, 27 באוקטובר 2019

379 Building lightweight apps with Dekel Naar

פודקאסט מספר 379 של רברס עם פלטפורמה - אורי ורן מארחים בכרכור (יומיים לפני יום ההולדת של רן! מזל טוב לגיל 16, בדיוק התחלף הקול? . . . ) את דקל נער מחברת Facebook לשיחה קלילה על אפלקציות קלילות לאנדרואיד, ולא רק (כן רק קלילות, לא רק לאנדרואיד . . .)


קודם כל קצת על דקל - 
  • דקל - בן 32, גר ועובד בתל אביב - כבר בערך 6 שנים בפייסבוק ישראל.
  • בשנים האחרונות מתמחה ב - Performance של אפליקציות - הרבה על אנדרואיד ולאחרונה גם קצת על IOS, ועושה כל מיני דברים מגניבים.

קצת על פייסבוק בישראל - מה קורה שם היום?
  • בהשוואה ללפני חמש שנים, מה שקורה היום הוא שקורה הרבה - 
    • המשרד גדל מאוד - התחלנו ממשרד של 20-30 מהנדסים והיום אנחנו כבר מעל 250, וכבר יש לנו 4-5-6 פרוייקטים שרצים במקביל עם הרבה מאוד צוותים.
    • מתמחים בעיקר באיזור של Connectivity ובעצם ב-Emerging Markets - יש לנו פרויקטים בנושא חיבור אנשים לאינטרנט כמו Internet.org, הרבה פרוייקטים סביב הנושא של  “Lite" - אפליקציות “קלות” לאנדרואיד ול - IOS ולמערכות הפעלה נוספות - כל מה שיכול ליצור חווייה טובה יותר למשתמשים ממקומות שהם לא מרכז תל אביב או סן פרנסיסקו או ניו-יורק, עם ה - iPhone 11 Pro שיצא לפני שבועיים . . .
רגע . . יש עולם מחוץ למרכז תל אביב?! כל מה שתחת ההגדרה של “רחוק לי” . . . מסתבר שיש שם הרבה מאוד אנשים. מה הן המגבלות הפיסיות שמצריכות כאלו אפליקציות רזות?
  • שאלה מעולה - שאין לה תשובה אחת, אלא הרבה מאוד תשובות שמשתנות לפי המקומות.
  • יש מקומות שבהם זו הרשת הסלולארית - או Wi-Fi, או האם יש בכלל רשת סלולארית
  • האם יש בכלל חשמל?
  • יש מקומות שבהם ראינו שאנשים משתמשים בכוונה ב - Feature Phones, כי הם “מחזיקים” יותר זמן בלי חשמל
רגע - הסבר על Feature Phones:
  • מדובר ב - Buzz word נפוצה עבור מכשירים “מלפני עידן ה - iPhone” . . . כל מיני מכשירים של Nokia ו - Windows Phones וגם מכשירי Android של $20/$50/$100 - מכשירים מאוד חלשים במהותם.
  • אז זה גם מכשירים - וגם כאן אפשר לאפיין מכשירים שיש בהם בעיית זיכרון (מאוד בולט) או כוח עיבוד - או שפשוט אין מקום . . .  אתה מכיר אנשים עם כל מיני iPhone-16Gb שכל הזמן מוחקים תמונות כי נגמר המקום? אז “אהה - פייסבוק, 0.5Gb?! בוא נמחק את זה”.
  • אז אמרנו אחסון ורשתות - וגם עניין של הרגלים, או אפילו חלוקה של כמה משתמשים באותו מכשיר לצורך גישה.
  • ראינו המון מאפיינים שונים שגרמו לנו להגיע לזה - ובפרט הגענו עם כמה מוצרים שונים.

 לפני שנצלול טיפה פנימה, אולי קצת הקשר היסטורי (עם הרפרנס המתבקש לפרופסור הרסגור זצ”ל) - פייסבוק רכשה חברה ישראלית בשם Snaptu (שעשתה בעצם Facebook for feature-phones), ואחר כך רכשה גם את Onavo - ונראה ששתי החברות בערך באותו כיוון של “לאפשר תקשורת לטלפונים קצת יותר נחותים” - Snaptu עבור פייסבוק, Onavo לא דווקא ספציפית.
  •  דקל הגיע מתוך Onavo, מה שאולי מסביר את המשיכה הספציפית לתחום.
נראה איכשהו ש“יצא בפוקס” שבישראל מתמקדים בדברים האלה . . . 
  • דווקא להיפך - אני (דקל) חושב שאלו טכנולוגיות שפייסבוק הביאה אליה דווקא כיוון שהיא ראתה את האופק הזה - יש אנשים שיודעים “לתקל”  (Tackle) את השווקים האלה, אז אפשר להשתמש בטכנולוגיות הללו ולנצל אותן על מנת לתת חווייה טובה יותר (אפשר לפרש את הפסקה האחרונה בכל מיני צורות…).
אז פייסבוק ראתה מעבר לאופק של ה - Silicon Valley . . .
  • כן - וזה כבר מזמן לא רק פייסבוק: אנחנו רואים אפליקציות Lite גם מכיוון YouTube (לא Lite אלא YouTube Go) ו - Spotify Lite - זה טרנד שנכנסנו (פייסבוק) אליו יחסית מוקדם, ועם הרבה מאוד כח אש
  • זה הקהל הבא - החברות הללו רוצות לגדול, המשקיעים מצפים שהחברות האלה תגדלנה - וכשאתה מגיע ל 2-3 מיליארד משתמשים אתה שואל “מה עושים?”.
או שמולידים עוד אנשים, או שיוצרים עוד Bandwidth . . .

אז בעצם אתה רומז שיש יותר מפייסבוק אחד - אם אני הולך ל - App Store, אני יכול לבחור פייסבוק או Facebook Lite?
  • לא רומז - אומר . . . לך ל App Store או ל Google Play וחפש את Facebook Lite - עבור אנדרואיד זה כבר בכל המדינות בעולם, עבור השאר אנחנו עדיין בשלבי פיתוח כאלה ואחרים - וזו אפליקציה שגם בארץ יש לה לא מעט משתמשים
    • זה לא רק חברים שלנו ואשתי שאני אומר להם להוריד - זה גם אנשים אחרים :-)
    • וזה קצת הפתיע אותנו - לאנשים חשובה הרספונסיביות (responsiveness) ושזה לא יתפוס להם הרבה מקום ב - Storage כי הם רוצים לצלם עכשיו תמונות ולא להתעסק בכמה מקום נשאר, או זה שיש קליטה קצת מעפנה ואנחנו רוצים שדברים עדיין יתפקדו לנו בצורה סבירה.

אז בעצם - מכיוון שאנחנו לא יודעים על איזה מכשיר נרוץ או על איזו רשת או מה יהיה מצב ה-Storage במכשיר, אנחנו צריכים כל הזמן לאפטם (To optimize) בכל הצירים . . .
  • לגמרי נכון - יש לנו בשביל זה גם כמה צוותי Performance מאוד חזקים שעובדים וזה מה שהם מנסים לעשות.
  • אגב - גם היום באפליקציית Facebook “הכחולה” (הלא-Lite), זו שרוב האנשים משתמשים בה, יש המון פוקוס על כל סוגי הביצועים, החל מ Storage דרך כמה זמן לוקח לה לעלות “כשהכל קר”, כמה זיכרון היא תופסת ועוד - יש צוות לכל דבר כזה ומערכות כלים שלמות על מנת לראות איך אנחנו גורמים לכל וקטור כזה להיות במקסימום שאנחנו יודעים לייצר, ואיך אנחנו גם לא פוגעים בחווייה בזמן שאנחנו מצליחים לגרום לאפליקציות להצטמק ולהצטמק ולהיות יותר ויותר קלילות על הטלפון.

אז לפני שנצלול קצת יותר לטכנולוגיה, ננסה לסגור כמה שאלות מוצריות - 
למעשה, פייסבוק Lite מספקת סט פיצ’רים קצת שונה מזה של “פייסבוק הכחולה”?
  • בלי סוכר?
  • בסך הכל החוויה מאוד דומה, ויש Trade-offs שאותם אנחנו לוקחים בצורה קצת שונה, מתוך הבנה שמי שבוחר את אפליקציית ה - Lite על פני הרגילה בעצם בוחר בזה - בין אם זו מדיניות של Cache בצורה מסויימת ואיך דברים עובדים, או לשחק קצת עם רזולוציות של תמונות וחוויות ודברים כאלה.
לצורך העניין - תראה תמונה ברזולוציה פחות טובה אבל היא תעלה יותר מהר, או לחלופין - האפליקציה תרוץ יותר לאט (כי יש פחות Caching), אבל היא לפחות תרוץ ולא יגמר לך הזכרון?
  • נכון - יש כל מיני Trade-offs, ובמקומות מסויימים גם בחירה בטכנולוגיות שלאו דווקא מביאות Trade-off מסויים כדי להצליח להגיד שבנינו את זה בצורה יותר יעילה (?).
אתה אומר Trade-off - זה מבחינת המשתמש?
  • זה Trade-off בין אלמנטים של המשתמש - זה יכול להיות גם בין האחסון שלו לבין השימוש שלו ברשת, אבל בסוף פונקציית המקסימום היא על החווייה שלו.
    • אני לא צריך להקריב את החווייה בשביל הביצועים, אבל החווייה הכוללת צריכה להיות עם ROI חיובי.

אוקיי - אז החלטת שחשוב שהאפליקציה תיהיה “רזה”, באופן מאוד כללי - גם אנדרואיד, גם IOS וגם “Nokia” או איך שלא נקרא לזה (נראה ש Asha).
אז מה עושים? עם מה מתחילים למדוד? באילו כלים אתה משתמש?
  • הדבר הראשון הוא שזה באמת לא טריוויאלי - זה שמתחילים בלמדוד, ולהבין איפה בכלל אנחנו נמצאים.
  • גודל האפליקציה זה משהו מאוד קל למדידה - תקמפל (Compile) ותראה מה הגודל.
  • לדברים כמו גדלי ה -Cache השונים או Storage footprint (כמה בסה”כ אנחנו משתמשים ב - Storage של המכשיר) - אנחנו מכניסים קוד ייעודי שעושה איזושהי הערכה (“תפסנו עכשיו 22Mb בשביל ה - Cache הזה וזה ה - Cache-Hit שלנו”).
  • יש לנו המון כלים שמפותחים in-house - חלקם יותר Open-Source כמו Hive וכאלה וחלקם בשלב בגרות יותר מוקדם
  • ברוב הפעמים, כשאנחנו רוצים להבין מה קורה, אנחנו משתמשים ברצף של מידע, כשאנחנו משתמשים בכלי פנימי שלנו ואומרים - “אוקיי, כאן אנחנו נמצאים כרגע - איפה אנחנו רוצים להיות עוד רבעון / חציון וכו’ - מה יכול להביא אותנו לשם?”.
  • עורכים מעיין Brainstorming ויוצאים עם סט של פרויקטים שאם נצליח בהם - נצליח להביא את השינוי שאנחנו מעוניינים בו.

זה מכריח אתכם גם לאימפלמנטציות (Implementations) בצד השרת (server-side)?
  • כן - גם מבחינת ייצוג פרוטוקולים וכאלה, וספציפית - Facebook Lite היא אפליקציה שבה הרבה מה - Heavy Lifting והרבה לוגיקה וכוח העיבוד יושב בשרתים, וזה מבוסס על טכנולוגיה שהזכרנו קודם, של Snaptu - שהיום הפכה ל”מפלצת” שאף אחד לא דמיין שתיהיה.
  • יש לנו סט ענק של שרתים שעושים גם את העיבוד עבור המשתמש, החל מאיזה סט של Feeds או אילו Stories אתה עכשיו הולך לראות ועד איך אנחנו מצפים שה - Client ירדנדר (Render) את זה ואיך לשלוח דברים על הפרוטוקול.
  • גם כאן יש לנו trade-offs של האם עדיף לעשות את זה ב Client-side או ב - Server-side, לפי מה שיתן בסוף את החווייה או את הביצועים היותר טובים.
לפעמים האפליקציה שלך תיהיה יותר רזה, כי היא צריכה לעשות פחות עיבוד ב - Client, אבל אתה תעשה יותר עיבוד ב - server ותשלח על הרשת יותר מידע - ואז יש כבר Trade-off עם ה - Network bandwidth…
  • זה נכון, אעפ”י שבדרך כלל זה לאו-דווקא מתבטא ב - Bandwidth
  • לרוב הייצוג יכול להיות לא פחות יעיל, אבל סט של עיבוד מסויים שתעשה על השרת “יעלה לך” ב - round-trip ובזמן יותר ארוך, ואז תשאל את עצמך - עבור המכשיר הממוצע או עבור ה - Use-case הספציפי, האם בסך הכל זה שהעברתי את הפעולה ל-Server Side תשפר את מה שהמתשמש חווה?
בסוף לאנשים לא יהיה חשמל, כי כל החשמל יילך לחוות השרתים של פייסבוק . . . אז נבנה אפליקציות יותר רזות, מה הבעיה?
  • מצחיק, אבל באמת בונים את כל חוות השרתים באיזורים הנורדיים - חוות פסיכיות, והכל מבוסס על אנרגיה ירוקה, מכניסים אוויר קר בחורף וכו’, די טירוף.
אפשר להעביר פקטות לאפריקה באמצעות הציפורים שנודדות . . . סטארטאפ מטורף.

אפשר לקבל איזשהו Benchmark - עד כמה האפליקציה “הלבנה” יותר קטנה מהאפליקציה “הכחולה” נכון להיום?
  • יש לנו כמה נתונים די פסיכיים . . .
  • קודם כל - הגודל של ה - APK, הגודל הבינארי שאתה מוריד מ - Google Play - האפליקציה הכחולה הייתה באיזור ה - 95Mb, ואז פחדו לעבור את ה - 100Mb כי חשבו שהכל יתפוצץ אז עבדו עליה וירדו לאיזור ה - 50Mb וגאים ש”ממש ירדנו ואנחנו רזים” - אז עבור האפליקציה הלבנה היינו מאוד מוטרדים כשהתחלתי לעבוד כי היינו סביב ה - 1.7Mb ופחדנו לעבור את ה - 2Mb כי זה ממש עצום.
  • היום אנחנו סביב ה - 1.15-1.2Mb, שזה ממש קטן.
  • זמן ה - Startup שלנו (Cold-startup) הוא פחות מ-4 שניות, על ה - Device הממוצע שלנו ברחבי ה - Emerging Markets, שזה די מדהים - לקחת אנרואיד בן בערך שבע שנים, ללחוץ - ולראות וך 3-4 שניות איך האפליקציה עולה.
  • האפליקציה הכחולה, הרגילה, עושה את זה בסדר גודל של 7-10 שניות (עבור אותו מכשיר ממוצע - על מכשירים חזקים יותר זה כמובן מצטמצם).
זה “שם” (ב”אפריקה”), או פה? בישראל זה לוקח פחות זמן?
  • על מכשיר חזק עם רשת חזקה, גם האפליקציה הכחולה עושה את זה בבערך 3 שניות, שזה מאוד מרשים.

בוא נדבר קצת על דאטה פיקנטי - למשל: איזו מדינה היא המשתמשת הכי גדולה של האפליקציה “הלבנה”?
  • שאלה טובה (ואי אפשר לשלוח לשרת לבדוק) . . . אם אני (דקל) לא טועה זה הודו או הפיליפינים, באיזור הזה יש את השווקים המאוד חזקים, ואחרי זה כל איזור ה - Latin america (מכסיקו, ברזיל וכו’).
אילו מכשירים הם הכי נפוצים?
  • באנדרואיד, בשונה מ - iPhone, ה - distribution הוא מאוד אחיד . . . מכשירי ה - Galaxy המוקדמים (2-4) היו פעם מאוד פופלאריים, אבל עבר זמן מאז שהסתכלתי על הדאטה הזה אז לא לגמרי בטוח.
מדובר בעיקר במכשירים ישנים, או במכשירים חדשים אבל “רזים”, שמשווקים ספציפית לשווקים האלה?
  • על זה דווקא יש Fun-Fact מעניין - בפייסבוק הבנו שיש לנו בעיה להבחין בין Devices ישנים שעלו פעם סביב ה - $1000 לבין מכשירים שהיום קונים ב - ~$10 והם בעצם אותו הדבר, ולכן יש לנו מדד שאנחנו מכנים Year-Class - אנחנו מסתכלים על מכשיר ואומרים - “אם אני מסתכל על המאפיינים שלו (מעבד, זכרון וכו’), באיזו שנה, אם הוא היה משווק בה, הוא היה נחשב כ - High-end?”
    • אנחנו יכול להסתכל היום על איזשהו מכשיר בינוני שעולה $200 ולהגיד שאם הוא היה יוצא ב-2014 הוא היה נחשב כ - High-end, אז אני אחשיב אותו כ”מכשיר 2014”.
    • על פי אותו עקרון יש לנו 2012, 2013 וכן הלאה
    • המכשירים שהיו חזקים ב-2012-2013 (!HTC) הם אלו שאנחנו רואים היום הכי הרבה - בגדול מדובר בעד 1Gb זכרון ומעבד בינוני כלשהו - זו הספסיפיקציה (Specification) הממוצעת, ואנחנו רואים את זה פרוש באופן מאוד אחיד, קשה למצוא מכשירים ספציפיים בולטים.
יש היום שוק של מכשירים “רזים”, שיוצאים במיוחד בשביל שווקים כאלה?
  • כן - ולפני הכל יש שוק Refurbish מטורף, ואתה רואה הרבה מאוד מכשירים ש”הגיעו מהמערב”: אתה רואה במדינות מסויימות את ה - iPhone 5 למשל נעלמים, ו”צצים” במדינות אחרות.
    • רמז - הם כנראה לא יוצרו אתמול.
  • אנחנו רואים את התנודה הזו, ואנחנו גם רואה מכשירים חדשים מכל מיני סוגים - ואפשר אפילו לראות את זה במכשירי Samsung ו - iPhone חדשים, שכבר יוצאים גם עם specifications חלשים יותר, כי מבינים שה - High-end לא יכול למכור לכולם, וכם החברות הללו צריכות בסוף לגדול ולמכור יותר מכשירים . . .

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

איך אותם משתמשים יודעים להתקין את האפליקציה הנכונה? אתה מנסים לקדם אותה באיזורים האלה?
  • לחלוטין כן - אפילו יש לנו כמה פיצ’רים מגניבים, כמו למשל שאם אתה נכנס לאתר שלנו דרך ה - Browser, אתה רואה את Facebook.com מתחיל להיטען, ואם זה לוקח יותר מסביב ה-6 שניות אתה תקבל הודעה שאומרת “זה לוקח יותר מדי זמן, אם אתה רוצה שזה יטען יותר מהר תתקין Facebook Lite”), וככה אנחנו פונים בדיוק לאוכלוסיה הספציפית שיכולה להרוויח משימוש באפליקציה הזו.

זה נכון גם לגבי אפליקציות אחרות “במשפחה” - Instagram , WhatsApp וכו’?
  • עדיין לא . . .
  • מבחינה ארכיטקטונית, WhatsApp למשל יותר “קלה”, והאפליקציות שמרו על סט מאוד רזה של פיצ’רים ו - Performance מאוד גבוה. Instagram עדיין לא הגיעו לאיזור הזה.
  • עבור שאר האפליקציות מסביב אנחנו עושים אפקט דומה - Messenger למשל עושה ככה היום.

מה לגבי אנדרואיד עצמה - מערכת ההפעלה וכל האפליקציות שבאות ביחד איתה?
  • גם Google לא מזניחה את התחום הזה, וגם כל שאר החברות מסביב (הזכרנו את גרסת ה - Lite של YouTube - Go - פחות ברור ישירות מה - Play אם לא מחפשים ישירות).
  • בכלל - אנדרואיד בגרסאות האחרונות ניסו “לחתוך” הרבה, וליצור איזשהו סט יותר מינימלי
  • חוץ מזה, יש את כל פרויקט Android Go וגם מכשירים קצת יותר קלים - בכל סדרת הפיקסלים (Pixel) יש גם מכשירים יותר פשוטים
  • בסוף כולם מבינים שאם עד היום בנינו עבור מי שיכול להרשות לעצמו את החווייה האידיאלית - וכשעשינו את זה כנראה כיוונו אל מה שיותר קרוב אלינו - פספסנו מיליארדים (בלי הגזמה) של אנשים, שהיום אנחנו מנסים להנגיש את השירותים שלנו גם אליהם.
זאת אומרת שאם אני עכשיו משתמש הודי, וקניתי בשוק Galaxy 5 - האם Google תדאג להעלות אותו עם סוג של “Android Lite” כברירת מחדל?
  • אין כזה דבר כברירת מחדל, אבל הם כן מנסים שכאשר משדרגים לאחת ממערכות ההפעלה האחרונות שלהם, החווייה שתתקבל היא יותר “רזה” - אם פעם מערכות ההפעלה הפכו כל הזמן ליותר ויותר “שמנות” ובעצם הכריחו להחליף מכשירים - היום הם מנסים להפוך את הטרנד הזה, ולהגיד שמערכות ההפעלה החדשות לאו דווקא כבדות יותר ומכבידות יותר על המכשיר, אלא להנגיש גם לקהל הזה שירותים.
  • אבל זה בסוף שאלות גם לחבר’ה מ-Google - מעניין איך הם יענו עליהן . . .
למאזינינו ב - Google - אתם מזומנים slightly smiling face 

בוא נדבר קצת על קוד - בתוך אפליקציית פייסבוק אני (רן) מניח שיש כמה מאות פיצ’רים, ויש כמה מאות אלפי שורות קוד, אם לא יותר 
  • כנראה שהרבה מיליונים, וכנראה שגם הגזמת מאוד למטה עם כמות הפיצ’רים . . .
אמרת שאתם למעשה משמרים את רוב הפיצ’רים, אבל עושים Trade-offs - אני מניח שלא כתבתם את כל הקוד מחדש, מאפס - איך עובד המנגנון הזה, של לקחת את “אפליקציית האם”, “לגלף” אותה ולהוציא אפליקציה אחרת? האם יש אילו שהם כלים שבהם אתם משתמשים על מנת לעשות את הטרנספורמציות האלה בקוד, או שפעם בשנה את תופסים את הראש ואומרים “יאללה - צריך לעדכן”?
  • שאלה מעניינת - כי אין תשובה אחת נכונה, ואתה באמת מתפרץ לדלת המאוד פתוחה של “אין עושים את הדבר הזה כך שלא יהיה Engineering-consuming בטירוף?”
  • יש כמה דרכים לעשות את זה - 
    • קודם כל - בהתחלה בנו באמת סט של דברים והייתה הרבה מאוד עבודה כפולה, רק על מנת להראות שהדבר הזה בכלל אפשרי.
    • עם הזמן אנחנו הולכים לסוג של “בנייה בשכבות” - בהתחלה “הכל צריך להיות פה כי זה המנגנון שלנו”; אחר כך מנסים להבין מה אפשר לקחת אחורה כך שיהיה משותף.
    • מתחילים מה - Database ומה - Processing, טכנולוגיות כמו GraphQL והמון Queries שהולכים אחורה לעיבוד מרכזי - הרבה דברים שיושבים מאחורה.
    • כשאתה מגיע ל Facebook Lite אתה בעצם מגיע לשכבה שהיא Server-side שהיא “שלנו” (Lite), ומאחוריה יש שכבה לוגית ושכבת ה - Databases שבה זה כבר משותף לגמרי
      • זה אגב נכון בין אם אתה גולש דרך Browser ובין אם דרך אפליקציית Native, אנדרואיד או IOS - הדברים האלה מנסים להיות מאוד רחבים.
    • עם הזמן ניסינו להביא את האבסטרקציה עוד שכבות קדימה - למשל תוך שימוש ב Native Template שזה סוג של Flex UI, קצת דומה ל React Native (לפחות הקונספט מאוד דומה בשביל ההבנה), שבו אנחנו יכולים להגיד “ככה שכבת UI צריכה “להתנהג” בשביל לתת חווייה מסויימת - וככה היא “מתרנדרת” (rendered) בפייסבוק Lite וככה בפייסבוק Android-native - וככה באתר כשאתה פשוט גולש מהמחשב” - היום אנחנו מנסים שיהיה הרבה פחות שכפול בחוויות האלה.
יש גם שיתוף בין הקוד של אנדרואיד ושל IOS למשל, או שזה לגמרי ורטיקלי?
  • האמת שיש המון שיתוף - ובפרט היום עברנו לאיחוד של כל ה - Codebases ביחד.
  • אם פעם היה לנו Codebase נפרד לאנדרואיד למשל (שיטה מאוד GitHub-ית) - אז היום יש code-base אחוד, כבד מאוד (לעשות Pull זה לא תמיד כיף . . .) - אבל כזה שמאפשר בדיוק את האינטגרציות האלה, שבהן כשיש חווייה משותפת לאנדרואיד, IOS או Website - אתה כותב את החווייה פעם אחת.
  • זה באידיאל . . .  כמובן שבסוף לפעמים השכבות שלמות יותר או שבורות יותר, אבל היום אתה מקבל הרבה יותר מזה “בחינם” לעומת פעם, כשהיית כותב מחדש “ככה ב - IOS זה צריך להיראות”.

אז אתם בעצם נמצאים כל הזמן “במרדף אחרי הפיצ’רים של הגרסא הכחולה”? (אחלה שם לסרט . . .)
  • היום בעצם הפכנו את זה - אם פעם היינו פרוייקט קטן ונישתי שעושים כמה חבר’ה בתל אביב וזה לא היה כל כך מוכר, היום זו כבר אפליקציה של מאות מיליונים.
  • המבנה בפייסבוק הוא סוג-של-מטריציוני (?aren’t we all) - מצד אחד יש לנו את אנשי ה - Interface (כמו Facebook Lite או Facebook for Android), ומצד שני יש מישהו שעובד על “Videos”, ורוצה להוציא סוג חדש של Reactions לוידאו והוא בונה “חוויית וידאו” - היום האינטרס שלו להגיע אלי ולהגיד “דקל - אתה מ - Lite, אני עושה פיצ’ר חדש לוידאו ואני רוצה להוציא אותו אצלכם”.
    • בשיטת המדידה שלנו בפייסבוק מסתכלים על ה-Impact של מה שהוא עושה ועל הקהל שהוא מצליח להגיע אליו - ו”הנה פה יש מאות מליונים שאני יכול להגיע אליהם - מה אני צריך לעשות?”
    • אני עונה שיש Wiki - קרא שם מה צריך לממש - “את זה אנחנו יורשים אותו הדבר בדיוק, את זה אתה צריך לעשות ספציפית - והנה אתה יכול לשבת ולממש את הפיצ’ר שלך”.
    • ככה קצת הצלחנו להפוך את הטרנד מ”אנחנו צריכים לרוץ אחרי כולם כדי להכניס פיצ’רים” ל”אנחנו פלטפורמה כמו שאר הפלטפורמות”, כך שאם למישהו יש אינטרס לדחוף את הפיצ’ר שלו לכמה שיותר פלטפורמות במקביל, זה כולל גם אותנו.

בעצם מה שאתה מתאר זה מצב בו החברה הגיעה לגודל שוק מסויים, ואמרה שעל מנת להתפתח הלאה ולצאת מהשוק המסויים שכבר יש, צריך לפתח איזשהו Growth initiative - ו Lite זה סוג של Growth initiative, כי אני רוצה להגיע עכשיו לעוד הרבה משתמשים.
בטח לקח כמה שנים עד שה - Growth initiative הזה הגיע להיות מספיק גדול כדי שיקרה מהרגע תיארת, ומתחיל להיות חלק מה - Core של Facebook, כי הוא מחזיק איזשהו נתח ניכר מהמשתמשים.
מהו סדר הגודל של ה”נתח הניכר” הזה, אם אתה יכול להגיד? כמה מהמשתמשים של Facebook היום הם “Lite”?
נניח 20%-30%? (ללא תגובה) - בכל מקרה נתח מאוד משמעותי, לגמרי חלק מה - Core של המוצר.
  • היום כשמסתכלים על פייסבוק Lite, הוא לחלוטין בטופ של ה 4-5 Interfaces החזקים שלנו
  • למעשה אני חושב אפילו שהגודל היום של Facebook Lite באנדרואיד דומה לאפליקציית Native של iPhone - כי יש כל כך הרבה אנשים בשווקים המתפתחים האלה, שזה כבר דומה לכמות המשמשים בעולם שיש להם מכשירי iPhone חדשים.
    • זה נתון די פסיכי - להבין שאלו סדרי הגודל, בלי לזכור בדיוק מי כרגע קצת יותר קדימה.

זה נכון להגיד על פיצ’ר שפיתחת ש”אם זה רץ על Lite, זה בטוח ירוץ על האפליקציה הכחולה”?
  • לא.
  • יש כמה רמות של אבסטרקציה - מרמת ה - Database, Feed, Processes וכל החוויה שהמשתמשים מקבלים, ועד רמות ה - React Native וה - Rendering ואיך שהמסך נראה.
  • בסוף - החיבורים האלה כן נעשים לפי אפליקציה, כי אתה רוצה שהחווייה תיהיה מאוד קוהרנטית, ולא רוצה מצב של קפיצה ממסך אחד למסך אחר, כי אז אם תיקח את זה לאנדרואיד או Browser או iPhone ,חוויית ה - Back או ה - Manuals למשל לא לגמרי דומות, ויש שם צורך בקצת חיבור קצוות פתוחים.
  • עדיין - היום המרחק הוא משמעותית קטן יותר
  • לא רק שהוא קטן יותר - בניגוד לפעם, כשהיית צריך להיות Super Lite-Engineer מנוסה ולהבין את הפרוטוקול כדי לכתוב איזשהו פיצ’ר, היום הרבה מאוד מה”איך עושים את הדברים” מאוד מונגש מבחינת ה - codebase לדברים שאנשים רגילים לעשות ב  -Facebook ורגילים להשתמש בהם.

אם אני היום בא - וממש מתחשק לי לכתוב אפליקציה Lite מאיזושהי סיבה (נניח שהשוק שלי הוא איפשהו בשווקים מתפתחים) - אני מניח שאני אעשה טעות פטאלית אם אבחר ב - Framework כמו Flutter או CORDOVA - או אפילו React Native שהזכרת קודם.
עד כמה? תוכל לתת איזשהו קנה מידה עד כמה הטעות הזאת הולכת להיות פטאלית? כמה זה הולך “לעלות לי”?
  • אני לא בטוח שיש לנו איזושהי השוואה ספציפית - אבל אני חושב שגם חשוב להגיד שאין פה תשובה אחת נכונה.
  • כל אפליקציה ומה שהיא מנסה לעשות ומה שהיא מנסה להציג ולפי החווייה שהיא מנסה לייצר - תבחר בחירה אחרת.
  • אם אתה נותן משהו כמו אפליקציה להאזנה לפודקאסטים (דוגמא היפותטית - איזה שוק יש לזה בכלל?), כנראה יש לך איזשהו Core שישב ב - Client, כי אתה תרצה שהוא יהיה שם כדי לתת חווייה טובה.
    • מצד שני - אם הוא ממש (ממש) כבד, אולי תבחר במשהו ייעודי קטן ל - Client ומשהו שיקרה ב - Server-side.
  • אני לא חושב שאף אחת מהטכנולוגיות האלה היא בחירה פטאלית - את React Native ספציפית אני זוכר ששקלנו והמשקל בסוף של ה - Client, ב - Megabytes, הוא לא משהו שהיינו מוכנים ”לשלם”
    • אבל מאז אני חושב שהם עשו כברת דרך ויש להם חווייה הרבה יותר בסיסית היום, כלומר - אם פעם היו המון Dependencies על רשת של עשרות חבילות שמגיעות ברגע שאתה עושה את ה “Hello world” שלך, אז היום זה הרבה יותר מודולרי ואתה יכול לקבל רק את מה שאתה באמת צריך.
  • אני לא חושב שיש כאן נוסחא מושלמת ומוכנה של “הנה ה א’-עד-ת’ שאתה צריך לעשות”, אלא יותר שצריך להיות Minded לזה, ולחשוב Lite-י, מה אתה רוצה שיהיה “קל” ועל אילו אלמנטים - ולפי זה לבחור.

אתם ביום-יום שלכם כותבים עבור IOS ב Objective C וב-Java לאנדרואיד?
  • כן - באופן כללי בפייסבוק אנחנו בגישת ה “The right tool for the job” - מ - Objective C וקצת Swift ולאנדרואיד React Native, ובאמצע קצת טכנולוגיות Lite-יות וכל מיני פייתונים (כזה, לא כזה) מוזרים שרצים . . .
רגע - מה הכוונה ב “טכנולוגיות Lite-יות”? דברים שרצים על ה - Server?
  • למשל כמו Snaptu, כשיש לך פרוטוקול שרץ על ה - Server וכאלה.
אני (רן) אגיד לפחות לפי ידעתי מה Snaptu עשו - למעשה הם היו עושים Rendering בצד של ה - Server ושולחים .jpeg ל - Client, שהיה פשוט מציג את התמונה, ולא “באמת” היו כפתורים בתוך הטלפון, אלא היו מציגים תמונה ו”מרגישים” איפה לוחצים על הכפתור.
  • כן -איזשהו מימוש בצד הקיצוני של הסקאלה של “Thin Client”, שבו יש לך תמונה ואת ה (X,Y) של הקליק - וזהו.
  • הארכיטקטורה היום עדיין דומה, אבל הייצוג הרבה יותר מתקדם - יש כל מיני Flexboxes, והייצוג UI יכול להיות יותר ב - Client side בלי שאנחנו מכבידים עליו.
אגב - הטרנד הזה בא והולך . . . לא מזמן Google הכריזו על איזשהו מוצר ל - Gaming שעובד בדיוק בצורה הזו (Stadia) - מנוע Gaming לאנדרואיד שעושה את כל ה - Rendering בצד של ה-Server, ורק מציג את התמונות בצד של ה - Client.
הרבה מאוד מעולם ה - Gaming הולך למקום הזה - וזה ניהיה גם שוק מטורף ל-GPUs (פרק 363 עם nVidia) - בצד של ה - Server.

אני (אורי) חושב שגם מיקרוסופט עם Xbox וכו’ מתחילים לדבר על זה - לכל גיימר מרנדרים (Render) בעצם Video Stream.
ו - Xbox זה חתיכת מפלצת, לא משהו קליל.
  • אז להשקיע ב - nVidia?

אז לקראת סיום - יש עוד נושאים שרצית להזכיר ולא הגענו אליהם?
  • אפשר לדבר קצת על פרויקטים שעשינו על מנת להצליח להיות Lite-ים.
  • אם הסתכלנו על המדדים של מה שחשוב לנו עם Facebook Lite (“האפליקציה הלבנה”), אז היו לנו את גודל האפליקציה, זמן הטעינה שלה, נפח האחסון שלה וכו’.
  • כשהצבנו לנו מדדים על כל אחד מאלה, התחלנו לבוא עם הרבה מאוד פרויקטים - חלק בסקלה של Trade-offs כמו Cache או Prefetching (בדומה ל - Trade-offs של CPU) - האם לעשות Pre-fetch לתמונות, או אפילו Pre-fetch ב - Server-side  -אם אני יודע שאני חוזה שמשתמש הולך להתחבר, אני הולך מראש להביא מ - Cache מאוד רחוקים תמונות שיהיו ב - Cache קרוב, כל מיני ZippyDB וכאלה - כדי שיהיה קל מאוד לשלוף.
  • היו לנו גם כל מיני פרוייקטים ב - Client Side, כמו למשל - מאוד היה חשוב לנו שהחווייה הראשונית תיהיה מאוד קלה, ולכן רצינו להוריד הרבה מאוד משקל מה - APK, מהגודל הבינארי.
  • עשינו כמה פרויקטים - 
    • אחד היה לטעון כמה שיותר תוכן ומדיה בצורה Lazy-ית (“עצלנית”) - האפליקציה עולה פעם ראשונה, ובעצם לכאורה חלק מהדברים חסרים.
    • דוגמא אחת שאני יכול לזכור - יש סאונד אופייני לכל קליק (לא עובר טוב בטקסט - תקשיבו או תעשו טו-דו-דו לבד …) - עשינו ככה שאם תעלה את פייסבוק Lite מאוד מהר ותלחץ מיד !Like, יש סיכוי שלא תשמע את הצליל (מעניין האם תשים לב שלא שמעת או שהמוח כבר ישלים לבד…), ותצטרך לבקש ממישהו ליד שישלים לך.
    • זה סוג ה - Trade-offs - זה נשמע לנו כמו מחיר שהגיוני לשלם כדי שקודם כל תוכל להתחיל להשתמש הכי מהר, אם פתאום לא הייתה לך קליטה או שאתה בדיוק עולה על רכבת - יש לך 1Mb וקיבלת את האפליקציה.
    • מצד שני - אחר כך תוריד ותקבל חווייה מלאה - ואולי נוכל לתת לך עוד קבצי סאונד בלי שתצטרך להוריד Update לכל האפליקציה, ואפשר להוריד כל מיני קבצי מדיה כאלה שעשינו להם הורדות Lazy, או Optional Downloads כמו שקראנו לזה.
    • היו לנו גם פרויקטים יותר ברמת הטכנולוגיה - למשל הסתכלנו על אנדרואיד והסתכלנו על מערכת ה - exceptions, שזה פרויקט שאני ספציפית התעסקתי איתו לא מעט - בין השאר גילינו שאנחנו שולחים המון Symbols . . . בלי להיכנס יותר מדי לעומק, כשאנחנו כמפתחים מקבלים Exceptions, אנחנו מצפים ל  -Stack-trace יפה ומפורסר (Parsing) עם כל הפונקציות ומה גרם למה ולמה יש לנו Exception ואיזה Crash - וכל המנגנון הזה עובד על ידי זה שב - Client אנחנו שולחים את כל ה - Symbols, כדי שכשה-JVM בזמן ריצה קורס, הוא יוכל להגיד - “הנה, זה היה בפונקציה ()ShowVideoFeed"
      • ואז הבנו שכל הדבר הזה תופס לנו בערך 15% מכל גודל הקוד, וחשבנו מה יקרה אם נוכל לשים את זה ב - Server side?
      • לקח לנו הרבה חודשים להצליח לייצב את זה ולהצליח לתת כיסוי אינהרנטי לכלל המצבים שאפשר להגיע אליהם - זה קצת מסובך וזה בתוך ה-JVM - אבל כשעשינו את זה בסוף אמרנו “הנה דרך להוריד 15% מגודל הקוד, וזה לא Trade-off עבור המשתמש” (שלא אכפת לו איך אני שולח Exceptions ומתי אני עושה פרסום ל - Stack-trace).
      • חוץ מזה - אנחנו יכולים לעשות את זה גם לכל שאר האפליקציות של פייסבוק . . . “הנה - קחו 15% בחינם”.
      • מעבר לזה - אפשר לעשות את זה Open-source עבור שאר האפליקציות שרוצות לתת חווייה טובה למשתמשים.
    • איך למעשה אתה יכול לעשות את זה? כל הסיפור הזה בשליטה של ה - JVM (או Dalvik) - איך אתה “נכנס לקרביים” שלו? זו הרי מערכת ההפעלה.
    •  - או לקרוס . . .
    • אבל כשזה קורס אין לך Stack-trace
    • ה - Downside הוא לא נורא, כי גם אם אתה קורס, היית בכל מקרה באמצע קריסה . . . הסיכון העיקרי שלך הוא לא לדעת מה קרה
  • ואת זה שרדינגר כבר פתר. או שלא.
מגניב - נשמע אחלה אתגר, פרוייקט מאוד מעניין.

תודה רבה - ואוטוטו מזל טוב! (כבר היה - עדיין).

הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

אין תגובות:

פרסום תגובה