> If the broadcast needs to launch any .apks, it gets serialized so that only > one .apk is launched at a time.
Thanks for the detailed info. This is good news. ((ok, now the only problem I see in my use case is if those broadcast receivers launch services to continue their work, and then a couple of services have to struggle for memory concurrently - but there is probably not much the platform can do about that. Probably it is best if each service indicates when it is done, so that the next apk can be launched by the main program through an apk specific broadcast)) Peli On Jul 15, 8:36 pm, Dianne Hackborn <[email protected]> wrote: > On Wed, Jul 15, 2009 at 10:59 AM, Peli <[email protected]> wrote: > > I have the following follow-up question: > > Even for small apks (single broadcast receiver, few lines of code), > > top shows a few MB of memory usage. Is there a rule of thumb how much > > of this is shared and how much is approximately due to the apk? > > Well take for example the alarm clock running, which I haven't launched > myself but whose process got launched from a broadcast at some point, so > shouldn't have done a whole lot: > > 217 10496K 10496K 2177K 1400K com.android.alarmclock > > That's almost 1.5MB purely owned by the process and immediately made > available if the process is killed; the extra .6MB (bring us up to 2MB pss) > is shared memory, so it won't be available if the process is killed. > > Considering the amount of memory on the device, a process is a > super-expensive object. You really want to avoid using extra processes > where you don't need to, and this is why I am so adamant about people not > leaving a process sitting there running in the background forever. (In fact > there just isn't the memory to allow for that, so by the time we got to 1.0 > the system became quite aggressive about killing long-running processes, > even if they contain actively running services, to be able to keep the > overall experience decent.) > > Oh and for the shared memory, you need to be careful in interpreting the > numbers -- it's not really .6MB that is shared, this has been weighted by > the number of processes sharing it. So given this device currently has 13 > Java processes running in it, you can figure that there is around 8MB that > we manage to share from zygote into the Java processes. Thank ghod for > zygote. :) > > (I'm especially interested in the situation where there is one main > > > program that sends a broadcast to several apks. Would this scale well, > > or would this quickly fill up the memory, even if the individual apks > > are small (since all broadcast receivers would be called > > concurrently)). > > If the broadcast needs to launch any .apks, it gets serialized so that only > one .apk is launched at a time. Trying to just blindly launch a bunch of > apps to receive the broadcast would be very painful. :) > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
