Каковы преимущества и недостатки использования нескольких процессов в приложении для Android

Я пишу этот вопрос не как часть какого-либо конкретного приложения, а как часть потенциального использования для будущих приложений. Я знаю, что ответы на этот вопрос могут быть очень конкретными для приложения, но я надеюсь, что вы со мной поговорите. Я передам свое понимание как есть, и, надеюсь, вы сможете мне помочь, расширив его. Удивительно зря, я обыскал в Интернете "полный" обзор и не смог его найти. Любые ссылки на соответствующие страницы приветствуются, очевидно.

Андроидное приложение по умолчанию работает в одном процессе. Каждое действие или служба, которые вы запускаете, по умолчанию даже запускаются в основном потоке. Все действия пользователя помещаются в очередь Looper основного потока, а соответствующие обратные вызовы обрабатываются в основном потоке.

Чтобы обеспечить concurrency, потоки можно запускать множеством разных способов: одиночными или в пулах. В этом отношении нет явной потребности в нескольких процессах. Использование нескольких процессов для параллельной работы нескольких ядер вашего устройства не требуется, так как Threads можно запускать параллельно, возможно, даже ваш основной поток? Но, возможно, этого будет легче достичь?

Чтобы работа Activity или Service работала в определенном (потенциально различном) процессе, вы устанавливаете только атрибут android:process в файле манифеста. Так легко реализовать?

Фреймворк Android специально создан для мобильных устройств, которые, как правило, имеют ограниченную память для работы. Поэтому процессы могут быть убиты при различных обстоятельствах, четко указано здесь. До тех пор, пока вы выполняете обратные вызовы жизненного цикла в действиях и службах, например onStop или onDestroy, это не должно давать никаких реальных проблем. Но очевидно, что раздельные части вашего приложения, используя несколько процессов, потенциально могут сохранить более важные вещи. Например, служба загрузки фона может быть сохранена (уровень 3 по важности), в то время как процесс с начальным Управлением, который запустил эту Службу, теперь в фоновом режиме (уровень 4) может быть освобожден для своих ресурсов. Кроме того, тот факт, что вы изолируете основные функции вашего приложения, может позволить вашему устройству лучше использовать его ресурсы?

Основа Binder делает IPC довольно простой в обращении, и это то, что вы будете использовать в целом, независимо от того, на самом деле использует несколько процессов. Я думаю, что основная стоимость наличия нескольких процессов для приложения - это доступ к общим ресурсам или отправка этих ресурсов между процессами, за исключением дополнительных ресурсов, необходимых для разветвления процесса от Zygote. Интересно, будет ли использование нескольких процессов фактически заставить вас реализовать ваше приложение по-другому?

Я думаю, что концептуально использование нескольких процессов не увеличит простоту реализации?

В суммировать плюсы нескольких процессов:

  • Изоляция потенциально дает более продолжительную защиту.
  • Отделка дает устройству большую маневренность при восстановлении ресурсов.
  • Повышение производительности параллелизма?

Минусы:

  • Новый процесс должен быть вилка из Zygote с использованием ресурсов
  • В рамках ресурсов приложения необходимо разделить несколько процессов, которые напрягают как устройство, так и, возможно, производительность приложения.

основной пример использования Я могу думать:

  • Используйте активность переднего плана для любых пользовательских взаимодействий и запускайте постоянно используемую связанную службу для полезной синхронизации, которая может пережить сеанс, который пользователь имеет с вашей деятельностью и/или приложением.

Если у вас есть какие-либо замечания в моем понимании, пожалуйста, укажите это (обратите внимание на несколько вопросительных знаков в моем объяснении). Если у вас есть какие-либо плюсы и/или минусы для добавления, ответьте также, я добавлю их в список.

Ответ 1

Использование нескольких процессов для параллельной работы нескольких ядер вашего устройства не требуется, так как потоки могут выполняться параллельно, возможно, даже ваш основной поток?

Живые (неблокированные) потоки будут выполняться параллельно через несколько ядер автоматически.

Но, возможно, это будет легче достичь на самом деле?

Я бы рассматривал потоки проще, чем процессы, но "проще", как правило, мнение.

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

За исключением того, что вы потратили больше ресурсов на то, чтобы иметь два процесса в первую очередь, а обслуживание службы в течение длительных периодов времени обычно является анти-шаблоном.

Структура Binder упрощает управление IPC и что вы будете использовать в целом, независимо от использования нескольких процессов

Разработчики обычно не используют Binder напрямую. Для этого нужны только те, кто использует связанные службы, и это довольно небольшой процент приложений для Android.

Интересно, может ли использование нескольких процессов заставить вас реализовать ваше приложение по-другому?

Да.

Изоляция потенциально дает более продолжительную защиту

IMHO, это не является оправданием для того, чтобы тратить RAM, CPU и аккумулятор на несколько процессов.

Повышение производительности параллелизма?

Потоки охватывают это.

Основной пример использования, который я могу придумать

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