Смысл "Android: процесс" при определении служб или получателей - PullRequest
Новая
       4

Смысл "Android: процесс" при определении служб или получателей

0 голосов
/ 05 октября 2018

Я более подробно изучаю атрибут android:process, когда он определен в service или receiver в AndroidManifest.xml

Это цитата из документов :

android: процесс

Имя процесса, в котором должна запускаться служба.Обычно все компоненты приложения выполняются в процессе по умолчанию, созданном для приложения.Он имеет то же имя, что и пакет приложения.Атрибут процесса элемента может установить разные значения по умолчанию для всех компонентов.Но компонент может переопределить значение по умолчанию с помощью своего собственного атрибута процесса, что позволяет распределить приложение между несколькими процессами.

Если имя, назначенное этому атрибуту, начинается с двоеточия (':'), новый процесс, приватныйк приложению, создается, когда это необходимо, и служба запускается в этом процессе.Если имя процесса начинается со строчной буквы, служба будет запускаться в глобальном процессе с таким именем, если у него есть разрешение на это.Это позволяет компонентам в разных приложениях совместно использовать процесс, сокращая использование ресурсов.

При следующих примерах того, как написать службу синхронизации, а также получателя, эти выборки обычно содержат определения манифеста с отдельным именем android:process.

Вот пример, гдеопределены получатель и служба (: удаленный и : синхронизация ) 

<receiver android:name="myapp.backgroundAnalysis.BackgroundAlaramReceiver"
        android:process=":remote"
        >
<intent-filter>
    <action android:name="android.intent.action.BOOT_COMPLETED"/>
</intent-filter>


<service
    android:name="myapp.backgroundCloudSync.SyncService"
    android:exported="false"
    android:process=":sync">
    <intent-filter>
        <action android:name="android.content.SyncAdapter"/>
    </intent-filter>
    ...
</service>

Что бы на самом деле произошло, если бы яопустить android:process от обоих?Я понимаю, что они будут выполняться в процессе по умолчанию, где также выполняется все остальное (Main, Threads? И т. Д.), Но повлияет ли это на поведение получателя и SyncService?

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

(История вопроса связана спроблема в том, что мне нужно запускать операции синхронизации на некотором общем ресурсе из различных объектов (основного приложения, получателя и SyncAdapter), но общий ресурс не может работать в многопроцессорных средах, поэтому я пытаюсь понять последствия возможных обходных путей или решений)

1 Ответ

0 голосов
/ 06 октября 2018

повлияет ли это на поведение получателя и SyncService?

Не напрямую.

Может ли это повлиять на поведение приложений при запуске

Безопасность потоков становится все более важной проблемой для всегов одном процессе.OTOH, это может быть намного проще, чем координировать работу в процессах 2+, так что один процесс не мешает работе другого процесса.

Я знаю, что служба будет запущена наосновной поток

Методы жизненного цикла службы (например, onStartCommand()) будут выполняться в главном потоке приложения;Ваша бизнес-логика должна работать в фоновых потоках.Вы должны сделать это независимо от того, находится ли все в одном процессе или разделено между процессами.

что-то остановит или только задержит, когда запланировано выполнение кода в главном потоке?

Если ваша служба выполняет код в главном потоке приложения, она будет блокировать все остальное в этом потоке во время выполнения этого кода.Вот почему службы всегда используют фоновые потоки.

В зависимости от того, как вы синхронизируете доступ к общим объектам, код службы, работающий в фоновом потоке, может заблокировать доступ к этим общим объектам и, следовательно, заблокировать код пользовательского интерфейса, который пытается получить доступ к этим объектам.,Вот почему мы пытаемся организовать наш код, чтобы избежать блокировки вызовов из пользовательского интерфейса для таких объектов, например, с помощью реактивных опций (LiveData, RxJava и т. Д.).

...