Нативные драйвера что это
Введение в MySQL Native Driver для PHP
В этой заметке речь пойдет об альтернативном драйвере для доступа к СУБД MySQL, через PHP. Имя ему — MySQL Native Driver.
В PHP существуют три API для работы с MySQL: mysql, mysqli и PDO. Все три реализованы в виде расширений на языке C.
Самым старым из этих API является mysql. Это расширение появилось еще в PHP 3 и отлично поддерживало версии MySQL младше 4.1 (version =4.1) есть некоторые сложности. API mysql просто не поддерживает некоторые возможности новых версий MySQL’а.
Затем появилось расширение mysqli (вероятно, mysql improved). Это API поддерживает все новые возможности СУБД MySQL. Плюс к этому mysqli позволяет использовать ОПП синтаксис наряду с процедурным. Расширение mysqli поставляется с PHP начиная с версии 5.
Третье API называется PDO (PHP Data Objects). В общем смысле это не только API к MySQL, но и некий слой абстракции от конкретной СУБД. Как уже было сказано, PDO поставляется как расширение к PHP. Так вот вместе с этим расширением поставляются драйвера для конкретных СУБД: начиная от SQLite и заканчивая Oracle.
Эти API объединяет то, что они используют одинаковую библиотеку для непосредственного общения с MySQL. Они используют стандартную клиентскую библиотеку MySQL (libmysql). Библиотека эта написана на C, и к слову используется не только для клиентских приложений на PHP, но и для Perl, C/C++, Ruby и т.п.
Так вот, уже давно (кажется с начала 2007) имеется возможность использовать MySQL Native Driver (mysqlnd). Что это такое? Концептуально это замена libmysql. И не задаром он «Native» (родной, встроенный), так как всей своей реализацией тесно переплетён с PHP (на уровне языка C, разумеется) и распространяется в соответствии с лицензией PHP.
Собственно прелесть в том, что начиная с PHP5.3/6 mysqlnd приходит на замену libmysql. При этому API никоим образом не будут затронуты, и для разработчика процесс перехода обещает быть прозрачным – весь написанный ранее код с использованием API mysql, mysqli и PDO будет работать как часы.
Схематически, это выглядит так:
Преимущества MySQL Native Driver происходят из его природы, тесно связанной с внутренностями PHP. mysqlnd использует некоторые встроенные в PHP функции, что не может не повлиять на производительность.
В любом случае изучение внутренностей MySQL Native Driver равно как и его преимуществ достойны отдельной заметки или даже статьи.
Я же надеюсь, что данная вводная заметка о MySQL Native Driver будет хоть немного вам полезна.
Что такое драйвер и зачем он нужен
Это виртуальная инструкция к любому «железу» в компьютере
«Слетели драйвера», «У меня нет драйверов на принтер», «Видеокарте нужны драйвера» — если вам непонятно, что это значит и на что влияют драйверы, то эта статья для вас.
Что такое драйвер
Драйвер — это программа, которая работает как инструкция для операционной системы. Драйвер объясняет операционке, как пользоваться каким-то устройством.
Устройство — это то, что физически подключается к компьютеру:
Драйвер рассказывает компьютеру, как этим железом пользоваться, что оно умеет, какие команды понимает и как это железо могут использовать другие программы.
👉 Технически драйвер — это программа, которая висит в памяти компьютера всё время, пока компьютеру нужно это устройство.
Известное и неизвестное железо
Операционная система в компьютере знает и умеет многое, в том числе и работать со стандартным оборудованием. Стандартным — это значит тем, которое предоставляет стандартные возможности.
Например, клавиатура, мышь или веб-камера — это стандартное оборудование, потому что независимо от производителя они делают примерно одно и то же.
Разработчики операционной системы знают про такое оборудование, поэтому могут написать стандартные драйверы, которые подойдут к большинству устройств. Именно поэтому мы можем купить в магазине новую мышь и просто подключить её к компьютеру без установки дополнительных программ — операционная система сама разберётся, что делать.
Но бывает так, что разработчики добавили в устройство нестандартные возможности: переназначение сочетаний клавиш, сделали мышь с несколькими колёсиками или встроенный лазерный дальномер в видеокамеру. В этом случае компьютер не разберётся, как этим всем пользоваться, потому что в стандартных драйверах про это ничего нет.
В таких случаях разработчики устройств пишут свой драйвер, который объяснит компьютеру, как пользоваться всеми возможностями устройства. Этот драйвер нужно будет установить.
Сложное оборудование
Ещё бывает так, что оборудование хоть и стандартное, но сложное, например, видеокарта или принтер. Каждый производитель добавляет свои функции и технологии, которые считает нужными, и чаще всего они не совпадают с другими. Если подключить такое устройство к компьютеру, то компьютер, скорее всего, разберётся, что именно в него воткнули, то как с этим работать — неизвестно.
Здесь тоже нужны драйверы — они идут или в комплекте с устройством на компакт-диске или их качают с официального сайта производителя. Чем сложнее устройство, тем больше вероятность, что без установки дополнительных драйверов оно работать не будет.
Например, если у вас навороченная видеокарта, вы вставляете её в компьютер и сначала видите странную огромную картинку с низким разрешением. Это значит, что компьютер пока не нашёл драйверов на эту карточку и запустил её в «режиме совместимости» — то есть в том режиме, в котором он точно сможет ей управлять. Но возможности видеокарты будут сильно порезаны, пока мы не установим нужные нам драйверы.
Что значит «слетели драйвера»?
Это значит, что компьютер не может найти файлы с инструкциями от какого-то устройства. Так бывает при обновлениях системы, заражении вирусом или просто кто-то случайно мог удалить нужные файлы или папку целиком.
Решение простое: берёте заново драйвер с официального сайта или тот, который шёл в комплекте с устройством, и запускаете программу-установщик заново. А она уже сама разберётся, каких файлов не хватает, и настроит всё заново.
Драйверы нужны только на Windows?
Драйверы нужны на всех компьютерах и для всех операционных систем. Но некоторые операционки идут с кучей драйверов в комплекте, а у других этот набор более скромный.
Общее правило для 2021 года такое: большая часть оборудования, которое нужно для обычной офисной работы, подключится к любому компьютеру без необходимости что-то устанавливать. Операционка сама поймёт, что это за устройство, и, скорее всего, у неё уже будут драйверы.
А вот какое-то более сложное оборудование (например, профессиональная аудиокарта или видеокамера) потребуют установки драйверов от производителя.
В чём проблема с драйверами
Проблема в том, что часто производители не делают новые драйверы для старого оборудования. Например:
Есть диджейский контроллер Numark NS7 — это профессиональное оборудование для диджеев и артистов, оно стоит дорого и нужно примерно 100 тысячам человек на всей планете.
Когда контроллер только вышел, компания Numark выпускала драйвера на все свежие операционные системы, проблем с совместимостью не было.
Потом аппарат сняли с производства, поддержку прекратили. Последняя версия драйверов, которую выпустил Numark, — для Windows 10 и MacOS 10.12 (Sierra). С тех пор у Windows вышло большое обновление до 11, а MacOS обновился раз пять. Причём последние две версии сделаны для процессоров Apple, и уже нет надежды, что Numark обновит драйверы для этой архитектуры.
Так что, если вам достался этот редкий профессиональный прибор, вы вынуждены сидеть на древней MacOS Sierra, которая стремительно перестаёт поддерживаться современным софтом.
Что с этим делать? А ничего ты с этим не сделаешь. Такова жизнь.
Мобильная разработка: Cross-platform или Native
Всем привет! Я Игорь Веденеев, руководитель мобильной разработки в AGIMA. Поговорим немного о нативной и кроссплатформенной разработке. Раньше я по большей части скептически относился ко второй: не устраивало качество конечных приложений в первую очередь. Однако за последний год темпы развития кроссплатформенных фреймворков уже не в первый раз заставляют пересмотреть свое мнение насчет такого подхода. Поэтому давайте еще раз сравним самые популярные кроссплатформенные решения и нативную разработку.
На всякий случай
Если вы не знаете, что такое нативная и кроссплатформенная разработка:
нативная разработка (2 независимых приложения на языках Swift и Kotlin);
кроссплатформенная разработка — общая кодовая база для iOS и Android (с применением фреймворков Flutter или React Native (далее RN)).
У каждого способа есть свои особенности, плюсы и минусы. Соответственно, под каждый конкретный проект и каждую конкретную цель подходит какой-то один из них. Сейчас объясню, как выбрать и на что обращать внимание.
Нативная разработка
Нативная разработка — это классический способ создания приложения для iOS и Android. Ведется она с использованием инструментов и языков программирования, предложенных вендорами — Apple и Google. Языки в данном случае — Swift (iOS) и Kotlin (Android), а инструментов для профилирования и отладки в нативной разработке очень много.
Однако мы должны понимать, что в данном случае мы делаем два независимых приложения. Разрабатываются они параллельно. Каждое приложение может реализовать фичу по-своему, и у каждого могут быть свои баги. И самое главное, нативная разработка никуда не денется: пока существуют iOS и Android, Apple и Google будут предоставлять инструментарий для создания приложений.
Нативная разработка позволяет создать самое качественное и функциональное приложение, но взамен придется разрабатывать и отлаживать всё 2 раза и следить, чтобы приложения соответствовали друг другу функционально.
Среди разработчиков это пока самый популярный способ создания приложений. Поэтому собрать команду, даже большую, в этом случае проще, чем для кроссплатформы. В первую очередь из-за количества предложений на рынке.
Плюсы и минусы нативной разработки
2 независимых приложения
Стоимость разработки и отладки
Меньше потребляемых ресурсов*
Богатый инструментарий для разработки
Широкий рынок разработчиков
Кроссплатформенная разработка
Кроссплатформенная разработка подразумевает, что мы используем один и тот же код и на iOS, и на Android. Вообще говоря, это всё такое же нативное приложение, но, запустив его, мы сразу проваливаемся в мир Flutter или RN, и всё происходит уже там. Стоит отметить, что разработка на Flutter/RN идет быстрее. Причем не только за счет того, что мы делаем 1 приложение вместо 2-х, а еще и за счет концепций создания приложений, в частности UI.
Но, увы, не всё так хорошо: кроссплатформа имеет ряд проблем, на которые стоит обратить внимание, прежде чем выбирать этот подход для своего приложения. React Native и Flutter всё же сторонние Open Source-решения. В них могут встречаться баги. Новые фишки iOS и Android там будут появляться не так быстро, как при нативных решениях. Может прекратиться поддержка, в конце концов.
Также, довольно часто придется полагаться на сторонние Open Source-библиотеки, что тоже несет в себе риски потенциальных проблем: например, совместимость версии Flutter/RN. Не исключен вариант, что нужной библиотеки не существует в природе, и тогда придется реализовывать всё с нуля самому. Также нельзя добавить расширения для iOS-приложений или, например, приложение на часы. Это касается и Flutter, и RN.
То есть для реализации определенных фич придется добавлять нативный код, что приведет к смешению технологий. Как минимум надо будет иметь в них компетенции. Как максимум — организовывать передачу данных из нативного кода в кроссплатформенный и наоборот.
Если в приложении много логики и есть необходимость сделать ее многопоточной, это тоже будет проблемой и во Flutter, и в RN. Это возможно, но, скажем, это не то, для чего были предназначены эти фреймворки. Также каждый из фреймворков имеет достаточно тяжелую исполнительную среду, что делает кроссплатформенные приложения более ресурсоемкими и требовательными к процессору/оперативке телефона.
Если приложение подразумевает обширное использование аппаратных возможностей телефона, взаимодействия с ОС, то я бы тоже не рекомендовал использовать кроссплатформу — есть риск, что в какой-то момент или код станет очень запутанным, или мы упремся в ограничения одной из платформ или самого фреймворка. Еще стоит учесть, что нам стоит использовать платформенно нейтральный UI, чтобы не создавать потенциальных проблем с различным поведением на платформах и в принципе не снижать на этом скорость разработки.
На картинке ниже представлены результаты теста с простым списком с изображениями: видим, что нативное приложение выигрывает вчистую. Да, на более новых моделях телефонов разница будет не такой значительной, но тенденцию можно видеть. Результаты остальных тестов тут.
Если проще, то кроссплатформа позволяет разработать приложение в кратчайшие сроки. Лучше всего подходит для приложений-витрин услуг или товаров среднего/малого объема без обширного использования платформенных возможностей. То есть снять фотку на аватар или отсканировать QR-код не составит больших проблем, но, если вы делаете приложение вокруг камеры, лучше рассмотреть нативную разработку.
Плюсы и минусы кроссплатформенной разработки
Принципы работы драйверов iRidium
это программа, позволяющая вашему проекту взаимодействовать с оборудованием системы автоматизации.
Оборудование различных типов и производителей использует собственные протоколы, поэтому iRidium включает набор готовых драйверов для управления наиболее популярными системами автоматизации, а так же универсальный AV & Custom Systems для создания на его базе любых не поддерживаемых по умолчанию драйверов. В составе программного комплекса iRidium различают нативные (встроенные, стандартные) и скриптовые драйверы на базе AV & Custom Systems, использующие для работы iRidium Script API.
Встроенный драйвер
готовый драйвер, входящий в стандартную базу данных iRidium. Быстро настраивается в GUI Editor за счет стандартного набора параметров, характерного для этого драйвера и управляемой системы
Драйвер создает и поддерживает подключение, формирует команды для контроллера и получает ответы, которые после преобразования выводятся в каналы обратной связи в виде чисел или строк.
Он позволяет отправить команду в любом формате (HEX, DEC, ASCII) любому устройству. В этой схеме драйверная часть только поддерживает подключение к оборудованию и передает команды, которые полностью формируются пользователем.
Недостаток «чистого» драйвера AV & Custom Systems заключается в том, что с помощью него нельзя получить обратную связь. Эту проблему решает система скриптов, которая служит надстройкой над нативным драйвером AV & Custom Systems. Она позволяет получать, обрабатывать и отдавать в интерфейс данные, полученные от любого оборудования (см. iRidium Script API)
Совокупность нативной и скриптовой части, обрабатывающей данные, получаемые от оборудования, получила название Скриптовый драйвер:
Скриптовые драйверы (модули iRidium Script)
это драйверы на базе встроенного AV & Custom Systems, работающие за счет iRidium Script (базируется на языке Java Script). Используются для управления любыми системами, не входящими в стандартную базу данных iRidium. Script обеспечивает отправку команд и обратную связь от управляемых систем, cм. принципы работы драйверов iRidium.
Таким образом, скриптовый драйвер состоит из нативного драйвера AV & Custom Systems (транспортная часть и отправка команд) и программы, написанной на языке iRidium Script:
За счет нативной части, скриптовый драйвер формирует сессию подключения к оборудованию и обеспечивает поддержку подключения, а отправляет команды. За счет скриптовой части драйвер получает и обрабатывает данные от оборудования, а затем записывает в каналы драйвера для вывода на элементы графического интерфейса.
Натив или кроссплатформа? Детальный разбор простым языком
Немного знаний терминологии не повредит, чтобы иметь больше совместного контекста. Постараюсь не быть занудой.
SDK — software development kit — инструментарий разработчика. Говорят например, — AppStore SDK — набор инструментов для реализации платежей и подписок в приложении. Или Android SDK — совокупность более мелких SDK для разработки под всю платформу.
API — это программный интерфейс, (тяжело объяснять простыми словами оказывается). Руль — физический интерфейс к колёсам, коробка передач — к двигателю, мы дергаем за них, чтобы машинерия внутри сделала для нас более сложную работу через простой для восприятия интерфейс. Программные интерфейсы — наборы функций, объектов, используя которые программисты выполняют сложную работу более простыми действиями.
Поскольку сухой разбор преимуществ и недостатков той или иной технологии — пустая трата времени, будем честны, из любой технологии можно сделать какашку и конфетку, вопрос лишь какой ценой, поэтому для развития осознанного понимания, зайдем чуть издалека.
Так или иначе, клиент любого бизнеса, пожелавшего открыть для себя вожделенную айтишечку, доступен через 3 окошка:
Также мы не рассматриваем устройства носимой электроники, интернета вещей, экранов холодильников, различных embedded систем — уж очень они специфичны.
На заре широкого коммерческого успеха мобильных гаджетов, некто по фамилии Джобс, отстаивал идею о том, что персональный смартфон — это всего лишь окошко к всемирной паутине, которое всегда с собой. Круто же звучит! Вот что он говорил:
Полноценный движок Safari уже присутствует внутри iPhone. То есть, вы можете создавать изумительные Web 2.0 и Ajax приложения, которые выглядят и ведут себя так же, как родные программы iPhone. И они способны прекрасно взаимодействовать с его сервисами: звонить, отправлять электронные письма, разыскивать местоположение в Google Maps. И знаете, что? Для этого не нужен SDK! У вас уже все есть для написания невероятных приложений для iPhone, если вы знаете, как создавать программы, используя современные веб-стандарты.
Есть предположение, что изменить взгляд Джобсу помог Джонни Айв, убедив его в том, что устройства эппл без нативных сторонних приложений не будут доступны для создателей контента, плюс от этого платформа потеряет эксклюзивность. В тоже время, в кулуарах Гугл зрел андроид и у менеджмента не было особого мнения на этот счет.
Собственно, к чему эта лирика. Исторически, мы имеем два основных способа доставки приложения пользователю:
-Нативное приложение — созданное с использованием инструментов разработки вендоров: Apple/Google и распространяемое через магазины приложений. Для разработки под Apple актуальны технологии: UIKit, SwiftUI + богатый iOS SDK, язык программирования Swift (и для особых случаев старичок Objective-C)Для Андроид соответственно — Android SDK, Jetpack Compose, языки: Java 8, Kotlin
Веб-приложение, использующее браузер в качестве среды выполнения и ограниченного доступа к ресурсам девайса (я специально не называю веб-приложение сайтом, так мы в терминах отделяем статические странички от динамичных, наполненных различной бизнес-логикой, приложений). К ним же относятся так называемые WebView — приложения, обернутые тонким слоем нативного кода, использующего SDK браузера для открытия веб-приложения, также распространяются через сторы.На ладан дышащие представители этого вымирающиего семейства — Apache Cordova и Ionic. Они не скрывают свое основное назначение — быстрое прототипирование приложений. Для них актуальны классические веб технологии — HTML, CSS, Javascript. Сюда же попадают поделки из no-code конструкторов типа GlideApps и его аналогов.
Оба подхода стоят диаметрально противоположно друг другу по ряду критериев:
Промеж первых двух, с недавних пор, расположись гибридные технологии, которые в настоящий момент чаще всего подразумеваются как кроссплатформенные:
Гибридные, компилируемые в нативный код — приложения написанные с использованием сторонних инструментов разработки, языков программирования, которые имеют свой набор библиотек, связывающих программные интерфейсы платформенных SDK с собственными интерфейсами или полностью заменяющие их.
Типичные представители этого семейства: React Native, Native Script, Electron.
Пока мы не убежали далеко, хочу немного шокировать нетехническую публику — самая кроссплатформенная технология, он же язык программирования, внимание, — C++! Та-да-а-ам! И как ни странно, он очень широко используется для создания полностью нативных кроссплатформенных модулей. Никаких компромиссов! Только хардкор! Ведь наши приложения, это не только кнопочки и списки. Обработка сотен точек на картах, базы данных с особыми возможностями синхронизации совместного доступа к данным, криптография, доставка и обработка видео в реальном времени, ежесекундные данные котировок, которые мы хотим доставлять молниеносно для десятков биржевых тикеров одновременно и многое другое. Никто не пишет эту логику дважды или трижды под каждую платформу.
Главный вопрос при выборе технологии (безотносительно иных бизнес целей) — опыт какого качества мы хотим подарить пользователю. И вот несколько критериев, влияющих на пользовательский опыт:
Говоря образно, по степени абстрактности к конечной мобильной платформе, технологии можно разделить так:
Кроссплатформенные технологии, в первую очередь, хотят завлечь нас преимуществами единой кодовой базы. С этим трудно спорить:
Сравните 2 кусочка кода, описывающих карточку с картинкой:
Команды нативных разработчиков часто разбавляют C/C++ программистами. Они пишут кроссплатформенные модули для разных задач в основном не связанных непосредственно с бизнес логикой.
На старте с нуля ему нет равных в качестве продукта к скорости разработки. 2-3 разработчика способны наковырять безумное количество фич в кратчайшие сроки и выпустить продукт. При этом look-and-feel, производительность будут более чем приемлемыми. Большое количество библиотек решат множество задач типовой функциональности. Я бы назвал flutter серебряной пулей, но. надо кое-что иметь в виду.
Технология предназначена для создания UI! Как и язык программирования Dart.
Выдержка из википедии в доказательство о том, что есть флаттер на самом деле:
Flutter is an open-source UI software development kit created by Google.
Разработка с этим SDK мне всегда напоминала письмо из Простоквашино:
На личном опыте проверено, что в процессе развития продукта скорость нативной разработки со временем возрастает, а кроссплатформенной убывает. Это обусловлено тем, что в начале требуется больше усилий для сборки архитектуры и наработке кода для 2х проектов, нежели для одного. Пока умудренные в особенностях своих платформ, кодеры скрупулезно собирают базовые джентельменские наборы для любого нативного приложения, их коллеги по кроссплатформенному цеху возможно уже готовятся выпускать MVP. Всё меняется на зрелой стадии продукта.
Вот список бед на кроссплатформе, которые на поздней стадии сожрут больше денег, чем на старте:
Дайте знать, если хотите продолжение про KMM и Xamarin, жду вас и ваши мнения в комментариях!
Канала в телеге нет, но если что, пишите в личку