본문 바로가기

StackOverflow

[Android] Receiver에 리모트 프로세스(process =“:remote”)를 해줘야 할 이유가 있나요?

http://stackoverflow.com/questions/4311069/should-i-use-android-process-remote-in-my-receiver


Q: Receiver에 리모트 프로세스(process =“:remote”)를 해줘야 할 이유가 있나요?

저는 굉장히 빈번하게 호출되는 BroadcastReceiver를 가지고 있습니다. 

그리고 많은 사람들이 BroadcastReceiver를 구현할 때, 아래와 같은 코드를 이용하는 것을 보았습니다.

android: process =":remote" 

제 BroadcastReceiver의 목적은, 몇 가지 조건을 체크한 다음 알람을 울리는 것입니다. 

제가 궁금한 부분은, 위와 같은 코드를 AndroidManifest.xml에 꼭 추가해야 하는지 입니다.

이 코드를 추가하면 얻을 수 있는 이점이 무엇인가요?


(질문자: Jason)


A: 리시버에 android:process=":remote"를 추가하면 별도의 프로세스에서 (즉, 별도의 Virtual Machine에서) 실행하게 됩니다. 일반적인 유스케이스에서, 이렇게 별도의 프로세스에서 무언가를 처리해야하는 경우는 별로 없습니다. 필요한 동작 대부분은 로컬에서 (당신의 APK 프로세스 안에서) 동작시킬 수 있을겁니다.

android:process=":remote"의 단점은, (별도의 프로세스에서 실행시키기 때문에) 좀 더 많은 리소스를 쓰게 된다는 것입니다. 이 코드를 추가하면, 기본적으로 2개의 VM이 동작하고, 몇가지 기능은 동작하지 않을겁니다. 예를 들면 싱글톤, 스태틱 변수 같은 것은 별도의 프로세스로 실행되고 있는 쪽에서는 접근할 수 없습니다.

몇 가지 경우에는 android:process=":remote"가 장점을 가질수도 있는데요, 당신의 어플리케이션을 종료해야 하는데 서비스는 계속 동작하고 있어야 할 경우 (별도의 프로세스를 돌리기 때문에) 이렇게 코딩할 수 있습니다. 다른 경우로는, remote 클라이언트가 당신의 서비스에 bind 해야 할 경우 이렇게 처리할 수 있습니다.

broadcastReceiver가 별도의 프로세스에서 수행될 경우, onReceive()를 동작시키면서도 어플리케이션의 메인쓰레드를 멈추지 않게 됩니다. (하지만, 동일한 기능을 다른 방법으로도 얼마든지 구현할 수 있습니다)

제 생각에는 대부분의 경우, 대부분의 일반적인 경우에, android:process=":remote"를 쓸 필요가 없습니다.

(답변자: ddewaele)



_

I have a BroadcastReceiver which is called every so often, and I have noticed many people use

android: process =":remote" 

in their receiver. Mine is used to check a few things and if the conditions match then activate an alarm. My question is should I use the line I had posted above in my manifest? And if so what are the benefits of doing so?

shareeditflag

_

105down voteaccepted

By defining your receiver with android:process=":remote" you basically run your receiver in a different process (= VM). For typical use-cases, you don't need to run this in a different process, and whatever you want to do can probably run just fine locally (in your APK process).

The drawback of using android:process=":remote" is that you need additional resources for it to run (in this case a separate process). When doing so, you're basically dealing with 2 VMs, and some patterns like singletons, static fields can no longer be shared between your app and your remote service.

The benefit of using android:process=":remote" is that for some use-cases, it might be handy to start a service that will keep on running (in its own process) after you've shutdown your application, or if you want remote clients to be able to bind to your service. Your broadcast receiver will not block your applications main thread when running in a separate process upon calling the onReceive()method (however, there are other ways of implementing this).

I've found that most of the time, for most common use-cases, you can get away without using android:process=":remote".

shareeditflag