#BitCode: כאשר אפל ממציאה מחדש את ג'אווה בדרכה ומכוונת לעצמאות חומרה

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

Java נמצאת בכל מקום... מלבד ב-iOS!

20 שנה מאוחר יותר, ג'אווה כבשה במידה רבה את עולם העסקים, וחזרה לפופולריות בשנים האחרונות, עם ההחלטה של ​​גוגל להשתמש בה עבור אנדרואיד. כעת ברור שהוא בראשבדירוג טיובה, אשר מעריכה את השפות הפופולריות ביותר בכל שנה. למרות הצלחה זו,אפל בחרה להמשיך עם ObjectiveC, שפה גם מכוונת עצמים, אך הבסיס שלה שונה מאוד מג'אווה: יש לנהל את הזיכרון באופן ידני וזו שפה מהודרת, שמייצרת קובצי הפעלה ספציפיים לפלטפורמה אחת (או יותר). לכל אחד יש את היתרונות והחסרונות שלו, והבחירה באפל התבררה בסופו של דבר ממש משכנעת: עובדת ההידור מציעה ביצועים טובים יותר באופן משמעותי עבור מעבד שווה, האפליקציות צורכות פחות זיכרון, היא לא צריכהאספן אשפהכדי לנהל את הזיכרון שלך ואסור לנו לשכוח שהוא תואם לאחור עם שפת C, עדיין מאוד פופולרי (מקום שני בדירוג Tiobe). אבל מצד שני, לג'אווה יש כמה יתרונות, ולא פחות:ג'אווה נגישה הרבה יותר מ-ObjectiveC (לרוב לומדים אותה בבית הספר), המתכנת לא צריך לנהל זיכרון ומעל לכל, הוא לא תלוי בפלטפורמת חומרה ספציפית אחת.

זריז, כובש ג'אווה

כבר כמה שנים שאפל החליטה לבוא ולטייל על אדמת ג'אווה, אבל בגישה משלה.הגעתו שלקֶשֶׁתאפשרו למפתחים המגיעים מהאינטרנט או מעולם ה-Java לא לדאוג יותר לניהול זיכרוןמבלי לעשות שום הנחות על ביצועים (ללא אספן אשפה). טכנולוגיה זו, שהוכיחה את עצמה ב-iOS, נשמרה באופן הגיוני עם Swift.

הגעתה של השפה החדשה הזו לא התרחשה במקרה וגם ג'אווה הייתה על הכוונת שלה:המבנה פשוט יותר, ואפילו קרוב יותר לשפות הסקריפט הפופולריות ביותר(JavaScript, PHP...), ערובה גדולה לאימוץ בקרב צעירים. יותר טוב,Swift 2 הפך לקוד פתוח... בדיוק כמו Java כבר למעלה מ-10 שנים!! כְּמוֹג'ף הסביר לך את זהלפני מספר ימים העניין בהחלטה זו הוא עצום, הן ברמה האקדמית והן כדי לכבוש, למשל, את שוק השרתים.

השנה,אפל סוף סוף הניחה את האבן האחרונה הדרושה כדי להשיג את מבנה ג'אווה: עצמאות פלטפורמה בזכותBitCode. ההכרזה נעלמה מעט במהלך ההרצאה והמפתחים שנכחו ב-WWDC הופתעו למדי שלא ראו מפגשים ייעודיים (מלבד כמה מילים באפליקציית דילול ב-Xcode). מוזר יותר, התיעוד מוגבל לרק כמה שורות:

הBitCodeשל אפל למעשה מתקרבByteCodeג'אווה, עם ההבדל שהיא לא תפעל ישירות על האייפון.באנדרואיד, גוגל משתמשת בטכנולוגיה הנקראתבדיוק בזמןמה שמאפשר להרכיב את האפליקציה ישירות בטלפון, כאשר אפל בוחרת להציע רק קבצים בינאריים מותאמים למשתמשים שלה (אנחנו תוהים אם קיימת חוות Mac היכן לבצע את הפעולה! ). לכן קופרטינו מבקשת מהמפתחים שלהקומפילציה מראשהתוכניות שלהם, היא אחראית על ניהול השלב האחרון, הכולל קומפילציה של הקוד עבור פלטפורמה נתונה וניהול האופטימיזציות האחרונות, המבוצעות בדרך כלל על ידי המהדר, בצד המפתחים. הגישה היא אינטליגנטית, שכןאפל עשויה לשנות את המעבדים שלה מבלי לדרוש עבודה נוספת מהמפרסמים שלה.יתר על כן, פתרון מסוג זה מאפשר לך להתאים כל אפליקציהעם בצל קטןעבור מעבד וסביבה נתונים: נכון לעכשיו, אפליקציה מורכבת באותו אופן עבור כל המכשירים, כשהבחירה היחידה היא גרסת 32 ו-64 סיביות. מעתה ואילך, Cupertino יכול להציע עשרות שילובים אפשריים של אותה תוכנית, כל אחד מותאם במיוחד למכשיר הנוגע בדבר.

BitCode, הדלת פתוחה למחשבי ARM Mac? לא כל כך מהר!

כתבה אנונימית שפורסמה ב-Medium יצרה באז מאז אתמול, האיש מאמין בכךאפל למעשה מכינה מעבר מעבד או יותר נכון, מציעה לעצמה את הבחירה של שבבים: אם BitCode יגיע יום אחד למק (זה עדיין לא המקרה כרגע), זה יכול לאפשר למפתחים לספק לאפל קובצי הפעלה שיהיו תואמים באותה מידה למכונות ARM או אינטל. עם זאת, זו רק תיאוריה:נכון לעכשיו, אפל מטילה קוד סיביות אחד לכל ארכיטקטורה, כך שלא ניתן לקבל קוד זהה עבור אפליקציות 32 ו-64 סיביות. נכון לעכשיו, רק שינויים אדריכליים קלים נתמכים, אבל זו כנראה רק ההתחלה.

ב-iOS, BitCode כבר מוטל על ה-Apple Watch, מה שיאפשר לאפל להציע מעבדS2אופטימיזציה מיידית עםעַתִיקיישומים, מבלי לבקש מהמפתחים להדר מחדש את האפליקציות שלהם. עבור iOS, הבינארי הקלאסי נשאר במקום, וה-BitCode נשלח רק (בינתיים) בנוסף. לכן BitCode מציג את עצמו בתורדרך אידיאלית להימנע מלמצוא את עצמך תלוי בפלטפורמת חומרה, מבלי לאבד ביצועים או להיאלץ ליצור טכניקותבדיוק בזמןמשמש כיום כדי להאיץ את הביצוע של שפות לא הידור (Java, JavaScript, PHP וכו').

קבלת פנים מעורבת בקרב מפתחים

ומה חושבים על זה המפתחים?BitCode?המעט שאנחנו יכולים לומר הוא שהתגובות מעורבות. מצד אחד, רובם מברכים על האלגנטיות של הפתרון, שיכול להתגלות כיעיל במיוחד ביום שבו החומרה כבר לא מוגבלת ל-ARM ב-iOS ו-x86 ב-Mac. אבל הטכניקה הזו גם פותחת שאלות רבות:

- איזה שני בדיקות?

זה הפחד העיקרי של מפתחים:אם מחר, אפל תשחרר אייפון 6s עם מעבד A9, קופרטינו יוכל להרכיב מחדש את כל האפליקציותעבור מעבדים זה, עם כל האופטימיזציות הנדרשות. הבעיה היחידה,אף מפתח לא יוכל לבדוק את הקוד לפני השחרור. לכן אפל לוקחת את הסיכון לראות תוכניות מסוימות קורסות או מתנהגות בצורה חריגה. מפתחים רבים ממשיכים לסבול מהשפעות המעבר ל-64 סיביות (שזה לא היה תהליך חלק, רחוק מכך) וכןהרעיון שאפל יכולה לאמת מעבר חדש בעצמו מדאיג. עם זאת, המהנדסים הרגיעו במהלך מעבדות ה-WWDC: לעת עתה, אותו BitCode ישמש רק עבור שינויים ארכיטקטוניים קטנים מאוד. אבל הסיכון לעולם לא יהיה אפס!

- אתה מנהל גרסאות?

גם כאן אנחנו יכולים לשאול את עצמנו:האם למפתח עדיין יש שליטה על האפליקציות שלו?אם אפל אחראית על קומפילציה של התוכניות, האם גרסה מותאמת ל-A9 תוגדל אוטומטית ב-App Store או במספרי ה-build? לפי שעה לא נמסר מידע.

- האם אתה ניפוי באגים?

אם מדמיין שאפל מייצרת גרסאות חדשות של אפליקציות באופן אוטומטי (מה שיקרה בכל מקרה), איך נוכל לשחזר רישומי קריסה ותוכניות ניפוי באגים? לשאלה הזו,iTunes Connect יספק בדרך כלל קבצי DSYMsהכרחי כדי להתחקות אחר מקור קריסות המשתמשים שלו. זה אושר לנו על ידי מקורות שונים.

- מה לגבי אופטימיזציות של CPU?

ה-BitCode נוצר במהלך שלב פנימי של מהדר Clang/LLVM, וגם אם זו לא שפת מכונה, אנחנו עדיין משיגים קוד ברמה נמוכה למדי. ברור שהאופטימיזציות יבוצעו אוטומטית על ידי המהדר (וגם על ידי אפל, בסופו של דבר) אבל אז זה יהיהלא מסוגל לכלול קוד assembly, למשל. קשה לדעת אם כיום מפתחי iOS רבים מייעלים את הקוד שלהם בצורה כזו, אבל ב-Mac, סביר להניח שהפרקטיקות הללו עדיין נפוצות יחסית בתחומים מסוימים (הדמיה, משחקים וכו').

- מה לגבי ספריות של צד שלישי?

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

אם עבור OpenSource libs קל להשיג בנייה חדשה,זה תמיד מסובך יותר עבור ספריות קנייניות. רבים מקווים שאפל לא תכפה את BitCode מהר מדי, כפי שהיה במקרה של 64 סיביות!

BitCode בלב העתיד של OS X ו- iOS? לא בלי Mac App Store 2.0!

אם הגעתו של BitCode ל-iOS מייצרת בסופו של דבר יותר שאלות מאשר חששות אמיתיים,ההרחבה שלו ל-Mac ול-OS X נראית ברורה,במיוחד עם הרעיון של ARM Mac על הכוונת שלנו.

ההבדל הבולט היחיד כרגע הואעדיין ניתן להוריד תוכניות מחוץ ל-Mac App Store, שגם מתקשה לשכנע מפתחים. מאחורי הקלעים אפילו מדברים על פיאסקו של ממש, כשהפתרון של אפל נחשב מגביל מדי מבחינתסִמוּלוה-30% המפורסמים שנוכו לא מפצים על הנראות שהחנות עלולה להביא.

על הנייר, וללא מודל הפצה מרוכז, אנחנו עדיין רחוקים מלהיות מסוגלים לקוות להגעתו של BitCode למערכת ההפעלה. וגם אם אפל סוגרת יותר ויותר את המודל שלה (במיוחד על ידי אילוץ מפתחים לחתום על התוכנית שלהם), אנחנו לא רואים את זה בבירורכיצד תוכל החברה לאלץ מפרסמים לא להפיץ יותר את האפליקציות שלהם כראות עיניהם, מבלי לקחת סיכונים גדולים מאוד עבור עתיד ה-Mac.