Comments 43
Также к этому можно добавить про сочетание использования сервисов с WakeLock`ом.
Не просто с меньшей вероятностью.
Во-первых, это логично и правильно: это независимое действие, а не часть какой-то activity. (Аналогично: зачем разделять программу на функции и классы?)
Во-вторых, некоторые гарантии выполнения после выхода из activity всё-таки есть:
When an app goes into the background, it has a window of several minutes in which it is still allowed to create and use services. At the end of that window, the app is considered to be idle. At this time, the system stops the app's background services, just as if the app had called the services' Service.stopSelf()
methods. Under certain circumstances, a background app is placed on a temporary whitelist for several minutes. While an app is on the whitelist, it can launch services without limitation, and its background services are permitted to run.
developer.android.com/about/versions/oreo/background.html#services
Такая схема позволяет, с одной стороны, мгновенно доставлять push-уведомления всем приложениям (не дожидаясь следующего периода синхронизации), с другой стороны, не держать множество приложений одновременно запущенными.
Простите за офф-топик, но такая схема еще позволяет доминировать на рынке прошивок. На самом деле, телефон без установленных на нем Google Play Services лишается практически всех нужны для нормальной работы приложения механизмов: пушей, карт, локации, activity recognition и т.п.
Следующая часть наконец-то вышла: https://habr.com/company/solarsecurity/blog/427431/
Я наконец написал продолжение! https://habr.com/company/solarsecurity/blog/427431/
Пытался читать наверное с десяток книжек по архитектуре андроида. Но там всё так затянуто, и разбавлено водой что я не успел узнать ничего прежде чем мне надоело читать.
Статьи отличные. Сжато, кратко, доступно.
Да, именно в этом и есть смысл разделения на activity (GUI), которые могут запускаться, когда нужно, завершаться и перезагружаться; и сервисы, которые остаются запущенными даже без activity. Нет, всё это происходит в рамках одного приложения, конечно.
Но, как я рассказал в статье, Android 8 не позволяет таким приложениям поддерживать соединение в фоне (и вообще серьёзно ограничивает фоновые сервисы); вместо этого нужно использовать push-сервисы вроде Firebase Cloud Messaging. Вероятно, многие из этих приложений так и делают.
С другой стороны, пока что Viber и WhatsApp работают на Oreo в режиме совместимости (у обоих target SDK < 26), то есть на них эти ограничения не распространяются.
Нет, всё это происходит в рамках одного приложения, конечно.
А есть вообще возможность разделения на разные приложения? Межпроцессорное взаимодействие по примеру тех-же PIPE`ов в десктопных системах или WCF из мира .Net?
Конечно есть! Обычные pipe-ы никуда не делись (Android is Linux), правда совсем не очевидно, как их прокидывать из одного приложения в другое. Основной механизм IPC на Android — Binder, про который я рассказывал в первой статье.
Я опять приведу в качестве примера Google Play Services — приложение, которое не имеет собственного интерфейса, но реализует разнообразную функциональность, которой пользуются (подключаясь к нему через Binder) другие приложения.
Честно говоря, именно с callback hell я в Android не встречался, но есть и много других, мягко говоря, сложностей, с которыми приходится сталкиваться разработчику — в основном это вопросы архитектуры приложения и правильной работы с lifecycle (в том числе фрагментов). Решается это использованием реактивных библиотек вроде RxJava или новых Android Architecture Components. Подробнее об этом я собираюсь рассказать в одной из следующих статей.
Но основной механизм освобождения памяти в Android — это завершение наименее используемых компонентов приложений (в основном activity)
Это неверно, если только не писать многопроцессное приложение. Завершается процесс целиком.
stackoverflow.com/questions/34834490/android-memory-management-granularity-activity-or-process
К сожалению, этот вопрос плохо описан в документации. Насколько я понимаю, здесь есть такие особенности:
- при нехватке памяти система действительно завершает процессы целиком, при этом она может вызвать, а может и не вызвать
onDestroy()
у запущенных компонентов; - когда activity завершается не прямо перед завершением всего процесса (а, например, при повороте экрана),
onDestroy()
вызывается обязательно, но освобождение памяти самой activity происходит через обычный механизм сборки мусора (в том числе, если сохранить лишнюю ссылку, будет activity leak).
Но здесь нужно помнить, что запуск и завершение процесса — это всё-таки более низкий уровень, чем жизненный цикл компонентов приложения. Процитирую первую статью:
Android максимально абстрагирует понятие приложение запущено как от пользователя, так и от разработчика. Конечно, процесс приложения нужно запускать и останавливать, но Android делает это автоматически
То есть на этом более высоком уровне — как я описал в статье — может так получиться, что из двух копий activity одна запущена, а другая полностью завершена — например, если пользователь вернулся в одну из этих копий после того, как (на низком уровне) процесс был завершён из-за временной нехватки памяти, а потом запущен снова.
Наверно, я не очень удачно сформулировал. Конечно же, основной механизм освобождения памяти в Android — завершение всего неиспользуемого. Вопрос только в том, может ли приложение перейти из состояния «activity1 работает, acivity2 работает» напрямую в состояние «activity1 работает, acivity2 завершена», или только через состояние «activity1 заврешена, acivity2 завершена, процесс убит».
Переформулировал этот кусок в статье.
даёт их компонентам шанс дополнительно освободить ресурсы, вызывая такие методы, как onDestroy, и завершает их, полностью освобождая используемую ими память и ресурсы
Насколько мне известно, это тоже неверно и onDestroy в таком случае не вызывается или как минимум не стоит на это рассчитывать. Например из статьи той же Dianne Hackborn:
Once Android determines that it needs to remove a process, it does this brutally, simply force-killing it. The kernel can then immediately reclaim all resources needed by the process, without relying on that application being well written and responsive to a polite request to exit.
Да и в документации повсюду написано, что onDestroy никому и никогда не гарантирован.
Рассчитывать не стоит и не гарантирован (когда по памяти завершают, иначе гарантирован), но в документации явно написано, что система может его вызвать в такой ситуации:
onDestroy()
Called before the activity is destroyed. This is the final call that the activity receives. The system either invokes this callback because the activity is finishing due to someone's callingfinish()
, or because the system is temporarily destroying the process containing the activity to save space. You can distinguish between these two scenarios with theisFinishing()
method. The system may also call this method when an orientation change occurs, and then immediately callonCreate()
to recreate the process (and the components that it contains) in the new orientation.
Четвёртая статья: https://habr.com/company/solarsecurity/blog/427431/
Вопрос есть, я столкнулся с проблемой передачи данных по сети.
ru.stackoverflow.com/questions/725580/android-http-connection-refused
Мой сервис, каждые 10 секунд отправляет данные на сервер. Сервис Sticky.
На Андроид 4.1.2 все работает хорошо, а на Андроид 5.1.1 нет. Как только система уничтожит сервис при нехватке памяти, то после перезапуска сервиса отправка данных на сервер перестает работать. Если вручную удалить приложение из списка задач и запустить снова, то отправка начинает работать. Также отправка возобновляется, если я снова жму иконку программы в списке задач. Насколько я понял из статьи с 5.0 версии Андроида используется новая JVM. Не с этим ли связана эта проблема? Как мне ее решить? Запускать activity и service в разных процессах? У меня возникло ощущение, что система прибивая процесс и запуская его снова, оставляет заблокированными сетевые порты.
Нет, переход на ART вряд ли повлиял на работу сетевых соединений.
(Этот абзац не специфичен для Android, а верен на любой Linux-системе) Действительно, система может освобождать занятые порты не сразу после завершения державшего их процесса, а только после отправки всех буферизованных данных (это называется socket linger, и с этим часто борются с помощью SO_REUSEADDR
), но это актуально для портов с заранее известным номером. Если вы просто делаете POST-запрос, система автоматически назначит вам подходящий свободный порт, и этой проблемы не возникнет.
Хабр — не Тостер, но думаю, вам стоит посмотреть с помощью сниффера, в чём разница в успешных и неуспешных запросах, как вам и порекомендовали на StackOverflow.
Ну и не могу не упомянуть, что отправка данных на сервер каждые 10 секунд — это, мягко говоря, не лучшая идея. Создавать для этого каждый раз новый сокет и забывать его закрыть — тоже.
Спасибо за статью, очень интересно. На первый взгляд кажется что вся эта машинерия и все эти абстракции в android довольно элегантны но чувствую должна быть и критика и перечень недостатков в сравнением с каким-нибудь десктопным ubuntu, так как сейчас есть планшеты как на андроиде так и на десктопных ос (как windows так и на ubuntu, debian и др)
Как работает Android, часть 3