SDK - что это такое? Описание и особенности. На три буквы. Вся правда о том, что такое SDK

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

Оба поставщика устройств и поставщики программного обеспечения могут и должны предоставлять четко определенный API. Этот API позволяет другим программам (быть написанным) взаимодействовать с поставщиками собственных программных компонентов или аппаратных устройств.

Если у кого-то есть больше идей, чтобы объяснить это ясно, я был бы очень благодарен за предложения. Я хочу подчеркнуть, что цель состоит в том, чтобы объяснить понятия не программисту, который не знает разработчика lingo .

В частности, в контексте датчика отпечатков пальцев и программного обеспечения для регистрации/проверки, вот как я попытался это объяснить:

Если я являюсь изготовителем устройства/датчика отпечатков пальцев, а не бизнес написания программного обеспечения, способы, которыми я мог бы лучше продавать свои продукт:

10 ответов

Кусок торта:

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

* Все, что может использовать API. Некоторые API имеют положения безопасности, требующие лицензионные ключи, аутентификацию и т.д., Которые могут запрещать полное использование API в конкретных случаях, но это происходит только из-за сбоя определенных шагов аутентификации/авторизации. Любое программное обеспечение, которое предоставляет правильные учетные данные (если требуется), может использовать API.

** Технически, если API хорошо документирован, вам не нужен SDK для создания собственного программного обеспечения для использования API. Но наличие SDK обычно облегчает процесс.

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

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

кодирование без SDK или API похоже на создание всего с нуля без мастерской - вы должны даже создавать свои собственные инструменты

Предположим, что компания C предлагает продукт P и P каким-то образом связана с программным обеспечением. Затем C может предоставить библиотеку/набор библиотек разработчикам программного обеспечения, которые управляют программными системами P.

Эта библиотека/библиотеки SDK . Это часть систем P. Это набор для разработчиков программного обеспечения для изменения, настройки, исправления, улучшения и т.д. Программный фрагмент P.

Если C хочет предлагать функции P другим компаниям/системам, он делает это с помощью API .

Это интерфейс для P. Способ взаимодействия внешних систем с P.

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

В целях, однако, они на самом деле довольно разные.

Вы создаете что-то с SDK, и вы используете или потребляете что-то с API.

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

Интерфейс прикладного программирования - это набор подпрограмм/структур данных/классов, который определяет способ взаимодействия с целевой платформой/программным обеспечением, таким как OS X, Android, приложение для управления проектами, программное обеспечение для виртуализации и т. /p >

Хотя Software Development Kit - это оболочка API/s, которая упрощает работу для разработчиков.

Например, Android SDK позволяет разработчикам взаимодействовать с платформой Android в целом, в то время как сама платформа построена составными программными компонентами, общающимися через API.

Кроме того, иногда SDK создаются для облегчения разработки на определенном языке программирования. Например, веб-драйвер Selenium (встроенный Java) предоставляет API-интерфейсы для управления любым браузером изначально, а capybara можно рассматривать как SDK, который позволяет разработчикам Ruby использовать веб-драйвер Selenium. Тем не менее, веб-драйвер Selenium также является SDK сам по себе, поскольку он сочетает взаимодействие с различными драйверами родного браузера в один пакет.

API - это спецификации о том, как что-то сделать, интерфейс, такой как "Железнодорожные пути находятся на расстоянии четырех футов друг от друга, а металлический стержень шириной 1 дюйм". Теперь, когда у вас есть API, теперь вы можете построить поезд, который будет соответствовать на тех железных дорогах, если вы хотите отправиться куда угодно. API - это просто информация о том, как создать код, он ничего не делает.

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

SDK также имеют свои собственные API. "Если вы хотите привести в действие поезд, поместите в него уголь", "Потяните синий рычаг, чтобы переместить поезд". "Если поезд начинает действовать смешно, вызовите обслуживающего человека" и т.д.

API = Словарь доступных слов и их значений (и требуемая грамматика для их объединения)

Программирование для Android, часть первая: знакомство с SDK

2012-02-10 14:05

Установка SDK, знакомство с SDK, инструменты SDK.

В этой части пробежимся по верхушкам Android Software Development Kit (SDK), посмотрим, как он устроен, какие инструменты в него входят и как с этими инструментами работать. Особо углубляться в детали не будем, лишь поиграемся с отдельными программами, чтобы понять, как там всё работает.

Подготовка и установка SDK

Итак, приступим. Прежде всего вам необходимо установить java sdk, одного только java runtime для полноценной работы Android SDK недостаточно.

Напомню, что у меня везде речь идёт только о линуксе. Для начала создаём на компьютере каталог ~/android , там у нас будет лежать всё нужное для работы. Я это делаю специально, чтобы все инструменты находились в одном месте и во всех последующих статьях подразумевается, что SDK установлен ровно так, как сейчас будет описано.

% mkdir ~/android % cd ~/android

Дальше скачиваем в этот каталог архив SDK (ссылку берём с официального сайта) и распаковываем (скачанный файл обычно называется как-то типа adt-bundle-linux-x86-20130219.zip , он достаточно большой):

% unzip adt-bundle-linux-x86-20130219.zip

В этом архиве находится базовая часть SDK, она распаковалась в каталог с именем типа adt-bundle-linux-x86-20130219 , можете туда зайти и посмотреть, что там вообще есть, запускать пока ничего не надо. А лежит там собственно SDK и предварительно настроенная среда разработки Eclipse со всеми необходимыми плагинами. Не переименовывайте и не перемещайте никакие файлы или каталоги внутри каталога SDK, этим вы можете сломать работу Eclipse. Более подробно о файлах в SDK можно почитать на офсайте .

Начнём с Eclipse ADT, он запускается такой командой (вместо adt-bundle-linux-x86-20130219 может быть другой путь, зависит от версии скачанного SDK, дальше во всех именах файлов я его буду обозначать как adt-bundle-):

% ~/android/adt-bundle-/eclipse/eclipse

Можете создать симлинку или ещё как-нибудь запомнить эту команду. При первом запуске вам предложат выбрать каталог для проектов, вариант по умолчанию вполне годится, можно ничего не менять. Сразу после запуска вы увидите приветсвенный экран с короткой информацией по ADT и SDK. Всё на английском, конечно, привыкайте.

Из окна ADT запускаем менеджер SDK, через меню Window → . Выглядит он примерно так:

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

По умолчанию менеджер SDK предлагает поставить модули для самых последних версий андроида. Но нам пока этого не надо, поэтому снимем все галочки (для этого можно кликнуть по ссылке Deselect all в этом окне), но выберем модуль Android SDK Platform-tools и установим его (для этого нажмём кнопку внизу справа, на ней ещё написано что-то типа Install 1 package... , соглашаемся с условиями лицензии, ну разберётесь, короче, не в первый раз ставить программы; впрочем, этот модуль может быть уже установлен, если вы только что скачали последнюю версию SDK). В этом модуле Platform tools содержатся всякие важные программы, с ними мы чуть позднее поработаем.

Менеджер SDK весьма глючен, поэтому настоятельно советую его перезагружать после каждой установки модулей.

Архитектура SDK

В своём составе SDK содержит эмулятор андроидных платформ, он построен на базе qemu и весьма нетороплив (мягко говоря). Эмулятор позволяет создавать виртуальные устройства (Android Virtual Device или AVD в терминологии SDK), на которых можно запускать и тестировать создаваемые приложения. Советую аббревиатуру AVD запомнить, она дальше будет неоднократно всплывать.

Модули SDK можно разделить на две группы: в первую входят модули с данными для разработки приложений под конкретную версию андроидной платформы, они в списке обычно обозначены как SDK Platform внутри «папки» с названием версии платформы, также в неё входят дополнительные компоненты для конкретных девайсов, например, для планшета Samsung Galaxy Tab есть отдельный модуль Android 2.2/GALAXY Tab by Samsung Electronics. ; во вторую группу входят все остальные модули (примеры кода, например, или модули для поддержки гугловых сервисов, или документация по API).

Модуль SDK Platform обычно распаковывается в каталог ~/android/adt-bundle-/platforms/platform-NNN , где NNN - номер версии API платформы (число). Для каждого мажорного релиза платформы выпускается новая версия API, к примеру, для Android 2.2 номер версии API - 8, для Android 2.3.1 - 9, для Android 2.3.3 - 10, для Android 4.2.2 - 17 и так далее. В модуле содержатся файлы, необходимые для запуска данной платформы в эмуляторе андроидных платформ. Сразу же скажу, что в этом модуле не установлены гугловые сервисы для работы Google Maps, к примеру. Модули с поддержкой Google API выделены отдельно и обычно называются Google APIs by Google Inc. В принципе, все модули, разворачивающиеся в каталоге ~/android/adt-bundle-/platforms по структуре примерно одинаковы - там содержатся файлы, из которых создаётся образ виртуального девайса AVD.

Работа с виртуальными девайсами

Чтобы создать виртуальный девайс, нужно сначала установить модуль с образами для него, например, модуль с образом «голого» андроида (модуль с именем SDK Platform любой версии API); или образ какого-нибудь девайса, например, Galaxy Tab (модуль называется Android 2.2 (API 8)/GALAXY Tab by Samsung Electronics ).

Менеджер виртуальных девайсов можно запустить либо из окна Eclipse ADT (меню Window → ), либо из окна менеджера SDK (меню Tools → Manage AVDS... ) Выглядит этот менеджер вот так:

Чтобы создать новый девайс, жмём New... , открывается примерно такой диалог (здесь поля уже заполнены, об их значении -после скриншота):

В поле AVD Name вводим название девайса, для начала сойдёт что-нибудь типа test-111 , из списка Device выбираем «реальный» аппарат, который мы хотим эмулировать (или просто разрешение экрана), из списка Target выбираем образ на основе которого будет создан девайс. В группе Memory options указываем параметры оперативной памяти устройства. В поле Internal storage вводим размер «встроенной флешки», также можно задать размер «внешней» флешки. Когда всё сделано, жмём OK . На остальные поля в диалоге можете пока забить, значения по умолчанию сгодятся. После некоторой паузы показывается диалог со списком фич виртуального девайса и в списке должна появиться новая строчка, выделяем её и кликаем по кнопке Start... , далее на Launch . Загрузка девайса может занять немало времени, но в итоге всё загрузится как надо: на экране появляется новое окно с изображением экрана устройства, можно по экрану кликать мышкой (это аналог тыка пальцем по экрану), можно тыкать на «хардварные» кнопки сбоку.

Информация Виртуальные девайсы физически создаются в каталоге ~/.android/avd , для каждого девайса с именем NNNN там создаётся каталог NNN.avd с образами дисков и памяти, а также конфиг NNN.ini . Запускать нужный образ в эмуляторе можно такой командой (в аргументе -avd указываем имя нашего девайса, в данном случае это test-111): % ~/android/adt-bundle-/tools/emulator -avd test-111

У команды emulator есть куча разнообразных полезных параметров, полный список можно посмотреть командой:

% emulator -help

Совет Очень рекомендую добавить каталоги ~/android/adt-bundle-/tools и ~/android/adt-bundle-/platform-tools в переменную окружения PATH, чтобы программы из этих каталогов можно было вызывать откуда угодно без указания полного пути. Дальше я предполагаю, что вы это сделали, поэтому имена программ буду указывать без пути к каталогу, где они лежат.

Android Debug Bridge (ADB)

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

Первый из них называется Android Debug Bridge - это утилита командной строки, называется adb , лежит в каталоге ~/android/adt-bundle-/platform-tools и позволяет выполнять отладочные работы на подключенном устройстве.

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

% adb devices List of devices attached emulator-5554 device

Итак, видим девайс с названием emulator-5554 , с ним и будем работать. Все доступные опции программы adb можно посмотреть командой adb help , она покажет длинный список всевозможных опций с достаточно подробным описанием каждой.

Давайте посмотрим системный лог нашего виртуального девайса, это делается так (выйти из него можно через стандартный хоткей Ctrl+C):

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

Ещё немного поиграемся с logcat , сначала немного про формат вывода. Вот небольшой кусок лога:

D/dalvikvm(119): GC_EXTERNAL_ALLOC freed 4667 objects / 256808 bytes in 324ms V/MediaScanner(230): pruneDeadThumbnailFiles... android.database.sqlite.SQLiteCursor@44f17b18 V/MediaScanner(230): /pruneDeadThumbnailFiles... android.database.sqlite.SQLiteCursor@44f17b18 D/MediaScanner(230): prescan time: 987ms D/MediaScanner(230): scan time: 28ms D/MediaScanner(230): postscan time: 129ms D/MediaScanner(230): total time: 1144ms D/MediaScannerService(230): done scanning volume external I/Launcher.Model(119): not binding apps: no Launcher activity

У каждой записи есть приоритет , он обозначается буквой в начале сообщения, например, D означает Debug , то есть отладку; V - это наименьший возможный приоритет, от слова Verbose . Приоритет сообщения указывается программой, которая его сгенерила, всего возможно семь приоритетов (по возрастанию значимости): Verbose, Debug, Info, Warning, Error, Fatal, Silent.

Сразу за приоритетом, после символа / указывается тег сообщения, обычно это название сервиса или программы, сгенерившей сообщение. Далее в скобках указывается PID процесса, а после двоеточия собственно текст сообщения, который программа отправила в лог.

Как вы могли заметить, при выводе записей не указывается время, когда произошло событие. Это легко исправить опциями форматирования вывода:

% adb logcat -v time

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

Информация Если adb видит несколько девайсов, вам придётся указать, какой именно вы хотите использовать. В местных примерах я этого не делаю, так как adb достаточно умная команда и в случае всего одного девайса подцепляется к нему автоматически, однако если девайсов несколько, придётся указать, какой именно нужно использовать при помощи опции -s: adb -s emulator-5554 logcat . Также есть две полезных опции: -d позволяет подключиться к реальному подключенному девайсу, -e - к виртуальному; то есть если у вас подключено два девайса (один виртуальный, другой реальный), то командой adb -e можно подключиться к виртуальному, а командой adb -d - к реальному без ввода идентификатора.

С логом поигрались, теперь вспомним, что на девайсе работает практически полноценный линукс, а у линукса есть терминал, в который можно зайти, выполнив команду adb shell:

% adb shell root@android:/ # pwd / root@android:/ # ls acct cache config d data default.prop dev etc init init.goldfish.rc init.rc init.trace.rc init.usb.rc mnt proc root sbin sdcard sys system ueventd.goldfish.rc ueventd.rc vendor

В этом терминале обычно доступны самые базовые линуксовые команды типа ls , pwd , mount , однако опции этих команд могут сильно отличаться от тех, к которым вы привыкли на обычной линукс-машине. Возможности терминала там также довольно скромны, многих привычных фич bash/zsh там точно не будет. Кроме того, полноценный суперюзерский доступ по умолчанию есть только на виртуальных девайсах, производители железок предпочитают давать лишь весьма ограниченный доступ (который, однако, иногда можно расширить до полноценного суперюзерского, эта процедура называется в русском андроид-сообществе рутованием девайса или получением root-доступа ).

Можете полазить по файловой системе девайса, посмотреть, что и где там лежит. Вы, несомненно, обнаружите, что от привычной линуксовой машины структура файловой системы довольно сильно отличается. К примеру, нет каталога /usr , однако есть /system , причём этот каталог примонтирован с правами только для чтения, так что даже с суперюзерским доступом туда слазить не получится.

Ещё одна полезная опция прогаммы adb называется bugreport , она собирает и выводит на экран с девайса максимум информации о конфигурации (как программной, так и аппаратной):

Dalvik Debug Monitor Server (DDMS)

Ещё один крайне полезный инструмент называется Dalvik Debug Monitor Server (DDMS), эта программа находится в каталоге ~/android/adt-bundle-/tools и позволяет лазить в недра работающего девайса подобно adb , тоже работает как с виртуальными, так и с реальными железками. Однако в отличие от adb , эта программа не с интерфейсом командной строки, а с полноценным графическим интерфейсом.

Однако обычно нет необходимости запускать DDMS вручную, поскольку программа встроена в Eclipse ADT и оттуда её можно открыть через меню Window → Open Perspective → DDMS .

Если же вы решите запустить ddms вручную, то увидите такое окно:

Через DDMS можно смотреть системный лог девайса, изучать работающие процессы, ходить по файловой системе. Одна из самых полезных фич программы - снятие скриншотов с девайса, делается это через меню Device → Screen Capture или хоткеем Ctrl+S .

Вводный обзор средств SDK на этом и закончим.

Ссылки

• Developer Guide/Tools/adb - полная документация по программе adb
• Using DDMS - подробное описание DDMS на девелоперском офсайте андроида.

Читайте в следующей части: установка и настройка eclipse для нашего программного окружения

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

Три в одном
Страшная аббревиатура расшифровывается как Software Development Kit , то есть “набор для разработки программ”. Можно подумать, что к SDK в таком случае относится любой программный инструмент, например тот же Delphi или MSVC++ . Однако название обманчиво. На самом деле SDK — это комплект, который расширяет функциональность какой-то программы или игры и позволяет другому программисту или даже игроку создавать свои собственные программы.
SDK был бы не SDK, если бы в него не входили три важнейших компонента. Первый компонент — собственно программа или библиотека , которая позволяет разрабатывать новые программы или игры на базе чего-то, уже существующего. Второй — документация , которая в SDK, как правило, проста и лаконична. Она обычно делится на две части: Tutorial — пошаговый курс в стиле “Построим город за 10 минут” и раздел Reference — справочник по всему, что можно сделать с помощью данного SDK. Третий компонент обычно самый “вкусный” — примеры того, что можно сделать с помощью SDK. Во-первых, благодаря им можно вообще не вникать в SDK, но ознакомиться с тем, что же может пакет. Во-вторых, есть люди, которым даже относительно небольшой Tutorial читать лень. Так и не надо! Бери один из примеров, изменяй его и — вуаля! Новая программа или игра готова.

От нашего дома вашему
Все SDK условно можно разделить на две большие группы. Первые создаются разработчиками для тех, кто хочет сделать самостоятельную программу или игры. Пример такого SDK — DirectX , который установлен практически на любом компьютере. Но у простых смертных стоят только рабочие библиотеки — так называемый Redistributable . Для программерствующего же люда Microsoft подготовила полноценный пакет DirectX SDK весом 100 Мб. В нем есть все, что необходимо разработчику для создания компьютерной игры: собственно библиотеки, заголовочные файлы для MSVC++, примеры и многостраничная документация. Причем SDK распространяется совершенно бесплатно.
Но как быть тем несчастным, которые программируют не на MSVC++, а в других средах, например в Delphi? Microsoft тут не помощник, но почти для любого из языков программирование есть адаптер, с помощью которого можно использовать возможности DirectX.
Второй вид SDK — самодостаточные инструменты. К ним, к примеру, относится Torque Game Engine SDK от компании Garage Games — полноценный игровой движок, поддерживающий самые передовые технологии. В отличие от DirectX, который все же полуфабрикат, с помощью Torque можно создавать хорошие игры без глубокого знания технологий программирования под 3D. В Torque используется С-подобный скриптовый язык программирования. Для своих возможностей лицензия на разработку с помощью Torque стоит удивительно недорого — всего $100.
Сколь бы ни был распространен DirectX, но самые известные SDK среди разработчиков — это движки Unreal Warfare и Lightech . В их составе есть и инструменты для разработки, и документация, и примеры готовых игр. Только условия лицензирования гораздо более жесткие.
Кстати, не стоит думать, что в одной игре или программе может быть использован только один пакет разработчиков. Для создания некоторых игр применяется до десятка SDK.
Мнение общества
Чаще всего SDK, только что сошедший с конвейера, содержит массу багов. Чтобы упростить разработку программ и игр, а заодно подчистить глюки движка, разработчики создают специализированное Community — Сообщество разработчиков SDK. В разных компаниях сообщество организовано по-разному, но чаще всего это форум, где разработчики могут обсудить тонкости использования SDK, посоветоваться и задать вопросы в службе технической поддержки. Иногда делается лист рассылки с новостями о развитии SDK и раздел документации, который постоянно обновляется. Приплюсуйте к этому статьи самих разработчиков, общение с другими пользователями — разработчиками SDK и самое важное — круглосуточную техническую поддержку по телефону, электронным средствам связи и даже с выездом в офис клиента.
В России традиционно недооценивается эта составляющая и ценность службы технической поддержки вообще. Зато на Западе техподдержка ценится не меньше подробной документации. И стоимость этого компонента составляет значительную часть стоимости всего SDK.
* * *
Если к какой-то игре вышел SDK — это отличный повод совершенно бесплатно (лишь иногда — за небольшие деньги) создать свою собственную игру. Не надо программировать собственный движок, создавать множество дополнительных утилит, связывать все это вместе. Все уже сделано за нас. Нам нужно только изучить основы работы в SDK и... творить.

использование мобильный

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

Поставщикам устройств и поставщикам программного обеспечения могут и должны предоставлять четко определенный API. Этот API позволяет другим программам (быть написанным) взаимодействовать с собственными программными компонентами или аппаратными устройствами поставщика.

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

В частности, в контексте датчика отпечатков пальцев и программного обеспечения для регистрации / проверки, вот как я попытался это объяснить:

Если я являюсь производителем устройств / датчиков отпечатков пальцев и не занимаюсь написанием программного обеспечения, то я мог бы лучше продавать свой продукт:

1. Убедитесь, что мои драйверы устройств установлены в самых разных операционных системах
2. Определите и предоставите API для разработчиков программного обеспечения для написания программ (например, для регистрации, проверки), чтобы «поговорить» или использовать мое устройство
3. Разрабатывайте и предоставляйте SDK (один шаг за пределы API), чтобы разработчики программного обеспечения могли быстрее и быстрее писать программы, которые работают с моим устройством. SDK могут предоставлять библиотеки вспомогательного кода, справочные приложения, документацию и т. Д.

2018-11-27T00:00Z

5 Answers

API = Интерфейс прикладного программирования SDK = Комплект разработки программного обеспечения

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

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

Например, JDK (Java Development Kit) содержит API, а также компиляторы, среды выполнения и другие инструменты. Java API - это просто все библиотеки, которые составляют основной язык, с которым вы можете работать из коробки.

Примеры API: API Java, API Карт Google, API Flash Player.

Примеры SDK: JDK, GWT, Flex SDK.

2018-12-04T00:00Z

API = Словарь доступных слов и их значений (и требуемая грамматика для их объединения)

SDK = система обработки Word ... для 2-летних младенцев... которая пишет прямо из идей

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

2018-12-11T00:00Z

Интерфейс прикладного программирования - это набор подпрограмм / структур данных / классов, который определяет способ взаимодействия с целевой платформой / программным обеспечением, таким как OS X, Android, приложение для управления проектами, программное обеспечение для виртуализации и т. Д.

Хотя Software Development Kit является оберткой API / s, что упрощает работу для разработчиков.

Например, Android SDK позволяет разработчикам взаимодействовать с платформой Android в целом, в то время как сама платформа построена составными программными компонентами, общающимися через API.

Кроме того, иногда SDK создаются для облегчения разработки на определенном языке программирования. Например, веб-драйвер Selenium (встроенный Java) предоставляет API-интерфейсы для управления любым браузером изначально, в то время как capybara можно рассматривать как SDK, который позволяет разработчикам Ruby использовать веб-драйвер Selenium. Тем не менее, веб-драйвер Selenium также является SDK сам по себе, поскольку он сочетает взаимодействие с различными драйверами родного браузера в одном пакете.

2018-12-18T00:00Z

Предположим, что компания C предлагает продукт P и P каким-то образом использует программное обеспечение. Затем C может предоставить библиотеку / набор библиотек разработчикам программного обеспечения, которые управляют программными системами P.

Эта библиотека / библиотеки - это SDK . Это часть систем P. Это набор для разработчиков программного обеспечения для использования, чтобы модифицировать, настраивать, исправлять, улучшать и т. Д. Программный фрагмент P.

Если C хочет предложить функциональность P другим компаниям / системам, она делает это с помощью API .

Это интерфейс для P. Способ взаимодействия внешних систем с P.

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

С целью, однако, они на самом деле совершенно разные.

Вы создаете что-то с SDK, и вы используете или потребляете что-то с API.

2018-12-25T00:00Z

Кусок пирога:

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

* Все может использовать API. Некоторые API имеют положения безопасности, требующие лицензионные ключи, аутентификацию и т. Д., Которые могут запрещать полное использование API в конкретных случаях, но это происходит только из-за сбоя определенных шагов аутентификации / авторизации. Любое программное обеспечение, которое предоставляет правильные учетные данные (если требуется), может использовать API.

** Технически, если API хорошо документирован, вам не нужен SDK для создания собственного программного обеспечения для использования API. Но наличие SDK обычно делает процесс намного проще.