It is much like regular java: 1. It really depends on the hardware, but you have to assume that your app's process can get killed. And if you have background tasks/threads running, they'll be killed automatically with the process (just like in Java).
2. Yes, just like Java. If java object become non-reachable, the objects will be eligible for garbage collection. 3./4. If you haven't set your android:process attribute in you app's components, all your app's components will run in one process. I haven't seen anything to the contrary with activities/services/etc. that are private to your own app. However, just like java, memory is not shared between processes. Your static variable will hang around, but just for their own process. Each process instantiates its own JVM (DalvikVM) and static variables are not shared between processes. On Monday, February 27, 2012 9:32:04 PM UTC-5, John Sheehy wrote: > > Hi all, > > I ported an app to android that sends and receives messages, sometimes > interactively, sometimes doing the upload/download in the background. My > app has a bunch of singletons - using the static getInstance() pattern - > that handle things such as the network, database etc. and also a bunch of > activities which access the singletons' data whenever they're visible via > getInstance() etc. Some of these singletons have Executors of small thread > pools. Also, I use C2DM to poke the app when an incoming message arrives. > > From my non-android background I wrote it so that these thread pools and > static instances would keep the process alive indefinitely, albeit non > doing any processing and hopefully using minimal amounts of memory/battery > (just so I could avoid class loading etc.). However from what I've read it > seems that maybe some of this should be in a service - I'm trying to figure > out the reasons why I should do this, as the app seems to work just fine at > the moment - I would be hugely grateful if anyone could tackle some of the > questions below: > > 1. If I leave things as they are am I more or less likely to be killed in > times of low memory? My process doesn't show up in the "Running" column, > yet I can see it in DDMS > > 2. My c2dm broadcast receiver handles the intent, and schedules a runnable > in one of those process-level singletons, then returns. The whole trip > completes in milliseconds. Is this robust? Or would (for some reason) > having that singleton's processing in a service be more "correct" ? > > 3. If my singletons have a static "instance" variable, can the > object-level member variables ever be eligible garbage collection if they > are set to null at some point? > > 4. Finally I've read in this group that android re-uses linux processes > for new Application/Activities etc. to reduce overhead - in this case, what > happens to process-level static objects - do they also hang around? > > I suppose I'm really looking to see what happens under the hood at the > kernel process level, and in times of low memory if I switch > static-instance singletons to members of a service class. > > I'm coding to 2.2 APIs. > > Thanks a lot in advance for any help > On Monday, February 27, 2012 9:32:04 PM UTC-5, John Sheehy wrote: > > Hi all, > > I ported an app to android that sends and receives messages, sometimes > interactively, sometimes doing the upload/download in the background. My > app has a bunch of singletons - using the static getInstance() pattern - > that handle things such as the network, database etc. and also a bunch of > activities which access the singletons' data whenever they're visible via > getInstance() etc. Some of these singletons have Executors of small thread > pools. Also, I use C2DM to poke the app when an incoming message arrives. > > From my non-android background I wrote it so that these thread pools and > static instances would keep the process alive indefinitely, albeit non > doing any processing and hopefully using minimal amounts of memory/battery > (just so I could avoid class loading etc.). However from what I've read it > seems that maybe some of this should be in a service - I'm trying to figure > out the reasons why I should do this, as the app seems to work just fine at > the moment - I would be hugely grateful if anyone could tackle some of the > questions below: > > 1. If I leave things as they are am I more or less likely to be killed in > times of low memory? My process doesn't show up in the "Running" column, > yet I can see it in DDMS > > 2. My c2dm broadcast receiver handles the intent, and schedules a runnable > in one of those process-level singletons, then returns. The whole trip > completes in milliseconds. Is this robust? Or would (for some reason) > having that singleton's processing in a service be more "correct" ? > > 3. If my singletons have a static "instance" variable, can the > object-level member variables ever be eligible garbage collection if they > are set to null at some point? > > 4. Finally I've read in this group that android re-uses linux processes > for new Application/Activities etc. to reduce overhead - in this case, what > happens to process-level static objects - do they also hang around? > > I suppose I'm really looking to see what happens under the hood at the > kernel process level, and in times of low memory if I switch > static-instance singletons to members of a service class. > > I'm coding to 2.2 APIs. > > Thanks a lot in advance for any help > On Monday, February 27, 2012 9:32:04 PM UTC-5, John Sheehy wrote: > > Hi all, > > I ported an app to android that sends and receives messages, sometimes > interactively, sometimes doing the upload/download in the background. My > app has a bunch of singletons - using the static getInstance() pattern - > that handle things such as the network, database etc. and also a bunch of > activities which access the singletons' data whenever they're visible via > getInstance() etc. Some of these singletons have Executors of small thread > pools. Also, I use C2DM to poke the app when an incoming message arrives. > > From my non-android background I wrote it so that these thread pools and > static instances would keep the process alive indefinitely, albeit non > doing any processing and hopefully using minimal amounts of memory/battery > (just so I could avoid class loading etc.). However from what I've read it > seems that maybe some of this should be in a service - I'm trying to figure > out the reasons why I should do this, as the app seems to work just fine at > the moment - I would be hugely grateful if anyone could tackle some of the > questions below: > > 1. If I leave things as they are am I more or less likely to be killed in > times of low memory? My process doesn't show up in the "Running" column, > yet I can see it in DDMS > > 2. My c2dm broadcast receiver handles the intent, and schedules a runnable > in one of those process-level singletons, then returns. The whole trip > completes in milliseconds. Is this robust? Or would (for some reason) > having that singleton's processing in a service be more "correct" ? > > 3. If my singletons have a static "instance" variable, can the > object-level member variables ever be eligible garbage collection if they > are set to null at some point? > > 4. Finally I've read in this group that android re-uses linux processes > for new Application/Activities etc. to reduce overhead - in this case, what > happens to process-level static objects - do they also hang around? > > I suppose I'm really looking to see what happens under the hood at the > kernel process level, and in times of low memory if I switch > static-instance singletons to members of a service class. > > I'm coding to 2.2 APIs. > > Thanks a lot in advance for any help > On Monday, February 27, 2012 9:32:04 PM UTC-5, John Sheehy wrote: > > Hi all, > > I ported an app to android that sends and receives messages, sometimes > interactively, sometimes doing the upload/download in the background. My > app has a bunch of singletons - using the static getInstance() pattern - > that handle things such as the network, database etc. and also a bunch of > activities which access the singletons' data whenever they're visible via > getInstance() etc. Some of these singletons have Executors of small thread > pools. Also, I use C2DM to poke the app when an incoming message arrives. > > From my non-android background I wrote it so that these thread pools and > static instances would keep the process alive indefinitely, albeit non > doing any processing and hopefully using minimal amounts of memory/battery > (just so I could avoid class loading etc.). However from what I've read it > seems that maybe some of this should be in a service - I'm trying to figure > out the reasons why I should do this, as the app seems to work just fine at > the moment - I would be hugely grateful if anyone could tackle some of the > questions below: > > 1. If I leave things as they are am I more or less likely to be killed in > times of low memory? My process doesn't show up in the "Running" column, > yet I can see it in DDMS > > 2. My c2dm broadcast receiver handles the intent, and schedules a runnable > in one of those process-level singletons, then returns. The whole trip > completes in milliseconds. Is this robust? Or would (for some reason) > having that singleton's processing in a service be more "correct" ? > > 3. If my singletons have a static "instance" variable, can the > object-level member variables ever be eligible garbage collection if they > are set to null at some point? > > 4. Finally I've read in this group that android re-uses linux processes > for new Application/Activities etc. to reduce overhead - in this case, what > happens to process-level static objects - do they also hang around? > > I suppose I'm really looking to see what happens under the hood at the > kernel process level, and in times of low memory if I switch > static-instance singletons to members of a service class. > > I'm coding to 2.2 APIs. > > Thanks a lot in advance for any help > On Monday, February 27, 2012 9:32:04 PM UTC-5, John Sheehy wrote: > > Hi all, > > I ported an app to android that sends and receives messages, sometimes > interactively, sometimes doing the upload/download in the background. My > app has a bunch of singletons - using the static getInstance() pattern - > that handle things such as the network, database etc. and also a bunch of > activities which access the singletons' data whenever they're visible via > getInstance() etc. Some of these singletons have Executors of small thread > pools. Also, I use C2DM to poke the app when an incoming message arrives. > > From my non-android background I wrote it so that these thread pools and > static instances would keep the process alive indefinitely, albeit non > doing any processing and hopefully using minimal amounts of memory/battery > (just so I could avoid class loading etc.). However from what I've read it > seems that maybe some of this should be in a service - I'm trying to figure > out the reasons why I should do this, as the app seems to work just fine at > the moment - I would be hugely grateful if anyone could tackle some of the > questions below: > > 1. If I leave things as they are am I more or less likely to be killed in > times of low memory? My process doesn't show up in the "Running" column, > yet I can see it in DDMS > > 2. My c2dm broadcast receiver handles the intent, and schedules a runnable > in one of those process-level singletons, then returns. The whole trip > completes in milliseconds. Is this robust? Or would (for some reason) > having that singleton's processing in a service be more "correct" ? > > 3. If my singletons have a static "instance" variable, can the > object-level member variables ever be eligible garbage collection if they > are set to null at some point? > > 4. Finally I've read in this group that android re-uses linux processes > for new Application/Activities etc. to reduce overhead - in this case, what > happens to process-level static objects - do they also hang around? > > I suppose I'm really looking to see what happens under the hood at the > kernel process level, and in times of low memory if I switch > static-instance singletons to members of a service class. > > I'm coding to 2.2 APIs. > > Thanks a lot in advance for any help > On Monday, February 27, 2012 9:32:04 PM UTC-5, John Sheehy wrote: > > Hi all, > > I ported an app to android that sends and receives messages, sometimes > interactively, sometimes doing the upload/download in the background. My > app has a bunch of singletons - using the static getInstance() pattern - > that handle things such as the network, database etc. and also a bunch of > activities which access the singletons' data whenever they're visible via > getInstance() etc. Some of these singletons have Executors of small thread > pools. Also, I use C2DM to poke the app when an incoming message arrives. > > From my non-android background I wrote it so that these thread pools and > static instances would keep the process alive indefinitely, albeit non > doing any processing and hopefully using minimal amounts of memory/battery > (just so I could avoid class loading etc.). However from what I've read it > seems that maybe some of this should be in a service - I'm trying to figure > out the reasons why I should do this, as the app seems to work just fine at > the moment - I would be hugely grateful if anyone could tackle some of the > questions below: > > 1. If I leave things as they are am I more or less likely to be killed in > times of low memory? My process doesn't show up in the "Running" column, > yet I can see it in DDMS > > 2. My c2dm broadcast receiver handles the intent, and schedules a runnable > in one of those process-level singletons, then returns. The whole trip > completes in milliseconds. Is this robust? Or would (for some reason) > having that singleton's processing in a service be more "correct" ? > > 3. If my singletons have a static "instance" variable, can the > object-level member variables ever be eligible garbage collection if they > are set to null at some point? > > 4. Finally I've read in this group that android re-uses linux processes > for new Application/Activities etc. to reduce overhead - in this case, what > happens to process-level static objects - do they also hang around? > > I suppose I'm really looking to see what happens under the hood at the > kernel process level, and in times of low memory if I switch > static-instance singletons to members of a service class. > > I'm coding to 2.2 APIs. > > Thanks a lot in advance for any help > On Monday, February 27, 2012 9:32:04 PM UTC-5, John Sheehy wrote: > > Hi all, > > I ported an app to android that sends and receives messages, sometimes > interactively, sometimes doing the upload/download in the background. My > app has a bunch of singletons - using the static getInstance() pattern - > that handle things such as the network, database etc. and also a bunch of > activities which access the singletons' data whenever they're visible via > getInstance() etc. Some of these singletons have Executors of small thread > pools. Also, I use C2DM to poke the app when an incoming message arrives. > > From my non-android background I wrote it so that these thread pools and > static instances would keep the process alive indefinitely, albeit non > doing any processing and hopefully using minimal amounts of memory/battery > (just so I could avoid class loading etc.). However from what I've read it > seems that maybe some of this should be in a service - I'm trying to figure > out the reasons why I should do this, as the app seems to work just fine at > the moment - I would be hugely grateful if anyone could tackle some of the > questions below: > > 1. If I leave things as they are am I more or less likely to be killed in > times of low memory? My process doesn't show up in the "Running" column, > yet I can see it in DDMS > > 2. My c2dm broadcast receiver handles the intent, and schedules a runnable > in one of those process-level singletons, then returns. The whole trip > completes in milliseconds. Is this robust? Or would (for some reason) > having that singleton's processing in a service be more "correct" ? > > 3. If my singletons have a static "instance" variable, can the > object-level member variables ever be eligible garbage collection if they > are set to null at some point? > > 4. Finally I've read in this group that android re-uses linux processes > for new Application/Activities etc. to reduce overhead - in this case, what > happens to process-level static objects - do they also hang around? > > I suppose I'm really looking to see what happens under the hood at the > kernel process level, and in times of low memory if I switch > static-instance singletons to members of a service class. > > I'm coding to 2.2 APIs. > > Thanks a lot in advance for any help > On Monday, February 27, 2012 9:32:04 PM UTC-5, John Sheehy wrote: > > Hi all, > > I ported an app to android that sends and receives messages, sometimes > interactively, sometimes doing the upload/download in the background. My > app has a bunch of singletons - using the static getInstance() pattern - > that handle things such as the network, database etc. and also a bunch of > activities which access the singletons' data whenever they're visible via > getInstance() etc. Some of these singletons have Executors of small thread > pools. Also, I use C2DM to poke the app when an incoming message arrives. > > From my non-android background I wrote it so that these thread pools and > static instances would keep the process alive indefinitely, albeit non > doing any processing and hopefully using minimal amounts of memory/battery > (just so I could avoid class loading etc.). However from what I've read it > seems that maybe some of this should be in a service - I'm trying to figure > out the reasons why I should do this, as the app seems to work just fine at > the moment - I would be hugely grateful if anyone could tackle some of the > questions below: > > 1. If I leave things as they are am I more or less likely to be killed in > times of low memory? My process doesn't show up in the "Running" column, > yet I can see it in DDMS > > 2. My c2dm broadcast receiver handles the intent, and schedules a runnable > in one of those process-level singletons, then returns. The whole trip > completes in milliseconds. Is this robust? Or would (for some reason) > having that singleton's processing in a service be more "correct" ? > > 3. If my singletons have a static "instance" variable, can the > object-level member variables ever be eligible garbage collection if they > are set to null at some point? > > 4. Finally I've read in this group that android re-uses linux processes > for new Application/Activities etc. to reduce overhead - in this case, what > happens to process-level static objects - do they also hang around? > > I suppose I'm really looking to see what happens under the hood at the > kernel process level, and in times of low memory if I switch > static-instance singletons to members of a service class. > > I'm coding to 2.2 APIs. > > Thanks a lot in advance for any help > -- 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
