By defining your receiver withandroid:process=":remote" you basically run your receiver in adifferent process (= VM). For typical use-cases, you don't need to runthis in a different process, and whatever you want to do can probablyrun just fine locally (in your APK process).
The drawbacks of using android:process=":remote" is that you needadditional resources for it to run (in this case a seperate process).When doing so, you're basically dealing with 2 VMs, and some patternslike singletons, static fields can no longer be shared between your appand your remote service.
The benefits of using android:process=":remote" is that for someuse-cases, it might be handy to start a service that will keep onrunning (in its own process) after you've shutdown your application, orif you want remote clients to be able to bind to your service. Yourbroadcast receiver will not block your applications main thread whenrunning in a seperate 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"
本文探讨了在Android中定义接收器使用android:process=:remote的方式运行在不同进程中的利弊。这种方式虽增加了资源消耗,但为服务持续运行及避免阻塞主线程提供了可能。
5万+

被折叠的 条评论
为什么被折叠?



