Nvidia framework sdk что это

Обновлено: 04.07.2024

Isaac SDK это современный фреймворк для разработки систем управления роботов, ориентированный на машинное обучение. Isaac SDK появился в начале 2019г. и уже имеет несколько релизов. Разрабатывается фреймворк компанией NVIDIA для своей встраиваемой платформы Jetson и компьютеров с GPU NVIDIA на борту. На другом железе Isaac SDK не поддерживается. Пользуясь тем, что никто еще тут про него не написал, попробую сделать это сам, раз уж имею какой-никакой опыт работы с ним.

Кроме того, совсем недавно вышла новая версия 2020.2. В которой появилось много нового. Примеры будут именно для этой версии.

Isaac SDK является аналогом ROS, и очень на него похож, однако, обладает существенными отличиями в реализации и архитектуре. Об этих отличиях чуть позже.

Содержание

1. Архитектура

Архитектура системы управления в Isaac SDK представляет собой граф узлов (nodes) и их соединений (channels), как и в ROS. Однако, узлы не являются отдельными независимыми процессами, которые в ROS общаются посредством TCP/IP(за исключением nodelet). В Isaac SDK весь граф собирается в одно приложение, которое все сразу собирается и все сразу запускается. Передача данных по сети, при необходимости, делается отдельно. При этом, система получается априори децентрализованной.

Для тех, кто не знаком с ROS

Для тех, кто не знаком с ROS, поясню, что узлами(nodes) называются программы, которые пишутся вами, другими пользователями, или уже есть готовые. Каждая из этих программ решает одну конкретную задачу. Например, детектирование объектов на изображении делает один узел, а предварительную обработку изображения (фильтрация, ректификация и т.п.) делает другой узел. Получением видеопотока с камеры занимается третий узел и т.д.

Передача информации между этими узлами происходит с помощью каналов или топиков, информацию в которые узлы могут публиковать и на которую могут подписываться. Иными словами, используется модель Издатель-Подписчик (Publisher-Subscriber).

Программные инструменты для написания узлов и коммуникации между ними предоставляет ROS. Аналогично работает и Isaac SDK.

Для пользователя, разрабатывающего приложения, Isaac SDK предоставляет множество инструментов и готовых решений:

Isaac SDK включает в себя поддержку CUDA, TensorRT, OpenCV, Eigen, Gstreamer, различные библиотеки для выполнения вычислений на графическом ускорителе и прочее. И в процессе установки он их все скачает :)

Для ряда задач робототехники и машинного обучения уже есть готовые GEMs (high-performance algorithms), причем среди них есть и достаточно вкусные алгоритмы. Например, AprilTags и ORB дескриптор с GPU ускорением. Включены примеры для работы с моделями по детектированию объектов, людей, области проходимости и тд. Есть инструменты для планирования маршрутов и навигации роботов на 2d карте для колесных и шагающих роботов.

В дополнение к Isaac SDK, поставляется ПО IsaacSim, которое позволяет использовать симуляторы для роботов. Поддерживаются хорошо известный Unity, и новинка от NVIDIA - Omniverse IsaacSim. Мне не приходилось, пока что, с ними работать, поэтому в данном руководстве работа с симуляторами рассматриваться не будет.

2. Установка

Фреймворк для работы требует видеокарту NVIDIA c драйвером 440 (рекомендовано). CUDA устанавливать рекомендуется, однако bazel при первой же сборке скачает и будет использовать свою версию NVCC для сборки CUDA кода.

Для SDK 2020.2 на Jetson должен быть установлен JetPack 4.4.1, а для версии 2020.1: JetPack 4.3. Это необходимо для корректной кросс-компиляции на Jetson.

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

/isaac . Далее вам нужно установить зависимости на компьютере, за которым вы будете работать (далее будем называть этот компьютер рабочим компьютером) :

Данный скрипт ни на одной моей Ubuntu 18.04 не сработал сразу без ошибок. Ни в версии 2020.1, ни в новой 2020.2 . К сожалению, вам придется в ручную смотреть что не смог установить скрипт и устанавливать это в ручную. Видимо, стоит его рассматривать только как пример, а не готовый к использованию инструмент.

Установка на Jetson, он же бортовой вычислитель робота (он находится с рабочим компьютером в локальной сети), делается следующей командой:

для более поздних версий

Заметим, для версии 2020.1 и более поздних скрипты располагаются немного в другом месте:

На этом установка закончится.

Как можно заметить, на бортовой вычислитель робота (в д.с. это Jetson TX2, Nano, Xavier NX или любой x86_64 компьютер c NVIDIA GPU) исходники скачивать не нужно. Предполагается, что все ПО собирается через кросс-компиляцию и закачивается на робот по сети. Это очень удобно и настроено из коробки. Подробнее об установке можно найти в официальной документации.

3. Сборка приложения

Isaac SDK использует систему сборки bazel и все приложения, пакеты, компоненты собираются вместе с исходниками всего SDK. При этом, многие зависимости будут скачиваться при первой сборке, поэтому первая сборка будет не быстрой.

Сборка для рабочего компьютера происходит следующей командой (для примера использовано стандартное приложение ping_pong):

Запуск приложения на рабочей машине:

Во время такого запуска, если это необходимо, происходит и сборка.

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

Тогда использование скрипта сборки выглядит следующим образом:

Добавка -pkg здесь не случайна. Ее необходимо добавлять к названию приложения. jetpack43 - обозначение версии платформы бортового вычислителя. Для семейства Jetson, на данный момент, используется jetpack43, в ином случае можно выбрать х86_64 . Запускаемое приложение скачивается на бортовой вычислитель в /home//deploy/bob, где bob - имя пользователя на рабочем компьютере

Для более старых версий: bob@desktop:

Для автоматического запуска приложения на бортовом вычислителе сразу после сборки, к команде добавляется аргумент --run.

Для ручного запуска, можно выполнить на бортовом вычислителе:

4. Создание своего приложения

Начнем с того, что в Isaac SDK используются такие понятия как: пакеты(packages), узлы(nodes), каналы(channels), но и такие понятия как: приложения(applications) и компоненты(components).

Так вот, одной фразой иерархию можно описать так: Пакеты включают в себя приложения, которые состоят из узлов, которые состоят из компонентов. Узлы между собой общаются с помощью каналов. При этом, стоит заметить, что компоненты универсальны по отношению к узлам. Все "полезные" вычисления происходят в компонентах. Компоненты, находящиеся в составе одного узла блокируют друг-друга, а находящиеся в разных узлах - нет.

Каждый пакет состоит из BUILD файла - c инструкциями для сборщика bazel. BUILD ссылается на один или несколько .json, в которых описывается структура и связи узлов и компонентов приложения, а также настройки компонентов. Компоненты обычно описываются в виде cpp/hpp или предварительно скомпилированных .so файлов. Кроме С++ поддерживается Python, который можно использовать для написания компонентов или вместо json файла.

В качестве примера реализуем простейшее приложение "Ping Pong", в отличие от стандартного, наше приложение будет состоять из одного компонента и для Ping и для Pong. (а почему бы и нет)

Итак, начнем. Создадим директорию нового приложения в

/isaac/sdk/packages/myapp. В этой директории создадим файлы:

Рассмотрим структуру файла MyPingPong.hpp:

И соответствующую реализацию в MyPingPong.cpp

Теперь разберем файл myapp.app.json

name - название приложения, описываемого данным json файлом

modules - список модулей или компонентов, которые используются в приложении

graph.nodes - определение узлов, из которых будет состоять граф приложения

Каждый узел описывается его именем name, задаваемым произвольно и списком компонентов узла components.

Компоненты описываются именем name, тоже задаваемым произвольно и типом type, который должен соответствовать классу, описывающему соответствующий компонент (см. ISAAC_ALICE_REGISTER_CODELET(/* type */) в .hpp файле)

graph.edges - определение ребер графа, связывающих узлы графа между собой. Или связывающих входы (graph.eges[].source) и выходы (graph.eges[].target) компонентов приложения между собой.

graph.config["Название узла"]["Название компонента"] <. >- определение параметров каждого компонента.

Для сборки приложения, необходимо, кроме прочего, определить инструкции для сборщика bazel в файле .BUILD:

isaac_app() - определяет название, состав модулей и .json файл для запуска. По умолчанию, для имени myapp будет запускаться myapp.app.json. Но это можно определить в ручную параметром app_json_file . Более подробно о параметрах можно узнать в файле //engine/build:isaac.bzl, который используется для загрузки правил сборщика в начале BUILD файла.

isaac_cc_module() - определяет модуль или цель сборки. Пользователю необходимо указать исходные и заголовочные файлы в соответствующих srcs и hdrs параметрах, а deps позволяет подключить модули из других компонентов Isaac SDK. Заметим, что вместо srcs можно напрямую указывать предварительно скомпилированные .so файлы. В модуле можно собрать исходники сразу для нескольких компонентов, поэтому это и называется модулем.

На этом создание простейшего приложения закончено, осталось лишь его запустить:

Если просмотреть лог, то можно найти много полезной информации, например, "посмертную" статистику работы приложения:

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

Кроме данных компонентов, ядром предоставляются и другие. Автоматически, по крайней мере в 2020.2, они не запускаются. Рассмотрим пару самых, на мой взгляд, необходимых:

5. WebsightServer

WEB-сервер, необходимый для взаимодействия пользователя и приложения. Для тех, кто знаком с ROS, этот компонент можно назвать аналогом RViz, который объединен с RQt.

Для простого запуска Sight необходимо добавить модуль "sight" в инструкции сборщика BUILD и инструкции запуска myapp.app.json .

Изменить в BUILD:

Изменить в myapp.app.json:

Тогда, в логе запуска нашего приложения появится пару строк:

Для нашего приложения WebSight будет выглядеть так:


Но может он выглядеть гораздо более красочно:


О том, как сделать его таким, рассмотрим чуть позже. А сейчас рассмотрим его интерфейс.

Справа список узлов, раскрывая которые можно менять параметры компонентов каждого узла.


Если поменять Пинг на Пинг мод, и нажать Submit , то наш компонент ping будет выводить в консоль:

Так можно менять любые параметры, и если логика компонента предусматривает, что значение параметра может быть изменено в процессе его работы, то это будет работать. Можно сказать, аналог dynamic_reconfigure из ROS.

Слева виден список окон:

Статистика (Statistics) - показывает статистику запущенных компонентов приложения.

статистика

статистика

Граф приложения (App Graph) - показывает граф узлов приложения и связи между ними. Аналог rqt_node_graph из ROS, но более скудный по функционалу. Например, он не показывает название каналов (аналог топиков в ROS), да и меньше инструментов по фильтрации отображения. Однако, тут показывается статус выполнения каждого из узлов и расположение узлов можно менять с помощью мышки. Это удобно.

серый цвет для еще не запущенных узлов

золотой для стартующих узлов

оранжевый для узлов, выполняющихся с частотой менее 0.1 Гц или находящихся на паузе.

зеленый для узлов, выполняющихся с частотой более 0.1 Гц.

красный для остановленных узлов.

PoseTree - окно, показывающее дерево зависимости систем координат в приложении. Аналог tf_tree в ROS. Работу с системами координат рассмотрим чуть позже. Изображение ниже показано для примера.

Пример дерева с/к

Пример дерева с/к

Virtual Gamepad - виджет WebSight позволяющий передавать сигналы джостика, мыши и клавиатуры в Isaac SDK, например, для ручного управления роботом по сети.

Пример окна для подключенного геймпада

Пример окна для подключенного геймпада

Для подключения джостика используется браузерный Gamepad API.

Для получения данных джостика из этого виджета, необходимо добавить в граф вашего приложения компонент isaac::navigation::VirtualGamepadBridge .

Replay Control Panel - виджет, позволяющий проигрывать ранее записанные данные каналов. Например, данные сенсоров. Аналог rosbag play из ROS.


Record Control Panel - виджет, позволяющий записывать данные публикуемые в каналы для последующего воспроизведения. Аналог rosbag record из ROS.


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

Однако, Sight позволяет выводить свою 2D/3D графику, строить графики изменения различных величин и интерактивные элементы.

5.1. Вывод своих данных в Sight

Вывод осуществляется с помощью функции show(). Для нее существует несколько реализаций, для различных типов данных и наборов аргументов:

Реализация функции show():

Тогда, в sight появится доступный к использованию канал:


После чего, отобразить график можно либо нажав ПКМ по latency, либо с помощью Add plot.


Либо, сконфигурировать изначально в myapp.app.json (добавить в config).

Функция show позволяет осуществлять и более сложный рендеринг с помощью sight::Sop. Тогда, show() будет выглядеть примерно так:

6. PoseTree

PoseTree это инструмент, упрощающий работу с преобразованием систем координат. Аналог TF из ROS.

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

После этого, необходимо определить параметр ping_T_pong , например, следующим образом:

В результате, мы увидим в WebSight:


Соответственно, если необходимо получить преобразование между теми или иными с/к, достаточно просто использовать get_foo_T_bar() , где foo и bar названия систем координат.

Заключение

В заключение, хотелось бы выразить свое мнение относительно Isaac SDK. Isaac SDK разработан для профессионального использования и хорошо оптимизирован под обработку видео данных и машинное обучение. Отдельно замечу удобство использования CUDA кода рядом с обычным C++(упрощена передача данных CPU-GPU) и богатую библиотеку стандартных компонентов, ускоренных с помощью GPU. Однако, система сборки bazel может оказаться непривычной, особенно, если необходимо использовать сторонний код, собираемый cmake. Дополнительно, серьезным недостатком является пока еще сравнительно маленькое сообщество и форум, на котором отвечают не так быстро, как хотелось бы.

Оговорюсь, что сравнивать с ROS1 этот фреймворк не стоит. На мой взгляд, ROS1 не годится для профессионального использования. ROS2 другое дело. Сравнение было бы интересно. Вроде бы, на просторах интернета такого сравнения еще нет.

Хочу сказать спасибо моему другу и коллеге Александру, который подал мне идею написать эту статью и периодически пинал меня, чтобы я ее закончил.

Прошу поучаствовать в опросе. Было бы интересно узнать, как много людей на хабре знакомы или используют Isaac SDK.

Что входит в NVIDIA SDK?

Опираясь на запросы разработчиков, NVIDIA раработала инструменты, библиотеки и улучшения модели CUDA, чтобы упростить создание приложений с искусственным интеллектом и высокопроизводительными вычислениями.

GPU Cloud

Уровень интереса к вычислениям на GPU растет, чему способствуют достижения в области ИИ.

Последние обновления Deep Learning SDK предоставляют новые возможности и оптимизацию производительности для приложений, использующих графические ускорители:

    теперь поддерживает графические процессоры Volta, повышает производительность библиотек до 5 раз, а также предоставляет новую модель для управления потоками и обновления отладочных инструментов. ускоряет машинное обучение в 3.5 раза благодаря встроенной поддержке оптимизации моделей Caffe и TensorFlow. обеспечивает в 2,5 раза более быстрое обучение нейронной сети ResNet50 от Microsoft на платформе Caffe2. предоставляет возможность масштабирования машинного обучения до восьми серверов с графическим ускорением. Благодаря этому время обучения нейронной сети сокращается с нескольких дней до нескольких часов.
  • Оптимизация процессоров Volta для таких фреймворков, как Caffe2, Microsoft Cognitive Toolkit, MXNet, PyTorch и TensorFlow, ускоряет их работу до 2,5 раз.

Чтобы узнать об изменениях больше, советуем посмотреть выступление генерального директора NVIDIA Хуана Женьсюня:

А что за GPU Cloud?

Компания также анонсировала запуск NVIDIA GPU Cloud (NGC), облачную платформу с графическим ускорением, оптимизированную для глубинного обучения. Платформа предназначена для разработчиков приложений с глубинным обучением, которые не хотят вручную настраивать новейшее программное и аппаратное обеспечение.

Это решение поставляется с NGC Deep Learning Stack — средой разработки, которая будет работать на ПК, суперкомпьютерах DGX и в облаке. Стек программ полностью управляется NVIDIA, поэтому разработчики могут использовать один видеоускоритель на своём ПК и дополнительные облачные ресурсы.

Функция масштабирования и повышения резкости изображений Nvidia, Nvidia Image Scaling, была обновлена ​​сегодня для повышения производительности и качества изображения. Хотя для геймеров здесь есть кое-что интересное, даже AMD. Эта функция масштабирования также делается с открытым исходным кодом и кроссплатформенной, что означает, что вскоре она может хорошо работать с графическими процессорами AMD и Intel.

Nvidia Image Scaling — это функция, которая уже несколько лет встроена в графические драйверы Nvidia. Вы можете включить его через панель управления Nvidia, и он предлагает альтернативу функции DLSS от Nvidia для геймеров без карт RTX и в играх, которые не поддерживают DLSS. Хотя это не совсем подходит для DLSS, это встроенное решение не требует специальной поддержки игр и, таким образом, будет работать в любой игре.

Что нового в этом обновлении, так это то, что масштабирование изображения Nvidia улучшается из Панели управления и GeForce Experience. Улучшенный алгоритм (версия 2.0) также предназначен только для начинающих, так как теперь есть возможность управлять резкостью всего изображения с помощью ползунка в меню.

В дополнение к этому, Nvidia также анонсирует новый SDK Nvidia Image Scaling, который делает для работы требуется внутриигровая поддержка со стороны разработчиков, но также будет работать на графических процессорах AMD и даже Intel.

Советы и подсказки

«Кросс-платформенный фактор стал намного более важным для многих разработчиков игр, которые говорят, что любят внедрять DLSS, но что делать тем, у кого его нет», — говорит Ларс Винанд из Nvidia. «И теперь мы предлагаем полное решение с DLSS и специальное решение для масштабирования для тех, кто не может использовать DLSS».

Этот SDK позволяет добавлять Nvidia Image Sharpening прямо в игровые меню, как вы ожидаете увидеть опции Nvidia DLSS или AMD FidelityFX Super Resolution.

Да, насчет последнего. Очевидно, есть некоторые четкие параллели между новым SDK апскейлинга с открытым исходным кодом от Nvidia и SDK апскейлинга с открытым исходным кодом от AMD. Оба нацелены на повышение уровня вашей игры без необходимости использования каких-либо модных тензорных ядер или AI-gubbins, и мы не единственные, кто проводит здесь параллели.

Nvidia говорит мне, что ожидает «очень похожего на FSR качества изображения» в целом, и в случае с Necromunda Hired Gun, игрой, которая нам не особо понравилась, она показала, что масштабирование даже «работает немного быстрее». » Тем не менее, наверняка будет много разнообразной игры.

Nvidia Image Scaling и FidelityFX Super Resolution сравнимы по производительности, хотя, если вы внимательно посмотрите, между ними есть заметные различия в конечном выводимом изображении. (Изображение предоставлено Nvidia)

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

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

NBA 2K22: Как разблокировать апартаменты в пентхаусе

Это соревнование работает изо всех сил, чтобы предоставить пользователю лучший опыт, и сегодняшнее объявление является такой же победой для владельцев видеокарт AMD, как и для видеокарт Nvidia. Большая поддержка игр для кроссплатформенных SDK для апскейлинга только улучшит частоту кадров и качество изображения в игре и, возможно, на более старых, более дешевых картах, которые в этом больше всего нуждаются.

Хотя нужно сказать, что пока нет запланированных игр с Nvidia Image Scaling SDK, так что в краткосрочной перспективе только владельцы графических процессоров Nvidia могут максимально использовать этот новый и улучшенный алгоритм. SDK доступен для разработчиков на GitHub сегодня, если они того пожелают, и Nvidia работает над плагином UE4 и другими ветвями движка, которые скоро появятся.

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

Вот проблема с ореолом, как она появляется в Cyberpunk 2077, которая теперь должна быть исправлена ​​с помощью DLSS версии 2.3, которая появится в игре с сегодняшнего дня. (Изображение предоставлено Nvidia)

Для Nvidia, тем не менее, DLSS по-прежнему доминирует и считает, что масштабирование изображений Nvidia «не подходит для DLSS, даже [with DLSS] в режиме производительности ». С сегодняшним объявлением также следует выпуск DLSS версии 2.3 в Cyberpunk 2033 с этой целью.

Так в чем же разница? Является ли это в первую очередь маркетинговой игрой семантики или существуют реальные различия в том, как разработчики должны взаимодействовать с программным обеспечением (и наоборот, как разработчики могут ожидать, что программное обеспечение будет вести себя)? Ожидается ли, что один будет на более высоком или низком уровне, чем другой, и т. Д.?

РЕДАКТИРОВАТЬ: Этот вопрос относится к SDK и фреймворкам в целом, а не только к двум, упомянутым выше.

Таким образом, вы можете разработать Framework, состоящий исключительно из библиотек, но если вы назовете его SDK, вы должны будете предложить что-то для поддержки разработки.

Я просто скопирую из Википедии:

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

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

Набор для разработки программного обеспечения (SDK или «devkit») обычно представляет собой набор инструментов для разработки, который позволяет разработчику программного обеспечения создавать приложения для определенного пакета программного обеспечения, структуры программного обеспечения, аппаратной платформы, компьютерной системы, игровой консоли, операционной системы. или аналогичная платформа. Это может быть что-то такое же простое, как интерфейс прикладного программирования в виде некоторых файлов для взаимодействия с конкретным языком программирования или сложное аппаратное обеспечение для связи с определенной встроенной системой. Общие инструменты включают средства отладки и другие утилиты, часто представленные в IDE. SDK также часто включают в себя пример кода и сопроводительные технические примечания или другую сопроводительную документацию, чтобы помочь прояснить моменты из основного справочного материала.

В двух словах, разница в следующем:

  • Вы вызываете функции SDK.
  • Платформа вызывает ваши функции.

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

Фреймворк принимает множество решений за вас, поэтому вам не нужно изобретать велосипед; Это скорее подход "заполнить пробелы". Меньше свободы, но вы экономите много времени и, возможно, избегаете некоторых ошибок.

Я был ведущим в Zend Framework в своей версии 1.0. Мы часто получали комментарии о том, что это не «фреймворк» в том смысле, в котором ожидали разработчики - они сказали, что это скорее библиотека классов.

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

Zend Framework был разработан для слабой связи, поэтому вы можете использовать любой из классов, если хотите. Это наложило несколько соглашений на ваш код или вашу базу данных. И мы собирались разработать генераторы кода, но еще не реализовали их.

Но я все еще чувствовал, что Zend Framework квалифицируется как фреймворк, а не как SDK, еще одним способом: фреймворк расширяемый . Он спроектирован как набор объектно-ориентированных базовых классов, и предполагается, что разработчики либо extend этих классов, либо пишут простые плагины в классах, чтобы добавить функциональность.

Традиционный SDK не расширяемый . Вы просто вызываете методы API в предоставленных классах, они делают то, что делают, и вы работаете с результатом. Любая настройка заключается в том, как вы используете API и как вы используете результаты.

Microsoft SDK может использоваться разработчиком для создания своих программ. Конечным пользователям обычно это не нужно.

Библиотека классов предоставляет классы, которые обычно используют одну и ту же грубую область применения (математика, рендеринг), но предназначены для использования в основном независимо друг от друга.

Фреймворк предоставляет классы, которые вместе образуют основу для приложения, которое вы только расширяете и уточняете.

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

В одном сравнении вы могли бы сказать:
Библиотека -> Framework -> SDK
Framework состоит из нескольких библиотек, а также некоторых инструментов (компиляторов и т. Д.) И не ориентирован на конкретную платформу. Для платформы может быть разработано несколько платформ, каждая из которых предназначена для разных целей. SDK предлагает вам фреймворки и все остальное, что вам нужно для разработки программного обеспечения для конкретной платформы.

Читайте также: