Google Play服務錯誤對話框潛在的內存泄漏？

Question

我考慮看看這個例子 https://developer.android.com/training/location/retrieve-current.html#CheckServices

這裏是有問題的代碼：

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

如果我們GooglePlayServicesUtil.getErrorDialog(..)看一看我們傳遞給this參考這恰好是一個Activity。

現在的問題是： 這會導致配置更改期間內存泄漏嗎？

我想答案取決於如何/如果GooglePlayServicesUtil.getErrorDialog(..)保持在內部參考Activity。

Answer 1

是的我的應用程序是用來泄漏

如果您有谷歌發揮服務錯誤對話框了，然後再次旋轉它會泄漏

這是我到位，以解決泄漏的解決方案，但這是假定你的谷歌在的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(); 
     } 

    } 

發揮服務檢查所以這裏的交易是我設置的getErrorDialog等於一個我自己的對話框變量，然後在onPause做一個簡單的空檢查（爲了避免可怕的空指針異常！）並打電話解僱。

我從閱讀這得到了主意，如果你想了解更多信息

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