התחל במצב לא מקוון עם האפליקציה Player FM !
379 Building lightweight apps with Dekel Naar
סדרה בארכיון ("עדכון לא פעיל" status)
When? This feed was archived on December 02, 2020 11:09 (). Last successful fetch was on October 23, 2020 02:18 ()
Why? עדכון לא פעיל status. השרתים שלנו לא הצליחו לאחזר פודקאסט חוקי לזמן ממושך.
What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.
Manage episode 245135410 series 2523706
- דקל - בן 32, גר ועובד בתל אביב - כבר בערך 6 שנים בפייסבוק ישראל.
- בשנים האחרונות מתמחה ב - Performance של אפליקציות - הרבה על אנדרואיד ולאחרונה גם קצת על IOS, ועושה כל מיני דברים מגניבים.
- בהשוואה ללפני חמש שנים, מה שקורה היום הוא שקורה הרבה -
- המשרד גדל מאוד - התחלנו ממשרד של 20-30 מהנדסים והיום אנחנו כבר מעל 250, וכבר יש לנו 4-5-6 פרוייקטים שרצים במקביל עם הרבה מאוד צוותים.
- מתמחים בעיקר באיזור של Connectivity ובעצם ב-Emerging Markets - יש לנו פרויקטים בנושא חיבור אנשים לאינטרנט כמו Internet.org, הרבה פרוייקטים סביב הנושא של “Lite" - אפליקציות “קלות” לאנדרואיד ול - IOS ולמערכות הפעלה נוספות - כל מה שיכול ליצור חווייה טובה יותר למשתמשים ממקומות שהם לא מרכז תל אביב או סן פרנסיסקו או ניו-יורק, עם ה - iPhone 11 Pro שיצא לפני שבועיים . . .
- שאלה מעולה - שאין לה תשובה אחת, אלא הרבה מאוד תשובות שמשתנות לפי המקומות.
- יש מקומות שבהם זו הרשת הסלולארית - או Wi-Fi, או האם יש בכלל רשת סלולארית
- האם יש בכלל חשמל?
- יש מקומות שבהם ראינו שאנשים משתמשים בכוונה ב - Feature Phones, כי הם “מחזיקים” יותר זמן בלי חשמל
- מדובר ב - Buzz word נפוצה עבור מכשירים “מלפני עידן ה - iPhone” . . . כל מיני מכשירים של Nokia ו - Windows Phones וגם מכשירי Android של $20/$50/$100 - מכשירים מאוד חלשים במהותם.
- אגב, ה - Nokia שהיה לי (אורי) פעם היה הדבר הכי חזק שאני מכיר, זה לא נשבר.
- אז זה גם מכשירים - וגם כאן אפשר לאפיין מכשירים שיש בהם בעיית זיכרון (מאוד בולט) או כוח עיבוד - או שפשוט אין מקום . . . אתה מכיר אנשים עם כל מיני iPhone-16Gb שכל הזמן מוחקים תמונות כי נגמר המקום? אז “אהה - פייסבוק, 0.5Gb?! בוא נמחק את זה”.
- אז אמרנו אחסון ורשתות - וגם עניין של הרגלים, או אפילו חלוקה של כמה משתמשים באותו מכשיר לצורך גישה.
- ראינו המון מאפיינים שונים שגרמו לנו להגיע לזה - ובפרט הגענו עם כמה מוצרים שונים.
- דקל הגיע מתוך Onavo, מה שאולי מסביר את המשיכה הספציפית לתחום.
- דווקא להיפך - אני (דקל) חושב שאלו טכנולוגיות שפייסבוק הביאה אליה דווקא כיוון שהיא ראתה את האופק הזה - יש אנשים שיודעים “לתקל” (Tackle) את השווקים האלה, אז אפשר להשתמש בטכנולוגיות הללו ולנצל אותן על מנת לתת חווייה טובה יותר (אפשר לפרש את הפסקה האחרונה בכל מיני צורות…).
- כן - וזה כבר מזמן לא רק פייסבוק: אנחנו רואים אפליקציות Lite גם מכיוון YouTube (לא Lite אלא YouTube Go) ו - Spotify Lite - זה טרנד שנכנסנו (פייסבוק) אליו יחסית מוקדם, ועם הרבה מאוד כח אש
- זה הקהל הבא - החברות הללו רוצות לגדול, המשקיעים מצפים שהחברות האלה תגדלנה - וכשאתה מגיע ל 2-3 מיליארד משתמשים אתה שואל “מה עושים?”.
- לא רומז - אומר . . . לך ל App Store או ל Google Play וחפש את Facebook Lite - עבור אנדרואיד זה כבר בכל המדינות בעולם, עבור השאר אנחנו עדיין בשלבי פיתוח כאלה ואחרים - וזו אפליקציה שגם בארץ יש לה לא מעט משתמשים
- זה לא רק חברים שלנו ואשתי שאני אומר להם להוריד - זה גם אנשים אחרים :-)
- וזה קצת הפתיע אותנו - לאנשים חשובה הרספונסיביות (responsiveness) ושזה לא יתפוס להם הרבה מקום ב - Storage כי הם רוצים לצלם עכשיו תמונות ולא להתעסק בכמה מקום נשאר, או זה שיש קליטה קצת מעפנה ואנחנו רוצים שדברים עדיין יתפקדו לנו בצורה סבירה.
- לגמרי נכון - יש לנו בשביל זה גם כמה צוותי Performance מאוד חזקים שעובדים וזה מה שהם מנסים לעשות.
- אגב - גם היום באפליקציית Facebook “הכחולה” (הלא-Lite), זו שרוב האנשים משתמשים בה, יש המון פוקוס על כל סוגי הביצועים, החל מ Storage דרך כמה זמן לוקח לה לעלות “כשהכל קר”, כמה זיכרון היא תופסת ועוד - יש צוות לכל דבר כזה ומערכות כלים שלמות על מנת לראות איך אנחנו גורמים לכל וקטור כזה להיות במקסימום שאנחנו יודעים לייצר, ואיך אנחנו גם לא פוגעים בחווייה בזמן שאנחנו מצליחים לגרום לאפליקציות להצטמק ולהצטמק ולהיות יותר ויותר קלילות על הטלפון.
- בלי סוכר?
- בסך הכל החוויה מאוד דומה, ויש Trade-offs שאותם אנחנו לוקחים בצורה קצת שונה, מתוך הבנה שמי שבוחר את אפליקציית ה - Lite על פני הרגילה בעצם בוחר בזה - בין אם זו מדיניות של Cache בצורה מסויימת ואיך דברים עובדים, או לשחק קצת עם רזולוציות של תמונות וחוויות ודברים כאלה.
- נכון - יש כל מיני Trade-offs, ובמקומות מסויימים גם בחירה בטכנולוגיות שלאו דווקא מביאות Trade-off מסויים כדי להצליח להגיד שבנינו את זה בצורה יותר יעילה (?).
- זה Trade-off בין אלמנטים של המשתמש - זה יכול להיות גם בין האחסון שלו לבין השימוש שלו ברשת, אבל בסוף פונקציית המקסימום היא על החווייה שלו.
- אני לא צריך להקריב את החווייה בשביל הביצועים, אבל החווייה הכוללת צריכה להיות עם ROI חיובי.
- הדבר הראשון הוא שזה באמת לא טריוויאלי - זה שמתחילים בלמדוד, ולהבין איפה בכלל אנחנו נמצאים.
- גודל האפליקציה זה משהו מאוד קל למדידה - תקמפל (Compile) ותראה מה הגודל.
- לדברים כמו גדלי ה -Cache השונים או Storage footprint (כמה בסה”כ אנחנו משתמשים ב - Storage של המכשיר) - אנחנו מכניסים קוד ייעודי שעושה איזושהי הערכה (“תפסנו עכשיו 22Mb בשביל ה - Cache הזה וזה ה - Cache-Hit שלנו”).
- יש לנו המון כלים שמפותחים in-house - חלקם יותר Open-Source כמו Hive וכאלה וחלקם בשלב בגרות יותר מוקדם
- ברוב הפעמים, כשאנחנו רוצים להבין מה קורה, אנחנו משתמשים ברצף של מידע, כשאנחנו משתמשים בכלי פנימי שלנו ואומרים - “אוקיי, כאן אנחנו נמצאים כרגע - איפה אנחנו רוצים להיות עוד רבעון / חציון וכו’ - מה יכול להביא אותנו לשם?”.
- עורכים מעיין Brainstorming ויוצאים עם סט של פרויקטים שאם נצליח בהם - נצליח להביא את השינוי שאנחנו מעוניינים בו.
- כן - גם מבחינת ייצוג פרוטוקולים וכאלה, וספציפית - Facebook Lite היא אפליקציה שבה הרבה מה - Heavy Lifting והרבה לוגיקה וכוח העיבוד יושב בשרתים, וזה מבוסס על טכנולוגיה שהזכרנו קודם, של Snaptu - שהיום הפכה ל”מפלצת” שאף אחד לא דמיין שתיהיה.
- יש לנו סט ענק של שרתים שעושים גם את העיבוד עבור המשתמש, החל מאיזה סט של Feeds או אילו Stories אתה עכשיו הולך לראות ועד איך אנחנו מצפים שה - Client ירדנדר (Render) את זה ואיך לשלוח דברים על הפרוטוקול.
- גם כאן יש לנו trade-offs של האם עדיף לעשות את זה ב Client-side או ב - Server-side, לפי מה שיתן בסוף את החווייה או את הביצועים היותר טובים.
- זה נכון, אעפ”י שבדרך כלל זה לאו-דווקא מתבטא ב - Bandwidth
- לרוב הייצוג יכול להיות לא פחות יעיל, אבל סט של עיבוד מסויים שתעשה על השרת “יעלה לך” ב - round-trip ובזמן יותר ארוך, ואז תשאל את עצמך - עבור המכשיר הממוצע או עבור ה - Use-case הספציפי, האם בסך הכל זה שהעברתי את הפעולה ל-Server Side תשפר את מה שהמתשמש חווה?
- מצחיק, אבל באמת בונים את כל חוות השרתים באיזורים הנורדיים - חוות פסיכיות, והכל מבוסס על אנרגיה ירוקה, מכניסים אוויר קר בחורף וכו’, די טירוף.
- ובדיוק שכבר חשבתם שיש אייטם לפרק 1 באפריל הבא - אז זה מ - 1 באפריל 2019 . . .
- יש לנו כמה נתונים די פסיכיים . . .
- קודם כל - הגודל של ה - 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”), וככה אנחנו פונים בדיוק לאוכלוסיה הספציפית שיכולה להרוויח משימוש באפליקציה הזו.
- עדיין לא . . .
- מבחינה ארכיטקטונית, WhatsApp למשל יותר “קלה”, והאפליקציות שמרו על סט מאוד רזה של פיצ’רים ו - Performance מאוד גבוה. Instagram עדיין לא הגיעו לאיזור הזה.
- עבור שאר האפליקציות מסביב אנחנו עושים אפקט דומה - Messenger למשל עושה ככה היום.
- גם Google לא מזניחה את התחום הזה, וגם כל שאר החברות מסביב (הזכרנו את גרסת ה - Lite של YouTube - Go - פחות ברור ישירות מה - Play אם לא מחפשים ישירות).
- בכלל - אנדרואיד בגרסאות האחרונות ניסו “לחתוך” הרבה, וליצור איזשהו סט יותר מינימלי
- חוץ מזה, יש את כל פרויקט Android Go וגם מכשירים קצת יותר קלים - בכל סדרת הפיקסלים (Pixel) יש גם מכשירים יותר פשוטים
- בסוף כולם מבינים שאם עד היום בנינו עבור מי שיכול להרשות לעצמו את החווייה האידיאלית - וכשעשינו את זה כנראה כיוונו אל מה שיותר קרוב אלינו - פספסנו מיליארדים (בלי הגזמה) של אנשים, שהיום אנחנו מנסים להנגיש את השירותים שלנו גם אליהם.
- אין כזה דבר כברירת מחדל, אבל הם כן מנסים שכאשר משדרגים לאחת ממערכות ההפעלה האחרונות שלהם, החווייה שתתקבל היא יותר “רזה” - אם פעם מערכות ההפעלה הפכו כל הזמן ליותר ויותר “שמנות” ובעצם הכריחו להחליף מכשירים - היום הם מנסים להפוך את הטרנד הזה, ולהגיד שמערכות ההפעלה החדשות לאו דווקא כבדות יותר ומכבידות יותר על המכשיר, אלא להנגיש גם לקהל הזה שירותים.
- אבל זה בסוף שאלות גם לחבר’ה מ-Google - מעניין איך הם יענו עליהן . . .
- כנראה שהרבה מיליונים, וכנראה שגם הגזמת מאוד למטה עם כמות הפיצ’רים . . .
- שאלה מעניינת - כי אין תשובה אחת נכונה, ואתה באמת מתפרץ לדלת המאוד פתוחה של “אין עושים את הדבר הזה כך שלא יהיה 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 - וככה באתר כשאתה פשוט גולש מהמחשב” - היום אנחנו מנסים שיהיה הרבה פחות שכפול בחוויות האלה.
- האמת שיש המון שיתוף - ובפרט היום עברנו לאיחוד של כל ה - Codebases ביחד.
- אם פעם היה לנו Codebase נפרד לאנדרואיד למשל (שיטה מאוד GitHub-ית) - אז היום יש code-base אחוד, כבד מאוד (לעשות Pull זה לא תמיד כיף . . .) - אבל כזה שמאפשר בדיוק את האינטגרציות האלה, שבהן כשיש חווייה משותפת לאנדרואיד, IOS או Website - אתה כותב את החווייה פעם אחת.
- זה באידיאל . . . כמובן שבסוף לפעמים השכבות שלמות יותר או שבורות יותר, אבל היום אתה מקבל הרבה יותר מזה “בחינם” לעומת פעם, כשהיית כותב מחדש “ככה ב - IOS זה צריך להיראות”.
- היום בעצם הפכנו את זה - אם פעם היינו פרוייקט קטן ונישתי שעושים כמה חבר’ה בתל אביב וזה לא היה כל כך מוכר, היום זו כבר אפליקציה של מאות מיליונים.
- המבנה בפייסבוק הוא סוג-של-מטריציוני (?aren’t we all) - מצד אחד יש לנו את אנשי ה - Interface (כמו Facebook Lite או Facebook for Android), ומצד שני יש מישהו שעובד על “Videos”, ורוצה להוציא סוג חדש של Reactions לוידאו והוא בונה “חוויית וידאו” - היום האינטרס שלו להגיע אלי ולהגיד “דקל - אתה מ - Lite, אני עושה פיצ’ר חדש לוידאו ואני רוצה להוציא אותו אצלכם”.
- בשיטת המדידה שלנו בפייסבוק מסתכלים על ה-Impact של מה שהוא עושה ועל הקהל שהוא מצליח להגיע אליו - ו”הנה פה יש מאות מליונים שאני יכול להגיע אליהם - מה אני צריך לעשות?”
- אני עונה שיש Wiki - קרא שם מה צריך לממש - “את זה אנחנו יורשים אותו הדבר בדיוק, את זה אתה צריך לעשות ספציפית - והנה אתה יכול לשבת ולממש את הפיצ’ר שלך”.
- ככה קצת הצלחנו להפוך את הטרנד מ”אנחנו צריכים לרוץ אחרי כולם כדי להכניס פיצ’רים” ל”אנחנו פלטפורמה כמו שאר הפלטפורמות”, כך שאם למישהו יש אינטרס לדחוף את הפיצ’ר שלו לכמה שיותר פלטפורמות במקביל, זה כולל גם אותנו.
- אני חושב שהנתונים האחרונים שלנו הם של מעל מיליארד, או מעל 2 מיליארד כשמסתכלים בהסתכלות חודשית על כלל משתמשי פייסבוק - אצלנו מדברים על מאות מיליונים.
- היום כשמסתכלים על פייסבוק Lite, הוא לחלוטין בטופ של ה 4-5 Interfaces החזקים שלנו
- למעשה אני חושב אפילו שהגודל היום של Facebook Lite באנדרואיד דומה לאפליקציית Native של iPhone - כי יש כל כך הרבה אנשים בשווקים המתפתחים האלה, שזה כבר דומה לכמות המשמשים בעולם שיש להם מכשירי iPhone חדשים.
- זה נתון די פסיכי - להבין שאלו סדרי הגודל, בלי לזכור בדיוק מי כרגע קצת יותר קדימה.
- לא.
- יש כמה רמות של אבסטרקציה - מרמת ה - Database, Feed, Processes וכל החוויה שהמשתמשים מקבלים, ועד רמות ה - React Native וה - Rendering ואיך שהמסך נראה.
- בסוף - החיבורים האלה כן נעשים לפי אפליקציה, כי אתה רוצה שהחווייה תיהיה מאוד קוהרנטית, ולא רוצה מצב של קפיצה ממסך אחד למסך אחר, כי אז אם תיקח את זה לאנדרואיד או Browser או iPhone ,חוויית ה - Back או ה - Manuals למשל לא לגמרי דומות, ויש שם צורך בקצת חיבור קצוות פתוחים.
- עדיין - היום המרחק הוא משמעותית קטן יותר
- לא רק שהוא קטן יותר - בניגוד לפעם, כשהיית צריך להיות Super Lite-Engineer מנוסה ולהבין את הפרוטוקול כדי לכתוב איזשהו פיצ’ר, היום הרבה מאוד מה”איך עושים את הדברים” מאוד מונגש מבחינת ה - codebase לדברים שאנשים רגילים לעשות ב -Facebook ורגילים להשתמש בהם.
- אני לא בטוח שיש לנו איזושהי השוואה ספציפית - אבל אני חושב שגם חשוב להגיד שאין פה תשובה אחת נכונה.
- כל אפליקציה ומה שהיא מנסה לעשות ומה שהיא מנסה להציג ולפי החווייה שהיא מנסה לייצר - תבחר בחירה אחרת.
- אם אתה נותן משהו כמו אפליקציה להאזנה לפודקאסטים (דוגמא היפותטית - איזה שוק יש לזה בכלל?), כנראה יש לך איזשהו Core שישב ב - Client, כי אתה תרצה שהוא יהיה שם כדי לתת חווייה טובה.
- מצד שני - אם הוא ממש (ממש) כבד, אולי תבחר במשהו ייעודי קטן ל - Client ומשהו שיקרה ב - Server-side.
- אני לא חושב שאף אחת מהטכנולוגיות האלה היא בחירה פטאלית - את React Native ספציפית אני זוכר ששקלנו והמשקל בסוף של ה - Client, ב - Megabytes, הוא לא משהו שהיינו מוכנים ”לשלם”
- אבל מאז אני חושב שהם עשו כברת דרך ויש להם חווייה הרבה יותר בסיסית היום, כלומר - אם פעם היו המון Dependencies על רשת של עשרות חבילות שמגיעות ברגע שאתה עושה את ה “Hello world” שלך, אז היום זה הרבה יותר מודולרי ואתה יכול לקבל רק את מה שאתה באמת צריך.
- אני לא חושב שיש כאן נוסחא מושלמת ומוכנה של “הנה ה א’-עד-ת’ שאתה צריך לעשות”, אלא יותר שצריך להיות Minded לזה, ולחשוב Lite-י, מה אתה רוצה שיהיה “קל” ועל אילו אלמנטים - ולפי זה לבחור.
- כן - באופן כללי בפייסבוק אנחנו בגישת ה “The right tool for the job” - מ - Objective C וקצת Swift ולאנדרואיד React Native, ובאמצע קצת טכנולוגיות Lite-יות וכל מיני פייתונים (כזה, לא כזה) מוזרים שרצים . . .
- למשל כמו Snaptu, כשיש לך פרוטוקול שרץ על ה - Server וכאלה.
- כן -איזשהו מימוש בצד הקיצוני של הסקאלה של “Thin Client”, שבו יש לך תמונה ואת ה (X,Y) של הקליק - וזהו.
- הארכיטקטורה היום עדיין דומה, אבל הייצוג הרבה יותר מתקדם - יש כל מיני Flexboxes, והייצוג UI יכול להיות יותר ב - Client side בלי שאנחנו מכבידים עליו.
- אז להשקיע ב - 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) - איך אתה “נכנס לקרביים” שלו? זו הרי מערכת ההפעלה.
- יש כל מיני דברים שאתה יכול להתמש בהם, כמו מה קורה כשה - Exception קורס ואז הוא קורא לך בדיוק לפני שהוא הולך לרדת, ושם היינו צריכים להתעסק קצת עם איכסה, אבל אפשר לגרום לזה לקרות…
- - או לקרוס . . .
- אבל כשזה קורס אין לך Stack-trace
- ה - Downside הוא לא נורא, כי גם אם אתה קורס, היית בכל מקרה באמצע קריסה . . . הסיכון העיקרי שלך הוא לא לדעת מה קרה
- ואת זה שרדינגר כבר פתר. או שלא.
25 פרקים
סדרה בארכיון ("עדכון לא פעיל" status)
When? This feed was archived on December 02, 2020 11:09 (). Last successful fetch was on October 23, 2020 02:18 ()
Why? עדכון לא פעיל status. השרתים שלנו לא הצליחו לאחזר פודקאסט חוקי לזמן ממושך.
What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.
Manage episode 245135410 series 2523706
- דקל - בן 32, גר ועובד בתל אביב - כבר בערך 6 שנים בפייסבוק ישראל.
- בשנים האחרונות מתמחה ב - Performance של אפליקציות - הרבה על אנדרואיד ולאחרונה גם קצת על IOS, ועושה כל מיני דברים מגניבים.
- בהשוואה ללפני חמש שנים, מה שקורה היום הוא שקורה הרבה -
- המשרד גדל מאוד - התחלנו ממשרד של 20-30 מהנדסים והיום אנחנו כבר מעל 250, וכבר יש לנו 4-5-6 פרוייקטים שרצים במקביל עם הרבה מאוד צוותים.
- מתמחים בעיקר באיזור של Connectivity ובעצם ב-Emerging Markets - יש לנו פרויקטים בנושא חיבור אנשים לאינטרנט כמו Internet.org, הרבה פרוייקטים סביב הנושא של “Lite" - אפליקציות “קלות” לאנדרואיד ול - IOS ולמערכות הפעלה נוספות - כל מה שיכול ליצור חווייה טובה יותר למשתמשים ממקומות שהם לא מרכז תל אביב או סן פרנסיסקו או ניו-יורק, עם ה - iPhone 11 Pro שיצא לפני שבועיים . . .
- שאלה מעולה - שאין לה תשובה אחת, אלא הרבה מאוד תשובות שמשתנות לפי המקומות.
- יש מקומות שבהם זו הרשת הסלולארית - או Wi-Fi, או האם יש בכלל רשת סלולארית
- האם יש בכלל חשמל?
- יש מקומות שבהם ראינו שאנשים משתמשים בכוונה ב - Feature Phones, כי הם “מחזיקים” יותר זמן בלי חשמל
- מדובר ב - Buzz word נפוצה עבור מכשירים “מלפני עידן ה - iPhone” . . . כל מיני מכשירים של Nokia ו - Windows Phones וגם מכשירי Android של $20/$50/$100 - מכשירים מאוד חלשים במהותם.
- אגב, ה - Nokia שהיה לי (אורי) פעם היה הדבר הכי חזק שאני מכיר, זה לא נשבר.
- אז זה גם מכשירים - וגם כאן אפשר לאפיין מכשירים שיש בהם בעיית זיכרון (מאוד בולט) או כוח עיבוד - או שפשוט אין מקום . . . אתה מכיר אנשים עם כל מיני iPhone-16Gb שכל הזמן מוחקים תמונות כי נגמר המקום? אז “אהה - פייסבוק, 0.5Gb?! בוא נמחק את זה”.
- אז אמרנו אחסון ורשתות - וגם עניין של הרגלים, או אפילו חלוקה של כמה משתמשים באותו מכשיר לצורך גישה.
- ראינו המון מאפיינים שונים שגרמו לנו להגיע לזה - ובפרט הגענו עם כמה מוצרים שונים.
- דקל הגיע מתוך Onavo, מה שאולי מסביר את המשיכה הספציפית לתחום.
- דווקא להיפך - אני (דקל) חושב שאלו טכנולוגיות שפייסבוק הביאה אליה דווקא כיוון שהיא ראתה את האופק הזה - יש אנשים שיודעים “לתקל” (Tackle) את השווקים האלה, אז אפשר להשתמש בטכנולוגיות הללו ולנצל אותן על מנת לתת חווייה טובה יותר (אפשר לפרש את הפסקה האחרונה בכל מיני צורות…).
- כן - וזה כבר מזמן לא רק פייסבוק: אנחנו רואים אפליקציות Lite גם מכיוון YouTube (לא Lite אלא YouTube Go) ו - Spotify Lite - זה טרנד שנכנסנו (פייסבוק) אליו יחסית מוקדם, ועם הרבה מאוד כח אש
- זה הקהל הבא - החברות הללו רוצות לגדול, המשקיעים מצפים שהחברות האלה תגדלנה - וכשאתה מגיע ל 2-3 מיליארד משתמשים אתה שואל “מה עושים?”.
- לא רומז - אומר . . . לך ל App Store או ל Google Play וחפש את Facebook Lite - עבור אנדרואיד זה כבר בכל המדינות בעולם, עבור השאר אנחנו עדיין בשלבי פיתוח כאלה ואחרים - וזו אפליקציה שגם בארץ יש לה לא מעט משתמשים
- זה לא רק חברים שלנו ואשתי שאני אומר להם להוריד - זה גם אנשים אחרים :-)
- וזה קצת הפתיע אותנו - לאנשים חשובה הרספונסיביות (responsiveness) ושזה לא יתפוס להם הרבה מקום ב - Storage כי הם רוצים לצלם עכשיו תמונות ולא להתעסק בכמה מקום נשאר, או זה שיש קליטה קצת מעפנה ואנחנו רוצים שדברים עדיין יתפקדו לנו בצורה סבירה.
- לגמרי נכון - יש לנו בשביל זה גם כמה צוותי Performance מאוד חזקים שעובדים וזה מה שהם מנסים לעשות.
- אגב - גם היום באפליקציית Facebook “הכחולה” (הלא-Lite), זו שרוב האנשים משתמשים בה, יש המון פוקוס על כל סוגי הביצועים, החל מ Storage דרך כמה זמן לוקח לה לעלות “כשהכל קר”, כמה זיכרון היא תופסת ועוד - יש צוות לכל דבר כזה ומערכות כלים שלמות על מנת לראות איך אנחנו גורמים לכל וקטור כזה להיות במקסימום שאנחנו יודעים לייצר, ואיך אנחנו גם לא פוגעים בחווייה בזמן שאנחנו מצליחים לגרום לאפליקציות להצטמק ולהצטמק ולהיות יותר ויותר קלילות על הטלפון.
- בלי סוכר?
- בסך הכל החוויה מאוד דומה, ויש Trade-offs שאותם אנחנו לוקחים בצורה קצת שונה, מתוך הבנה שמי שבוחר את אפליקציית ה - Lite על פני הרגילה בעצם בוחר בזה - בין אם זו מדיניות של Cache בצורה מסויימת ואיך דברים עובדים, או לשחק קצת עם רזולוציות של תמונות וחוויות ודברים כאלה.
- נכון - יש כל מיני Trade-offs, ובמקומות מסויימים גם בחירה בטכנולוגיות שלאו דווקא מביאות Trade-off מסויים כדי להצליח להגיד שבנינו את זה בצורה יותר יעילה (?).
- זה Trade-off בין אלמנטים של המשתמש - זה יכול להיות גם בין האחסון שלו לבין השימוש שלו ברשת, אבל בסוף פונקציית המקסימום היא על החווייה שלו.
- אני לא צריך להקריב את החווייה בשביל הביצועים, אבל החווייה הכוללת צריכה להיות עם ROI חיובי.
- הדבר הראשון הוא שזה באמת לא טריוויאלי - זה שמתחילים בלמדוד, ולהבין איפה בכלל אנחנו נמצאים.
- גודל האפליקציה זה משהו מאוד קל למדידה - תקמפל (Compile) ותראה מה הגודל.
- לדברים כמו גדלי ה -Cache השונים או Storage footprint (כמה בסה”כ אנחנו משתמשים ב - Storage של המכשיר) - אנחנו מכניסים קוד ייעודי שעושה איזושהי הערכה (“תפסנו עכשיו 22Mb בשביל ה - Cache הזה וזה ה - Cache-Hit שלנו”).
- יש לנו המון כלים שמפותחים in-house - חלקם יותר Open-Source כמו Hive וכאלה וחלקם בשלב בגרות יותר מוקדם
- ברוב הפעמים, כשאנחנו רוצים להבין מה קורה, אנחנו משתמשים ברצף של מידע, כשאנחנו משתמשים בכלי פנימי שלנו ואומרים - “אוקיי, כאן אנחנו נמצאים כרגע - איפה אנחנו רוצים להיות עוד רבעון / חציון וכו’ - מה יכול להביא אותנו לשם?”.
- עורכים מעיין Brainstorming ויוצאים עם סט של פרויקטים שאם נצליח בהם - נצליח להביא את השינוי שאנחנו מעוניינים בו.
- כן - גם מבחינת ייצוג פרוטוקולים וכאלה, וספציפית - Facebook Lite היא אפליקציה שבה הרבה מה - Heavy Lifting והרבה לוגיקה וכוח העיבוד יושב בשרתים, וזה מבוסס על טכנולוגיה שהזכרנו קודם, של Snaptu - שהיום הפכה ל”מפלצת” שאף אחד לא דמיין שתיהיה.
- יש לנו סט ענק של שרתים שעושים גם את העיבוד עבור המשתמש, החל מאיזה סט של Feeds או אילו Stories אתה עכשיו הולך לראות ועד איך אנחנו מצפים שה - Client ירדנדר (Render) את זה ואיך לשלוח דברים על הפרוטוקול.
- גם כאן יש לנו trade-offs של האם עדיף לעשות את זה ב Client-side או ב - Server-side, לפי מה שיתן בסוף את החווייה או את הביצועים היותר טובים.
- זה נכון, אעפ”י שבדרך כלל זה לאו-דווקא מתבטא ב - Bandwidth
- לרוב הייצוג יכול להיות לא פחות יעיל, אבל סט של עיבוד מסויים שתעשה על השרת “יעלה לך” ב - round-trip ובזמן יותר ארוך, ואז תשאל את עצמך - עבור המכשיר הממוצע או עבור ה - Use-case הספציפי, האם בסך הכל זה שהעברתי את הפעולה ל-Server Side תשפר את מה שהמתשמש חווה?
- מצחיק, אבל באמת בונים את כל חוות השרתים באיזורים הנורדיים - חוות פסיכיות, והכל מבוסס על אנרגיה ירוקה, מכניסים אוויר קר בחורף וכו’, די טירוף.
- ובדיוק שכבר חשבתם שיש אייטם לפרק 1 באפריל הבא - אז זה מ - 1 באפריל 2019 . . .
- יש לנו כמה נתונים די פסיכיים . . .
- קודם כל - הגודל של ה - 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”), וככה אנחנו פונים בדיוק לאוכלוסיה הספציפית שיכולה להרוויח משימוש באפליקציה הזו.
- עדיין לא . . .
- מבחינה ארכיטקטונית, WhatsApp למשל יותר “קלה”, והאפליקציות שמרו על סט מאוד רזה של פיצ’רים ו - Performance מאוד גבוה. Instagram עדיין לא הגיעו לאיזור הזה.
- עבור שאר האפליקציות מסביב אנחנו עושים אפקט דומה - Messenger למשל עושה ככה היום.
- גם Google לא מזניחה את התחום הזה, וגם כל שאר החברות מסביב (הזכרנו את גרסת ה - Lite של YouTube - Go - פחות ברור ישירות מה - Play אם לא מחפשים ישירות).
- בכלל - אנדרואיד בגרסאות האחרונות ניסו “לחתוך” הרבה, וליצור איזשהו סט יותר מינימלי
- חוץ מזה, יש את כל פרויקט Android Go וגם מכשירים קצת יותר קלים - בכל סדרת הפיקסלים (Pixel) יש גם מכשירים יותר פשוטים
- בסוף כולם מבינים שאם עד היום בנינו עבור מי שיכול להרשות לעצמו את החווייה האידיאלית - וכשעשינו את זה כנראה כיוונו אל מה שיותר קרוב אלינו - פספסנו מיליארדים (בלי הגזמה) של אנשים, שהיום אנחנו מנסים להנגיש את השירותים שלנו גם אליהם.
- אין כזה דבר כברירת מחדל, אבל הם כן מנסים שכאשר משדרגים לאחת ממערכות ההפעלה האחרונות שלהם, החווייה שתתקבל היא יותר “רזה” - אם פעם מערכות ההפעלה הפכו כל הזמן ליותר ויותר “שמנות” ובעצם הכריחו להחליף מכשירים - היום הם מנסים להפוך את הטרנד הזה, ולהגיד שמערכות ההפעלה החדשות לאו דווקא כבדות יותר ומכבידות יותר על המכשיר, אלא להנגיש גם לקהל הזה שירותים.
- אבל זה בסוף שאלות גם לחבר’ה מ-Google - מעניין איך הם יענו עליהן . . .
- כנראה שהרבה מיליונים, וכנראה שגם הגזמת מאוד למטה עם כמות הפיצ’רים . . .
- שאלה מעניינת - כי אין תשובה אחת נכונה, ואתה באמת מתפרץ לדלת המאוד פתוחה של “אין עושים את הדבר הזה כך שלא יהיה 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 - וככה באתר כשאתה פשוט גולש מהמחשב” - היום אנחנו מנסים שיהיה הרבה פחות שכפול בחוויות האלה.
- האמת שיש המון שיתוף - ובפרט היום עברנו לאיחוד של כל ה - Codebases ביחד.
- אם פעם היה לנו Codebase נפרד לאנדרואיד למשל (שיטה מאוד GitHub-ית) - אז היום יש code-base אחוד, כבד מאוד (לעשות Pull זה לא תמיד כיף . . .) - אבל כזה שמאפשר בדיוק את האינטגרציות האלה, שבהן כשיש חווייה משותפת לאנדרואיד, IOS או Website - אתה כותב את החווייה פעם אחת.
- זה באידיאל . . . כמובן שבסוף לפעמים השכבות שלמות יותר או שבורות יותר, אבל היום אתה מקבל הרבה יותר מזה “בחינם” לעומת פעם, כשהיית כותב מחדש “ככה ב - IOS זה צריך להיראות”.
- היום בעצם הפכנו את זה - אם פעם היינו פרוייקט קטן ונישתי שעושים כמה חבר’ה בתל אביב וזה לא היה כל כך מוכר, היום זו כבר אפליקציה של מאות מיליונים.
- המבנה בפייסבוק הוא סוג-של-מטריציוני (?aren’t we all) - מצד אחד יש לנו את אנשי ה - Interface (כמו Facebook Lite או Facebook for Android), ומצד שני יש מישהו שעובד על “Videos”, ורוצה להוציא סוג חדש של Reactions לוידאו והוא בונה “חוויית וידאו” - היום האינטרס שלו להגיע אלי ולהגיד “דקל - אתה מ - Lite, אני עושה פיצ’ר חדש לוידאו ואני רוצה להוציא אותו אצלכם”.
- בשיטת המדידה שלנו בפייסבוק מסתכלים על ה-Impact של מה שהוא עושה ועל הקהל שהוא מצליח להגיע אליו - ו”הנה פה יש מאות מליונים שאני יכול להגיע אליהם - מה אני צריך לעשות?”
- אני עונה שיש Wiki - קרא שם מה צריך לממש - “את זה אנחנו יורשים אותו הדבר בדיוק, את זה אתה צריך לעשות ספציפית - והנה אתה יכול לשבת ולממש את הפיצ’ר שלך”.
- ככה קצת הצלחנו להפוך את הטרנד מ”אנחנו צריכים לרוץ אחרי כולם כדי להכניס פיצ’רים” ל”אנחנו פלטפורמה כמו שאר הפלטפורמות”, כך שאם למישהו יש אינטרס לדחוף את הפיצ’ר שלו לכמה שיותר פלטפורמות במקביל, זה כולל גם אותנו.
- אני חושב שהנתונים האחרונים שלנו הם של מעל מיליארד, או מעל 2 מיליארד כשמסתכלים בהסתכלות חודשית על כלל משתמשי פייסבוק - אצלנו מדברים על מאות מיליונים.
- היום כשמסתכלים על פייסבוק Lite, הוא לחלוטין בטופ של ה 4-5 Interfaces החזקים שלנו
- למעשה אני חושב אפילו שהגודל היום של Facebook Lite באנדרואיד דומה לאפליקציית Native של iPhone - כי יש כל כך הרבה אנשים בשווקים המתפתחים האלה, שזה כבר דומה לכמות המשמשים בעולם שיש להם מכשירי iPhone חדשים.
- זה נתון די פסיכי - להבין שאלו סדרי הגודל, בלי לזכור בדיוק מי כרגע קצת יותר קדימה.
- לא.
- יש כמה רמות של אבסטרקציה - מרמת ה - Database, Feed, Processes וכל החוויה שהמשתמשים מקבלים, ועד רמות ה - React Native וה - Rendering ואיך שהמסך נראה.
- בסוף - החיבורים האלה כן נעשים לפי אפליקציה, כי אתה רוצה שהחווייה תיהיה מאוד קוהרנטית, ולא רוצה מצב של קפיצה ממסך אחד למסך אחר, כי אז אם תיקח את זה לאנדרואיד או Browser או iPhone ,חוויית ה - Back או ה - Manuals למשל לא לגמרי דומות, ויש שם צורך בקצת חיבור קצוות פתוחים.
- עדיין - היום המרחק הוא משמעותית קטן יותר
- לא רק שהוא קטן יותר - בניגוד לפעם, כשהיית צריך להיות Super Lite-Engineer מנוסה ולהבין את הפרוטוקול כדי לכתוב איזשהו פיצ’ר, היום הרבה מאוד מה”איך עושים את הדברים” מאוד מונגש מבחינת ה - codebase לדברים שאנשים רגילים לעשות ב -Facebook ורגילים להשתמש בהם.
- אני לא בטוח שיש לנו איזושהי השוואה ספציפית - אבל אני חושב שגם חשוב להגיד שאין פה תשובה אחת נכונה.
- כל אפליקציה ומה שהיא מנסה לעשות ומה שהיא מנסה להציג ולפי החווייה שהיא מנסה לייצר - תבחר בחירה אחרת.
- אם אתה נותן משהו כמו אפליקציה להאזנה לפודקאסטים (דוגמא היפותטית - איזה שוק יש לזה בכלל?), כנראה יש לך איזשהו Core שישב ב - Client, כי אתה תרצה שהוא יהיה שם כדי לתת חווייה טובה.
- מצד שני - אם הוא ממש (ממש) כבד, אולי תבחר במשהו ייעודי קטן ל - Client ומשהו שיקרה ב - Server-side.
- אני לא חושב שאף אחת מהטכנולוגיות האלה היא בחירה פטאלית - את React Native ספציפית אני זוכר ששקלנו והמשקל בסוף של ה - Client, ב - Megabytes, הוא לא משהו שהיינו מוכנים ”לשלם”
- אבל מאז אני חושב שהם עשו כברת דרך ויש להם חווייה הרבה יותר בסיסית היום, כלומר - אם פעם היו המון Dependencies על רשת של עשרות חבילות שמגיעות ברגע שאתה עושה את ה “Hello world” שלך, אז היום זה הרבה יותר מודולרי ואתה יכול לקבל רק את מה שאתה באמת צריך.
- אני לא חושב שיש כאן נוסחא מושלמת ומוכנה של “הנה ה א’-עד-ת’ שאתה צריך לעשות”, אלא יותר שצריך להיות Minded לזה, ולחשוב Lite-י, מה אתה רוצה שיהיה “קל” ועל אילו אלמנטים - ולפי זה לבחור.
- כן - באופן כללי בפייסבוק אנחנו בגישת ה “The right tool for the job” - מ - Objective C וקצת Swift ולאנדרואיד React Native, ובאמצע קצת טכנולוגיות Lite-יות וכל מיני פייתונים (כזה, לא כזה) מוזרים שרצים . . .
- למשל כמו Snaptu, כשיש לך פרוטוקול שרץ על ה - Server וכאלה.
- כן -איזשהו מימוש בצד הקיצוני של הסקאלה של “Thin Client”, שבו יש לך תמונה ואת ה (X,Y) של הקליק - וזהו.
- הארכיטקטורה היום עדיין דומה, אבל הייצוג הרבה יותר מתקדם - יש כל מיני Flexboxes, והייצוג UI יכול להיות יותר ב - Client side בלי שאנחנו מכבידים עליו.
- אז להשקיע ב - 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) - איך אתה “נכנס לקרביים” שלו? זו הרי מערכת ההפעלה.
- יש כל מיני דברים שאתה יכול להתמש בהם, כמו מה קורה כשה - Exception קורס ואז הוא קורא לך בדיוק לפני שהוא הולך לרדת, ושם היינו צריכים להתעסק קצת עם איכסה, אבל אפשר לגרום לזה לקרות…
- - או לקרוס . . .
- אבל כשזה קורס אין לך Stack-trace
- ה - Downside הוא לא נורא, כי גם אם אתה קורס, היית בכל מקרה באמצע קריסה . . . הסיכון העיקרי שלך הוא לא לדעת מה קרה
- ואת זה שרדינגר כבר פתר. או שלא.
25 פרקים
כל הפרקים
×ברוכים הבאים אל Player FM!
Player FM סורק את האינטרנט עבור פודקאסטים באיכות גבוהה בשבילכם כדי שתהנו מהם כרגע. זה יישום הפודקאסט הטוב ביותר והוא עובד על אנדרואיד, iPhone ואינטרנט. הירשמו לסנכרון מנויים במכשירים שונים.