我对此很纳闷。我显然已经注意到，Android可以在不主动接收或等待用户输入的任何时候杀死正在运行的应用程序（例如，在“火鸡”中按下“在桌面终端会话上按Control-C”）。 ，例如当它在后台停留了相当长的时间，并且如果您切换回它，则从一开始就从无到有地启动了应用程序。因此，这会引起有关可变状态值的持久性的问题，以便在恢复应用程序时可以毫无缝隙地恢复运行。
我想知道的问题是：最佳的设计方法是什么？应该使用哪种工具来保证可以毫无问题地完成这一工作？看来它必须有效地支持在应用程序执行中的任意点处终止，而不会出现任何故障。这似乎意味着在理论上您可以想象这样的事情，即使您有一个将状态变量设置为某些后台计算过程的一部分的命令，然后又有一个命令将其保存后，该过程可能会在这两个状态并不会被保存，并且您可能会非常罕见地发生错误，但从理论上讲可能足以引起投诉，并且当程序员交付一个知道其有故障的系统时，责任就直截了当，完全在程序员的肩膀上。
（我还注意到有些“服务”似乎是为进行后台计算而设计的，但它们似乎也很容易被自发杀死。）
那么我的问题是，考虑到这些因素，确保数据和状态“ 100％杀死安全”的标准方法是什么？
我一直在玩的一件事是“房间持久性库”，它允许一个人使用“ LiveData”对象来连续存储和更新数据（我认为它很健壮，因为它是由Google的系统设计师制作的）。但是，这有点违背我一直尝试使用的设计模型，在该模型中，有一个单独的类对象使用专门调用的save方法来处理数据存储，从而使我们无法确切知道我们使用的是哪种存储系统-特别是，将不得不去操纵数据的任何地方，您不能仅仅拥有一个单独的存储命令。是这样吗，那么您如何避免与特定的持久性解决方案过于紧密地结合呢？还是可以认为实时保存数据的需求是Android系统的基本必要，因此假设所有形式的持久性都应该以这种方式工作？