Android: намерение или обработчик + слушатель + runnable?

Question

Мое приложение анализирует данные из inputStream в фоновом потоке. Он должен нажимать сообщениям gui в зависимости от прочитанных данных.

Несколько месяцев назад я сделал implentation, который работает что-то вроде этого:

• activiy реализует определенный интерфейс слушателя (один метод для каждого типа сообщения, параметры сообщений передаются как структурированный параметр методы) ,
• Деятельность регистрирует слушателя где-то.
• каждый раз, когда поток чтения имеет что-то для нажатия на действие, он создает runnable, который переносится на обработчик (созданный в потоке gui). Прогон выполняется в потоке активности и вызывает метод слушателя.

Это работает довольно гладко, но ...

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

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

У кого-нибудь есть ключ?

Благодаря

Julien

Answer 1

Интересно, какое решение будет соответствовать лучшим с точки зрения производительности

Это зависит от того, что вы имеете в виду под «простого намерения вещания».

Если вы имеете в виду, что вы звоните sendBroadcast() и registerReceiver() на вашем Activity или другой Context, это будет хуже в производительности, так как это предполагает взаимодействие между процессами (IPC), даже если вещатель и приемник находятся в одной обработать. Это также вызывает проблемы с безопасностью, так как любое приложение в системе может отправлять вам эти трансляции.

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

Лично я хотел бы использовать другую реализацию шины событий, например greenrobot's EventBus, для удобства программирования.

Answer 2

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