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.
