Удаление DerivedData — хорошо известный трюк, который пригодится каждый раз, когда Xcode ведет себя странно без видимой причины. Я до сих пор хорошо помню, как мой старший в первый раз рассказал мне об этом базовом трюке iOS-разработчика.
Шли годы и накапливался опыт, и я начал понимать, какие ошибки можно исправить таким образом. Однако я так и не понял, что именно находится внутри папки DerivedData. Я решил изменить это, и вот мои выводы.
Примечание. Содержимое DerivedData зависит от версии Xcode. В этом посте я использовал Xcode 10.0 beta 6.
Я полностью удалил существующую папку DeriveData. Затем я создал пример проекта под названием DDExample из шаблона приложения с одним представлением и открыл его в Xcode.
Xcode немедленно создает новую папку DerivedData с двумя подпапками — одну с именем ModuleCache и одну с именем проекта, за которым следует какой-то хэш.
Module Cache
Как следует из названия, именно здесь Xcode хранит предварительно скомпилированные файлы модулей (.pcm). Модуль — это способ организации и совместного использования повторно используемого кода. Модули были введены в Clang (компилятор, используемый Xcode) несколько лет назад, в основном для обеспечения разумного и масштабируемого времени компиляции. Было обычным делом, что для каждого отдельного импорта в исходном файле компилятору приходилось включать и анализировать мегабайты дополнительных заголовков. Благодаря модулям заголовки анализируются и компилируются только один раз.
Там вы можете увидеть две подпапки с именами AIEKQT3S8ZS7 и 391J0EBN0O3XH. Количество этих папок и их имена, скорее всего, на вашем компьютере будут другими. Имя каждой подпапки относится к хэшу, вычисленному из аргументов, переданных компилятору. Чем больше уникальных конфигураций компилятора использует ваш проект, тем больше подпапок с файлами .pcm находится в этой папке. Каждая вложенная папка содержит один и тот же набор файлов .pcm, предварительно скомпилированных с заданными аргументами.
Дополнительная информация об этом процессе: За кулисами процесса сборки Xcode.
Стоит прямо упомянуть, что папка ModuleCache не зависит от проекта и является общей для всех ваших проектов.
Index
Здесь Xcode хранит данные, собранные на этапе индексации. Эти данные используются для поиска, быстрой навигации и рефакторинга внутри проекта. До Xcode 9 данные хранились с использованием SQLite в удобочитаемой форме.
В Xcode 9 Apple изменила способ хранения данных индекса и теперь использует LMDB.
Это не имеет большого значения, потому что вы все еще можете открывать и проверять файлы mdb. Однако вместо человекочитаемых ключей Apple использует какие-то хэши. Однако Apple использует двоичные ключи, и они не читаются человеком.
Я использовал FastoNoSQL, чтобы открыть файл mdb.
Я не могу рассказать вам больше о том, как работает текущий формат, потому что я не смог найти никакой дополнительной информации по этому вопросу. Не стесняйтесь оставлять комментарии ниже или пинговать меня в Твиттере, если у вас есть дополнительная информация.
Logs
Внутри этой папки Xcode хранит всевозможные журналы, разделенные по доменам (Install, Build и т. д.). Помните, что я еще не построил проект, поэтому папка журналов сборки пуста. Посмотрите, что происходит, когда я создаю проект:
Дополнительные сведения о журналах тестирования в Xcode.
TextIndex
Я понятия не имею, для чего эта папка. Мне не удалось найти ни одной информации, в которой упоминалась бы эта папка или файл. Если вы можете помочь пролить свет на это, пожалуйста, прокомментируйте ниже или напишите мне в Твиттере.
Build/Products
Вероятно, самая важная папка внутри DerivedData! Здесь собран ваш окончательный файл .app (папка). Это фактический файл, который копируется и устанавливается в симулятор (или на устройство iOS).
Вы можете видеть, что я создал приложение в конфигурации отладки, ориентированной на симулятор iOS. Когда я создаю его для реального устройства, создается подпапка Debug-iphoneos.
Build/Intermediates.noindex
И, наконец, последняя папка, о которой я хотел бы упомянуть: Intermediates. Это место, где система сборки Xcode записывает вспомогательные файлы, необходимые для сборки приложения. Эти файлы также кэшируются здесь и повторно используются позже. Система сборки достаточно умна, чтобы не перекомпилировать файлы, которые не были изменены.
Посмотрите, что происходит, когда я что-то меняю в AppDelegate.swift и снова собираю. Вы можете видеть, что были обновлены только вспомогательные файлы AppDelegate.
