Question

应用程序后台服务更新sqlite数据库。因此，我的活动已经过时了。活动意图还包含过时的参数，因此onCreate，onResume将使应用程序崩溃。最简单的解决方案是重新启动整个应用程序。我不想在所有活动中为所有onCreate，onResume方法添加IF来处理一个特殊情况。

我注意到ACRA在处理异常后执行了以下代码。

android.os.Process.killProcess(android.os.Process.myPid());
System.exit(10);

然而，许多人不鼓励使用System.exit(0)。对于Android应用程序数据完整性，System.exit(0)真的那么危险吗？当然，我的代码会在现有代码之前关闭数据库。

更新

我知道如何使用finish()，内容提供商，发送广播，在SO上阅读许多答案等等。但是，这些方法中的每一种都需要额外的数千行代码。我在十分钟内用System.exit(0)实现了解决方案。重启速度非常快，以至于无法与普通的startActivity动作区分开来。数据库更新/重新启动在用户不活动较长时间后完成，因此系统已暂停应用程序。我的应用程序不需要实时同步。在测试期间，应用程序行为正常。这是一个快速而肮脏的解决方案。

因此我问了System.exit(0)可能产生的副作用的问题。不是我如何能够以不同的方式进行设计。我知道目前的设计并不完美。

Answer 1

System.exit(0)是来自Java运行时的工件，不适用于Android。所以在任何情况下使用它都是最糟糕的解决方案。

为什么不优雅地使用Activity.finish()？

如果你终止你所居住的过程，你将失去大部分缓存和重启时间（〜用户眼中的恢复），因为下次它会更高。

在Activity Lifecycle documentation on Android Developers中阅读更多内容。

Answer 2

杀死进程不会清除进程外部的任何已注册资源。例如，BroadcastReceivers。这是泄漏，设备会告诉你。

您确实不应该从后台服务更新数据库架构。在你的活动恢复时这样做。

如果您只是更新数据，则恢复活动应验证Intent指定的数据，并告诉用户，例如，项目X是否不再存在。

Answer 3

如果仔细使用并且经过深思熟虑的目的，没有任何工具是危险的。

但是，在您的情况下，我不相信System.exit()是正确的方法。如果您的应用程序依赖于数据库中的数据，请创建一个后台服务（或几个，具体取决于您的需要），它将通知您的应用程序更改并更新数据。在我看来，这是处理变化的正确方法。

至于您想要使用System.exit()时的情况，我个人有时会在无法从严重错误中恢复时使用它，并且不会出现优雅降级。在这些情况下，最好强制停止与您的应用程序相关的所有资源，而不是仅仅将松散的末端缠绕在一起。为了澄清，在做任何激进之前，你应该总是使用错误处理。正确的错误处理通常是可行的方法。

但这是一个非常微妙的话题，你很可能会收到不同的答案。

Answer 4

因此我的活动已经过时了。

使用ContentProvider和ContentObserver（或Loader框架），或使用消息总线（LocalBroadcastManager，Otto等）更新活动原地。

活动意图也包含过时的参数，所以onCreate，onResume会使应用程序崩溃

将相关的“params”复制到活动的数据成员。根据需要更新这些数据成员（例如，来自消息总线引发事件的处理程序）。保留该数据作为配置更改的实例状态的一部分（例如，onSaveInstanceState()）。使用onCreate()，onResume()等

中的数据

最简单的解决方案是重新启动整个应用程序

如果您重视用户，这并不是最简单的，因为您的用户不会感谢您的应用在使用时自然蒸发。您是否认为每次收到电子邮件时Gmail都会崩溃他们自己的应用程序？

接下来，您将建议编写一个使用某些漏洞来破坏浏览器的Web应用程序，因为您无法弄清楚如何更新网页。

我注意到ACRA在处理异常后执行了以下代码。

顶级异常处理程序是拥有此类代码的唯一合理位置，即使在那里，目标也是这个代码永远不会运行（即，没有未处理的异常）。

Answer 5

现有答案HERE可能会为您提供一些帮助，说明为什么人们说使用System.Exit（）是不好的。

System.exit（0）真的那么危险吗？

5 个答案: