Пожалуй я вряд ли смогу ответить на Ваши вопросы, но всё же сделаю некоторые предположения =)
Если я правильно понимаю, AIDL самый тяжеловесный вариант, да и не особо рекомендуемый судя по документации. К тому же Messenger использует теже механизмы, что и AIDL, только с потоками нет заморочек. Мне не совсем понятна причина почему AIDL.
Честно говоря сейчас так с ходу и не отвечу. Когда я начинал сам анализировать, что лучше использовать, у нас сервис изначально был заложен как тяжеловесный вариант, поэтому я на легковестность решения мало смотрел.
Что значит держать соединение, если я запускаю сервис с главного активити, могу ли я пользоваться уже этим открытым соединением (все же в одном процессе) из другого активити или все же надо отрывать новое соединение?
Открывать новое
Вы пишите, что если соединение открыто, то задержек не будет, т.е. при открытии активити по любому будет задержка в 50мс?
Да, но если вы её в onResume засунете, то с точки зрения юзера, он не успеет что-то запустить в 1/20 секунды, а вот с точки зрения самого кода, можно получить null, как я писал выше.
Если активити по каким-то причинам была убита ОС, то сервис повис в памяти навечно?
Да, сервис будет висеть. Он тем и хорош, что он БУДЕТ висеть и БУДЕТ выполнять необходимое задание. Активность после падения перезапустил и заново подключился к этому сервису. Правда я так понимаю, такой вариант вам не нужен.
Все это работает, когда в одном процессе. Но идет серьезная задержка UI потока при загрузке и при проигрывании относительно длинных звуков.
Я так понимаю это происходит даже при проигрывании в отдельном потоке (т.е. я надеюсь что вы не в главном потоке проигрываете), то ... то могу сказать только предположения на эту тему.
1. Возможно у вас часто срабатывает GC, следовательно следует меньше порождать объекты (к примеру в играх вообще стараются не создавать новые объекты).
2. Сервис в отдельном процессе всё же вам даёт X2 оперативной памяти для вашей программы, т.к. создается новая копия Далвик машины. Чем больше памяти, тем проще работает GC.К примеру есть замечательная статья
Почему веб-приложения на мобильных платформах работают медленно
Сделаю небольшую вырезку из статьи
СБОРЩИК МУСОРА НА МОБИЛЬНОЙ ПЛАТФОРМЕ ЭТО НЕ ТОЖЕ САМОЕ, ЧТО СБОРЩИК МУСОРА НА ДЕСКТОПЕ
Если у вас из этой статьи в голове останется что-то одно, пусть это будет этот слайд. Ось Y — это время, потраченное на сборку мусора. Ось X — это «относительный расход памяти». Относительный к чему? К минимальному требуемому размеру памяти.
Вот то, что этот слайд нам хочет сказать: «Пока у тебя в 6 раз больше памяти, чем нужно на самом деле, ты — в шоколаде. Но горе тебе, если опустишься ниже 4 размеров требуемой памяти». Необязательно верить мне на слово:
Точнее, когда у сборщика мусора есть в 5 раз больше памяти, чем требуется, его производительность совпадает или слегка превосходит прямое управление памятью. Однако, производительность сборщика мусора быстро деградирует, когда ему требуется работать с небольшими хипами. С 3-мя размерами требуемой памяти он, в среднем, работает на 17% медленнее, а с двумя размерами — на 70% медленнее. Также сборщик мусора более подвержен пейджингу, если память дефрагментирована. В подобных условиях, все протестированные нами сборщики мусора работают на порядок медленнее прямого управления памятью.
По поводу конкретной задачи
Конкретная задача:
Нужно проигрывать короткие звуки по вызову из разных активити. Допустимая задержка начала проигрывания <10-20мс.
Загрузка звуков (использую Sounds) просходит в головной активити, где звуки map-ся с ID из базы данных.
Соответственно, вызов звука идет по ID.
Попробуйте поискать на stackoverflow, наверняка таких тем должны быть тучи
К пример, может эта поможет
The correct way to play short sounds Android?
Ну и напоследок, вы когда разберетесь, может даже что-то напишете, можете сделать заметку на сайте по поводу возможных вариантов и что когда лучше использовать. Самому тема интересна, думаю сам скоро буду с точно таким же разбираться, правда у меня реализация специфического диктофона будет.
.