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

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

тремя способами

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

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

BoundService

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

Синглтон

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

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

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

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

4 ответов


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

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

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


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

в соответствии с Ofek Рон упомянул Service С BroadcaseReceiver это лучше идея чем BoundService. Потому что это утомительный процесс поддержания связи. И я также рекомендую pub/sub способ вещания, как Otto или EventBus (Я сам предложил Отто квадратом, который является чистым и блестящим api).

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

и еще один момент-use START_STICKY на onStartCommand() запустить службу после получения разрушен. См.этой ссылка.

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

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

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

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

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

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


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

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


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

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

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

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

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