Rendimiento Android - 'Evitar interna getters/setters'

Question

Basta con leer esto en el sitio dev:

Avoid Internal Getters/Setters

En lenguas nativas como C++ es una práctica común utilizar captadores (por ejemplo, i = getCount()) en lugar de acceder al campo directamente (i = mCount). Este es un hábito excelente para C++, ya que el compilador generalmente puede alinear el acceso, y si necesita restringir o depurar el acceso al campo, puede agregar el código en cualquier momento.

En Android, esta es una mala idea. Las llamadas a métodos virtuales son costosas, mucho más que las búsquedas de campo de instancias. Es razonable seguir prácticas comunes de programación orientada a objetos y tener getters y setters en la interfaz pública, pero dentro de una clase siempre se debe acceder directamente a los campos.

Sin un JIT, el acceso directo al campo es aproximadamente 3 veces más rápido que invocar un getter trivial. Con el JIT (donde el acceso directo en el campo es tan barato como acceder a un local), el acceso directo al campo es aproximadamente 7 veces más rápido que invocar un getter trivial. Esto es cierto en Froyo, pero mejorará en el futuro cuando el JIT incorpore métodos getter.

Así que está diciendo que usaría el acceso de campo dentro de la clase:

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; 
    } 
} 

Pero ¿qué pasa con el acceso de otro objeto:?

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 

     } 

} 

Answer 1

El impacto en el rendimiento de la utilización de captadores y definidores internos también se aplica a captadores y definidores externos.

Sin embargo, en el caso externo los getters y setters tienen beneficios significativos en otras áreas; p.ej. preservando la encapsulación, reduciendo el acoplamiento dañino, haciendo que su código sea más fácil de mantener, y así sucesivamente. Por lo tanto, generalmente se considera como mejor práctica utilizar getters y setters a pesar del impacto en el rendimiento que esto pueda ocasionar.

El golpe de rendimiento es un resultado de las limitaciones de la generación actual de compiladores JIT de Android anteriores. Esta situación seguramente mejorará ha mejorado con Gingerbread. (Referencia - https://stackoverflow.com/a/4930538/139985 ... y tenga en cuenta quién escribió esa respuesta!)

En general, es una mala idea "ajustar" su código para una plataforma inferior, especialmente si hay una posibilidad razonable de que una mejor esté a la vista.

Answer 2

// 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 3

Aunque b.innerObject es más rápido, a medida que avanza la tecnología (mejor CPU, JIT, etc.) la diferencia entre el dos opciones se hacen más pequeñas

El único punto donde puede importar es cuando se realiza en ciclos intensivos que se ejecutan todo el tiempo. Por ejemplo, en el método onDraw de un juego, cuando recorre cientos de objetos.

Answer 4

Tenga en cuenta que esas consideraciones de rendimiento son relevantes solo si se accede al miembro en cuestión miles de veces por segundo.

Un buen ejemplo donde el acceso directo puede ser una buena idea es la scenegraph de un juego (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

Getters y Setters siempre tienen una sobrecarga, ya que son llamadas a funciones. Cuando está en el mismo objeto, puede optimizar su código al no usarlo, ya que sabe para qué se utiliza y no necesita abstraerlo/encapsularlo de su propio objeto.

Creo que también hay que mirarlo desde una perspectiva diferente:

1. a no quieren tener un captador/definidor romper las prácticas comunes Oops? No querrá tener referencias directas si está creando objetos/módulos que otros usarán.

2. Realmente no desea utilizar getters/setters demasiadas veces como al final, a menos que el sh! * Sea optimizado fuera de las llamadas de función tendrá sobrecarga.

Usted realmente necesita para optimizar de forma percase, si yo estoy construyendo dos módulos donde algunos componentes son accesibles únicamente por sí podría hacer un campo estático demás que se adherirá a getters/setters

Answer 6

En cuanto a rendimiento, no hay diferencia en el acceso a this.field o that.field.

La sensación de que un campo de instancia es más accesible para el objeto que la aloja es solo una ilusión de sintaxis.

OO sabio, en serio, ¿cuán compleja puede ser una aplicación para Android? Muchos de los mantras de OO provienen de la construcción de aplicaciones de monstruos. ¿Cuál es el problema si su pequeña aplicación usa objetos como estructuras?

E incluso en una gran aplicación, mientras esté en casa, y todo el código fuente que accede a un campo está disponible para la refactorización, no hay ningún problema en exponer los campos.

Answer 7

Para el registro, otro problema con setter y getter (en Java) es que son dolorosamente feo de usar.

Digamos que el siguiente ejercicio, tenemos que modificar una información privilegiada campo de un campo de un objeto

en Java es:

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

Mientras que en C# el mismo código es (incluso con la encapsulación)

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

por lo tanto, utilizando el campo público en Java (o androide) es mucho más limpio:

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