Лучший способ реализовать Socket.io в android

Я планирую реализовать Socket.io в android этой библиотекой для приложения на основе чата. Насколько я понял, библиотека кажется довольно хорошей. Я хочу знать, как постоянно поддерживать одно соединение сокетов во всем приложении? Здесь я перечислил способы достижения, в которых мне нужен лучший и стабильный способ.

Три способа

Класс MainApplication расширяет приложение

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

BoundService

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

одиночка

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

Если у меня есть смысл, пожалуйста, помогите мне. Если не прокомментировать это.

редактировать

Я дал ответ, который больше подходит для меня.

Solutions Collecting From Web of "Лучший способ реализовать Socket.io в android"

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

Кроме того, я бы рекомендовал использовать Google Cloud Messaging вместо создания собственного механизма. Было бы лучше всего использовать время работы устройства и гораздо меньше кода для вас.

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

Обслуживание для подключения socket

По BoundService Рона, Service с BroadcaseReceivers является лучшей идеей, чем BoundService . Потому что его утомительный процесс для поддержания общения. И я также рекомендую pub/sub способ трансляции, например, Otto или EventBus (я сам предлагаю Otto by Square, который является чистым и блестящим api).

Плюсы OTTO
1. Очиститель Api
2. Вы можете подписаться и опубликовать в / к любой деятельности, фрагменту, сервису, классу.
3. Развязка . (Вы должны как можно меньше входить в свой код).

И еще один момент – использовать START_STICKY в onStartCommand для запуска службы после ее уничтожения. См. Эту ссылку.

MainApplication для запуска службы

Лучше всего начать работу в приложении MainApplication . Поскольку приложение будет убито при наличии ограничения памяти, или пользователь принудительно закрывает приложение из стека. Поэтому onStartCommand не будет вызываться часто, как если бы мы реализовали в Activity.

Реализация онлайн-статуса

Вы можете реализовать онлайн-статус, просто MainApplication Application.LifeCycleCallbacks в классе MainApplication , который имеет большинство обратных вызовов жизненного цикла активности и будет уведомлен в MainApplication . Благодаря этому вы можете реализовать Online статус просто без кодов пластин котла. (Если кому-то нужна помощь, дайте мне знать).

Загрузка или загрузка изображений или файлов.

Лучшая практика – реализовать IntentService потому что она работает в отдельном потоке. Я обещаю, что даст лучшую производительность, потому что он обрабатывается самим андроидом, а не потоками, созданными нами.

Вы можете комбинировать первый и третий способы:

Создайте Socket s в своем Application и объявите их как static . Таким образом, вы можете поддерживать и получать доступ к ним, где бы вы ни находились. Не забудьте создать отдельный Thread s для выполнения сетевых операций, вы можете использовать ThreadPool для управления этим Thread . Если вы хотите обновить свой пользовательский интерфейс из этого Thread вы можете использовать Handler и Message для связи с UI Thread

Прежде чем создать собственную реализацию клиента socket.io, вы должны предоставить этой библиотеке шанс: https://github.com/socketio/socket.io-client-java

Я использую его в одном из моих проектов для связи с сервером node.js, который работает очень хорошо. Собственно, все ваши предложения верны и в основном зависят от того, чего вы хотите достичь. Тем не менее, один контекст всегда доступен: контекст приложения. Поэтому вы должны сохранить экземпляр singleton в классе Application и получить его с помощью getApplicationContext() .

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

Чат: данные чата передаются только при активном приложении. Таким образом, это должно быть сделано в деятельности.

И служба, и деятельность могут обращаться к экземпляру singleton клиента socket.io из контекста приложения. Пока вы не обрабатываете сложные данные по основному потоку, все в порядке. Таким образом, оберните свои звонки в отдельный поток и начните их только тогда, когда они действительно нужны.