Загрузка кода во время выполнения
Вы, возможно, должны пользоваться динамическими совместно используемыми библиотеками, хранящими повторно используемый код в Ваших приложениях для использования в своих интересах функциональности, используемой больше чем одним приложением. Например, когда Вы разрабатываете приложения Какао, как минимум Ваши ссылки на приложение против платформ Набора Основы и Приложения. Через эту практику Ваша программа может автоматически использовать в своих интересах улучшения тех платформ, поскольку пользователи Вашего приложения обновляют системное программное обеспечение в своих компьютерах. Посмотрите продукты — Типы Мужественных Файлов, которые Можно Создать для получения дополнительной информации о динамических совместно используемых библиотеках.
Если Вы разрабатываете совместно использованные библиотеки и распределяете их, поскольку платформа связывается, чтобы использоваться другими разработчиками в их приложениях, необходимо гарантировать изменения, которые Вы вносите в библиотеки (для реализования новых опций, например) не повреждают текущие версии приложений, использующих их. Вы поддерживаете совместимость путем представления того же интерфейса программирования клиентским приложениям между обновлениями совместно используемых библиотек.
Когда изменение в API Вашей платформы требуется, чтобы реализовать опцию, необходимо сделать доступным в том же пакете платформы последняя версия платформы, представляющей API, который текущие клиентские приложения ожидают, в дополнение к версии платформы, представляющей новый, несовместимый API. Если Вы следуете этой инструкции, разработчики клиентских приложений не должны пересматривать их каждый раз изменения API Вашей платформы. И разработчики, принимающие решение обновить их приложения, могут использовать в своих интересах опции, которые Вы добавили к платформе. Чтобы гарантировать, чтобы более ранние версии клиентских приложений Вашей платформы не повреждались, когда платформа обновляется, необходимо упаковать совместно используемые библиотеки и их ресурсы в пакете платформы в пути, позволяющем более ранним версиям клиентских приложений продолжать использовать версии платформы, которую они понимают.
Эта статья описывает, как можно загрузить код во время выполнения. Это показывает преимущества пользования совместно используемыми библиотеками и объясняет, как они упаковываются в платформах для поддержания совместимости клиентского приложения через обновления к платформам. Это также описывает, как среда выполнения OS X использует в своих интересах пакеты, чтобы позволить Вам загружать сменный код во время выполнения.
Пользование совместно используемыми библиотеками и платформами
Программисты часто обращаются к динамическим совместно используемым библиотекам с помощью различных имен, такой, как динамично соединено совместно использованные библиотеки, динамические библиотеки, DLLs, dylibs, или просто совместно использованные библиотеки. В OS X все эти имена относятся к той же вещи: библиотека кода динамично загрузилась в процесс во время выполнения.
Динамические совместно используемые библиотеки позволяют операционной системе в целом использовать память эффективно. Каждый процесс в OS X имеет свое собственное виртуальное адресное пространство. Ядро OS X позволяет областям логической памяти быть отображенными в многократные процессы в различных адресах. Динамический компоновщик использует в своих интересах эту функцию путем отображения той же копии только для чтения совместно используемого кода библиотеки в адресное пространство каждого процесса. Результат состоит в том, что только одна физическая копия совместно используемой библиотеки находится в памяти в любое время, даже при том, что много процессов могут использовать его одновременно. Данные, такие как переменные и константы, содержавшие совместно используемой библиотекой, отображаются в каждый клиентский процесс с помощью возможности оптимизации копии на записи ядра. С копией на записи данные совместно используются среди процессов, пока один из процессов не пытается изменить данные. В той точке ядро создает перезаписываемую копию данных, частных к тому процессу. Другие процессы продолжают использовать совместно используемую копию только для чтения. Таким образом дополнительная память для данных выделяется только при необходимости.
Динамические совместно используемые библиотеки также обеспечивают путь к программам для бесшовного получения преимуществ от обновлений системы. Когда система обновляется, совместно используемые библиотеки обновляются, но программы не должны быть. Так как они динамично связываются с совместно используемыми библиотеками, программы могут продолжать вызывать те же функции, и обновленная реализация совместно используемых библиотек выполняется. Для получения дополнительной информации о разработке динамической библиотеки и использовании, посмотрите, что Динамическая Библиотека Программирует Темы.
Поддержание совместимости клиентского приложения
Это - обзор различных параметров, влияющих на совместимость с клиентскими приложениями. Во время изготовления можно установить эти параметры. Для более детального обсуждения этой темы см. Динамическое Руководство по проектированию Библиотеки в Динамической Библиотеке, Программируя Темы.
Совместно используемые библиотеки имеют два номеров версий, позволяющие Вам создавать версии совместно используемой библиотеки, которые являются двоичные совместимый (т.е. они не требуют, чтобы клиентские программы были перекомпилированы), с функциями, экспортируемыми более ранними версиями библиотеки:
Текущая версия библиотеки указывает число текущей версии реализации библиотеки. Клиентская программа может исследовать этот номер версии для обнаружения точной версии библиотеки, которая может быть полезна для проверки дополнений функции и исправлений ошибок. Совместно используемая библиотека может также исследовать номер версии, против которого первоначально соединилась клиентская программа, который может быть полезен для поддержания назад совместимости.
Версия совместимости библиотеки указывает версию API библиотеки, с которым совместно используемая библиотека утверждает, что была обратно совместима. Если версия совместимости совместно используемой библиотеки более свежа, чем версия, зарегистрированная с клиентской программой, программе не удается соединиться, и ошибка происходит.
Имя установки является путем, используемым динамическим компоновщиком для нахождения совместно используемой библиотеки во время выполнения. Имя установки определено совместно используемой библиотекой и зарегистрировано в клиентскую программу статического компоновщика.
Упаковка совместно используемой библиотеки как платформа
Платформа является совместно используемой библиотекой, упакованной со связанными ресурсами, такими как заголовки, локализованные строки и документация, установленная в стандартной иерархии папок, обычно в стандартном расположении в файловой системе. Папки обычно содержат связанные заголовочные файлы, документацию в любом формате и файлы ресурсов. Платформа может содержать многократные версии себя, и каждая версия может иметь свой собственный набор ресурсов, документации и заголовочных файлов.
С точки зрения инструментов платформа является совместно используемой библиотекой, имя установки которой заканчивается в форме frameworkName.framework/Versions/
versionName/
frameworkName или форма frameworkName.framework/
frameworkName.
Вы создаете платформу путем встраивания нормальной динамической совместно используемой библиотеки в папку с тем же именем и .framework
расширение. Например, для создания платформы по имени Чаос разместите динамическую совместно используемую названную библиотеку Chaos
в вызванной папке Chaos.framework
. Можно создать другие папки в этой папке для хранения связанных ресурсов, таких как заголовочные файлы, документация и изображения (стандартные имена папок для них вызывают, соответственно, Headers
, Documentation
, и Resources
).
Можно определить местоположение частных платформ и совместно использованных библиотек в пакете приложений с помощью начала имени установки относительного пути @executable_path
, такой как @executable_path/../Frameworks/MyFramework.framework
. Это полезно для совместного использования функциональности с плагинами (пакеты).
Apple следует стандартному соглашению управления версиями платформы, отличающемуся от совместно используемой системы нумерации версии библиотеки. Управлением версиями Ваша платформа можно поставить более старые версии платформы рядом с более новыми версиями, чтобы позволить клиентам старшего возраста продолжать функционировать, все еще позволяя Вам усовершенствовать проект платформы способами, не совместимыми с клиентами старшего возраста.
Для управления версиями платформы создайте родительскую папку в вызванной платформе Versions
, создайте подпапку в Versions
с помощью схемы именования по Вашему выбору и сборки платформа совместно использовала библиотеку и другие папки в этой подпапке. Тогда создайте символьные ссылки в корневой папке платформы для указания на совместно используемую библиотеку и папки. Когда необходимо создать версию платформы, которая не совместима с предыдущей версией, встройте его в новый каталог в каталоге версий и обновите символьные ссылки для указания на новую версию. Когда клиент соединяется с имеющей версию платформой, имя установки, зарегистрированное в клиентской исполнимой программе, включает полный путь в совместно используемую исполнимую программу библиотеки, и динамический компоновщик, таким образом, загружает только ту версию.
Например, клиент соединяется с вызванной платформой Peace.framework
, и символьные ссылки в Peace.framework
укажите на последнюю версию, которую называют B
.The устанавливают имя концов платформы с Peace.framework/Versions/B/Peace
. Статический компоновщик записывает это имя установки в клиенте. Когда клиент загружается, динамический компоновщик пытается загрузить совместно используемую библиотеку этим именем установки. Обратите внимание на то, что, в то время как платформы, поставляющие с системой обычно, называют последовательные версии с последовательными буквами английского алфавита (Через Z), можно использовать любое имя, которое Вы хотите.
Разработчик инфраструктуры может создать простую, имеющую версию платформу на четырех шагах:
Создайте каталог версии платформы.
Скомпилируйте исполнимую программу платформы в каталог версии платформы.
Создайте названную символьную ссылку
Current
это указывает на каталог версии платформы.Создайте символьную ссылку на исполнимую программу платформы в родительском каталоге платформы.
Команды оболочки в Перечислении 1 создают названную платформу Bliss
от исходных файлов C Peace.c
и Love.c
. Получающаяся платформа имеет имя установки Bliss.framework/Versions/A/Bliss
.
Перечисление 1 , Создающее платформу
gcc -c -o Peace.o Peace.c |
gcc -c -o Love.o Love.c |
mkdir -p Bliss.framework/Versions/A |
gcc -dynamiclib -o Bliss.framework/Versions/A/Bliss Peace.o Love.o |
cd ./Bliss.framework/Versions && ln -sf A Current |
cd ./Bliss.framework && ln -sf Versions/Current/Bliss Bliss |
Перечисление 2 демонстрирует, как создать частную платформу — т.е. платформа, расположенная в пакете приложений. Укажите имя установки явно во время соединяющейся фазы и снабдите префиксом его @executable_path.
Имя установки получающейся платформы @executable_path/../Frameworks/Bliss.framework/Versions/A/Bliss
.
Перечисление 2 , Создающее частную платформу
mkdir -p Bliss.framework/Versions/A |
gcc -c Peace.c Love.c |
libtool -dynamic |
-install_name @executable_path/../Frameworks/Bliss.framework/Versions/A/Bliss |
-o Bliss.framework/Versions/A/Bliss Peace.o Love.o |
-framework System |
Для получения дальнейшей информации о разработке и использовании платформ, см. Руководство по программированию Платформы.
Упаковка платформ и библиотек под платформой зонтика
Платформа зонтика является платформой, служащей «родителем» группы платформ и совместно использованных библиотек, та реализация связала функциональность. Платформы зонтика помогают управлять чрезвычайно большими проектами разработки со сложными взаимозависимостями, такими как подсистемы самого OS X. Для всех других проектов единственная платформа должна быть достаточной (и лучше для производительности времени загрузки).
Для создания платформы зонтика можно взять нормальную платформу и определять подмножество ее импортированных платформ как подплатформы. Сами подплатформы не должны знать, что они - часть зонтика. С ld
, можно использовать -sub_umbrella
опция определять подплатформу.
Когда Ваша программа соединяется против платформы зонтика, она также неявно соединяется против всех подплатформ. Символы, расположенные в подплатформах платформ зонтика, зарегистрированы в клиентской программе, как будто они были реализованы непосредственно в платформе зонтика. Эта функция позволяет содержанию платформы зонтика изменяться в течение долгого времени при сохранении совместимости с более старыми клиентскими программами.
Чтобы гарантировать, чтобы клиенты соединились с «родительской» платформой зонтика и не одной из подплатформ, подплатформа может быть создана со специальной командой загрузки для предотвращения несанкционированного соединения. Когда клиент пытается соединиться непосредственно с такой подплатформой, статический компоновщик производит ошибку. Однако подплатформа может разрешить определенные клиенты соединяться против него, и все подплатформы платформы зонтика неявно разрешены соединиться друг против друга. (Команды загрузки объяснены в OS X ABI Мужественную Ссылку Формата файла. Определенные команды загрузки, на которые ссылаются здесь, документируются как sub_framework_command
и sub_client_command
; ld
генерирует их, если дали -sub_framework <parent_umbrella_name>
и -sub_client <client_name>
опции.) Обратите внимание на то, что эти соглашения осуществляются во время изготовления статическим компоновщиком, но игнорируются динамическим компоновщиком во время выполнения.
Можно также включать библиотеки в платформы зонтика. Например, платформа Основы включает обоих библиотека времени выполнения Objective C (libobjc
) как подбиблиотека и Базовая платформа Основы как подплатформа. Можно создать Основу с помощью изменения на командах, перечисленных в Перечислении 3.
Перечисление 3 , Создающее простую платформу зонтика
mkdir Foundation.framework |
gcc -dynamiclib -o Foundation.framework/Foundation -sub_umbrella CoreFoundation |
-sub_library libobjc -framework CoreFoundation -lobjc Foundation.o |
Условно, подплатформы платформы зонтика живут в Frameworks
каталог в корневом каталоге платформы зонтика, несмотря на то, что это - очевидно, не техническое требование. Например, платформа Какао является платформой зонтика, включающей платформу AppKit; платформа AppKit является самостоятельно платформой зонтика, включающей Основу и Прикладные службы как подплатформы.
Загрузка сменного кода с пакетами
Пакеты обеспечивают механизм OS X для загрузки расширения (или плагин) код в приложение во время выполнения. Как правило, пакет соединяется против двоичного файла приложения для получения доступа к экспортируемому API приложения. Пакеты могут быть — но не требуются, чтобы быть — упакованы с ресурсами, с помощью той же иерархии папок в качестве того из пакета приложений. В некоторых случаях (в зависимости от кода в пакете), пакеты могут также быть разгружены.
OS X поддерживает несколько схем, позволяющих сторонним разработчикам расширять возможности Вашего приложения путем записи сменного кода, который программа может загрузить во время выполнения. Несмотря на то, что можно использовать любую из этих сменных схем в любом типе приложения, некоторые больше подходят для особых ситуаций, чем другие. Например:
Для загрузки классов Objective C во время выполнения используйте класс платформы Основы
NSBundle
.NSBundle
предоставляет общие услуги для обращения к упакованной программе, является ли программа приложением или плагином.Для загрузки функций C во время выполнения используйте Базовый объект платформы Основы
CFBundle
, который, какNSBundle
класс, предоставляет общие услуги для обращения к упакованной программе, является ли программа приложением или плагином.Базовый объект платформы Основы
CFPlugin
реализует маленькое подмножество стандарта Microsoft Component Object Model (COM). COM позволяет Вам инстанцировать функций C и данных объектно-ориентированным способом во время выполнения.Разработчики углерода могут также использовать Code Fragment Manager (CFM) для загрузки фрагментов кода, обновленных для Углерода от файлов PEF. Для получения дополнительной информации посмотрите менеджера по Фрагменту Кода документация.
В целом, для приложений или библиотек, предназначенных для OS X v10.4 или позже, используйте динамические функции совместимости загрузчика, определенные в
/usr/include/dlfcn.h
, загружаться и файлы пучка каналов. Эти функции являются предпочтительным способом загрузить код во время выполнения. Они особенно полезны при портировании инструментов UNIX, поддерживающих плагины к OS X. См. “Динамические Функции Совместимости Загрузчика” в OS X ABI Динамическая Ссылка Загрузчика для получения дополнительной информации.
CFBundle
и CFPlugin
объекты могут оба использоваться из приложений Углерода, работающих и в Mac OS 9 и в OS X. Оба NSBundle
класс и CFPlugin
объект позволяет Вам коду плагина пакета с ресурсами, связанными с плагином (такими как графические файлы и документация), подобный упаковке для приложения. Загрузить COM-объекты в Mac OS 9, CFPlugin
менеджер по Фрагменту Кода использования, и в OS X, CFPlugin
использует изображение объектного файла dyld
библиотечные функции.
Для получения дополнительной информации о загружающихся ресурсах с помощью NSBundle
класс, см. Руководство по программированию Ресурса. Для получения дополнительной информации о менеджере по Фрагменту Кода посмотрите Архитектуру Времени выполнения Mac OS. Для получения дополнительной информации о CFPlugin
и COM, посмотрите, что Плагин Программирует Темы.