One of the use cases that application developers tend to ignore or deal at last is the case where in Android kills the application process when it is in background and there is a need for memory to launch or resume other applications. In an ideal scenario, the state saved in Activity's and Fragment's onSaveInstanceState should be good enough to restore the application to its last known state as and when the user resumes the application (after a kill). Nevertheless, it has to be verified in a development environment.
So how are application developers supposed to test this case? Android's low memory killer works on a pre defined threshold values to decide when to kick in and start killing least important process. This pre defined threshold usually does't come into play when user is dealing with one application, which is most often the case with developers working on their app. So the obvious solution is to fine tune these values to cause the low memory killer to be more aggressive. However, this would need a platform change, rebuild of the system image and flashing it on to a device. This might seem too much of a work just to test one use case and specially for application developers.
So the easiest alternative to simulate a low memory kill is to pause the application as usual and push it to background and then kill the application process from adb shell (Android's emulator's shell supports killing of process). In this case, android would have saved the state of the application as soon as it was being paused and it doesn't really care as to how the process is killed. Now as and when the user resumes the application via Recent apps list, Android would pass on the saved state to the application and the overall functional behavior is as good as a low memory kill.
So how are application developers supposed to test this case? Android's low memory killer works on a pre defined threshold values to decide when to kick in and start killing least important process. This pre defined threshold usually does't come into play when user is dealing with one application, which is most often the case with developers working on their app. So the obvious solution is to fine tune these values to cause the low memory killer to be more aggressive. However, this would need a platform change, rebuild of the system image and flashing it on to a device. This might seem too much of a work just to test one use case and specially for application developers.
So the easiest alternative to simulate a low memory kill is to pause the application as usual and push it to background and then kill the application process from adb shell (Android's emulator's shell supports killing of process). In this case, android would have saved the state of the application as soon as it was being paused and it doesn't really care as to how the process is killed. Now as and when the user resumes the application via Recent apps list, Android would pass on the saved state to the application and the overall functional behavior is as good as a low memory kill.
No comments:
Post a Comment