(Not disagreeing with or contradicting anything in Streets of Boston's reply).
Applications on Android consist of zero or more components -- activities, services, and broadcast receivers. Processes run components and applications. They're managed separately. An application's components have to run in a process. They do NOT have to run in the SAME process, though by default they do. A process can run components from more than one application. Though by default, for security reasons, it won't. But you can set it up that way for your own applications, typically for efficiency reasons. In other words, processes are just a resource for running your components. And between intervals running your component, that resource can be taken away! Your component will then later be reconstructed in a new process. (Broadcast receivers, since they run only once per instantiation, have no "between intervals"). On Apr 10, 7:25 pm, Jason LeBlanc <[email protected]> wrote: > Since process != application.. just what are the distinctions? > > > > On Fri, Apr 9, 2010 at 5:06 PM, Bob Kerns <[email protected]> wrote: > > Just to point out a couple more things here. > > > 1) a Service's lifetime is NOT, in general, the same as an > > Application's lifetime. A service can be deleted when it's not in > > active use by any activity or intent. This can save memory. > > > 2) Under some circumstances, more than one application may be running > > in the same process. You won't be encountering those situations by > > accident, but it's an important part of the model nonetheless. In > > Android, process != application. > > > 3) By using a service, you get control over when and how your service > > gets restarted if your application and process get deleted in a low- > > memory situation. Services will be automatically restarted. > > Applications, and any singletons they manage, will not, unless they're > > required by a service being restarted! In a sense, your service > > continues to "exist" even when there's no process available to run it > > in.Once a process is available, your service is recreated and resumed. > > (This applies to services started with startService rather than > > binding. But if you want this, you can do both operations on the same > > service). > > > On Apr 9, 10:49 am, Mark Murphy <[email protected]> wrote: > > > ailinykh wrote: > > > > What do mean by "when all components of an Android application are > > > > destroyed"? > > > > Let's talk about Activity, for example. Does "destroy Activity" means > > > > unload Java class? > > > > No, I mean destroyed, as in onDestroy(). > > > > > If so, what happens when system tries to destroy activity but it is > > > > referenced by another object ( for instance, a singleton may keep > > > > reference to it) ? > > > > The component is destroyed from an Android standpoint, but the Activity > > > will not be garbage collected. This results in a memory leak and is why > > > mutable static data members should be avoided where possible. > > > > -- > > > Mark Murphy (a Commons Guy)http://commonsware.com| > >http://twitter.com/commonsguy > > > > Android App Developer Books:http://commonsware.com/books > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%2Bunsubs > > [email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
