Работа с Bluetooth Low Energy в FireMonkey на Android и iOS
Bluetooth Low Energy позволяет обмениваться небольшими объёмами данных между мобильным приложением и внешним устройством, расходуя значительно меньше энергии, чем классический Bluetooth. Такой подход используется в датчиках, медицинских приборах, трекерах, системах контроля доступа, промышленной автоматике и аксессуарах для смартфонов.
В FireMonkey разработчик может создать общий пользовательский интерфейс и большую часть прикладной логики для Android и iOS. Работа с BLE при этом строится вокруг сканирования устройств, подключения к периферии, поиска GATT-сервисов и чтения или записи характеристик.
Кроссплатформенность не означает полного отсутствия различий между операционными системами. Android требует внимательной настройки разрешений и фильтров сканирования, а iOS строже контролирует фоновые операции и формат взаимодействия с периферийными устройствами.
Надёжное BLE-приложение начинается с правильно спроектированного протокола. Необходимо заранее определить UUID сервисов и характеристик, формат пакетов, правила подтверждения команд, обработку разрывов соединения и поведение программы при повторном подключении.
Архитектура BLE В FireMonkey
В Delphi для доступа к Bluetooth Low Energy обычно применяется пространство имён System.Bluetooth. Центральным объектом выступает компонент или экземпляр TBluetoothLE, который выполняет сканирование и управляет найденными устройствами. После обнаружения периферии приложение получает объект устройства и может установить соединение.
Типичный жизненный цикл состоит из нескольких этапов: запуск поиска, отображение результатов, выбор устройства, подключение, обнаружение GATT-сервисов, получение характеристик и подписка на уведомления. Эти операции лучше разделить по методам или отдельным классам, чтобы код формы не превращался в набор обработчиков событий.
Сканирование и подключение выполняются асинхронно. Нельзя рассчитывать, что сервисы будут доступны сразу после вызова метода соединения. Следующий шаг должен запускаться только после соответствующего события, иначе приложение столкнётся с пустым списком характеристик, ошибкой доступа или обращением к ещё не готовому объекту.
Сканирование И Поиск Устройств
Во время сканирования полезно фильтровать устройства по имени, MAC-адресу, идентификатору производителя или UUID рекламируемого сервиса. Фильтрация по имени удобна для прототипа, но для готового продукта менее надёжна: имя может измениться, отсутствовать или совпасть с другим устройством.
На Android результат обнаружения часто зависит от разрешений и состояния системных служб. На старых версиях ОС для поиска BLE требовался доступ к геолокации, поскольку операционная система связывала Bluetooth-сканирование с потенциальным определением местоположения. На Android 12 и новее используются отдельные разрешения BLUETOOTH_SCAN и BLUETOOTH_CONNECT, которые нужно запросить во время работы приложения.
На iOS пользователь должен предоставить доступ к Bluetooth через описание назначения в настройках приложения. Строка NSBluetoothAlwaysUsageDescription добавляется в Info.plist. Если устройство не рекламирует нужный сервис, сканирование по UUID может не дать результата, поэтому на этапе диагностики полезно временно проверять все доступные периферийные устройства.
GATT-Сервисы И Характеристики
BLE-устройство представляет данные в виде иерархии GATT: периферийное устройство содержит сервисы, а сервисы — характеристики. Характеристика может поддерживать чтение, запись, уведомления или несколько операций одновременно. Именно через неё приложение получает измерения и отправляет команды.
После подключения следует выполнить обнаружение сервисов и найти нужный UUID без предположений о порядке элементов. Нельзя обращаться к сервису по индексу, поскольку разные прошивки могут возвращать коллекцию в различной последовательности. Для стабильной работы используются заранее согласованные 128-битные UUID.
Уведомления предпочтительнее постоянного опроса. После включения notification или indication периферийное устройство самостоятельно отправляет данные при изменении значения. Это экономит заряд и уменьшает количество запросов. При этом приложение должно корректно преобразовывать массив байтов в число, строку, структуру или пакет собственного протокола.
Передача Данных И Формат Пакетов
Bluetooth Low Energy не является потоковым соединением в привычном смысле. Ограничение размера полезной нагрузки зависит от MTU и конкретной реализации, поэтому длинное сообщение может быть разделено на несколько фрагментов. Протокол должен содержать длину пакета, тип сообщения, порядковый номер и контрольную сумму либо другой способ проверки целостности.
Для команд управления желательно предусмотреть подтверждение. Приложение отправляет запрос, устройство возвращает код результата, а таймер контролирует ситуацию, когда ответ не пришёл. Повторная отправка допустима только для идемпотентных команд, иначе устройство может выполнить одну операцию несколько раз.
Данные, поступающие в обработчиках BLE-событий, не следует сразу изменять в визуальных компонентах. Сначала их нужно скопировать, проверить и передать в основной поток. Обновление TLabel, таблиц или индикаторов из фонового callback может привести к нестабильности или аварийному завершению приложения.
Различия Android И iOS
Android обычно предоставляет больше возможностей для фоновой работы, однако поведение зависит от версии системы, производителя смартфона и настроек энергосбережения. Сканирование нужно своевременно останавливать, когда устройство найдено, а при потере связи — освобождать старые объекты и запускать повторный поиск с ограниченной частотой.
На iOS приложение работает в рамках более строгой модели жизненного цикла. Система может приостановить процесс, особенно если он не использует разрешённые фоновые режимы. Для BLE-проектов важно заранее определить, должна ли программа продолжать обмен в фоне, и корректно настроить соответствующий режим в параметрах iOS-приложения.
Общую бизнес-логику удобно оставить в Delphi, а платформенные особенности изолировать в небольших адаптерах. В таком случае слой протокола не знает о конкретных разрешениях, а экран получает единые состояния: «поиск», «подключение», «готово», «потеряно» и «ошибка».
Надёжность И Безопасность Соединения
Разрыв соединения — штатная ситуация для BLE. Пользователь может уйти за пределы радиуса действия, выключить аксессуар или заблокировать смартфон. Приложение должно отличать временный обрыв от окончательной ошибки и предлагать автоматическое переподключение с увеличивающейся задержкой.
Перед повторным соединением рекомендуется сбрасывать состояние текущего сеанса: отписываться от старых уведомлений, очищать ссылки на сервисы и характеристики, а затем заново выполнять обнаружение GATT. Попытка использовать устаревший объект иногда выглядит как случайная ошибка чтения или записи.
BLE не следует считать защищённым только потому, что используется беспроводной протокол. Для чувствительных данных применяются pairing, шифрование на уровне протокола устройства, проверка разрешённых команд и, при необходимости, прикладная криптография. Секреты нельзя хранить непосредственно в исходном коде мобильного клиента.
Если измерения или команды передаются на сервер, их можно сохранять через API. При проектировании такого слоя пригодятся практики из материала об интеграции PHP с MySQL: валидация входных данных, параметризованные запросы и разделение логики доступа к базе.
Отладка И Сравнение Платформ
Отладку лучше проводить поэтапно. Сначала проверяется факт обнаружения устройства, затем подключение, список сервисов, доступные свойства характеристик, чтение, запись и уведомления. Для анализа удобно использовать сторонние BLE-сканеры, которые показывают рекламные пакеты и GATT-структуру независимо от приложения FireMonkey.
В журнале стоит фиксировать UUID, состояние соединения, размер отправленного пакета, полученный ответ и код ошибки. При этом персональные данные и ключи доступа должны удаляться из логов. Полезно также тестировать сценарии выключения Bluetooth, отказа в разрешении, потери сигнала и повторного запуска приложения.
| Особенность | Android | iOS |
|---|---|---|
| Основные разрешения | BLUETOOTH_SCAN, BLUETOOTH_CONNECT, а на старых версиях доступ к геолокации |
Разрешение Bluetooth и описание назначения в Info.plist |
| Фильтрация устройств | По имени, адресу, UUID и рекламным данным | Чаще по UUID сервиса и идентификатору периферии |
| Фоновая работа | Зависит от версии ОС и ограничений производителя | Ограничивается жизненным циклом и фоновыми режимами |
| Повторное подключение | Требует учёта энергосбережения и особенностей прошивок | Контролируется системой и состоянием приложения |
| Главный риск | Отсутствующие разрешения и нестабильное сканирование | Ограничения фона и неверная конфигурация Info.plist |
FireMonkey помогает сократить объём общего кода, но результат зависит от качества BLE-абстракции. Надёжное приложение должно учитывать разрешения, асинхронность, ограничения пакетов, особенности фонового режима и корректное освобождение ресурсов на обеих платформах.