I was recently asked some questions in an interview about Android. I searched for some of them but I couldn't find the suitable resources and answers. So I wanted to share it with you here.
What is the preferred layout to use in Android ( for Better memory consumption or so ) ? I didn't have answer for that and the interviewer told me it is relative layout. Is this true ? any explanation for that ?
Tell me some practices you do for better memory consumption ? I had a look here but it seems there are other stuff. because the interviewer mentioned some things related to static variables are better.
If Android needs memory, will it kill a service or Activity ? a matter of priority issue. I also didn't find any one discussing this. The interviewer said some thing about Service has high priority (??) than activity so the activity is the component which will be killed. Is this true ? any further resources or explanations ?
Kindly share any knowledge or resources you know about this issues.
Answering one by one:
Nr. 1
Sounds wrong. It's wrong to say that RelativeLayout is always faster than any other layout. What makes a layout "fast" or "slow" is how long it takes to calculate the positions and sizes for all it's children. So when you're only displaying 15 rows of TextView, one below the other, a LinearLayout would most certainly be faster (and less cumbersome to use).
Generally, I would advice to use the layout that best suites your situation.
Nr. 2
Preferring static variables has the "advantage" that they are initialized (and therefor in memory) only once. But this is more of a design decision than a performance one.
You should avoid huge nested collections in memory (such as List<List<HashMap<?,?>>), but this should really be common sense. The thing with object creation is, that if you create many objects and don't keep any references to them, they'll get garbage collected. This will add runtime-overhead to your application.
Nr. 3
This is both right and wrong. Services can be started with different priorities. But, before anything used by your application (be it a service or an activity) gets killed, backgrounded applications and their resources will be freed.
For Services, the documentation gives multiple hints:
The Android system will attempt to keep the process hosting a service around as long as the service has been started or has clients bound to it. When running low on memory and needing to kill existing processes, the priority of a process hosting the service will be the higher of the following possibilities: [Full List]
On Activities, the following is listed:
An activity has essentially four states:
If an activity in the foreground of the screen (at the top of the stack), it is active or running.
If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.
So, for Activities, it depends on the current state how likely it is for it to be killed.
Conclusion
A quote on optimization by "M. A. Jackson":
We follow two rules in the matter of optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.
Not using a particular platform feature because it is "too slow" is often a bad idea. Google and Oracle take great care that their standard libraries are as optimized as possible. Let the experts worry about things like this.