Лучший способ реализовать сокет.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()
.
онлайн-статус пользователя: здесь вы должны создать фоновую службу, которая постоянно прослушивает состояние пользователей. Поскольку информации не так много, это должно быть нормально и не должно слишком сильно разряжать батарею. Кроме того, вы можете отправить флаг, если есть новая информация и только если есть что-то новое, вы начинаете другой поток, который получает новые данные. Это сохраняет данные низкий.
чат: данные чата передаются только тогда, когда приложение активно. Итак, это должно быть сделано в деятельности.
службы и деятельности может открыть одноэлементный экземпляр сокета.Ио клиента от контекста приложения. Пока вы не обрабатываете какие-либо сложные данные в основном потоке, все в порядке. Итак, оберните свои вызовы в отдельный поток и запустите их только тогда, когда они действительно нужны.