Clases internas: Android vs Java

Question

Soy consciente de que las clases internas no se recomiendan en Android porque contienen una referencia a la clase adjunta. Sin embargo, en Java, la clase externa solo se GCed cuando ya no se hace referencia a la clase interna. Eso significa que, en Android, siempre que tenga una referencia no estática en la clase de actividad externa para la clase interna, la clase interna no puede existir más tiempo que la clase de actividad externa porque la actividad solo se puede destruir si no contiene una referencia a la clase interna más (al menos eso es lo que estoy deduciendo). Entonces, ¿cuál es el problema al usar clases internas no estáticas (dado que obviamente no pueden existir más tiempo que la actividad externa si inferimos de Java)? ¿Me estoy perdiendo de algo?

Gracias!

Answer 1

consideran este sencillo ejemplo

class Leaker 
{ 
    public static Object leakedObj; 
} 

class MyActivity extends Activity 
{ 
    public class MyInnerClass { ... } 

    void onCreate(Bundle savedState) 
    { 
     Leaker.leakedObj = new MyInnerClass(); 
     //The activity now won't be GCed until Leaker.leakedObj is cleared.   
    } 
} 

Puede pasar fácilmente de una clase no estática interna fuera del contexto de su actividad. Siempre y cuando no pases tu clase interna a objetos fuera del ciclo de vida de tu actividad, deberías estar bien. Pero ciertamente es posible filtrar su actividad a través de una clase interna.

Answer 2

No me molestaré en parafrasear, porque Google puede explicarlo mejor.

Suponiendo: Clase de los padres es Foo y clase interna es Foo$Inner:

El problema es que la máquina virtual considera que el acceso directo a los miembros privados de Foo de Foo $ Interno ser ilegal porque Foo y Foo $ Interior distintas clases, aunque el lenguaje Java permite que una clase interna acceda a miembros privados de una clase externa. Para cerrar la brecha, el compilador genera un par de métodos sintéticos:

/*package*/ static int Foo.access$100(Foo foo) { 
    return foo.mValue; 
} 
/*package*/ static void Foo.access$200(Foo foo, int value) { 
    foo.doStuff(value); 
} 

El código de clase interna llama a estos métodos estáticos cada vez que necesita para acceder al campo mvalue o invocar el método hacerTarea en la clase externa. Lo que esto significa es que el código anterior realmente se reduce a un caso en el que está accediendo a los campos de miembros a través de métodos de acceso. Anteriormente hablamos sobre cómo los accessors son más lentos que los accesos directos a los campos, por lo que este es un ejemplo de un idioma determinado que resulta en un golpe de desempeño "invisible".

Si está utilizando un código como este en un punto de acceso de alto rendimiento, puede evitar la sobrecarga declarando campos y métodos a los que acceden las clases internas para tener acceso a paquetes, en lugar de acceso privado. Desafortunadamente, esto significa que se puede acceder directamente a los campos por otras clases en el mismo paquete, por lo que no debe usar esto en la API pública.

Fuente: https://developer.android.com/training/articles/perf-tips.html#PackageInner