Dyld shared cache что это
OS X Mavericks: Профилактика «пляжного мяча»
В последнее время приходит много писем с вопросами о том, почему после обновления на OS X Mavericks, казалось бы, новая сверхскоростная система начинает некоторым образом подтормаживать, всё чаще появляется SPOD (Spinning Pinwheel of Death) — попросту, «пляжный мячик» или «лоллипоп». Ниже решение проблемы с подвисаниями системы, помогает в 99 случаях из ста!
Изменённое состояние курсора, выражающееся в появлении крутящегося разноцветного кружка — SPOD, означает, что какое-то приложение на вашем Mac занято или подвисло. Как правило, переключение к другому приложению или клик на пустом месте прекращают подобные безобразия. В крайнем случае, можно легко избавиться от полностью зависшего приложения, нажав комбинацию клавиш Command+Option+Escape и выбрав его из списка. Это работает всегда и везде. Но такой способ решения — это уже лечение. Давайте всё же займёмся профилактикой.
Весь процесс, описанный ниже, состоит из нескольких несложных действий, выполнить их будет легко даже новичку.
Исправляем диск (Repair Disk) и восстанавливаем права доступа к файлам (Repair Permissions):
Перезагружаемся в обычный режим
Перестраиваем кэш dyld. Если кому-то интересно — это динамический редактор ссылок, содержит ссылки на библиотеки, необходимые для работы приложения. Повреждение кэша библиотеки процедур приводят к появлению SPOD, очистка или перестройка кэша помогает с этим справиться.
Команда выполнена, перезагружаемся!
В процессе выполнения команды в окне «Терминала» могут появиться строки с сообщениями об ошибках в перестраиваемом кэше dyld. В зависимости от конфигурации вашего Mac процесс может занять до нескольких минут.
С помощью подобных нехитрых действий можно избавиться от подвисаний и подтормаживаний в работе системы. Кстати, в профилактических целях советую проводить проверку диска и восстановление прав доступа, описанные в первом пункте инструкции, хотя бы раз в месяц. Здоровья вашему Mac!
Новости, статьи и анонсы публикаций
Свободное общение и обсуждение материалов
Лонгриды для вас
Спам в 📆 календаре iCloud — это давняя проблема, которую Apple не может побороть. Поэтому время от времени спамеры возобновляют свою активность, нарушая своими рассылками покой пользователей. Разбираемся, что с этим делать
В iOS 15, iPadOS 15 и других новых операционках Apple представила новый режим Фокус, который позволит настроить получение уведомлений от определенных приложений и контактов. Разобрались, как именно он работает.
Apple совместно с учёными Корнельского университета научила AirPods определять частоту дыхания, используя встроенные микрофоны. Эта функция может иметь большую диагностическую ценность, если её разрешат внедрить в коммерческую версию наушников
Профилактика OS X: возвращаем системе производительность
Продолжаем приводить Mac в порядок. На прошлой неделе мы устроили профилактику накопителю, а сегодня возьмемся непосредственно за операционную систему.
Итак, OS X. Причин снижения производительности, появления различных неполадок в работе и других проблем может быть огромное множество, поэтому рассмотреть их все в рамках одного материала просто не представляется возможным. Поступим проще.
Мы предлагаем вам 6 советов, которые гарантированно не навредят системе и с высокой степенью вероятности повысят производительность компьютера, а также предотвратят возникновение проблем в будущем. Ничего сложного — просто несколько полезных трюков. Поехали!
Совет 1. Проверка списка автозагрузки
Начнем с банального — автозагрузки. Открываем «Системные настройки» и выбираем пункт «Пользователи и группы». Переходим на вторую вкладку под названием «Объекты входа» и внимательно изучаем список приложений, которые запускаются вместе с системой. Если заметили что-то откровенно лишнее, то смело выделяем эту программу и нажимаем на минус внизу. Снятие или установка галочки эффекта не дадут — это всего лишь средство скрыть окно программы после ее автозагрузки при запуске системы.
Очевидно, что Final Cut Pro X при запуске системы – не лучшая идея
Совет 2. Обнуление PRAM
Далее еще один известный, но от этого не менее полезный совет — сбросить PRAM. Эта процедура описана даже на сайте Apple:
PRAM — это небольшой раздел памяти компьютера, где хранится ряд значений параметров, к которым система OS X может быстро получить доступ.
Соответственно, периодический сброс данного раздела позволит «взбодрить систему». Для этого делаем следующее:
После того как система все-таки загрузится, вы можете заметить, что некоторые параметры сбились. Их придется настроить заново в «Системных настройках».
Совет 3. Использование Терминала
В «Терминале» OS X можно вводить команды, которые позволят внепланово запустить процедуры обслуживания системы. Для этого запускаем «Терминал» и копируем туда следующее:
sudo periodic daily
sudo periodic weekly
sudo periodic monthly
После этого потребуется ввести пароль администратора. Обратите внимание, что набираемые символы в «Терминале» не видны. Нажимаем Enter и ждем выполнения всех процедур.
Также из «Терминала» можно перестроить кэш dyld. Нередко его повреждение приводит к «задумчивости» компьютера, когда появляется индикатор загрузки и то или иное приложение становится временно недоступным для работы.
Потребуется ввести пароль, а затем желательно перезагрузить компьютер.
Совет 4. Очистка кэша приложений
Для выполнения этого совета придется завершить все запущенные приложения. Затем открываем Finder и нажимаем комбинацию клавиш Shift-Cmd-G. В появившемся поле вводим адрес
/Library/Caches и попадаем в указанную папку. Отсюда абсолютно все отправляем в корзину.
Все это смело отправляем в корзину
Вновь открываем Finder и нажимаем Shift-Cmd-G. Теперь в поле вводим уже /Library/Caches (отличие в тильде) и опять удаляем все файлы и папки. Очищаем корзину, перезагружаем компьютер.
Этот совет будет полезен, если какое-то приложение стало работать слишком медленно или даже перестало запускаться. После очистки кэша и последующего запуска программы он будет создан заново, но уже лишен проблем.
Совет 5. Заглядывайте в Мониторинг системы
У пользователей Windows есть «Диспетчер задач», а у владельцев компьютеров Mac «Мониторинг системы». Его можно найти среди других системных утилит в Launchpad. После запуска нас интересуют первые две вкладки: ЦП и Память.
Если какой-то процесс отъедает неожиданно много ресурсов процессора, то его необходимо закрыть. Простое правило, позволяющее зачастую определить программу, тормозящую работу всей системы.
На вкладке «Память» тоже стоит обратить внимание на программы, использующее чересчур много оперативной памяти. Например, этим иногда страдает Safari — браузер вроде бы завис, а на деле не может справиться с огромным куском ОЗУ, который отхватил себе у других программ. Если не хотите ждать несколько минут, пока система разберется сама, то лучше помочь Safari завершить работу принудительно.
Совет 6. Используйте специальный софт для профилактики OS X
Проще всего ухаживать за системой при помощи специального программного обеспечения. Такого для OS X в избытке, но самая популярная и, пожалуй, мощная — CleanMyMac 3. Кроме перечисленных выше операций, она обладает массой других возможностей, которые могут оказаться полезными именно вам. Разумеется, утилита платная.
Зачастую любую проблему в OS X можно победить даже без переустановки системы. Перечисленные выше советы — верный шаг к восстановлению прежней работоспособности компьютера. Главное, что следовать им достаточно просто и совершенно безопасно.
Mac OS X для всех
Вы знаете, что разноцветная вертушка указателя мыши означает временную задержку, в то время как ваш Mac пытается выяснить что-то.
В этом случае, ваш Mac пытается думать, но ничего не происходит, поэтому вертушки продолжает вращаться, и вращаться, и вращаться.
К счастью, SPOD редко является признаком того, что ваш Mac завис. Более вероятно, что одно приложение подвисло или заморожено. Если вы перейдёте к другому приложению или просто нажмёте мышкой на рабочем столе, то скорее всего, вернёте Mac назад под ваш контроль.
Вы можете принудительно завершить зависшее приложение, например, из меню Apple в левом верхнем углу или нажав ⌥⌘⎋. Если и в следующий раз, запустив приложение, которое вызвало SPOD, вы увидите вертушку снова, то надо предпринять некоторые действия.
Когда я сталкиваюсь с этой проблемой, я делаю две вещи, чтобы исправить ситуацию.
Во-первых, выполнить repair permission в дисковой утилите (желательно загрузившись из режима восстановления), чтобы убедиться, что приложения и все связанные файлы, имеют необходимые разрешения для запуска.
Второе, что необходимо сделать, это перестроить dyld (динамический редактор ссылок)кэш.
dyld кэш содержит ссылки для загружаемых программ на общие библиотеки.
Если приложение использует общую библиотеку процедур, а в OS X большинство приложений действительно используют разделяемые библиотеки, то динамический редактор ссылок (dyld) как раз и содержит ссылки на библиотеки, необходимые для работы приложения. Динамический редактор ссылок держит кэш недавно использованных точек входа библиотек. Именно повреждения этого кэша может вызвать SPOD. Очистка кэша, как правило позволяет устранить SPOD.
Очистка кэш dyld
На терминале строке введите следующую команду. Обратите внимание, это одна строка
вам потребуется ввести пароль администратора. Как только пароль будет принят, терминал может отображать некоторые предупреждающие сообщения о несоответствиях в dlyd cache.
Не волнуйтесь, это предупреждение о содержимом, очищается и затем обновляются командой.
Очистка кэша может занять несколько минут. Дождитесь завершения, и перегрузите систему. Теперь должно быть все ОК! Пишите если что…
Русские Блоги
Роль dyld в процессе запуска приложения
Dyld Вход
__dyld_start внутренне вызывает функцию dyldbootstrap :: start (), взглянем на внутреннюю реализацию dyldbootstrap :: start ():
Операция по нахождению адреса основной функции приложения в основном выполняется в функции _main, а в функции _main выполняется больше операций. Посмотрим, как реализована функция _main ().
функция _main ()
В функции _main () содержится больше кода, и многое еще сделано. В основном завершается создание контекста, основная программа инициализируется в объект ImageLoader, загружается динамическая библиотека общей системы, загружается зависимая динамическая библиотека, связывается динамическая библиотека, инициализируется основная программа и возвращается адрес функции main () основной программы. Далее рассмотрим конкретную реализацию каждой функции в отдельности.
instantiateFromLoadedImage
Функция instantiateFromLoadedImage () в основном преобразует файл Mach-O основной программы в объект ImageLoader, который используется в последующем процессе компоновки. ImageLoader является абстрактным классом, и его родственными классами являются ImageLoaderMachO, ImageLoaderMachO является подклассом ImageLoader, ImageLoaderMachO имеет два подкласса, ImageLoaderMachOCompressed и ImageLoaderMachOClassic. Отношения между этими классами следующие: 
В процессе запуска приложения основная программа и связанные с ней динамические библиотеки в конечном итоге преобразуются в объект ImageLoader. Посмотрите на операции, выполненные в instantiateFromLoadedImage.
isCompatibleMachO в основном проверяет, совместимы ли cutype и cpusubtype файла mach-o с текущей системой, а затем вызывает функцию instantiateMainExecutable (), взглянем на реализацию функции instantiateMainExecutable ():
Функция instantiateMainExecutable () вызывает ImageLoaderMachOCompressed :: instantiateMainExecutable () и ImageLoaderMachOClassic :: instantiateMainExecutable () в зависимости от того, был ли сжат файл Mach-O. Все текущие файлы Mach-O сжаты, поэтому мы рассмотрим только реализацию ImageLoaderMachOCompressed :: instantiateMainExecutable.
В результате такой последовательности операций файл Mach-O в конечном итоге преобразуется в сжатый объект ImageLoaderMachOC.
mapSharedCache
В mapSharedCache () много кодов, мы рассмотрим только некоторые коды:
В mapSharedCache () вызываются некоторые методы в ядре, и, наконец, фактически выполняется системный вызов. Основная логика mapSharedCache (): сначала определите, была ли общая динамическая библиотека отображена в памяти, и, если она уже существует, вернитесь напрямую, в противном случае откройте файл кэша и отобразите общую динамическую библиотеку в память.
loadInsertedDylib
После сопоставления общей динамической библиотеки с памятью dyld загрузит динамическую библиотеку в переменную среды приложения DYLD_INSERT_LIBRARIES, вызвав функцию loadInsertedDylib (). Вы можете установить переменные окружения в xcode и распечатать переменную окружения DYLD_INSERT_LIBRARIES во время запуска приложения. Вот посмотрите на переменную окружения DYLD_INSERT_LIBRARIES разработанного нами приложения:
Взгляните на логику реализации в loadInsertedDylib:
Функция loadInsertedDylib () в основном вызывает функцию load (), взглянем на реализацию функции load ():
Функция load () является точкой входа для поиска динамической библиотеки. В функции load () для поиска динамической библиотеки будут вызываться loadPhase0, loadPhase1, loadPhase2, loadPhase3, loadPhase4, loadPhase5, loadPhase6. Наконец, в loadPhase6 файл mach-o анализируется и, наконец, преобразуется в объект ImageLoader. Взгляните на логику реализации в loadPhase6:
Функция ImageLoaderMachO :: instantiateFromFile () используется в loadPhase6 для генерации объекта ImageLoader. Реализация ImageLoaderMachO :: instantiateFromFile () аналогична логике реализации instantiateMainExecutable, упомянутой выше. Сжатие, генерировать различные объекты ImageLoader, не слишком много введение здесь.
После того, как основная программа и связанные с ней динамические библиотеки в своих переменных среды конвертированы в объекты ImageLoader, dyld свяжет эти ImageLoaders, и эта ссылка использует собственную функцию link () ImageLoader. Посмотрите на конкретную реализацию кода:
Функция link () в основном выполняет следующую работу:
1. recursiveLoadLibraries рекурсивно загружает все зависимые библиотеки
2. recursiveRebase рекурсивно исправляет базовый адрес себя и зависимых библиотек
3. recursiveBind рекурсивно связывает символы
В процессе рекурсивной загрузки всех зависимых библиотек метод загрузки должен вызывать функцию loadLibrary (), а фактическим последним вызовом является метод load (). После link () адреса основной программы и связанных зависимых библиотек были пересмотрены для достижения цели доступности процесса.
initializeMainExecutable
После выполнения функции link () она вызовет функцию initializeMainExecutable (), которую можно понимать как функцию инициализации. На самом деле, в процессе запуска приложения, помимо того, что dyld выполняет некоторую работу, также есть важная роль, то есть runtime, и runtime, и dyld тесно связаны между собой. Некоторые уведомления обратного вызова Dyld регистрируются во время выполнения.Эти уведомления регистрируются при инициализации среды выполнения. Одно из уведомлений заключается в том, что при загрузке нового изображения будет выполнена функция load-images () во время выполнения. Затем посмотрите на некоторый исходный код во время выполнения и проанализируйте, что делает функция load-images ().
В load_images () сначала вызовите функцию trapare_load_methods (), затем вызовите функцию call_load_methods (). Посмотрите на реализацию parepar_load_methods ():
_getObjc2NonlazyClassList получает список всех классов, а remapClass должен получить указатель, соответствующий классу, а затем вызвать функцию schedule_class_load (), взглянуть на реализацию schedule_class_load:
Анализируя этот код, мы можем узнать, что перед добавлением подкласса в список загрузки, его родительский класс будет загружен в список первым. Вот почему метод + load родительского класса вызывается перед методом + load дочернего класса.
Затем мы рассмотрим реализацию функции call_load_methods ():
Функция call_class_loads () в основном вызывается в call_load_methods, взглянем на реализацию call_class_loads:
Основная логика заключается в том, чтобы найти соответствующий класс из списка loadable_classes для загрузки, а затем найти реализацию @selector (load) и выполнить ее.
getThreadPC
Основная логика этой функции заключается в том, чтобы пройти loadCommand, найти инструкцию ‘LC_MAIN’, получить дешевый адрес, на который указывает инструкция, после обработки получить адрес основной функции и вернуть этот адрес в __dyld_start. После сохранения адреса основной функции в регистре в __dyld_start, перейдите к соответствующему адресу и начните выполнение основной функции. На этом этапе процесс запуска приложения официально завершен.
резюме
Выше были представлены ключевые функции в каждом процессе в функции _main, и, наконец, давайте посмотрим на реализацию функции _main:
Is it safe to delete these 4 files in the folder called dyld
The system storage seemed to take you a lot of space so I used this software which gives you a visual depiction of the size of files on your Mac (big files are big squares and so on) and turns out these 4 files in system have randomly inflated, it wasn’t like this a few months ago. is it safe to delete these files they’re in some folder called dyld. if not then what do I do to clear the system storage because I really need the space rn for some applications.
2 GB large each, so I understand that you would like to get rid of them, but, as pointed out by @nohillside, they are part of macOS and can’t (and most importantly, shouldn’t) be deleted.
2 Answers 2
Is it safe to delete these 4 files in the folder called dyld ( /System/Library/dyld/ )?
Short answer
No, in Big Sur it’s not safe to delete them (from the screenshot in your question, I see you are on Big Sur).
Long answer
In previous macOS versions (at least in macOS 10.15 Catalina, from first-hand experience), these files were located in /var/db/dyld/ and could be recreated with this command (see for example Trying to force update_dyld_shared_cache but having some errors):
but update_dyld_shared_cache is deprecated in Big Sur (running the command has as only output This tool is deprecated. ).
Furthermore, the files in /System/Library/dyld/ no longer seem to be cache files in the sense that they store commonly used shared libraries (from man update_dyld_shared_cache ):
When loading [an executable file], dyld will first check if is in the share cache, and if it is will use that pre-bound version instead of opening, mapping, and binding the original file. This results in significant performance improvements to launch time.
Instead, in Big Sur, the cache files contain most of the macOS libraries.
The text map file contains information about the shared cache file, and looks like this:
The format of the map file (which is unchanged in Big Sur) is pretty straighforward:
Prior to Big Sur, all shared libraries listed in the map file (that’s 1809 in Catalina) were also located in the file system.
In Big Sur, most are not. In fact, in Big Sur 11.2.3, only 12 out of 1956 of the listed libraries can be found in the file system:
That’s most probably the reason why the cache files were moved from /var/db/dyld to a SIP-protected folder, namely /System : to make it clear that you shouldn’t mess around with them.
Further reading
How to fix an extracted dyld from dyld_shared_cache_x86_64? Stack Exchange/Reverse Engineering question on extracting dylib files from the shared cache (mentions a utility named dyld_shared_cache_util from this open source project: dyld-shared-cache-big-sur)