我也遇到过同样的问题。我的活动需要从一个URL解析一些数据，它很慢。所以我创建了一个线程来完成这个任务，然后显示一个进度对话框。当线程完成时，我让线程通过处理程序发布消息回UI线程。在处理程序。handleMessage，我从线程获得数据对象(现在准备好了)，并将其填充到UI。这和你的例子很相似。

经过反复试验，我似乎找到了解决办法。至少现在我可以在任何时候旋转屏幕，在线程完成之前或之后。在所有测试中，对话框都是正确关闭的，所有行为都符合预期。

我所做的如下所示。目标是填充我的数据模型(mDataObject)，然后将其填充到UI。应该允许屏幕旋转在任何时候没有意外。

class MyActivity {

    private MyDataObject mDataObject = null;
    private static MyThread mParserThread = null; // static, or make it singleton

    OnCreate() {
        ...
        Object retained = this.getLastNonConfigurationInstance();
        if(retained != null) {
            // data is already completely obtained before config change
            // by my previous self.
            // no need to create thread or show dialog at all
            mDataObject = (MyDataObject) retained;
            populateUI();
        } else if(mParserThread != null && mParserThread.isAlive()){
            // note: mParserThread is a static member or singleton object.
            // config changed during parsing in previous instance. swap handler
            // then wait for it to finish.
            mParserThread.setHandler(new MyHandler());
        } else {
            // no data and no thread. likely initial run
            // create thread, show dialog
            mParserThread = new MyThread(..., new MyHandler());
            mParserThread.start();
            showDialog(DIALOG_PROGRESS);
        }
    }

    // http://android-developers.blogspot.com/2009/02/faster-screen-orientation-change.html
    public Object onRetainNonConfigurationInstance() {
        // my future self can get this without re-downloading
        // if it's already ready.
        return mDataObject;
    }

    // use Activity.showDialog instead of ProgressDialog.show
    // so the dialog can be automatically managed across config change
    @Override
    protected Dialog onCreateDialog(int id) {
        // show progress dialog here
    }

    // inner class of MyActivity
    private class MyHandler extends Handler {
        public void handleMessage(msg) {
            mDataObject = mParserThread.getDataObject();
            populateUI();
            dismissDialog(DIALOG_PROGRESS);
        }
    }
}

class MyThread extends Thread {
    Handler mHandler;
    MyDataObject mDataObject;

    // constructor with handler param
    public MyHandler(..., Handler h) {
        ...
        mHandler = h;
    }

    public void setHandler(Handler h) { mHandler = h; } // for handler swapping after config change
    public MyDataObject getDataObject() { return mDataObject; } // return data object (completed) to caller

    public void run() {
        mDataObject = new MyDataObject();
        // do the lengthy task to fill mDataObject with data
        lengthyTask(mDataObject);
        // done. notify activity
        mHandler.sendEmptyMessage(0); // tell activity: i'm ready. come pick up the data.
    }
}

这对我来说很有效。我不知道这是否是Android设计的“正确”方法——他们声称这种“在屏幕旋转期间破坏/重建活动”实际上使事情变得更简单，所以我猜这应该不是太棘手。

如果您在我的代码中发现问题，请告诉我。如上所述，我真的不知道是否有任何副作用。

我发现了一个我还没有在其他地方见过的解决方案。你可以使用一个自定义应用程序对象，它知道你是否有后台任务在进行，而不是试图在活动中做这件事，在方向改变时被销毁和重新创建。我在这里写过博客。

当你切换方向时，Android会创建一个新的View。你可能会崩溃，因为你的后台线程试图改变旧线程的状态。(它也可能有麻烦，因为你的后台线程不在UI线程上)

我建议将mHandler设为volatile，并在方向改变时更新它。

对于这些问题，我想出了一个坚如磐石的解决方案，它符合“Android方式”。我使用IntentService模式进行所有长时间运行的操作。

也就是说，我的活动广播意图，IntentService负责工作，将数据保存在DB中，然后广播粘性意图。粘性部分很重要，即使Activity在用户启动工作后暂停，并且错过了来自IntentService的实时广播，我们仍然可以响应并从调用Activity中获取数据。progressdialog可以很好地使用onSaveInstanceState()与此模式一起工作。

Basically, you need to save a flag that you have a progress dialog running in the saved instance bundle. Do not save the progress dialog object because this will leak the entire Activity. To have a persistent handle to the progress dialog, I store it as a weak reference in the application object. On orientation change or anything else that causes the Activity to pause (phone call, user hits home etc.) and then resume, I dismiss the old dialog and recreate a new dialog in the newly created Activity.

对于无限进度对话框来说，这很容易。对于进度条样式，您必须将最后一个已知的进度放在bundle中，并将您在活动中本地使用的任何信息用于跟踪进度。在恢复进度时，您将使用此信息以与之前相同的状态重新生成进度条，然后根据当前状态进行更新。

总之，将长时间运行的任务放到IntentService中，再加上明智地使用onSaveInstanceState()，可以让你有效地跟踪对话框，并在活动生命周期事件中恢复对话框。活动代码的相关部分如下。您还需要BroadcastReceiver中的逻辑来适当地处理Sticky意图，但这超出了本文的范围。

public void doSignIn(View view) {
    waiting=true;
    AppClass app=(AppClass) getApplication();
    String logingon=getString(R.string.signon);
    app.Dialog=new WeakReference<ProgressDialog>(ProgressDialog.show(AddAccount.this, "", logingon, true));
    ...
}

@Override
protected void onSaveInstanceState(Bundle saveState) {
    super.onSaveInstanceState(saveState);
    saveState.putBoolean("waiting",waiting);
}

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    if(savedInstanceState!=null) {
        restoreProgress(savedInstanceState);    
    }
    ...
}

private void restoreProgress(Bundle savedInstanceState) {
    waiting=savedInstanceState.getBoolean("waiting");
    if (waiting) {
        AppClass app=(AppClass) getApplication();
        ProgressDialog refresher=(ProgressDialog) app.Dialog.get();
        refresher.dismiss();
        String logingon=getString(R.string.signon);
        app.Dialog=new WeakReference<ProgressDialog>(ProgressDialog.show(AddAccount.this, "", logingon, true));
    }
}

这是一个非常古老的问题，出于某种原因出现在侧栏上。

如果后台任务只需要在活动处于前台时存活，“新的”解决方案是在保留的片段中托管后台线程(或者，最好是AsyncTask)，如本开发指南和大量q&a中所述。

如果活动因配置更改而被销毁，则保留的片段将继续存在，但当活动在后台或后台堆栈中被销毁时则不存在。因此，如果onPause()中的isChangingConfigurations()为false，后台任务仍然应该被中断。

最初的问题是代码无法在屏幕方向改变时存活下来。显然，这是“解决”的程序处理屏幕方向变化本身，而不是让UI框架做它(通过调用onDestroy)。

I would submit that if the underlying problem is that the program will not survive onDestroy(), then the accepted solution is just a workaround that leaves the program with serious other problems and vulnerabilities. Remember that the Android framework specifically states that your activity is at risk for being destroyed almost at any time due to circumstances outside your control. Therefore, your activity must be able to survive onDestroy() and subsequent onCreate() for any reason, not just a screen orientation change.

如果你要接受自己处理屏幕方向变化来解决OP的问题，你需要验证onDestroy()的其他原因不会导致相同的错误。你能做到吗?如果不是，我会质疑这个“公认的”答案是否真的是一个很好的答案。