На WWDC 2015 было представлено столько интересных новинок, что многие разработчики пропустили одно из самых больших нововведений, представленных Apple — Bitcode.
Bitcode позволит оптимизировать приложения в App Store для различных устройств перед загрузкой пользователями. А уже существующие приложения в App Store, так же смогут использовать преимущества новых процессоров без каких-либо действий со стороны разработчиков. Не понадобятся ни обновления, ни повторная публикация.
Если Apple внезапно изменит архитектуру процессора в своих устройствах, у разработчиков отпадёт необходимость обновлять свои приложения для поддержки новой архитектуры. Благодаря тому, что App Store автоматически перекомпилирует приложения. Приложения сразу смогут работать с новыми процессорами, независимо от того, слышали ли вообще разработчики об их появлении или нет.
Что же представляет собой Bitcode?
Это хороший вопрос. Для начала, вы должны иметь представление о Low Level Virtual Machine (LLVM) — универсальная система трансформации, для преобразования существующего кода в машинный код для различных архитектур.
LLVM состоит из двух частей: “фронтенда” и “бэкенда”. Первая — это высокоуровневый язык программирования, на котором вы пишете свое приложение. Например, Objective-C, Swift, Python или Ruby. Вторая часть служит для компиляции этого приложения в машинный код. Преобразование команд в понятный отдельно взятому процессору. При такой архитектуре Bitcode является прослойкой или промежуточным языком, который может повторно скомпилировать приложение в машинный код. Bitcode может преобразовать код в исполняемое приложение, основанное на необходимом наборе инструкций.
Apple не боится смены архитектуры процессоров.
Как показывает история, Apple не стесняется менять архитектуру процессоров. Apple – одна из немногих компаний, которая успешно пережила смену архитектуры в своих продуктах. Самой значительной переменой был переход с архитектуры PowerPC на Intel в 2005 году. Apple отказалась от устаревшей аппаратной платформы, предоставив разработчикам новые возможности.
Из недавних изменений можно назвать переход на 64-битную архитектуру в iPhone два года назад. Тогда разработчикам пришлось повторно компилировать свои приложения, чтобы добавить в них поддержку 64-битного процессора iPhone 5s. С Bitcode разработчикам больше не нужно будет переделывать свои приложения даже после существенных изменений вычислительной архитектуры. Если Apple внезапно перейдет на новую архитектуру, например в iPad Pro, то благодаря Bitcode приложения разработчиков будут поддерживать новое устройство сразу после его релиза.
Но всё не так красочно, мнения разработчиков разнятся. iOS-разработчик Калеб Дэвенпорт считает, что у Bitcode есть как плюсы, так и минусы. Apple больше не нужно ждать разработчиков, чтобы представить обновленные инструменты для поддержки новых устройств.
«Меня пугает то, что мое приложение может быть скомпилировано в конфигурациях, которые я не смогу проверить, что, в свою очередь, приведет к ошибкам, которые я не смогу воспроизвести.»
Калеб Дэвенпорт ждал появления 64-битных устройств в продаже, чтобы протестировать свое приложение на «реальном» железе и только после тестирования добавлял в него соответствующую поддержку. В случае с Bitcode, который автоматически компилирует приложения для новых устройств без участия разработчиков, могут пройти недели, прежде чем разработчик купит новое устройство для тестов, в то время как пользователи будут использовать его приложение и сталкиваться с возможными ошибками.
Другие разработчики считают иначе. например, Сьёрд Дженссен положительно воспринимает нововведения Apple, поскольку они уменьшат объем работы, которую ему нужно выполнить для поддержки новых устройств. Он полагает, что, если бы Apple внезапно перешла на процессоры Intel в новых iPhone, с его стороны не требовалось бы никаких действий, чтобы обеспечить поддержку устройств в день релиза. Остальные разработчики пока воспринимают Bitcode со смешанными чувствами. Технология кажется удивительной, но в ней еще предстоит разобраться.
Проблема в том, что Apple не предоставляет разработчикам подробной информации о технологии. Несмотря на свое огромное значение, Bitcode был очень осторожно упомянут на WWDC и даже исключен из некоторых сессий (Bitcode был в описании 404 сессии WWDC, но потом исчез). В приложениях, где используются библиотеки с закрытым исходным кодом (CocoaPods), использование Bitcode нежелательно, поскольку может вызвать ошибки.
Более подробная информация о Bitcode может появиться ближе к выходу iOS 9 и watchOS 2, но странно, что Apple не уделила должного внимания Bitcode на WWDC.
Независимость от процессоров?
Пользователь Medium под ником Inertial Lemon считает, что эти изменения сигнализируют о чем-то большем. Bitcode обязателен в приложениях для Apple Watch, но лишь рекомендован для iOS. Для Apple Watch это означает, что в следующем поколении часов могут использоваться совершенно другие процессоры, но для разработчиков это не будет иметь никакого значения — App Store автоматически подготовит существующие приложения под новые устройства.
Кроме того, Bitcode может означать, что в скором будущем может измениться и архитектура процессоров Mac. Боб Мэнсфилд, которого тихо убрали из высшего исполнительного руководства, чтобы он возглавил “специальные проекты”, является одним из кандидатов для работы над этим. Apple уже производит процессоры для iPhone, поэтому переход Mac на процессоры собственного производства не выглядит таким уж необычным.
Пока Bitcode не поддерживается в приложениях для OS X. Но это только «пока». Человек, представлявший эту технологию на WWDC, работает в команде разработчиков OS X. Такие изменения означают, что Apple может перевести Mac с архитектуры Intel на ARM без адаптации базы существующих приложений. Так Apple может избавится от зависимости от процессоров Intel. Bitcode может сделать Apple более гибкой для радикальных изменений в аппаратной начинке своих устройств. Также в будущем компании не нужно будет уведомлять разработчиков об изменениях, что позволит ей сохранить информацию о новых устройствах в тайне до самой презентации.
В результате, у разработчиков уменьшится объём работы по адаптации приложений при больших обновлениях. Теоретически, им вообще ничего не нужно будет делать, хотя многие подозревают, что процесс перехода будет не настолько прост.
Bitcode должен достигнуть критической массы, прежде чем смена архитектуры станет простым процессом. Но Apple не спешит и дает разработчикам время привыкнуть и подготовиться к грядущим изменениям. [thenextweb]
(1 голосов, общий рейтинг: 5.00 из 5)
44 комментариев
Форум →С опозданием на 10 лет Apple изобрела .Net.
@karapuzis,
Вот не надо про .net. Cocoa фреймворк + object-c является ближайшим аналогом net. Тут нечто большее, что звучит как фантастика, но скорее всего будет работать только с проектами не имеющими зависимостей от сторонних либов. То есть только простейшие проекты или проекты целиком на кокосе. Либы то он не перекомпилирует.
@winnydows, давно уже object-c начал компилироваться в байткод?
@Владимир Гренадеров,
А вы статью то вообще читали ?
“Первая — это высокоуровневый язык программирования, на котором вы пишете свое приложение. Например, Objective-C, Swift, Python или Ruby”.
Если верить тексту из статьи то примерно так и должно происходить. Вопрос только в том что никто не знает как именно.
@winnydows, поэтому в данный момент – аналогом не является.
Причём тут байт код? Речь о схожести подходов у Cocoa и .NET.
По вашим словам можно подумать что это как раз .NET создаёт байт код под заданную архитектуру, да ещё и без участия разработчика.
@winnydows, нет никакой схожести. .NET – про компиляцию в байткод (хотя в МС предпочитают другое название, но не суть). Cocoa же – вообще не про компиляцию. Objective-C – компилируется, но сразу в машинный код.
Поэтому ничего общего нет. Когда в Xcode добавят возможность компиляции в некий байткод неизвестного пока формата – тогда можно будет о чем-то говорить.
@winnydows, в доках Apple говорилось про то, что будет возможность предоставлять байткод вместе с библиотеками. И если есть байткод для каждой из используемых библиотек, то можно создать байткод для всего приложения.
@karapuzis, “Точка Нет” это совсем другое. Более того, это другое очень плохо: написанные с помощью этого средства приложения крайне медлительны.
Пользователи “Уиндоуз”, у которых стоят видеоускорители “Эй-Эм-Ди”, подтвердят, что приложение для управления ими, написанное на “Точка Нет”, умудряется “тормозить” даже на самых производительных ЭВМ. Кроме того, объем этих приложений огромен, и они также требуют постоянного обновления библиотек или же, наоборот, параллельной установки старых версий библиотек.
@D_S, судить по одному приложению продукт это очень умно, знаете ли. Работают .Net приложения очень быстро и в подавляющем большинстве задач для пользователя ничем не отличаются от нативных приложений – такие же отзывчивые и шустрые. Проблемы начинаются разве что, когда все упирается в сборщик мусора или банальные вычисления. Но тогда делают очень просто – выделяют нужный кусок на C++ и подключают его к .Net приложению. Получается лучшее от обоих миров.
@creker,
.net это тормознутый инструмент для начинающих программистов на вин. Да он прост, да он удобен (по программа простейшая, а сложным приходится делать именно как вы сказали – доп куски на с++, да не просто с++ а жесть под названием с++ .нет со своими правилами и тараканами и без совместимости с человеским си). И самое печальное что у вин прогеров альтернативы то нет.
А вот кокос с обджи-си это совсем другое дело – тоже хомячковое удобство, то только без тормозов и с полной совместимостью с си кодом и использованием классических либов. После 5 лет разработки на .NET это можно сравнить только с попаданием из ада в рай. И это не простые размышления, а многолетний опыт разработки сначала на нет, теперь слава богу пишу в Xcode на кокосе.
Можно наглядно сравнить:
XviD4PSP 6 – на .net + c++ костыли по понятным вам причинам – тормознутый, но гламурный интерфейс. Зависимость от установки .net и тучи других компонентов.
XviD4PSP 7 на Cocoa + Object-C. Вся программа в одном .exe, без каких-либо зависимостей. Кстати работает в том числе и на винде, не смотря на Кокос. Но на маке конечно же быстрее и красивее, так как тут родной кокос.
@winnydows, многолетний опыт разработки позволил бы вам не писать такую чушь. Так что не врите. Маленький набор библиотек кокоа сравнить с .Net платформой это конечно мощно. Удивительно, что весь корпоративный софт это Java и .Net. Там и не знают, что кокос куда лучше всего их безобразия. Кокосу надо сначала дорасти как инструменту разработки взрослого софта, а не клиентов для фейсбука и твитера, где он осел и выбираться не собирается.
Но волноваться не стоит. Весь мир сейчас в ожидании релиза CoreCLR для OS X и прочих платформ, чтобы хотя бы ASP.NET vNext мог посетить бедные платформы.
@creker, “Весь мир сейчас в ожидании релиза CoreCLR для OS X и прочих платформ” – на самом деле это никому особо не интересно, особенно “прочие платформы”. Энтузиасты конечно в восторге, да.
@Владимир Гренадеров, ну почему же. Возможность развернуть ASP.NET приложение под другой ОС вроде бы как раз очень людям приглянулась. Особенно в купе с совместимостью с Docker.
@creker, так барин выше вроде вам про корпоративные решения и не загонял ничего, да и про взрослые продукты тоже, так что зря вы взбаламутились от того, про что вам не говорили…
@wmaybach, а что еще упоминать в контексте .net? Это огромная платформа, которой Cocoa в подметки не годится (собственно, никто и не гонится, Cocoa такие глобальные задачи и не решает). Барин решил противопоставить, еще и назвал это инструментом для начинающих. Как тут не возмутиться. У человека очевидно отсутствует всякий опыт с платформой. 5 лет можно и ерундой заниматься в WinForms, делая примитивные приложения вроде того же XviD4PSP.
@winnydows, “.net это тормознутый инструмент для начинающих программистов на вин. ” – .net это платформа. Про начинающих программистов конечно улыбнуло )
“После 5 лет разработки…” – после 5 лет разработки даже джуниоры начинают догадываться, что платформа имеет очень отдаленное отношение к качеству готового продукта.
“XviD4PSP 6 – на .net + c++ костыли по понятным вам причинам” – нет никаких “понятных причин”. Есть лишь неумение пользоваться предоставленными инструментами.
В том, что на фоне тысяч и тысяч отличных приложений конкретно Васино тормозит – виноват только сам Вася. Увы.
@Владимир Гренадеров, то, что приложения на “Точка Нет” (и на “Яве”) медленные, это, увы, печальное, но действительное обстоятельство.
@D_S, про дотнет аргументировать можете? Почему машинный код, выходящий из-под компилятора IL, медленнее машинного кода, выходящего из-под плюсового компилятора?
“Медленнее” означает не 10-25% (в тяжелых случаях, особенно при -O3), а так что бы вы это на глаз определили.
С интересом жду технических подробностей.
@D_S, к счастью, такое обобщение не имеет ничего общего с реальностью. Поэтому весь мир продолжает писать на том, что удобнее, а не на том, что теоретически в определенных условиях даст пользователю ощущение большей скорости работы. У вас привычка такая, писать то, о чем вы не имеет никакого представления? Встретил вас второй раз в комментариях, а проблема одна и та же.
@creker, как я уже упоминал, приложение “Каталист”, написанное “Эй-Эм-Ди” при глубокой поддержке “Майкрософта”, является очень медленным. Лично на моём ПК это самое медленное приложение; может соперничать только с приложениями, требующими “Яву”.
Кроме того, я не пишу о том, о чем не имею представления. В отличие от Вас, так как Вы не знаете, о чем пишите. И это не мнение, а обстоятельство, доказываемое цифрами: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=plaintext
Какое-то слабое доказательство. Тестируется интеграция рантайма (libc, JVM, .NET и т.п.) с сетевыми стёками. И на первых трёх местах там хрени приложения для JVM, которая как-бы ещё хуже по критерию тормознутости для Desktop-пользователя, чем .NET.
@karapuzis, т.е. .Net делает возможным без пересборки приложения подключать процессоры других архитектур? Что то я не слышал об этом, можно поподробнее рассказать….?
@[email protected], .Net вообще по-умолчанию независим от архитектуры процессора (JIT же), а с учетом ngen может компилировать приложение в машинный код хоста.
@creker, по сути что то типа Java? А приложения в магазине есть на .net под WinRT и Win 10 что бы и там и там нормально работали?
@[email protected], ну да, .Net и Java, грубо говоря, одно и тоже. Виртуальные машины, которые с помощью JIT компилируют и исполняют байткод в реальном времени. ngen еще позволяет скомпилировать сразу в машинный код. Как там с WinRT не вдавался, знаю, что они в облаке перекомпиляция для Windows Phone приложений делали.
@creker, вы ошибаетесь. У дотнета нет виртуальной машины, которая в режиме реального времени транслирует байткод в машинные команды. Трансляция (а точнее – компиляция) производится один раз – либо при вызове функции, либо при установке приложения (и вообще – в любой удобный момент).
Отсюда повышенное время запуска по сравнению с нативными приложениями (если зараненее не собрали под данную платформу, ессно), но сравнимая скорость работы.
Жаба же всегда работает медленнее – ибо VM.
@Владимир Гренадеров, как у Java есть JVM, так у .Net есть CLR, которые называются обычно виртуальными машинами. То, что вы описали, и есть JIT – компиляция байткода в машинный непосредственно при его исполнении, т.е. в реальном времени. Так работают обе платформы. Они не компилируют весь код сразу, а только то, что нужно, отчего и пошло называние процесса Just-In-Time компиляция.
@creker, ” у .Net есть CLR, которые называются обычно виртуальными машинами” – это неверно. Никто не называет CLR виртуальной машиной. Это просто рантайм со сборщиком мусора, поддержкой JIT и прочими плюшками. Никакой виртуальной машины в нем нет.
” компиляция байткода в машинный непосредственно при его исполнении, т.е. в реальном времени” – и это неверно. В дотнете код компилируется не ВО ВРЕМЯ, а ДО исполнения. При первом обращении функции, к примеру, ВЕСЬ код функции переводится в машинный код. И далее, при последующих обращениях, работает именно машинный код. Виртуальная же машина ничего не компилирует, она всегда исполняет байткод.
Именно поэтому жаба тормозит всегда, а .net – только при запуске / использовании ранее незадействованных веток кода. При этом дотнетовскую сборку можно сразу скомпилировать в машинный код, и тормозов больше не будет. В отличии от жабы.
@Владимир Гренадеров, к сожалению, не только при первом исполнении. Пользователи “Каталиста” видят “скорость” отклика приложения на любое своё действие совершенно каждый раз.
@D_S, “к сожалению, не только при первом исполнении”
Технические детали будут? Без них получается что-то вроде “тормозит и все тут, я не разбираюсь, но уверен”.
“Пользователи “Каталиста” видят…”
Берем любое тормозящее приложение, написанное на языке XXX, или с применением средства разработки / платформы YYY. Означает ли это, что язык XXX – плох, или платформа YYY – плоха? При том что множество других приложений работают совершенно нормально.
Конечно же нет. Плоха реализация конкретного приложения. Свежий пример – библиотека chartjs, автор которой сделал быструю отрисовку, но не осилил циклы, из-за чего график с 1000 точек рисует 70мс. Час ковыряния в исходниках уменьшил время отрисовки в 10 (десять) раз. Казалось бы, при чем тут язык?
@Владимир Гренадеров, хорошо бы перед тем, как начал говорить с видом эксперта что-то, это самое что-то немного изучить
@[email protected], почему нет? что именно по вашему мнению этому мешает?
когда-то давно, когда только вышел .net 2.0, я написал небольшое приложение, которое без пересборки работало на pocket pc и десктопе.
@zurba, ну это ведь интерпритатор по сути? А я имею ввиду именно сборку в байт код например…
@[email protected], нет, это не интерпритатор. .NET преобразует исходный код в бинарник, состоящий из инструкций IM – этакого платформонезависимого ассемблера.
Далее идет ключевое отличие от жабы – код преобразуется в машинные инструкции не во время выполнения (посредством VM), а заранее. По-умолчанию “заранее” случается в момент первого вызова функции. Ессно, можно специальной утилитой прогнать код и во время установки, получив машинный код для всего и сразу.
@Владимир Гренадеров,
> интерпритатор
и русский немного подучить
@[email protected], интерпретатор байт кода (а это уже совсем другое), если в чистом виде, но Вам говорят про JIT – программа приобретает совсем другие рамки исполнения и скорости – совсем… Программы, которые без перекомпиляции на .NET могут работать и на x86-x64 и на ARM. Есть такая опция как Any CPU – удивительно, но справляется. Работоспособность зависит от наличия библиотек на устройстве (не все программы для PC идут на PocketPC). На RT спецом подобрана библиотека с WinRT API – работает и на Windows RT и на Windows NT. Microsoft так же продвигает Native .NET – вообще вещь сочетающая в себе гибкость для программиста и мощь исполнения… Apple по сути сделал то же самое, только другие временные рамки подготовки кода здесь. .NET больше 10 лет, а Apple свой Java только сейчас. Увидим к чему всё приведёт. Пока все эти “прослойки” не дают полноценно использовать всю мощь процессора, конкретные оптимизации и т.п. Ждём, смотрим, получаем профит…
@[email protected], нет, это не интерпретатор. Давайте не будем лезть туда, где вы не понимаете. При желании все можно узнать из интернетов
@karapuzis, 15 лет, 15 :) Я помню начинал с какой-то беты, это был 2000-й год
@karapuzis, который в свою очередь – калька с JVM
Ой, ну это-то глупость какая-то:
“В приложениях, где используются библиотеки с закрытым исходным кодом (CocoaPods), использование Bitcode не желательно, поскольку может вызвать ошибки.”
Причем тут cocoapods? Что было в оригинале?
@egormerkushev, скорее всего речь о подключении бинарников библиотек…
Как фантастика это все не звучит, это скорее все элементарные вещи, но очевидно не будет работать с зависимостями, которые уже скомпилированы, что конечно редкость, но некоторые платные библиотеки распространяются уже в виде скомпилированных статических библиотек – LLVM тут ничем не поможет. Там уже машинный код.
А сама технология очевидно так легко как кажется не взлетит. Переход на новую архитектуру просто не может быть безболезненным, а виноват будет разработчик – именно в его адрес посыпятся отзывы о неработающем приложении. Сам с таким уже сталкивался, когда небольшая ошибка в выравнивании приводила к падению приложения на более новых процессорах, а на других все работало.
только вот переход с 32 на 64 бита таким образом невозможен. перекомпиляция неизбежна.
Нашли орфографическую ошибку в новости?
Выделите ее мышью и нажмите Ctrl+Enter.Как скопировать музыку с одного iPod на другой?
Как передать приложение с Android на iPhone и обратно
Почему iPhone отключается от Wi-Fi в ждущем режиме
Почему на iPhone не приходит код для двухфакторной аутентификации
Почему на iPhone не видно открытые вкладки Safari с Mac
Как управлять iMac без мыши
MacBook сильно греется, как его охладить?
Как использовать iMac в качестве дисплея для другого Mac