Версии платформы

Когда Вы разрабатываете новый проект платформы в XCode, среда сборки создает имеющую версию структуру пакета для Вас автоматически. Перечисление 1 показывает основную структуру каталогов получающегося пакета.

Перечисление 1  простой пакет платформы

MyFramework.framework/

    MyFramework  -> Versions/Current/MyFramework

    Resources    -> Versions/Current/Resources

    Versions/

        A/

            MyFramework

            Resources/

                English.lproj/

                    InfoPlist.strings

                Info.plist

        Current  -> A

В этом перечислении, Versions каталог является единственным реальным каталогом на верхнем уровне пакета. Оба MyFramework и Resources символьные ссылки на элементы в Versions/A. Причиной символьных ссылок является тот каталог Versions/A содержит фактическое содержание платформы. Это содержит и исполнимую программу и ресурсы, используемые платформой.

Перечисление 1 показывает, что символьные ссылки верхнего уровня не указывают непосредственно на элементы в Versions/A каталог. Вместо этого они указывают на элементы в Versions/Current каталог, который сам является символьной ссылкой на Versions/A. Этот дополнительный уровень абстракции упрощает процесс изменения ссылок верхнего уровня платформ со многими типами ресурсов для указания на определенную основную версию платформы, потому что только одна ссылка, Versions/Current, потребности, которые будут обновлены.

Каждый реальный каталог в Versions содержит определенную основную версию платформы. Более ранние основные версии платформы необходимы клиентам, создаваемым, когда те версии были текущими в то время. Новыми основными версиями платформы, требуются только, когда изменения в динамической совместно используемой библиотеке платформы предотвратили бы программу, соединенную с нею от выполнения. Созданное использование программ более ранней основной версии библиотеки должно продолжать использовать его, но программы в разработке должны соединиться против текущей версии библиотеки.

Перечисление 2 показывает платформу MyFramework после добавляющей главной версии к нему.

Перечисление 2  платформа с многократными версиями

MyFramework.framework/

    MyFramework  -> Versions/Current/MyFramework

    Resources    -> Versions/Current/Resources

    Versions/

        A/

            MyFramework

            Resources/

                English.lproj/

                    InfoPlist.strings

                Info.plist

        B/

            MyFramework

            Resources/

                English.lproj/

                    InfoPlist.strings

                Info.plist

        Current  -> B

Через Versions/Current символьная ссылка, MyFramework.framework/MyFramework точки к динамической совместно используемой библиотеке теперь текущей версии платформы, Versions/B/MyFramework. Из-за использования символьных ссылок, во время процесса ссылки программы, компоновщик находит последнюю версию библиотеки платформы. Это расположение гарантирует, что новые программы соединяются против последней основной версии платформы и что программы, созданные с более ранней основной версией платформы, продолжают работать неизменные. Для больше на главных и незначительных версиях платформы, и на управлении версиями в целом, посмотрите Версии Платформы. Для получения дополнительной информации об использовании динамических библиотек посмотрите, что Динамическая Библиотека Программирует Темы.

Дополнительные каталоги

Платформы обычно включают больше каталогов, чем просто Resources каталог. Например, Headers, Documentation, и Libraries. Таким образом, добавление a Headers каталог к примеру в Перечислении 2 привел бы к платформе как один показанный в Перечислении 3.

Перечисление 3  платформа с дополнительными типами ресурсов

MyFramework.framework/

    Headers      -> Versions/Current/Headers

    MyFramework  -> Versions/Current/MyFramework

    Resources    -> Versions/Current/Resources

    Versions/

        A/

            Headers/

                MyHeader.h

            MyFramework

            Resources/

                English.lproj/

                    Documentation

                    InfoPlist.strings

                Info.plist

        B/

            Headers/

                MyHeader.h

            MyFramework

            Resources/

                English.lproj/

                    Documentation

                    InfoPlist.strings

                Info.plist

        Current  -> B

Для создания дополнительных каталогов в платформе необходимо добавить фазы сборки к надлежащей цели в XCode. Фаза сборки Файлов Копии позволяет Вам создать каталоги и скопировать выбранные файлы в те каталоги. Таблица 1 перечисляет некоторые типичные каталоги, которые Вы могли бы добавить к своей платформе.

Конфигурация платформы

Платформы требуют того же вида конфигурации как любой другой тип пакета. В информационном списке свойств для Вашей платформы необходимо включать ключи, перечисленные в Таблицу 2. Большинство этих ключей включено автоматически, когда Вы устанавливаете свойства платформы в XCode, но необходимо добавить некоторых вручную.

Поскольку платформы никогда не связываются с документами непосредственно, Вы никогда не должны указывать типы документов. При необходимости можно включать информацию об имени дисплея.

Для получения дополнительной информации о конфигурации и информационных списках свойств, см. Инструкции по Конфигурации Во время выполнения.

Цель платформ зонтика

Цель платформы зонтика состоит в том, чтобы обеспечить все необходимые интерфейсы для программирования в определенной среде приложения. Платформы зонтика скрывают сложные перекрестные зависимости среди многих различных частей системного программного обеспечения. Таким образом Вы не должны знать, какой набор платформ и библиотек необходимо импортировать для выполнения определенной задачи. Платформы зонтика также делают более быстрые сборки возможными с помощью предварительно скомпилированных заголовков.

Платформа зонтика просто включает и соединяется с составляющими подплатформами и другими общедоступными платформами. Платформа зонтика охватывает все технологии и APIs, определяющий среду приложения или уровень системного программного обеспечения. Это также обеспечивает уровень абстракции между тем, с чем внешние разработчики соединяют свои программы и что разработка Apple обеспечивает как реализация.

Подплатформа является структурно общедоступной платформой, упаковывающей определенную технологию Apple, такую как события Apple, Кварц, или Откройте Transport. Однако подплатформа общедоступна с ограничениями. Несмотря на то, что APIs подплатформ общедоступен, Apple установил механизмы, чтобы препятствовать тому, чтобы разработчики соединились непосредственно с подплатформами (см. Ограничения на Подплатформу, Соединяющуюся). Подплатформа всегда находится в платформе зонтика, установленной в /System/Library/Frameworks, и в этой платформе зонтика, представлены ее заголовочные файлы.

Некоторые платформы зонтика включают другие платформы зонтика; это особенно имеет место с платформами зонтика для сред приложения Углерода и Какао. Например, и Углерод и Какао (прямо или косвенно) импортируют и соединяются с платформой защиты Core Services (CoreServices.framework). Эта платформа зонтика, в свою очередь, импортирует и соединяется с подплатформами, такими как Базовая Основа.

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

Пакет платформы зонтика

Физически, платформы зонтика имеют подобную структуру к стандартным платформам. Одной значительной разницей является добавление a Frameworks каталог для содержания подплатформ, составляющих платформу зонтика.

Перечисление 4 показывает частичное перечисление платформы Core Services. (Содержание подплатформ не включено, так как на них не ссылаются так или иначе.) Как со стандартными платформами, элементы верхнего уровня являются символьными ссылками на элементы глубже в структуре каталогов платформы. В этом случае соединенные библиотеки и каталоги расположены в папке A из платформы.

  Структура перечисления 4 платформы защиты Core Services

CoreServices.framework/

    CoreServices           -> Versions/Current/CoreServices

    CoreServices_debug     -> Versions/Current/CoreServices_debug

    CoreServices_profile   -> Versions/Current/CoreServices_profile

    Frameworks             -> Versions/Current/Frameworks

    Headers                -> Versions/Current/Headers

    Resources              -> Versions/Current/Resources

    Versions/

        A/

            CoreServices

            CoreServices_debug

            CoreServices_profile

            Frameworks/

                CarbonCore.framework

                CFNetwork.framework

                OSServices.framework

                SearchKit.framework

                WebServicesCore.framework

            Headers/

                Components.k.h

                CoreServices-gcc3.p

                CoreServices-gcc3.pp

                CoreServices.h

                CoreServices.p

                CoreServices.pp

                CoreServices.r

            Resources/

                Info-macos.plist

                version.plist

        Current             -> A

В отличие от стандартных платформ, Headers каталог платформы зонтика содержит более ограниченный набор заголовочных файлов. Это не содержит набор заголовков в его подплатформах. Вместо этого это содержит только основной заголовочный файл для платформы. При обращении к платформе зонтика в исходных файлах необходимо включать только основной заголовочный файл. Посмотрите Включая Платформы для получения дополнительной информации.