我想我找到了答案。让我简单地说一下我做了什么：

假设我有两个活动，即活动1和活动2，我正在从活动1导航到活动2（我在活动2中做了一些工作），然后通过单击活动1中的按钮再次返回活动1。现在在这个阶段，我想回到活动2，我想看到我的活动2处于上次离开活动2时的相同状态。

对于上述场景，我所做的是在清单中进行了如下更改：

<activity android:name=".activity2"
          android:alwaysRetainTaskState="true"      
          android:launchMode="singleInstance">
</activity>

在活动1的按钮点击事件中，我这样做了：

Intent intent = new Intent();
intent.setFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);
intent.setClassName(this,"com.mainscreen.activity2");
startActivity(intent);

在活动2的按钮点击事件中，我这样做了：

Intent intent=new Intent();
intent.setClassName(this,"com.mainscreen.activity1");
startActivity(intent);

现在将要发生的是，我们在activity2中所做的任何更改都不会丢失，并且我们可以以与之前相同的状态查看activity2。

我相信这就是答案，这对我来说很好。如果我错了，请纠正我。

现在，在视图模型中使用两种方法是有意义的。如果要将第一个保存为保存的实例：您可以像这样在视图模型中添加状态参数https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate#java

或者您可以在视图模型中保存变量或对象，在这种情况下，视图模型将保存生命周期，直到活动被破坏。

public class HelloAndroidViewModel extends ViewModel {
   public Booelan firstInit = false;

    public HelloAndroidViewModel() {
        firstInit = false;
    }
    ...
}

public class HelloAndroid extends Activity {

  private TextView mTextView = null;
  HelloAndroidViewModel viewModel = ViewModelProviders.of(this).get(HelloAndroidViewModel.class);
  /** Called when the activity is first created. */
  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    mTextView = new TextView(this);

    //Because even if the state is deleted, the data in the viewmodel will be kept because the activity does not destroy
    if(!viewModel.firstInit){
        viewModel.firstInit = true
        mTextView.setText("Welcome to HelloAndroid!");
    }else{
       mTextView.setText("Welcome back.");
    }

    setContentView(mTextView);
  }
}

Kotlin代码：

保存：

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState.apply {
        putInt("intKey", 1)
        putString("stringKey", "String Value")
        putParcelable("parcelableKey", parcelableObject)
    })
}

然后在onCreate（）或onRestoreInstanceState（）中

    val restoredInt = savedInstanceState?.getInt("intKey") ?: 1 //default int
    val restoredString = savedInstanceState?.getString("stringKey") ?: "default string"
    val restoredParcelable = savedInstanceState?.getParcelable<ParcelableClass>("parcelableKey") ?: ParcelableClass() //default parcelable

如果不想有Optionals，请添加默认值

现在Android为保存状态提供了ViewModels，您应该尝试使用它而不是saveInstanceState。

解决这个问题的简单快捷方法是使用IcePick

首先，在app/build.gradle中设置库

repositories {
  maven {url "https://clojars.org/repo/"}
}
dependencies {
  compile 'frankiesardo:icepick:3.2.0'
  provided 'frankiesardo:icepick-processor:3.2.0'
}

现在，让我们看看下面的示例，如何在“活动”中保存状态

public class ExampleActivity extends Activity {
  @State String username; // This will be automatically saved and restored

  @Override public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Icepick.restoreInstanceState(this, savedInstanceState);
  }

  @Override public void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
    Icepick.saveInstanceState(this, outState);
  }
}

它适用于Activities、Fragments或任何需要在Bundle上序列化其状态的对象（例如，迫击炮的ViewPresenter）

Icepick还可以为自定义视图生成实例状态代码：

class CustomView extends View {
  @State int selectedPosition; // This will be automatically saved and restored

  @Override public Parcelable onSaveInstanceState() {
    return Icepick.saveInstanceState(this, super.onSaveInstanceState());
  }

  @Override public void onRestoreInstanceState(Parcelable state) {
    super.onRestoreInstanceState(Icepick.restoreInstanceState(this, state));
  }

  // You can put the calls to Icepick into a BaseCustomView and inherit from it
  // All Views extending this CustomView automatically have state saved/restored
}

同时，我一般不再使用

Bundle savedInstanceState & Co

对于大多数活动来说，生命周期过于复杂且不必要。

谷歌表示，它甚至不可靠。

我的方法是立即保存首选项中的任何更改：

 SharedPreferences p;
 p.edit().put(..).commit()

在某种程度上，SharedPreferences的工作方式与Bundles类似。首先，这些值必须从偏好中读取。

对于复杂数据，您可以使用SQLite而不是首选项。

应用此概念时，活动只会继续使用上次保存的状态，而不管它是在重新启动后的初始打开状态，还是由于后堆栈而重新打开。