Develop Reference

Android performance: useless global variables vs inheritance

Let's say I have an object A and B that extends A.
B has global variables that are irrelevant for A (an array, and a few counters).
Since explicit casting is costly (I'm not sure how much), would it be better, from a sheer performance pov, to only create a class A and create an array only if needed so that I don't have to cast?
I guess the question is, do global variables of an object cost anything at all, even if unused?
Edit: forgot to add the most important... functions, obviously.

In recent years, inheritance is often treated like code-smell, because it can lead to different problems:
https://dzone.com/articles/is-inheritance-dead
If we talk in pure performance term, an empty array takes about 8 bytes in RAM (4 bytes store length and 4 bytes a reference, but it is a little platform-dependent: How much space does an array occupy?). So, even if you have a thousand of such objects, one array field will take approximately 1_000 * 8 bytes ~ 8 KBytes in RAM.
As you probably know, nowadays phones usually contain > 1 GByte of RAM. However, don't forget that your app usually can take from 60 to 192 MBytes of RAM (Detect application heap size in Android).
In any case, it is more than enough not to count every little field that you are adding to your class.
However, going back to my first statement, I suggest you to think about solving the problem using composition instead of inheritance, as it is suggested in Effective Java
Update
About performance, I would suggest you to read this topic: The performance impact of using instanceof in Java Are you sure that you need such type of premature optimization? Or is it more a theoretical question than practical?

Obviously, No, don't blend both classes in one class A. Never. as you mentioned, the array is irrelevant to class A. so don't put it to A.
next, in your case, downcasting is a point that tells: Wait programmer, do you want to think a little more? sometimes, there is a solution that does not need downcasting. but
Since explicit casting is costly
I don't think so. There is some benchmark and expansions that tells us, no there is no huge difference here.
expansion
benchmark
So. follow the first solution...

Since explicit casting is costly (I'm not sure how much), would it be
better, from a sheer performance pov, to only create a class A and
create an array only if needed so that I don't have to cast?
Besides the dubious claim about the cost of casting, maybe I'm misunderstanding but that raised red flags for me. If your design involves casting an object to a subclass it could probably be better designed in some other way. I can't say what without seeing more, but the need to cast is often a sign of design failure*. As Gaket suggests, composition could be better, or there might be some other change - factory pattern perhaps?
Secondly, you should only be concerned about performance if you have noticed a performance issue, or have a real reason to think there will be one. Almost anything the processor does is going to be plenty fast unless it's done many times over (like millions). Your performance issues (unless your program is unusual in some way) are most likely going to be I/O or memory. Then after you're identified a performance bottleneck, the steps to fix it are:
measure
set a goal
fix
measure
Don't leave out any steps.
*I know casting is a central part of Android programming because you have to cast Views every time you get them, and I wonder if there might have been a better way to do that, but that's what we're stuck with

why does reflection slow down android phone

I read many times that reflection will slow down the phone performance.
How true is this?
For example in my case, I get some parameters from a web service which have the same name as the parameters of a class I have in my android app. so I just set the values of these parameters using java fields and reflection... it doesn't seem to slow down the performance..
can anybody explain to me the fact behind this idea about reflection slowing down performance?

Take a look at this question. Basically, you are getting outside of the optimizations that the compiler can perform because reflection happens dynamically.
If you're not making a lot of reflection calls (e.g., it would be bad to do inside the getView of a ListView), you can probably get away with it. It's there to be used, just be judicious about it.

how true is this?
It is slower than not using reflection. It is definitely something you want to avoid in loops or during rapid UI processing (e.g., scrolling a ListView).
i get some parameters from a web service which have the same name as the parameters of a class i have in my android app. so i just set the values of these parameters using java fields and reflection... it doesn't seem to slow down the performance..
It does, though it may not be noticeable to the user in this case.
can anybody explain to me the fact behind this idea about reflection slowing down performance?
See the link provided by #Brian Cooley in his answer. Bear in mind that reflection on Dalvik (the virtual machine in Android) may be slower than reflection on the Java VM -- I am really rather certain it is not faster, at any rate.

Is using Serializable in Android bad?

I've been reading a lot of posts and articles extolling the speed of Parcelable over Serializable. I've been using both for a while to pass data between Activities through Intents, and have yet to notice any speed difference when switching between the two. The typical amount of data I have to transfer is 5 to 15 nested objects with 2 to 5 fields each.
Since I have about 30 classes which must be transferable, implementing Parcelable requires a lot of boilerplate code that adds maintenance time. One of my current requirements is also that the compiled code should be as small as possible; I expect that I could spare some space by using Serializable over Parcelable.
Should I use Parcelable or is there no reason to use it over Serializable for such small amounts of data? Or is there another reason why I shouldn't use Serializable?

For in-memory use, Parcelable is far, far better than Serializable. I strongly recommend not using Serializable.
You can't use Parcelable for data that will be stored on disk (because it doesn't have good guarantees about data consistency when things change), however Serializable is slow enough that I would strongly urge not using it there either. You are better off writing the data yourself.
Also, one of the performance issues with Serializable is that it ends to spin through lots of temporary objects, causing lots of GC activity in your app. It's pretty heinous. :}

Continue to use Serialization. You'll see lots of people online who will tell you that Serialization is very slow and inefficient. That is correct. But, one thing you never want to do as a computer programmer is take any comment about performance as an absolute.
Ask yourself if serialization is slowing your program down. Do you notice when it goes from activity to activity? Do you notice when it saves/loads? If not, it's fine. You won't get a smaller footprint when you go to a lot of manual serialization code, so there is no advantage there. So what if it is 100 times slower than an alternative if 100 times slower means 10ms instead of 0.1ms? You're not going to see either, so who cares? And, why would anyone invest massive effort into writing manual serialization for 30 classes when it won't make any perceptible difference in performance?

Everybody just blindly states that Parcelable is better and faster, than Serializable, but nobody has tried to support his statements with any proofs. I decided to test this myself and I got very interesting results.
Usual Java serialization on an average Android device (if done right) is about 3.6 times faster than Parcelable for writes and about 1.6 times faster for reads.
You can check my test project here: https://github.com/afrish/androidserializationtest

Has anyone considered serialization using JSON and passing the data as a string? GSON and Jackson should be efficient enough to be a competitor to Parcelable as well as Serializable.

android, object oriented programing vs designing for performance

I am a complete noob to android but I have been programing c# for a long time. I am writing an android application and have gotten to a point where the c# programmer in me wants to start creating a loosely coupled design and and moving code into different layers, using interfaces, etc.
But then I stumble upon the Designing for performance guidelines it is telling me to avoid object creation and then it also is saying to optimize judicially.
Do I just build based on good design and then deal with performance issues as they come up?
The last thing I want to do is go through the work of building a application and have it perform poorly. Can someone point me to some examples of application that are designed well and have good performance or just make some recommendations?
Thanks

I've found AndEngine to be fairly well designed and it has to be concerned with performance since it is a game development library -- so you might pull down a copy of it and read the source.
In the "Designing for performance" document, I would point out this statement:
Note that although this document
primarily covers micro-optimizations,
these will almost never make or break
your software. Choosing the right
algorithms and data structures should
always be your priority, but is
outside the scope of this document.
An example of this would be creating a particle system. A good way to model it is to have a ParticleSystem object that holds a collection of Particle objects...maybe those Particles implement a Particle interface...this is not the place to avoid object creation. However, for performance reasons, you will want to optimize the ParticleSystem to recycle Particle objects rather than creating them from scratch every time you spawn one.
Personally, I haven't found performance to be much of a limiting factor but I suppose that will really depend on what type of app you're building.
My opinion is to build a suitable design first, test the performance, and optimize from there.

Pay more attention to Donald Knuth's quote that appear in the same article:
"We should forget about small
efficiencies, say about 97% of the
time: premature optimization is the
root of all evil.root of all evil."
Then if you are dealing with the other 3% you'll see...

As a general rule, the thing to do is keep the data structure as simple and normalized as you can. Like don't just throw in hash table data structures just because they are easy to grab. Know how to do profiling (here's my method) and if you have a real performance problem then fix it. Otherwise, the simpler the better, even if that means simple arrays, lists, and O(N) loops.
The reason to keep the data structure normalized is, if it is not, then it can have inconsistent states, and you will have a strong temptation to write notification-style code to try to keep it consistent. Those can be real performance killers. If you do those, the profiling will tell you it that's what is happening.
If you must have redundant data, I think it's better to be able to tolerate some temporary inconsistency, that you periodically repair by passing through the data. This is better than trying to intensely guarantee consistency at all times by notifications.
Another problem with unnormalized data structure is it can have lots of object creation and destruction. That also can be a real performance killer, although you can ameliorate it with the pool technique.

how do "saved states" work? (Android)

I just read a pretty interesting article on how android (and i assume other OSs) work when low on memory. How is this done theoretically? Is it similar to Java's object serialization?

In a word: yes.
In a few more words, sort of. You have to handle more of it manually than personally I'd like. Essentially, all Android provides for you is a hash to shove a few serializable objects, referenced by strings, that is guaranteed to be safe across application shutdowns. So, whenever something happens that you'd like to preserve across a shutdown of your application, you are responsible for updating this saved state hash (and letting Android know that you've done so). This includes things like half-finished text entry in form fields. That means you have a lot to listen to.
Android will then call a particular hook in your Activity that handles restoring state to the Activity when it recycles your application and you need to do so. This doesn't happen for all recycles — there are various states of being/existence for your application.
The screwy part is that because you're expected to do this sort of tedious work anyway, Android gets lazy and implements things like screen rotation as a full recycle of your application.
I'm making it sound worse than it really is once you get used to it; it's really not a bad way of solving the problem in the confines of Java and mobile computing.
Of course, this is a response regarding Android. Other (desktop) OS's rely on Virtual Memory and Paging to deal with memory constraints.