[Sugar-devel] Killing activities when memory gets short

NoiseEHC NoiseEHC at freemail.hu
Mon Aug 9 09:44:23 EDT 2010


> Sugar has a similar mechanism. From the Low-level Activity API docs:
>
> org.laptop.Activity.SetActive(b: active)
> Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore.
>
> The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... 
>
> Maybe "good" activities could "volunteer" to be shut down first. Or "bad" activities would have to "beg" to live a little longer. Might just take an entry in the activity.info file.
>   

It will not work, because the application startup time is horrible on 
the XO. The Dalvik VM goes a loooong way to have fast application 
startup and to share most of the memory among applications (the Zygote 
process does this). Actually that was the exact thing I tried to do with 
the Python VM. Just at the exact time when I started to hack Python I 
have seen the Google I/O video about the Dalvik VM and thought that 
duplicating that work would have been a waste of time. So if you wanna 
fix the Python VM, good luck, but you know it is already been coded... 
:) Without fast activity startup, killing activities will be a horrible 
user experience. Maybe not that bad as a totally unresponsive XO though.


> (*) Apple seems to have foreseen this "developer psychology" issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it.
>   

All of them. If an Android application does not implement it correctly 
then there will be big problems while switching apps and while 
navigating among application screens.



More information about the Sugar-devel mailing list