Android：是否存在即使“android:configChanges=”也重新创建 Activity 的情况？设置为一切？
首先，对问题背景进行简短描述：
我在根据 Activity 生命周期处理后台工作人员生命周期时遇到了麻烦。第一个问题是，只要配置发生变化（这包括屏幕方向），就会创建一个新的活动实例，因此我必须将我的工作人员从旧实例拉到新实例。其次，由于有时工作人员会显示进度对话框，有时还会显示用户必须与之交互的错误对话框，因此情况变得复杂。跨活动实例处理所有这些东西 - 工作人员、对话框等 - 已经变得如此复杂，以至于现在我清楚地看到这是错误的方法。
我认为，正确的方法是首先消除重新实例化。如果提供了这一点，那么我的活动就具有非常直接和简单的生命周期，并且不需要跟踪工作人员和对话。这可以通过将 android:configChanges="..." 放入清单中来实现。
现在的问题是：
鉴于 Activity 具有 android:configChanges="..." 其中包括所有可能的内容（方向、键盘和所有其他内容） - 是否可以保证一个活动在它活着的时候被实例化一次，并且即使在后台也不会被杀死/重新创建？文档并不清楚这一点。
如果有人知道此类保证不成立的情况 - 请告诉我。最重要的是 - 如何模拟这些案例以对其进行测试？
我非常感谢您的回答。
PS：文档确实说“系统可以在任何时候删除您的活动，如果它愿意的话” - 但我们在这里不考虑它，因为当用户回到屏幕，哪个活动以这种方式被删除了。在这种情况下，我们只需从头开始，就像用户刚刚打开此屏幕一样。
First, a short description of the problem's background:
I've run into troubles with handling background workers lifecycles in line with Activity lifecycle. First problem is that a new instance of activity is created whenever the configuration changes (this includes screen orientation) so I had to pull my workers from the old instance to the new one. Second, this is complicated by the fact that sometimes workers display a progress dialog and also, occasionally, they display an error dialog which the user has to interact with. Handling all that stuff - workers, dialogs, etc. - across the activity instances has grown so complex that now I clearly see it was the wrong way to go.
The right way to go, I believe, was to eliminate that re-instantiation in the first place. If that was provided then I had activities with a very straight-forward and simple lifecycle and no need for tracking workers and dialogs. This can be achieved by putting android:configChanges="..." in the manifest.
Now, the question is:
Given that activity has android:configChanges="..." which includes every possible thing (orientation, keyboard, and all the rest) - is there a guarantee that an activity is instantiated exactly once while it's alive and not killed/re-created even in the background? The documentation is not clear about this point.
If someone knows cases when such guarantee doesn't hold up - please let me know. And most important - how to simulate those cases in order to test against them?
I appreciate your answers very much.
PS: What documentation does say is that "system can remove your activity at any point if it wants to" - but we don't consider it here, because that will be a new story for a new instance when the user is back to the screen which activity got removed this way. In this case we'll simply start from the scratch like if the user just opened this screen.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您问这个问题，则您的应用程序可能已损坏。
那么——你为什么关心？如果您无法处理重新启动的活动，那么您将陷入这样的情况：您的应用程序进程需要在后台被杀死以获取内存，并且用户稍后返回到它。
如果您可以处理重新启动，那么您为什么关心可能存在某些需要重新启动 Activity 的情况呢？
无论如何，答案是没有办法保证 Activity 永远不会重新启动，因此不要滥用 android:configChanges 来尝试避免这种情况。你无法阻止它，你只是让自己不太明显地发现你的应用程序已损坏，但用户仍然会遇到你所遇到的错误。
如果您在处理此问题时遇到困难，请考虑使用新支持库中的一些最新设施，例如片段和加载器。它们具有许多功能，使应用程序可以更轻松地处理重新启动的活动 - 可以在重新启动时保留片段，加载器保持其数据加载活动，等等。
还有应用程序可能需要重新启动的一组可能原因不是固定的。将来可以并且将会添加新的更改，并且您无法解释它们。
If you are asking this, your app is probably broken.
So -- why do you care? If you can't handle your activity being restarted, then you will break in the situation where your app's process needs to be killed for memory while in the background and the user later returns to it.
If you can handle being restarted, why do you care that there may be some case where the activity needs to be restarted?
Anyway the answer is that there is no way to guarantee that the activity is never restarted, so don't abuse android:configChanges to try to avoid that. You can't prevent it, you just make it less obvious to yourself that your app is broken, but users will still encounter the bugs you have.
If you are having trouble dealing with this, consider using some recent facilities like fragments and loaders in the new support library. These have a number of features that make it easier for apps to handle their activity being restarted -- fragments can be retained across restarts, loaders keep their data loads active, etc.
Also the set of possible reasons that an app may need to be restarted is not fixed. New changes can and will be added in the future, and you can't account for them.
通常，当您希望某些对象在活动重新创建时保留，您应该使它们不依赖于活动，而是依赖于应用程序上下文。如果您的应用程序对象（如建议的那样）是单例，那么让您的项目在活动生命周期中生存会容易得多。
以下是如何执行此操作的示例：
如何在 Android 中声明全局变量？
Usually, when you want some objects to remain accross activity recreation, you should make them depend, not on the activity, but on the application context. If your application object, as recommended, is a singleton, then it would be much easier to make your items survive to the activity life cycle.
Here is an exemple on how to do that :
How to declare global variables in Android?