Android 谷歌播放服务错误对话框潜在内存泄漏？

我来看看这个例子

以下是相关代码：

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（..）

，我们将传递一个对

此

的引用，它恰好是一个

活动

问题是: 这会在配置更改期间导致内存泄漏吗？

---

我想答案取决于/if

GooglePlayServicesUtil.getErrorDialog（..）

如何在内部保留对

活动的引用。
是的，在我的应用程序中，它曾经泄漏过

如果你有谷歌播放服务错误对话框，然后再次旋转它会泄漏

这是我为解决泄漏问题而制定的解决方案，但前提是您的Google play服务检查已在恢复中

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设置为一个我自己的dialog变量，然后在onPause中执行一个简单的空检查（以避免可怕的空指针异常！）并调用dismise

如果你想了解更多的信息，我是从阅读这篇文章中得到这个想法的

这解决了内存泄漏问题，但用户体验不佳。在配置更改过程中更改屏幕上的内容是一种糟糕的用户体验。如果对话框的显示方式与配置更改前不完全相同，则会很糟糕。这就是onResume的用武之地。在本例中，这很好，因为无论如何GPS对话框都会再次出现。对于其他对话框，如果对话框显示，只需设置一个布尔值，然后通过on Resume再次显示，并通过onSavedInstanceState恢复变量即可说明用户在对话框中所做的更改。这就是为什么我更喜欢在这个私有方法中使用对话框代码，使事情变得更容易和有组织