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 = getCount()) instead of accessing the field directly (i = mCount). This is an excellent habit for C++, because the compiler can usually inline the access, and if you need to restrict or debug field access you can add the code at any time.
On Android, this is a bad idea. Virtual method calls are expensive, much more so than instance field lookups. It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly.
Without a JIT, direct field access is about 3x faster than invoking a trivial getter. With the JIT (where direct field access is as cheap as accessing a local), direct field access is about 7x faster than invoking a trivial getter. This is true in Froyo, but will improve in the future when the JIT inlines getter methods.
Update in 2019/05: In the current version, the above material has been removed from the document!
So is it saying you would use field access within the class:
public class MyObject { public Object innerObject; // This would be private if I was using a getter public void doSomeStuff(){ if(innerObject){ // Within class access like this // .... } } public Object getInnerObject(){ // This would be removed if I was using field access return innerObject; } }
But what about access from another object?:
public class SecondObject { public void doSecondSomething(){ MyObject ob = new MyObject(); Object inner; //This is my question basically (from an Android performance perspective) inner = ob.getInnerObject(); // OR inner = b.innerObject } }
Thus: you avoid getters and setters by thinking in terms of behavior, not in terms of state. Getters/setters manipulate state, from the "outside" (by doing avail = purse.
Using getters and setters, is always, in my opinion good practice. One thing you should avoid is to have external entities mess with the internal structure of your class at will. Typical example, consider having a dateOfBirth parameter.
The reason for declaring the getters and setters private is to make the corresponding part of the object's abstract state (i.e. the values) private. That's largely independent of the decision to use getters and setters or not to hide the implementation types, prevent direct access, etc.
If your class is going to be used in the environment where setter is not required (e.g. ORM / dependency injection / serialization frameworks), it should be OK to do not use setter. In this particular case setter does not make much sense since variable is final and set only once.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With