Google Android - это несложно

Приветствую всех посетителей форума!

В качестве вступления.
Для начала представлюсь. Я - разработчик ICQ, Mail.Ru, XMPP мессенджера Mandarin IM для платформы J2ME. Если кто не слышал - прошу: http://tomclaw.com/library/?id=6
Его разработка началась, примерно, 4 года назад и проекту от первого релиза уже 2 года и 8 месяцев. Надо сказать, за это время я получил очень много опыта не только по части архитектур приложений, оптимизации кода, реализации разного рода интересных задач, но и разбираясь с протоколами как открытыми (XMPP), так частично открытыми (Mail.Ru) или даже вовсе закрытыми (ICQ, OSCAR). Проект Mandarin IM оказался весьма успешным и сейчас насчитывает более миллиона пользователей. Ежедневно Mandarin устанавливают от 1 000 до 3 000 человек. Кстати, проект открыт и его код доступен на GitHub: https://github.com/solkin/mandarin-j2me-legacy

В чём вопрос, чем я хочу поделиться и почему вообще пришёл сюда.
Не так давно (пару месяцев назад) я начал разработку новой линейки проекта - Mandarin IM для Android. Изучая саму платформу Android, у меня возникло много соображений относительно того, какую архитектуру приложения выбрать. Интуитивно я опираюсь на опыт разработчиков из Google, пытаясь понять, как устроен GTalk из Android 4 и как построить подобное ему лёгкое приложение, которое, по возможности, всегда в сети и готово принять сообщения к отправке. Заметил, что он работает с сервисом Google Services, который является отдельным процессом. И это совершенно правильная архитектура на мой взгляд - независимый сервис держит связь, а UI подключается к нему по необходимости и запрашивает, передаёт нужные данные.
После долгих изысканий я пришёл к архитектуре приложения, где сервис выполняется в отдельном от UI процессе, а обмен данными между UI и сервисом производится через интерфейс взаимодействия AIDL и Intent в обратную сторону (от сервиса к Activity). Вопросов может и не быть, но меня пугает то, что все данные, передаваемые между ними, сериализуются. Это явно не придаст скорости, даже если учитывать то, что используется быстрый способ - через интерфейс Parcelable. Насколько это решение оптимально?
Рассматривал построение приложения на основе Messenger, но он тоже основан на AIDL и является, по сути, его асинхронной реализацией.

Хочу услышать мнения, предложения и подискутировать насчёт построения архитектуры для такого приложения. Возможно, у кого-то есть подобный опыт?

И, спасибо всем заранее за участи в этой беседе!

Тут весь вопрос в том, сколько времени живет RemouteService после отключения всех приложений с ним взаимодействующих. Я вот сам сейчас ищу информацию о сервисах запущенных в отдельном процессе.

Есть следующий Lifecycle: http://developer.android.com/images/fun ... ecycle.png

Update:
Перечитал документацию, как и подозревал, сервисы в отдельных процессах могут быть прибиты так же, как и обычные. Так что их тоже нужно отправлять в Foreground.

Сервис живёт до тех пор, пока он сам не остановится или его не остановят. Ещё есть вариант, что сервис может быть остановлен системой по случаю нехватки ресурсов или убит пользователем через какую-то специальную программу. В этом случае всё зависит от того, какой флаг вернул сервис при старте. И если это REDELIVER, то система перезапустит сервис по возможности.

В этой части всё понятно. Неясным остаётся вопрос по эффективному общению с сервисом.

solkin писал(а):Сервис живёт до тех пор, пока он сам не остановится или его не остановят. Ещё есть вариант, что сервис может быть остановлен системой по случаю нехватки ресурсов или убит пользователем через какую-то специальную программу. В этом случае всё зависит от того, какой флаг вернул сервис при старте. И если это REDELIVER, то система перезапустит сервис по возможности.

В этой части всё понятно. Неясным остаётся вопрос по эффективному общению с сервисом.

Это теория, на практике все намного интересней =)

neoksi писал(а):

solkin писал(а):Сервис живёт до тех пор, пока он сам не остановится или его не остановят. Ещё есть вариант, что сервис может быть остановлен системой по случаю нехватки ресурсов или убит пользователем через какую-то специальную программу. В этом случае всё зависит от того, какой флаг вернул сервис при старте. И если это REDELIVER, то система перезапустит сервис по возможности.

В этой части всё понятно. Неясным остаётся вопрос по эффективному общению с сервисом.

Это теория, на практике все намного интересней =)

Умом Android не понять
На самом деле, сам он реально не завершится. Только если системе нужны ресурсы и потом она его перезапустит. Не сразу, конечно, как появятся ресурсы, но запустит. Это я много раз проверял.