Разработка
Как Xcode 14 непреднамеренно увеличивает размер приложения
Устаревание битового кода, которое произошло в Xcode 14, безусловно, является крайним примером регрессии размера приложения.
Переход на Xcode 14
Xcode 14, выпущенный 12 сентября, содержит множество новых функций и улучшений. «Первое, что вы заметите», это то, что Xcode стал быстрее и на 30% меньше. Повышенный параллелизм ускоряет создание проектов на 25%, а длительные тесты — на 30%.
Вскоре после выпуска Xcode 14 размер ряда приложений для iOS значительно увеличился. Сначала мы написали в Твиттере о том, что наблюдаем большой рост размера в приложении Zillow для iOS. Но Zillow не стал отдельным примером.
С середины сентября по начало октября:
- 8 октября размер приложения Nike для iOS был 182.2 МБ. Через неделю уже 322.1 МБ (+68%).
- Приложение American Airlines выросло с 182.2 до 389.1 МБ, при этом Xcode 14 вызвал увеличение на 76.2 МБ (+42%).
- Chime увеличился со 162.8 МБ до 212.8 МБ (+31%).
В каждом случае скачок размера связан с тем, что эти приложения впервые выпускались с Xcode 14. Среди других функций Xcode 14 по умолчанию отключил биткод:
Xcode больше не создает bitcode по умолчанию… Возможность сборки с биткодом будет удалена в будущем выпуске Xcode. IPA, содержащие биткод, должны удалять его перед отправкой в App Store — примечания к выпуску Xcode 14
Что такое биткод?
Биткод (bitcode) — это альтернативный способ упаковки приложения, при котором часть процесса сборки остается на стороне Apple после его отправки в App Store. Одна из вещей, которые делает Apple, — это удаление двоичных символов (binary symbols).
Удаление двоичных символов — это удаление из двоичного файла определенных типов метаданных, которые не нужны для запуска приложения в рабочей среде. Это метаданные, которые могут быть полезны перед выпуском приложения, например, для создания файлов dSYM, но они только пожирают место на телефоне пользователя в производственной сборке.
Простое объяснение заключается в том, что битовый код оптимизирует производственные сборки, частично за счет удаления двоичных символов. Без включения битового кода настройки сборки Xcode необходимо изменить, чтобы удалять двоичные символы.
Эта статья не о том, является ли отказ от биткода хорошим или плохим, а о менее известном эффекте выпуска приложений с Xcode 14. Ниже мы:
- Сравним сборки приложений до и после Xcode 14.
- Выясним, какие приложения имели регрессию размера из-за Xcode 14.
- И, наконец, покажем, как любое приложение может само удалять двоичные символы.
Сравнение Nike до и после Xcode 14
С Xcode 14 любое приложение, которое полагалось на bitcode , больше не обязательно удаляет двоичные символы из своего производственного приложения. Это означает, что приложение может стать намного больше даже без добавления какой-либо функциональности.
Вот анализ Emerge размера для версии 22.35.0 (измерено 8 октября) приложения Nike для iOS. В этой версии фреймворки занимают 163.7 МБ из всего установочного размера 191.7 МБ.
В версии 22.36.1 (15 октября) фреймворки увеличились до 293.8 МБ (+127.3 МБ) из 322.1 МБ. Обратите внимание на добавление темно-синих «String Table(s)», которые можно найти в каждом фреймворке.
Когда мы сравниваем две сборки, мы видим, что практически все увеличение на 130 МБ связано с увеличением таблиц DYLD.String. Эти таблицы строк — это ненужные метаданные, которые теперь используются в проде.
Nike увеличил объем двоичных символов с 213.9 КБ (0.11% от общего размера приложения) до 127.5 МБ двоичных символов — это почти 40% всего приложения.
В целом приложение Nike для iOS увеличилось на 130 МБ без каких-либо серьезных изменений.
Сколько приложений затронуто
Emerge Tools регулярно загружает приложения из App Store для анализа, что позволяет нам обнаруживать эти регрессии и более внимательно изучать их. Приведенные ниже данные представляют все приложения, в которых:
- Есть более 2 МБ двоичных символов.
- Более 5% приложения составляют двоичные символы.
- Процент приложения, состоящего из двоичных символов, вырос как минимум на 5% между сборками.
Каждое из вышеперечисленных приложений, вероятно, регрессировало из-за выпуска с Xcode 14. Тем не менее, есть много других приложений, которые имеют значительную экономию за счет удаления двоичных символов, что определенно не связано с Xcode 14.
Toyota (v2.0.9), приложение, о котором говорилось в в начале статьи, имеет установочный размер 550.2 МБ и может сэкономить 109.8 МБ (20% от общего размера приложения) за счет удаления двоичных символов. Это был первый раз, когда Emerge Tools проанализировали приложение Toyota, и мы не можем сказать, был ли в нем рост двоичных символов в предыдущих сборках.
Есть также такие приложения, как TurboTax, которые мы анализируем еженедельно с апреля 2022 года. TurboTax может потенциально сэкономить более 100 МБ в каждой измеренной нами сборке. Три основных приложения Intuit для iOS — TurboTax, Mint и Quickbooks — имеют общий установочный размер 1.37 ГБ. Они могут сэкономить 578 МБ (42% размера), просто удалив двоичные символы.
Ниже приведен список приложений, в которых более 15 МБ двоичных символов, но мы не можем точно сказать, связано ли это с переходом на Xcode 14.
Как удалить двоичные символы без биткода
К счастью, удалить двоичные символы из конечной сборки несложно. Вот два способа удаления двоичных символов.
Используя настройки сборки Xcode
Вы можете автоматически удалять символы из билда во время Архивирования сборки, установив:
- «Deployment Postprocessing» = «Yes»
- «Strip Linked Product» в «Yes»
- «Additional Strip Flags» в -rSTx
- Все остальные настройки чистки на значения по умолчанию
Однако с этим методом вы должны быть осторожны, чтобы настройки были одинаковыми для всех таргетов. Кроме того, могут быть подводные камни при использовании менеджеров пакетов. Для Cocoapods здесь обсуждается проблема, которая связана с одним из возможных решений (убедитесь, что все обрезаемые фреймворки являются динамическими, если вы делаете это).
Используя скрипт
Вы также можете запустить приведенный ниже скрипт в самом конце процесса сборки, прямо перед подписанием. Обратите внимание, что для некоторых менеджеров пакетов, таких как Cocoapods, может не быть никакой точки между копированием фреймворков и подписанием, где можно запустить пользовательский скрипт. В этом случае подпись необходимо будет снова выполнить вручную после удаления, потому что удаление сделает подпись недействительной.
Ниже приведен пример сценария, который вы можете использовать для удаления двоичных файлов. Огромное спасибо Филипу Бусику из Doordash за помощь!
В настройках этапов сборки убедитесь, что флажок «На основе анализа зависимостей» не установлен, чтобы скрипт запускался при каждой сборке. Подробнее об этом методе можно прочитать в нашей документации.
Примечание: удаление двоичных символов необходимо выполнить перед подписью приложения, иначе подпись кода будет признана недействительной.
Почему это важно
Как Apple сказала в своем видео про Xcode 14, размер приложения — это первое, что заметит ваш пользователь. И пользователи обращают на это внимание, как выразился недавний обозреватель iOS-приложения American Airlines:
В документации Google Play Console есть аналогичная рекомендация:
Размер приложения — один из важнейших факторов, влияющих на показатели установки и удаления вашего приложения. Важно регулярно отслеживать и понимать, как вы можете уменьшить размер загрузки и установки вашего приложения.
Хорошо… размер имеет значение… Если предположить, что это правда, как можно было бы избежать этой регрессии?
Нереально ожидать, что разработчики будут в курсе всех нюансов изменений версии платформы. Именно здесь вступает в действие непрерывный мониторинг. Если измерения выполняются вручную, регрессии не будут постоянно обнаруживаться до того, как они попадут в рабочую среду.
Выше приведено сообщение Slack от одного из наших клиентов, который спрашивает об увеличении размера своего приложения после перехода на Xcode 14. Они поймали регрессию перед выпуском с помощью инструментов непрерывной интеграции Emerge.
Устаревание битового кода, которое произошло в Xcode 14, безусловно, является крайним примером регрессии размера приложения. Однако мы обнаруживаем, что небольшие регрессии происходят все время, будь то обновление SDK или новая функция. Со временем эти изменения накапливаются и приводят к заметному ухудшению пользовательского опыта, что является еще одной причиной для того, чтобы заранее задуматься о размере вашего приложения.
