Я пишу этот вопрос не как часть какого-либо конкретного приложения, а как часть потенциального использования для будущих приложений. Я знаю, что ответы на этот вопрос могут быть очень конкретными для приложения, но я надеюсь, что вы со мной поговорите. Я передам свое понимание как есть, и, надеюсь, вы сможете мне помочь, расширив его. Удивительно зря, я обыскал в Интернете "полный" обзор и не смог его найти. Любые ссылки на соответствующие страницы приветствуются, очевидно.
Андроидное приложение по умолчанию работает в одном процессе. Каждое действие или служба, которые вы запускаете, по умолчанию даже запускаются в основном потоке. Все действия пользователя помещаются в очередь Looper основного потока, а соответствующие обратные вызовы обрабатываются в основном потоке.
Чтобы обеспечить concurrency, потоки можно запускать множеством разных способов: одиночными или в пулах. В этом отношении нет явной потребности в нескольких процессах. Использование нескольких процессов для параллельной работы нескольких ядер вашего устройства не требуется, так как Threads можно запускать параллельно, возможно, даже ваш основной поток? Но, возможно, этого будет легче достичь?
Чтобы работа Activity или Service работала в определенном (потенциально различном) процессе, вы устанавливаете только атрибут android:process в файле манифеста. Так легко реализовать?
Фреймворк Android специально создан для мобильных устройств, которые, как правило, имеют ограниченную память для работы. Поэтому процессы могут быть убиты при различных обстоятельствах, четко указано здесь. До тех пор, пока вы выполняете обратные вызовы жизненного цикла в действиях и службах, например onStop или onDestroy, это не должно давать никаких реальных проблем. Но очевидно, что раздельные части вашего приложения, используя несколько процессов, потенциально могут сохранить более важные вещи. Например, служба загрузки фона может быть сохранена (уровень 3 по важности), в то время как процесс с начальным Управлением, который запустил эту Службу, теперь в фоновом режиме (уровень 4) может быть освобожден для своих ресурсов. Кроме того, тот факт, что вы изолируете основные функции вашего приложения, может позволить вашему устройству лучше использовать его ресурсы?
Основа Binder делает IPC довольно простой в обращении, и это то, что вы будете использовать в целом, независимо от того, на самом деле использует несколько процессов. Я думаю, что основная стоимость наличия нескольких процессов для приложения - это доступ к общим ресурсам или отправка этих ресурсов между процессами, за исключением дополнительных ресурсов, необходимых для разветвления процесса от Zygote. Интересно, будет ли использование нескольких процессов фактически заставить вас реализовать ваше приложение по-другому?
Я думаю, что концептуально использование нескольких процессов не увеличит простоту реализации?
В суммировать плюсы нескольких процессов:
- Изоляция потенциально дает более продолжительную защиту.
- Отделка дает устройству большую маневренность при восстановлении ресурсов.
- Повышение производительности параллелизма?
Минусы:
- Новый процесс должен быть вилка из Zygote с использованием ресурсов
- В рамках ресурсов приложения необходимо разделить несколько процессов, которые напрягают как устройство, так и, возможно, производительность приложения.
основной пример использования Я могу думать:
- Используйте активность переднего плана для любых пользовательских взаимодействий и запускайте постоянно используемую связанную службу для полезной синхронизации, которая может пережить сеанс, который пользователь имеет с вашей деятельностью и/или приложением.
Если у вас есть какие-либо замечания в моем понимании, пожалуйста, укажите это (обратите внимание на несколько вопросительных знаков в моем объяснении). Если у вас есть какие-либо плюсы и/или минусы для добавления, ответьте также, я добавлю их в список.
