java - 当静态资源被杀死时，它们是全部被杀死还是会保留在罕见的边缘情况下？

Question

备注 :虽然到目前为止(9 月 6 日)提供的两个答案很有趣，但不幸的是它们没有解决这个问题。

我的 Android 测试设备之一是 HTC One X。该设备以经常杀死后台应用程序而闻名(甚至包括启动器，最令人气愤的是)，因为它在 RAM 分配方面往往处于边缘地位，可能是由于 HTC 膨胀软件。然而，就我的目的而言，这非常有用，因为它有助于突出各种低内存情况的影响，并允许我改进我的应用程序以应对此类事件。例如，我学到的一件事是 Application实例和其他 static资源可以被杀死，即使 Activity后台堆栈被保留。因此，为了提供良好的用户体验，即使运行应用程序的单个进程和所有 static它持有，已经消失。出于这个原因，我的应用程序现在非常坚固，可以优雅地检查状态，并在必要时对恢复任何 Activity 所需的“Singleton”数据进行重新初始化。 .

转到我的具体问题，我看到了一个罕见的症状，通过代码检查，我相信这可能只是由 static 引起的。一个类的成员已被杀死，然后重新初始化，而我的一个库类中的另一个静态资源尚未重新初始化。我很欣赏两个独立的 static 之间的这种依赖关系。资源代表我的糟糕设计，我将重构以避免这种情况。但是，我想知道我的分析是否可能是正确的——也就是说，是否有可能有一个保留 backstack 的位置，但只有一些 static资源被杀死，特别是在每个库/包的基础上？

编辑 1 我将提供有关这两个类的更多信息。

第 1 类是我们称之为 Controller 的类.它不用作 Singleton，但包含 static Map在所有实例中通用的数据。它的初始化如下:

private static Map<String, String> sSomeMetaData;

static {
    sSomeMetaData = new HashMap<String, String>();
}

接下来，我有一个名为 MyFlyweightFactory 的类。 .这个类存在于一个单独的库中。这个类是一个单例:

private static MyFlyweightFactory instance = new MyFlyweightFactory();

public static synchronized MyFlyweightFactory getInstance(){
    return instance;
}   

private MyFlyweightFactory(){ }

TreeMap<String, MyParserRenderer> images = new TreeMap<String, MyParserRenderer>(); 

现在，这是依赖项。工厂类有一个 getter 方法来获取某个命名的图像对象，该对象是通过从文件系统中解析文件来构造的。如果自工厂初始化以来工厂没有被要求提供该图像，它会从一个文件中解析它(它实际上是我的一个 SVG 图像解析器库)。图片被解析成 MyParserRenderer目的。当此图像解析发生时，工厂还会在 Controller 中填充一些数据。类(class)' sSomeMetaData成员。工厂保留的所有图像都保存在 images成员(member) TreeMap你看上面。因此，这些图像是 static 的非静态成员。单例工厂实例。

罕见的问题情况似乎是 Controller 的实例。找到 sSomeMetaData是空的，即使我知道 MyFlyweightFactory已从其 Map 中提供了一些对象.我相信，如果 MyFlyweightFactory 的实例，这肯定会发生。一直存在，因此不需要重新解析图像对象(这意味着它不会再次填充 sSomeMetaData)，但与此同时 static Controller 的初始化器此后再次执行。我可以确认 sSomeMetaData不是 clear()编辑代码中的其他任何地方。

Answer 1

你应该看看这个:Activity lifecycle.



当您内存不足时，暂停的 Activity 将被终止以释放内存。

因此，为什么您应该在必须重新创建 Activity 的每种情况下尝试并解释这一点。

这不是一个完整的应用程序，而是基于一个 Activity 。所以它会开始扼杀它认为不那么重要的 Activity 。在同一个应用程序中，某些 Activity 可能会受到影响，而其他 Activity 则不会。

Note the "Killable" column in the above table -- for those methods that are marked as being killable, after that method returns the process hosting the activity may killed by the system at any time without another line of its code being executed. Because of this, you should use the onPause() method to write any persistent data (such as user edits) to storage. In addition, the method onSaveInstanceState(Bundle) is called before placing the activity in such a background state, allowing you to save away any dynamic instance state in your activity into the given Bundle, to be later received in onCreate(Bundle) if the activity needs to be re-created. See the Process Lifecycle section for more information on how the lifecycle of a process is tied to the activities it is hosting. Note that it is important to save persistent data in onPause() instead of onSaveInstanceState(Bundle) because the latter is not part of the lifecycle callbacks, so will not be called in every situation as described in its documentation.