2014-09-11 2 views
2

Je suis jeter un oeil à cet exemple https://developer.android.com/training/location/retrieve-current.html#CheckServicesMessage d'erreur Google Play Services fuite de mémoire potentielle?

Voici le code en question:

public class MainActivity extends FragmentActivity { 
    ... 
    private boolean servicesConnected() { 
     ... 
     if (ConnectionResult.SUCCESS == resultCode) { 
      ... 
      // Google Play services was not available for some reason. 
      // resultCode holds the error code. 
     } else { 
      // Get the error dialog from Google Play services 
      Dialog errorDialog = GooglePlayServicesUtil.getErrorDialog(
       resultCode, 
       this, 
       CONNECTION_FAILURE_RESOLUTION_REQUEST); 
      ... 
     } 
    } 
} 

Si nous jetons un coup d'œil à GooglePlayServicesUtil.getErrorDialog(..) nous passons une référence à this qui se trouve être un Activity.

La question est: Est-ce que cela causerait une fuite de mémoire lors d'un changement de configuration?

Je suppose que la réponse dépend de comment/si GooglePlayServicesUtil.getErrorDialog(..) conserve la référence à Activity en interne.

Répondre

1

Yep sur mon application il utilisé pour fuir

Si vous avez la boîte de dialogue d'erreur des services Google Play et puis faites tourner à nouveau il fuira

Ceci est la solution que je mets en place pour résoudre la fuite mais cela suppose que votre chèque services Google Play est en onResume

public class MainActivity extends Activity 
{ 
private Dialog googlePlayErrorDialog; 

@Override 
    protected void onResume() 
    { 
     // TODO Auto-generated method stub 
     super.onResume(); 
     int isAvaiable = GooglePlayServicesUtil.isGooglePlayServicesAvailable(this); 
     if(isAvaiable == ConnectionResult.SUCCESS) 
     { 
      Log.d("TEST", "GPS IS OK"); 
     } 
     else if(isAvaiable == ConnectionResult.SERVICE_MISSING || 
       isAvaiable == ConnectionResult.SERVICE_VERSION_UPDATE_REQUIRED || 
       isAvaiable == ConnectionResult.SERVICE_DISABLED) 
     { 
      googlePlayErrorDialog = GooglePlayServicesUtil.getErrorDialog(isAvaiable, this, 10); 
      googlePlayErrorDialog.show(); 

     } 

    } 

    @Override 
    protected void onPause() 
    { 
     // TODO Auto-generated method stub 
     super.onPause(); 
     if(googlePlayErrorDialog != null) 
     { 
      googlePlayErrorDialog.dismiss(); 
     } 

    } 

donc, l'affaire est là que je mets le getErrorDialog égal à ma propre variable de dialogue puis en OnPause effectuer un simple contrôle nul (pour éviter NullPointerException redoutée !) et appel rejeter .

j'ai eu l'idée de lire si vous voulez plus d'informations

http://publicstaticdroidmain.com/2012/01/avoiding-android-memory-leaks-part-1/

+0

Cela résout la fuite de mémoire, mais il est une expérience utilisateur médiocre. Changer ce qui est à l'écran lors d'un changement de configuration est une expérience utilisateur médiocre. –

+0

Ce serait mauvais si la boîte de dialogue ne devait pas apparaître exactement comme avant la modification de la configuration. C'est là que onResume entre en jeu. Dans cet exemple, c'est bien parce que la boîte de dialogue GPS réapparaît de toute façon. Pour les autres boîtes de dialogue, il suffit de paramétrer un booléen si la boîte de dialogue est affichée, puis de l'afficher à nouveau via le bouton Reprendre et restaurer les variables via onSavedInstanceState que l'utilisateur modifie dans la boîte de dialogue. C'est pourquoi je préfère que le code de dialogue dans cette méthode privée rende les choses plus faciles et plus organisées – user3364963