Android Performance - 'Avoid Internal Getters/Setters'

Question

Just read this on the dev site:

Avoid Internal Getters/Setters

In native languages like C++ it\'s common practice to use getters (e.g. i = get

Answer 1

// this is faster
inner = b.innerObject

// but this won't hurt performance much because
// it's assumed that it will be rare
inner = ob.getInnerObject();

Answer 2

The performance hit of using internal getters and setters also applies to external getters and setters.

However, in the external case the getters and setters have significant benefits in other areas; e.g. preserving encapsulation, reducing harmful coupling, making your code more maintainable, and so on. So, it is generally regarded as best practice to use getters and setters despite the performance hit that this may incur.

The performance hit is a result of limitations of older Android JIT compilers. This situation improved significantly with Gingerbread (see - https://stackoverflow.com/a/4930538/139985 ... and note who wrote that answer!) and continues to improve. Indeed, in the current (2019) version of the Performance Tips, the entire section advising about internal getters and setters has been removed.

In general, it is a bad idea to "tune" your code for an inferior platform, especially if there is a reasonable chance that a better one is in the offing.

Answer 3

Although b.innerObject is faster, as the technology advances (better cpus, JIT, etc) the difference between the two options gets smaller.

The only point where it may matter is when done in intensive loops that are executed all the time. For example, in the onDraw method of a game, when you loop through hundreds of objects.

Answer 4

Keep in mind that those performance considerations are relevant only if the member in question is accessed thousands of times per second.

A good example where direct access may be a good idea is the scenegraph of a game (libgdx)

public abstract class Actor {
    public Group parent;
    public final String name;
    public boolean touchable = true;

    public float x;
    public float y;
    public float width;
    public float height;
    public float originX;
    public float originY;
    public float scaleX = 1;
    public float scaleY = 1;
    public float rotation;
    public final Color color = new Color(1, 1, 1, 1);

Answer 5

For the record, another problem with setter and getter (in Java) is they are painful ugly to use.

Let's say the next exercise, we need to modify a field insider a field of a object

In java is:

   object.getField().getSubField().setField3("hello"); // ugly

While in C# the same code is (even with encapsulation)

   object.Field.SubField.Field3="hello";  // fine

So, using public field in Java (or android) is a lot cleaner :

  object.field.subfield.field3="hello"; // fine too

Answer 6

Performance wise, there is no difference in accessing this.field or that.field.

The feeling that an instance field is more accessible to the object hosting it is just a syntax illusion.

OO wise, seriously, how complex can an Android app become? Many of the OO mantras are from building monster apps. What's the big deal if your little app uses objects like structs?

And even in a huge app, as long as it's in house, and all source code accessing a field are available for refactoring, there is no problem at all exposing the fields.