Управление кэшем с libcache

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

В более широком системном контексте Ваше приложение может теперь также помочь путем создания кэшей, которых операционная система может просто произвести чистку на приоритетной основе, поскольку давление памяти требует. OS X v10.6 включает низкий уровень libcache и уровень платформы NSCache APIs для создания этих purgeable кэшей.

cache_t *mycache

/* Attributes contain a series of callbacks for handling

   comparisons, retain/release, and so on.

 */

cache_attributes_t attrs = {

    .version = CACHE_ATTRIBUTES_VERSION_1,

    .key_hash_cb = cache_key_hash_cb_cstring,

    .key_is_equal_cb = cache_key_is_equal_cb_cstring,

    .key_retain_cb = copy_string,

    .key_release_cb = cache_release_cb_free,

    .value_release_cb = image_release_callback,

};

char *key;

void *data;

uint64_t data_len;

cache_create("com.mycompany.mycache", &attrs, &mycache);

cache_set_and_retain(mycache, key, data, data_len);

void *data;

...

cache_release_value(mycache, data);

char *key;

void *data;

...

if (cache_get_and_retain(image_cache, key, &data) == 0) {

    // Do something with the value now stored in "data".

} else {

    // Recompute the value.

}

Блочные объекты

OS X v10.6 предоставляет поддержку для блочных объектов в C, C++ и Objective C. Блочный объект (в случайном языке, часто именуемом просто как блок), является механизмом, который можно использовать для создания оперативного тела функции как выражения. На других языках и средах, блочный объект иногда вызывают закрытием или лямбдой. Вы используете блочные объекты, когда необходимо создать допускающий повторное использование сегмент кода, но определение функции или метода могло бы быть тяжеловесом (и возможно негибкий) решение — например, если Вы хотите записать обратные вызовы с пользовательскими данными или если Вы хотите выполнить работу на всех элементах в наборе.

Для получения дополнительной информации посмотрите, что Блоки Программируют Темы.

Центральная отгрузка

Grand Central Dispatch (GCD) является новой инфраструктурой уровня BSD. С этим простым и эффективным API разработчики приложений могут достигнуть параллелизма путем предотвращения блокирования APIs, спорил доступ к памяти и синхронизация с блокировкой и явным управлением потоком. Это обеспечивает организацию очереди задач уровня POSIX API и источник отгрузки API для обработки событий.

64-разрядное Ядро

OS X v10.6 включает 64-разрядное ядро. Несмотря на то, что OS X позволяет 32-разрядному ядру запускать 64-разрядные приложения, 64-разрядное ядро предоставляет несколько преимуществ:

• Ядро может лучше поддерживать конфигурации памяти большой емкости.

  Много структур данных ядра, таких как таблица страниц становятся больше как физические увеличения RAM. При использовании 32-разрядного ядра больше чем с 32 ГБ физического RAM эти структуры данных могут использовать неуправляемо значительную часть адресного пространства ядра на 4 ГБ.

  Путем перемещения в 64-разрядное ядро устраняется ограничение адресного пространства ядра на 4 ГБ, и таким образом эти структуры данных могут расти по мере необходимости.

• Максимальный размер буферного кэша увеличен, потенциально улучшив производительность I/O.

  32-разрядное ядро ограничивается в его возможности кэшировать доступы к диску из-за предела адресного пространства ядра на 4 ГБ.

  С 64-разрядным ядром буферный кэш может расти по мере необходимости для максимизации использования иначе неиспользованного RAM.

• Производительность улучшена при работе со специализированными сетевыми аппаратными средствами, эмулирующими память, отображающуюся через провод или с многократными видеокартами, содержащими более чем 2 ГБ видеопамяти.

  С 32-разрядным ядром, если объединенное физическое адресное пространство (видеопамять, например) всех Ваших устройств превышает приблизительно 1,5 ГБ, невозможно отобразить их полностью в 32-разрядное адресное пространство ядра одновременно. Для работы вокруг этого ограничения писатели драйвера должны отобразить меньшие апертуры того физического адресного пространства в адресное пространство ядра.

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

  С 64-разрядным ядром все устройство может быть отображено в адресное пространство ядра сразу. Это улучшает производительность путем удаления дополнительных издержек отображения и неотображения областей памяти. Это также удаляет нагрузку управления этими отображениями в Вашем коде драйвера, таким образом делая драйверы более простыми и менее вероятными генерировать панику путем неотображения неправильной памяти не в то время.

Необходимо сделать драйвер 64 битами способный для OS X v10.6, потому что 64-разрядное ядро не поддерживает 32-разрядные драйверы. К счастью, для большинства драйверов, это обычно не столь трудно, как Вы могли бы думать. По большей части переходя драйвер, чтобы быть 64-разрядный способный точно так же, как переходит любая другая часть кода. Пройдите через и ищите потенциальные проблемные области, такие как:

• Кастинг указателей на целые типы

• Присвоение long значения к int

• Хранение небулевых значений в a bool переменная

• Используя различные размером типы такой как long или типы указателей в структурах данных, совместно использующихся или передающихся между 32-разрядными и 64-разрядными адресными пространствами

Если Вы видите какую-либо из этих потенциальных проблем, или изменяете код так, чтобы они никогда не происходили, изменяли дополнение структур данных (или добавляют объединения) так, чтобы поля после различных размером типов не меняйте положения или используйте магические числа, чтобы поддерживать различные версии структур данных для 32-разрядного и 64-разрядного кода и обеспечить подпрограммы перевода для преобразования между ними.

Документ 64-разрядное Руководство по Переходу описывает вещи искать при проверке кода и обеспечивает полезные методы для обновления кода, чтобы быть 64-разрядное чистый.

В дополнение к тому, чтобы быть знакомым с общими проблемами портирования, необходимо также удостовериться, что драйвер избегает использования IOMemoryCursor класс и getPhysicalAddress метод. Используйте IODMACommand класс вместо этого. (Необходимо сделать это для 32-разрядных драйверов на основанном на Intel Macs также.)

Вот несколько других 64-разрядных изменений, определенных для драйверов:

• Только наборы символов KPI доступны. Наследство com.apple.kernel.* наборы символов не экспортируются для 64-разрядного KEXTs.

• clock_get_uptime работа не доступна (использование mach_absolute_time вместо этого).

• Различные структуры данных, связанные с вызовами времени, изменились для разрешения больших временных стоимостей.

• IOCreateThread и IOExitThread не доступны.

• Функция kernel_thread не доступно. Использовать kernel_thread_start вместо этого.

• kextload оснастите теперь исключительно расширения ядра загрузок. Дополнительная функциональность отладки управления KEXT, которая раньше была в kextload находится теперь в kextutil инструмент.

• Много функций в com.apple.unsupported недоступны. Консультируйтесь со справочной документацией и заголовками для получения дальнейшей информации.

Эти изменения применяются только к x86_64 часть Вашего универсального двоичного файла KEXT, не к существующему i386 или ppc код.

Кроме того, списки свойств расширения ядра теперь поддерживают архитектурно-зависимые свойства, чтобы позволить Вам указывать различные значения свойств для 64-разрядных версий Вашего расширения. Например, Вы могли бы указать ключ свойства OSBundleLibraries_x86_64 указать различное значение для OSBundleLibraries ключ для x86_64 архитектура.

Улучшенное завершение работы

Для улучшения пользовательского опыта в OS X v10.6 улучшения API помогают приложению способствовать более коротким временам завершения работы.

Для поддержки улучшенного завершения работы приложение должно отметить себя как «грязный» или «чистый», в зависимости от того, не сохранило ли это изменения и должно выполнить работу перед выходом или может быть завершено без дальнейшего уведомления. Когда система закрывается, чистые приложения завершаются (через SIGKILL) без дальнейшего взаимодействия.

API NSCache

В дополнение к уровню UNIX libcache API, описанный выше, OS X v10.6 также, обеспечивает Objective C API, NSCache. Этот API концептуально подобен libcache API, но NSCache также политики автоудаления предложений гарантировать, что объем потребляемой памяти кэша не становится слишком большим.

Для использования API сначала создайте новое NSCache объект. Затем, добавьте новые объекты для ключевого использования setObject:forKey: или setObject:forKey:cost:. Когда Вы захотите получить объект снова, вызвать objectForKey:. Если объект будет все еще доступен в кэше, то Вы вернете его. Иначе, необходимо воссоздать объект и его содержание.

Можно удалить элемент из кэша путем вызова removeObjectForKey: или очистите кэш путем вызова removeAllObjects.

При желании можно также указать консультативные пределы для максимального количества элементов в кэше и максимальной общей стоимости элементов в кэше. Можно также добавить собственного делегата, соответствующего NSCacheDelegate протокол. Если Вы делаете, cache:willEvictObject: метод вызовут, прежде чем объект выселен, чтобы позволить Вам очищать по мере необходимости.

Для получения дополнительной информации посмотрите Кэширование и Память Purgeable.

Память Purgeable

NSCache API не является единственным способом минимизировать объем потребляемой памяти Вашего приложения. Какао также обеспечивает NSPurgeableData класс, чтобы помочь Вашему приложению использовать память эффективно и возможно улучшить производительность. Разбивка на страницы является интенсивным временем процессом. С памятью, отмеченной как purgeable, система избегает расхода разбивки на страницы путем простого предъявления претензий в отношении той памяти. Компромисс, конечно, то, что данные отбрасываются, и если для Вашего приложения нужны те данные позже, это должно повторно вычислить его.

NSPurgeableData класс не должен использоваться в сочетании с NSCache; можно использовать его независимо для получения поведения чистки.

Для получения дополнительной информации посмотрите Кэширование и Память Purgeable.

Параллелизм с объектами операции

Операция Cocoa является объектом Объективным на базе С, разработанным, чтобы помочь Вам улучшить уровень параллелизма в Вашем приложении. Вы используете его для инкапсуляции задачи, которую Вы хотите выполняемый асинхронно. Можно представить объекты операции очереди и позволить соответствующей работе выполняться асинхронно на одной или более отдельных потоках.

Платформа Основы в версии 10.6 OS X включает новый класс, NSBlockOperation, для выполнения того или большего количества блоков одновременно. Поскольку это может выполнить больше чем один блок, объект блочной операции управляет использованием семантической группы; только то, когда все связанные блоки закончили выполняться, является работой, которую самой рассматривают законченной.

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

Эффективность файловой системы

OS X v10.6 максимизирует эффективность файловой системы при помощи URLs для консолидации доступа к файлам, свойствам файла и содержанию каталога. Это позволяет единственному механизму использоваться для доступа ко всем файлам, свойствам файла и каталогам и устраняет внутренние переводы между путями, URLs, и FSRefs.

Для максимизации эффективности файла в приложении необходимо использовать file: схема URLs как средства доступа файла, вместо использования FSRefs, FSSpecs, Подпрограммы Файлового менеджера или подпрограммы файла POSIX (stat, lstat, getattrlist, chmod, setattrlist, chflag) к свойствам файла доступа или содержанию каталога. Таким образом Ваши вызовы файловой системы могут быть обработаны с минимумом переводов формата.

Методы, принимающие URLs вместо путей, были добавлены к NSFileManager и NSFileHandler классы:

• copyItemAtURL:toURL:error:

• linkItemAtURL:toURL:error:

• moveItemAtURL:toURL:error:

• removeItemAtURL:error:

• fileHandleForReadingFromURL:error:

• fileHandleForUpdatingURL:error:

• fileHandleForWritingToURL:

Эти методы работают соответствующими методами, принимающими пути файловой системы.

Точно так же методы делегата, принимающие URLs, были также определены для NSFileManager:

• fileManager:shouldCopyItemAtURL:toURL:

• fileManager:shouldLinkItemAtURL:toURL:

• fileManager:shouldMoveItemAtURL:toURL:

• fileManager:shouldProceedAfterError:copyingItemAtURL:toURL:

• fileManager:shouldProceedAfterError:linkingItemAtURL:toURL:

• fileManager:shouldProceedAfterError:movingItemAtURL:toURL:

• fileManager:shouldProceedAfterError:removingItemAtURL:

• fileManager:shouldRemoveItemAtURL:

Свойства файла были добавлены к CFURL и NSURL обеспечить ту же гибкость и службы, раньше потребовавшие использования FSRef. Ваше приложение может идентифицировать свойства с помощью знакомого механизма ключей и значений, где свойства файла идентифицируются ключами (строковые константы), соединяющиеся со значениями (CFTypes для CFURL и объекты для NSURL).

Например, для получения даты модификации использования файла NSURL, Вы могли попросить свойство, связанное с ключом NSURLContentModificationDateKey. Для размера файла, существует NSURLFileSizeKey. Для значка, обычно связанного с этим типом файла, существует NSURLEffectiveIconKey. Для получения родительского каталога файла существует NSURLParentDirectoryURLKey. Для доступного файлового пространства на родительском объеме использовать NSURLVolumeAvailableCapacityKey.

Существует более чем 40 файлов, каталог и свойства объема, которые могут быть считаны этот путь. И потому что OS X v10.6 консолидировал свойство API файла, он может использовать интеллектуальное кэширование для свойств файла, часто позволяя Вам получить многократные свойства без дополнительного файлового ввода-вывода.

Для упрощения этого новые методы были добавлены к CFURL.h:

• CFURLCopyResourcePropertyForKey

• CFURLCopyResourcePropertiesForKeys

• CFURLSetResourcePropertyForKey

• CFURLSetResourcePropertiesForKeys

И похожие методы были добавлены к NSURL.h:

• getResourceValue

• resourceValuesForKeys

• setResourceValue

• setResourceValues

По большей части эти методы заменяют свойства API файла в Файловом менеджере, NSFileManager, и вызовы доступа к файлу POSIX (stat, lstat, getattrlist, chmod, setattrlist, chflag).

Кроме того, можно теперь создать два вида file: схема URLs — находящийся на пути и идентификатор файла базировалась — таким образом, Вы больше не должны полагаться на пути, когда файлы перемещаются, или каталоги были переименованы. Идентификатор файла базировался, URLs содержит объем ID и идентификатор файла цели, и может использоваться для указания файла или каталога (или пакет, который является каталогом другим именем).

CFURLCreateFileIDURL функция преобразовывает находящийся на пути URL в идентификатор файла URL, и CFURLCreateFileURL преобразовывает идентификатор файла URL в находящийся на пути URL. Вообще говоря, можно использовать идентификатор файла URL везде, где можно использовать a file: схема URL.

Следующий APIs будет также работать правильно с идентификатором файла, базируемым URLs:

-[NSURL path]

CFURLCopyFileSystemPath

CFURLGetFileSystemRepresentation

Существует также новая Закладка API, создающий объект данных (NSData) или CFDataRef (CFURL) содержа представление URL (a CFURLRef или NSURL). Это предоставляет услуги, раньше предоставленные псевдонимами, и заменяет менеджера по Псевдониму. Даже если тот файл переместился, данные закладки могут постоянно храниться — в файлах или базе данных Вашего приложения, например — и позже разрешены для создания URL, определяющего местоположение отмеченного файла. API также поддерживает выбирающие свойства ресурса непосредственно от данных закладки.

Эти методы были добавлены к CFURL.h:

CFURLCreateBookmarkData

CFURLCreateByResolvingBookmarkData

CFURLCreateResourcePropertyForKeyFromBookmarkData

CFURLCreateResourcePropertiesForKeysFromBookmarkData

И эти методы были добавлены к NSURL.h:

-bookmarkDataWithOptions:includingResourceValuesForKeys:relativeToURL:error:

-initByResolvingBookmarkData:bookmarkData:options:relativeToURL:bookmarkDataIsStale:error

+URLByResolvingBookmarkData:options:relativeToURL:bookmarkDataIsStale:error:

+resourceValuesForKeys:fromBookmarkData:

См. Ссылку CFURL и Ссылку класса NSURL для дополнительных подробных данных.

Поддержка изображения

APIs обработки изображений в OS X v10.6 был упрощен для улучшения возможности обработать изображения в приложении. Классы изображения являются более непротиворечивыми, и подсистемы в OS X v10.6 обеспечивают более эффективное образование моста между классами. Эти улучшения дают Вам несколько преимуществ:

• Меньше неопределенности в выборе среди типов изображения

• Меньше кода преобразования для Вас, чтобы записать и поддержать

• Улучшенная производительность в декодировании и рендеринге больших изображений с дополнительным уровнем детализации поддерживает в абстракциях изображения низшего уровня

• Сокращенное использование памяти посредством более эффективного кэширования данных изображения

OS X v10.6 также предлагает эффективное частичное декодирование файлов образа, оказывая поддержку для Вашего приложения для доступа к подпрямоугольникам изображений для мозаичного размещения.

Клиенты NSImage, CIImage и CGImageRef обычно не должны вносить изменения кода для получения преимуществ от улучшенного конвейера обработки изображений. При использовании Icon Services для получения значков, необходимо переключиться на NSWorkspace.

Платформа QTKit

Если Ваше приложение должно воспроизвести носители iPod, включая содержание, купленное через iTunes, можно использовать в своих интересах новую, легкую, и более эффективную возможность воспроизведения носителей, предоставленную в QuickTime X и OS X v10.6. Вы получаете доступ к этим мультимедийным службам через платформу QTKit.

Новый QuickTime X мультимедийных служб, предлагаемых в OS X v10.6, позволяют приложениям выполнять асинхронное открытие фильма, таким образом избегая операций от того, чтобы быть блокированным в течение долгих промежутков времени, когда открыт медиа-файл. Отметьте, однако, что асинхронное открытие не доступно для всех типов среды это поддержки QTKit. В любое время может также быть отменена асинхронная загрузка.

В OS X v10.6, также сохраняется максимальная обратная совместимость с существующими клиентскими приложениями QTKit. Это выполняется путем минимизации числа изменений, внесенных в существующий API QTKit и путем установки по умолчанию к абсолютно обратно совместимым способам поведения. Например, клиенты QTKit должны явно допустить, что разрешение QTKit попытаться использовать новые службы частных СМИ для определенного медиа-файла, включением нового атрибута в списке атрибутов передало -[QTMovie initWithAttributes:error:].

В OS X v10.6, поддержка QTKit новых мультимедийных служб, предоставленных в QuickTime X, прежде всего ограничивается воспроизведением носителей. Вы можете:

• Откройте медиа-файл

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

• Выведите на экран фильм в представлении

• Управляйте загрузкой и воспроизведением того фильма

В частности фильмы обработали использование новых мультимедийных служб в QuickTime X, не будет доступным для редактирования или экспортным. При попытке отредактировать a QTMovie объект, открытый как фильм только для воспроизведения, исключение, брошен. (Обратите внимание на то, что это - текущее поведение для приложений, пытающихся отредактировать объекты QTMovie, отмеченные как недоступные для редактирования.)

Среди улучшений, предоставленных мультимедийными службами в QuickTime X, определяются два новых и важных атрибута фильма:

NSString * const QTMovieOpenAsyncRequiredAttribute

NSString * const QTMovieOpenForPlaybackAttribute

Первый атрибут указывает ли a QTMovie объект должен быть открыт асинхронно. Установите этот атрибут в YES указать что все операции, необходимые, чтобы открыть файл ролика (или другой контейнер) и создать допустимое QTMovie объект должен произойти асинхронно. Т.е. методы movieWithAttributes:error: и initWithAttributes:error: возвратится почти сразу, выполняя любые длинные операции на другом потоке. Ваше приложение может контролировать состояние загрузки фильма для определения прогресса тех операций.

Второй атрибут указывает ли a QTMovie объект будет использоваться только для воспроизведения а не для редактирования или экспорта. Установите этот атрибут в YES указать, что Вы намереваетесь использовать способы его воспроизведения фильма, такой как play или stop, или соответствующие методы просмотра фильма такой как play: или pause: для управления фильмом, но не намеревайтесь использовать другие методы, редактирующие, экспортирующие, или всегда изменяющие фильм. Указание, что Вы должны воспроизвести службы только, может позволить QTMovie использовать более эффективные пути выполнения кода для некоторых медиа-файлов.

Поскольку простой и более эффективный фильм воспроизводит приложение, можно открыть файл ролика и присоединить его к a QTMovieView объект с помощью следующего отрывка кода:

 - (void)windowControllerDidLoadNib:(NSWindowController *) aController

    {

        [super windowControllerDidLoadNib:aController];

        if ([self fileName]) {

            NSDictionary *attributes = [NSDictionary dictionaryWithObjectsAndKeys:

                                        [self fileName], QTMovieFileNameAttribute,

                                        [NSNumber numberWithBool:YES],

                                        QTMovieOpenForPlaybackAttribute, nil];

            movie = [[QTMovie alloc] initWithAttributes:attributes error:NULL];

            [movieView setMovie:movie];

            [movie release];

            [[movieView movie] play];

        }

    }

Поскольку словарь атрибутов содержит пару ключ/значение с QTMovieOpenForPlaybackAttribute ключ и значение YES, QTKit использует новые мультимедийные службы, предоставленные в QuickTime X, если это возможно, для воспроизведения мультимедийного контента в выбранном файле.

OpenCL

OS X v10.6 позволяет Вашему приложению эффективно использовать не только многократный CPUs и многократные ядра, но и высокоэффективное питание параллельной обработки GPUs, встроенного во многие системы. Для многих приложений это может привести к значительному ускорению.

Приложения могут использовать эту новую возможность путем вызова OpenCL (Открытая Вычислительная Библиотека) платформа, предложенный Apple открытый стандарт для параллельного вычисления данных через GPUs и CPUs. OpenCL обеспечивает уровень абстракции так, чтобы можно было записать код один раз, и это может тогда работать на любых аппаратных средствах, поддерживающих стандарт OpenCL. Перед OpenCL было возможно записать приложения общего назначения, работавшие на GPUs, но необходимо было перевести вычисления в векторную арифметику и записать, что код на различном собственном языке для каждого вычисляет устройство.

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

Программирование OpenCL включает запись, вычисляют ядра на OpenCL-языке-C и вызов платформа OpenCL APIs для установки контекста, в котором ядра работают и ставить в очередь ядра для выполнения. Перед OpenCL вычисляют ядро, может работать на детали, вычисляют устройство, ядро должно быть скомпилировано в двоичный код, определенный для того устройства. Поэтому для создания программ OpenCL переносимыми компилятор OpenCL и время выполнения включен в платформу OpenCL, и ядра могут быть скомпилированы динамично во время выполнения. После того, как программа установлена в системе, время загрузки приложения может быть минимизировано путем компиляции программы для той системы и затем сохранения и выполнения скомпилированной версии в последующих вызовах приложения. С подпрограммами OpenCL можно соединить и вызвать как C функции от Какао, C, или приложения C++.

Многократные экземпляры вычислить ядра могут быть выполнены параллельно на один, или больше вычисляет модули, такие как ядра CPU или GPU. OpenCL позволяет Вам запрашивать текущее устройство для определения, сколько экземпляров ядра может быть выполнено параллельно для оптимизации на лету. Синтаксис OpenCL упрощает описывать проблемы с точки зрения многомерных массивов, часто самый естественный способ разработать программу. Многократные ядра могут быть соединены в большие программы OpenCL.

Для получения обзора описание процесса записи программы OpenCL и примеров кода, видит Руководство по программированию OpenCL для Mac.

64-разрядные требуемые плагины

В OS X v10.6, плагин должен соответствовать свое хост-приложение и с точки зрения архитектуры процессора и с точки зрения ширины адреса.

Приложения и другие исполнимые программы, поставляющие как часть OS X, переходятся к способным исполнимым программам на 64 бита. Если Вы пишете плагины для этих способных приложений на 64 бита (экранные заставки, например), Ваш код должен быть сделан 64 разрядными собственными компонентами в OS X v10.6, или это не будет работать над способным Macs на 64 бита.

Некоторые примеры затронутых плагинов включают:

• Расширения диалогового окна принтера

• Экранные заставки

• Аудиоустройства

• Средства импорта центра внимания

• Плагины инструментальной панели

• Плагины Safari

Если Вы пишете плагины, загружающиеся созданными Apple приложениями или демонами, необходимо сразу начать переходить плагины для добавления x86_64 версия к универсальным двоичным файлам. Плагины, которые являются только двухсторонние (32-разрядный) универсальный, не будут загружены 64-разрядными способными приложениями в OS X v10.6 и позже. Одно текущее исключение является приложением Установок системы, автоматически повторно запускающим себя в 32-разрядном режиме, если пользователь выбирает устаревшую 32-разрядную предпочтительную область. Для оптимального пользовательского опыта, однако, необходимо все еще обновить предпочтительные области для содержания x86_64 версия как можно скорее.

Чтобы изучить, как перейти Ваш код к 64-разрядному, считайте 64-разрядное Руководство по Переходу и затем считайте или 64-разрядное Руководство по Переходу для Какао или 64-разрядное Руководство для Разработчиков Углерода.

Базовый текст

Базовая текстовая платформа включает нового менеджера по Шрифту API для регистрации и активации шрифтов, управления дескрипторами шрифта, управления именами шрифтов и проверки файлов шрифтов. Для получения дополнительной информации посмотрите Базовый текстовый Ссылочный Набор.

Формальное принятие протокола

Для обеспечения лучшей проверки типа времени компиляции и AppKit и платформы Основы теперь используют формальные протоколы для методов делегата. Методы требуемого протокола отмечены с @required, если это возможно. Остальные отмечены с @optional.

Гамма 2.2

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

Исторически, гамма-коррекция по умолчанию для Mac OS была значением 1,8 (полезное значение для профессионалов печати). В последние годы телевидение, видео и веб-стандарты все рассчитались на гамме по умолчанию 2,2. В OS X v10.6, Mac перемещается в этот единый стандарт со следующими разветвлениями:

• Изображения без встроенной информации о гамме выглядят одинаково, когда создается на Mac OS и выведенный на экран в других системах, и наоборот.

• Изображения, тегированные с информацией о гамме, выглядят одинаково как в предыдущих версиях Mac OS (с незначительными улучшениями в некоторых случаях, потому что изображения, создаваемые в 2,2 пространствах, больше не преобразовываются).

• Изображения OpenGL и немаркированные веб-изображения имеют более высокий контраст. В целом выведенный на экран веб-контент будет более близко соответствовать яркость, замеченную в других системах, таких как PCs, выполняющий Microsoft Windows.

• Приложения, использующие систему элементы UI, такие как средства управления Какао, будут видеть минимальное изменение. Однако немаркированные изображения, которые не являются частью системы UI, кажутся более темными. Если Ваше приложение использует пользовательские элементы UI, Вы, возможно, должны скорректировать их яркость для получения желаемого появления.

Строго рекомендуется что Ваш тег приложения его изображения с информацией о гамме. Новый API был добавлен к ColorSync для возврата гамма значения для данного подключенного дисплея. Программно сгенерированные изображения должны использовать платформу ColorSync для автоматического вывода корректной яркости.

Поддержка Exchange

OS X v10.6 включает технологию для оказания поддержки Microsoft Exchange для Адресной книги, Почты и iCal. Это использует протокол Веб-сервисов Exchange для обеспечения доступа к Exchange Server 2007.

Производительность JavaScript

Safari в OS X v10.6 включает много улучшений для улучшения производительности JavaScript:

• Новый упрощенный DOM запрашивает API (Селекторы W3C API):

  • querySelector

  • querySelectorAll

• Новые собственные замены для обычно используемых библиотечных функций JavaScript:

  • getElementsByClassName

• Новый интерпретатор JavaScript в WebKit и Safari. Вместо того, чтобы выполнить сценарии с помощью традиционного интерпретатора, сценарии JavaScript теперь компилируются вниз в байт-код, затем выполнили использование механизма выполнения байт-кода. Это приводит к значительному повышению производительности по интерпретации сценариев на лету. В результате производительность JavaScript Safari в OS X v10.6 в четыре раза быстрее, чем это находится в Leopard.

В дополнение к этим базовым изменениям, описанным затем, существуют дополнительные инструменты для оптимизации Вашего кода JavaScript.

var stripetables = document.querySelectorAll(".stripedtable");

var darkstripes = document.querySelectorAll(".stripedtable tbody:nth-child(even)");

var lightstripes = document.querySelectorAll(".stripedtable tbody:nth-child(odd)");

// Obtain the initial list of matching tables

var stripetables = document.querySelectorAll(".stripedtable");

for (var mytable in stripetables) {

    // Perform further selection on each of the resulting elements.

    var darkstripes = mytable.querySelectorAll(".stripedtable tbody:nth-child(even));

    var lightstripes = mytable.querySelectorAll(".stripedtable tbody:nth-child(odd));

    ...

}

var buttonBarElements = document.getElementsByClassName('fancytoolbar_button');

<a class="fancytoolbar_button">...</a>

<img class="link_button fancytoolbar_button" />

<p class="fancytoolbar_button new_paragraph_button">...</p>

Веб-улучшения инспектора

Safari в OS X v10.6 обеспечивает много улучшений веб-инспектора, помогающих Вам настроить свой веб-сайт для лучшей производительности. Для использования их выберите Show Web Inspector из меню Develop. (Необходимо сначала включить меню Develop в области Advanced в Предпочтениях Safari, если Вы уже не сделали так.) В веб-инспекторе необходимо теперь видеть несколько значительных улучшений по предыдущим версиям Safari:

• Графическая область ресурсов

• Встроенный отладчик JavaScript

• Профилировщик производительности

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

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

Наконец, область Profiles позволяет Вам проведению испытаний на Вашем коде. Это встроенное профилирование производительности помогает Вам определить, какие области Вашего кода JavaScript необходимо оптимизировать для обеспечения самых больших повышений производительности. Для использования профилирования щелкните по точечному значку в нижнем левом углу, выполните некоторую задачу на веб-сайте, и затем прекратите профилировать путем щелчка по точке снова.

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