[Sugar-devel] Killing activities when memory gets short

[Lucian Branescu]

On 9 August 2010 14:44, NoiseEHC <NoiseEHC at freemail.hu> wrote:
>
>> 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.

It wouldn't be a duplication of efforts since Dalvik does not run
Python and it is unlikely that it ever will. Perhaps a simple fork
zygote for python wouldn't be that hard to accomplish in the sugar
shell.

>
>> (*) 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.