bitcode-on-wwdc2015

Bitcode появился в  iOS 9, которую Apple представила на WWDC 2015. Что это такое? Bitcode это один из механизмов функции под названием App Thinning.

Cмысл App Thinning состоит в том, что гаджеты будут загружать в память только самый необходимый код, чтобы игры и приложения занимали намного меньше места, чем они занимают сейчас.

Прежде чем перейти к Bitcode, рассмотрим две другие функции App Thining.

Основная функция – App Slicing. Так как приложения создаются под большое количество устройств, от 3,5-дюймового iPhone 4 до 5,5-дюймового iPhone 6S (скоро уже 7) и 9,7-дюймового iPad, они несут в себе все данные для каждого девайса – большинство из которых вашему устройству попросту не нужны. Технология App Slicing дает возможность разработчикам разделять пакеты данных по типам устройств, и когда пользователь будет скачивать приложение из App Store,  устройство загрузит только те данные, которые ему нужны.

Вторая функция – On-Demand Resources (ODR). ODR позволяет загружать контент по мере необходимости.

И наконец Bitcode.

До появления iPhone Apple использовала GNU Compiler Collection (обычно используется сокращение GCC) для компиляции Objective-C приложений в исполняемый код, который был приемлемым для процессоров.

Компилятор создавал исполняемые “толстые” двоичные файлы (ориг. fat binaries), эквивалентные EXE файлам на Windows и ELF на Linux – но, в отличие от последних, “толстый” двоичный файл мог содержать несколько версий одной и той же программы. Таким образом исполняемый файл мог работать на разных процессорах. Это в первую очередь та технология, которая позволила Apple перейти с PowerPC на PowerPC64, и затам на Intel (а позднее на Intel64). Недостатком такого подхода является то, что существует несколько копий исполняемого кода, которые хранятся в одном файле, и большинство из которых никогда не будут использованы. Это было продвинуто под названием “Универсальный Двоичный Файл” (Universal Binary) – в то время как первоначально этот термин использовался для обозначения поддержки PowerPC и Intel, а позже был переориентирован на обозначение поддержки 32-битной и 64-битной архитектуры. В “толстом” двоичном файле среда автоматически выбирает правильную версию кода, но приложение несет в себе лишний вес в случае, когда оно выполняется на другом процессоре.

С появлением мобильных устройств размер кода стал более важным в основном потому, что само устройство имеет гораздо меньше памяти, чем обычный жесткий диск. В то время как Apple переходила от оригинального ARM  процессора к собственному  A4 и далее, набор команд менялся и использовались разные версии кода. Эти опции определялись и определяются в Xcode в виде минимальной поддерживаемой версии iOS и итоговый двоичный файл содержит несколько вариантов кода.

Рост значимости биткода (bitcode) – и миграция в LLVM – начали происходить насколько лет тому, когда компания Apple решила уходить от GCC и инвестировать значительные средства в инструменты LLVM и инфраструктуру. На начальном этапе это заменило компиляцию особого GPU кода для OpenGL, а позже это способствовало появлению Clang компилятора. По мере роста поддержки Objective-C, это стало стандартом для Xcode и затем послужило началом усовершенствования Objective-C.

Наконец, это разблокировало потенциал для внедрения полного набора инструментов LLVM для компиляции iOS приложений.

LLVM предоставляет набор виртуальных команд, которые могут быть переведены (и оптимизированы) под конкретную архитектуру процессора.

Общий набор команд также имеет несколько форм представления: он может быть сохранен в текстовом формате на основе ассемблера или переведен в двоичный формат (как объектный файл). Именно этот двоичный формат и называется биткодом (bitcode).

Проще говоря с появлением биткода вместо загрузки скомпилированных заранее бинарных файлов, разработчики загружают то, что Apple называет “промежуточной версией”. Далее, перед началом загрузки приложения пользователем, App Store автоматически компилирует приложение с учетом архитектуры устройства. Это позволяет автоматически включать App Slicing, даже если разработчики не позаботились об этом – и устройство будет использовать только 32-битный или 64-битный код, в зависимости от типа процессора.

Также bitcode позволит Apple ре-оптимизировать двоичный код вашего приложения в будущем без необходимости отправлять новую версию приложения в AppStore.

Если Apple в будущем внезапно перейдет на новую архитектуру в любом из своих устройств, благодаря Bitcode приложения сторонних разработчиков будут поддерживать новое устройство сразу после его релиза. Но Bitcode должен достигнуть достаточной массы, для того чтобы смена архитектуры стала простым процессом.

Тем не менее движемся вперед в ногу с Apple!

Read about App Thinning from Apple