Почему BLE-коллбэки "перебивают" выполнение кода handler?

@antaki93 · Регистрация: 07.07.2012

Студворк — интернет-сервис помощи студентам

В своём приложении на Android я работаю с BLE. Делаю запросы к удалённому устройству и получаю от него асинхронные ответы в коллбэках.
В то же время, я использую handler.postDelayed(), который через заданное время закрывает соединение, если устройство не отвечает.

Кликните здесь для просмотра всего текста

1) делаем запрос к устройству
2) если в течение 10 сек. получаем ответ, продолжаем работу
3) делаем новый запрос
4) если в течение 10 сек. ответа нет, закрываем соединение
5) завершаем работу

Так вот, на днях у меня последовательно сработали сначала handler, завершающий работу, а затем (через 36 миллисек.) пришёл ответ от устройства (который уже никто не ждал). В итоге лог выглядел примерно так:

Кликните здесь для просмотра всего текста

1) сделали запрос
2) ответ не пришёл, закрываем соединение
3) ответ ПРИШЁЛ, пытаемся продолжать работу

Короче говоря, коллбэк выполнился, не дожидаясь завершения выполнения кода handler. Хотя, если я правильно понимаю, они оба должны выполняться в одном потоке и не могут "перебивать" друг друга. Кто-нибудь может объяснить, как это может работать?

@antaki93 · 12.07.2021, 13:19 **[ТС]**

BLE/GATT-колбэки в Android выполняются в отдельном потоке, поэтому их выполнение никак не согласовано с handler'ами из главного потока.
Этот отдельный поток создаётся системой автоматически при вызове connectGatt(). Чтобы перенаправить данные из колбэков в главный поток, проще всего использовать броадкасты. Если BroadcastReceiver был зарегистрирован в главном потоке, то его код будет всегда исполняться в главном потоке. Неважно, из какого потока был послан броадкаст.
Например:
Сервис:

Java
1
2
3
4
5
6
public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
    ...
    Intent intent = new Intent(ACTION_YOUR_ACTION);
    intent.putExtra(KEY_YOUR_DATA, yourData);
    context.sendBroadcast(intent); //отправка броадкаста происходит в служебном потоке
}

Активити:

Java
1
2
3
4
5
6
7
8
9
10
11
protected void onCreate(Bundle savedInstanceState) {
    …
    registerReceiver(yourReceiver, new IntentFilter(ACTION_YOUR_ACTION));
}
…
BroadcastReceiver yourReceiver = new BroadcastReceiver() {
    public void onReceive(Context context, Intent intent) { //обработка броадкаста происходит в главном потоке
        String yourData = intent.getStringExtra(KEY_YOUR_DATA);
        …
    }
}

Новые блоги и статьи Все статьи Все блоги /
Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .	Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .
SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .	SDL3 для Web (WebAssembly): Идентификация объектов на Box2D v3 - использование userData и событий коллизий 8Observer8 02.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-collision-events-sdl3-c. zip Сканируйте QR-код на мобильном и вы увидите, что появится джойстик для управления главным героем. . . .	Реалии Hrethgir 01.03.2026 Нет, я не закончил до сих пор симулятор. Эта задача сложнее. Не получилось уйти в плавсостав, но оно и к лучшему, возможно. Точнее получалось - но сварщиком в палубную команду, а это значит, в моём. . .	Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .

@antaki93 0 / 0 / 0 Регистрация: 07.07.2012 Сообщений: 29

	Почему BLE-коллбэки "перебивают" выполнение кода handler? 31.10.2017, 11:55. Показов 1215. Ответов 1 Метки android, async, bluetooth, handler (Все метки) В своём приложении на Android я работаю с BLE. Делаю запросы к удалённому устройству и получаю от него асинхронные ответы в коллбэках. В то же время, я использую handler.postDelayed(), который через заданное время закрывает соединение, если устройство не отвечает. Кликните здесь для просмотра всего текста 1) делаем запрос к устройству 2) если в течение 10 сек. получаем ответ, продолжаем работу 3) делаем новый запрос 4) если в течение 10 сек. ответа нет, закрываем соединение 5) завершаем работу Так вот, на днях у меня последовательно сработали сначала handler, завершающий работу, а затем (через 36 миллисек.) пришёл ответ от устройства (который уже никто не ждал). В итоге лог выглядел примерно так: Кликните здесь для просмотра всего текста 1) сделали запрос 2) ответ не пришёл, закрываем соединение 3) ответ ПРИШЁЛ, пытаемся продолжать работу Короче говоря, коллбэк выполнился, не дожидаясь завершения выполнения кода handler. Хотя, если я правильно понимаю, они оба должны выполняться в одном потоке и не могут "перебивать" друг друга. Кто-нибудь может объяснить, как это может работать? 0