问题标签 [low-memory]

在我的场景中，我使用压缩在资产中的外部只读数据库，并在初始运行时提取/复制到内部存储。

当用户的设备在磁盘上没有足够的内存来完成复制时，就会出现此问题。

我之前确实检查了可用空间，但是当 RAM 不足时，Android 操作系统本身将使用虚拟内存/页面文件，因此可用 MB 的数量不是恒定的。

我想找到一种方法来检查文件本身是否完整，有什么方法可以做到这一点？

我遇到内存不足的问题。每次推送视图时内存都会增长。当我运行 Instruments 时，我看到它是 ImageIO_PNG_Data，每次我推送视图时都会占用大量内存。我的旧应用程序运行良好，但是当我更改一些图像时，它给我带来了内存不足的问题。图片网址：https ://drive.google.com/file/d/0B5FeQzPDrl-oT2ZiZktuNWJONHM/view?usp= sharing 伙计们请看一看。

多谢你们。

我正在尝试找到一种方法来捕获低内存崩溃。大多数崩溃报告工具，例如 Crashlytics，不会捕获内存不足的操作系统终止。

https://twitter.com/crashlytics/status/235018252647010304 http://support.crashlytics.com/knowledgebase/articles/123408-do-you-catch-out-of-memory-crashes

有谁知道任何可以捕获低内存崩溃的崩溃报告工具？或者，有没有人知道在不添加任何报告工具的情况下检测这些崩溃的方法？

谢谢！

当 JavaScript 客户端应用程序使用过多内存时，浏览器将崩溃或抛出无法恢复或交换的异常，就像 80 年代一样。

浏览器是否表示它们几乎达到了选项卡的可用内存限制？

理想情况下，我希望能够在浏览器内存不足时捕获可以在 JavaScript 中拦截的事件，以便自动回退到应用程序的轻量版本或告诉我的用户去购买新计算机/ 电话。

我知道 Chrome 性能工具允许对已用内存进行不精确的查询，这是第一步，但可能不足以检测内存限制。

我的App有3个进程和2个服务，它们的关系如下：（UI启动并绑定BKService，UI启动并绑定LinkService，然后BKService绑定LinkService）

并且推送进程的内存使用量远低于守护进程。

我使用 dumpsys 活动进程来检查它们的 adj 类型和值，如下所示：

这是详细的 dumpsys 活动进程信息：

好的，据我了解，在内存不足的情况下，杀死顺序应该是：UI进程、守护进程、推送进程。（因为 BKService 是 LinkService 的客户端，所以 LinkService 在 unBind 之前不会死掉，并且相同的 oom_adj 值，LinkService 使用的内存更少）。

但实际上杀死的顺序始终是：UI进程、推送进程、守护进程。有人可以解释一下吗？

如果我改变绑定 C（LinkService 绑定 BKService）的方向，那么守护进程将比推送进程更早被杀死。

我不知道为什么，有人可以帮忙，在此先感谢。

在我的应用程序中，我覆盖了 onLowmemory 方法。每次都会调用它。而且我的手机卡住了。这种方法如何释放内存。

我正在使用以下代码：

仅使用 system.gc ...谢谢。

DialogFragment我有一个由类包裹的警报对话框。该对话框具有自定义布局，我在其中显示项目列表（我将 aListView与适当的适配器一起使用）。项目列表非常庞大且重要，因此我将其保存Fragment在我的类中DialogFragment，onPause()就像在此示例中一样。

一切正常，除了一种非常罕见的情况：当我在对话框窗口打开的情况下（通过按“主页”按钮）离开应用程序并且设备内存不足时，它会终止我的应用程序的进程。当我稍后回到我的应用程序时，它会尝试重新创建对话框，但会崩溃（我NullPointerException在对话框的ListView适配器中得到一个），因为它无法恢复在我的左打开对话框中显示的项目列表。发生这种情况是因为Fragment当系统终止我的应用程序的进程时，我存储对话框状态的位置也会被破坏，因此我DialogFragment无法重新创建它的对话框，因为它的列表适配器没有数据源。

我想从你这里为我提供一种更好的方法来保存我的对话框窗口的状态，以便即使在我的应用程序进程被终止后也可以重新创建它，或者如果项目列表null在它之前，我可以向我展示一种取消对话框的方法恢复（我的意思是在其重新创建期间在某处取消对话）。我不认为数据库是存储该数据的好方法，因为它需要太长时间。如果没有关于它的适配器的信息，我更喜欢一种停止对话框重新创建的方法。

更新：

在应用程序的生命周期中实现Parcelable保存对象确实是一个绝妙的主意。写入对象Parcel很快（相信我，在您开始不恰当地使用它之前，您不会看到生命周期更改之间有任何延迟），并且保存和恢复应用程序实例状态的过程由ActivityManager进程控制，因此即使不仅是您的Activity,而且托管整个应用程序的进程也会被 Android 系统破坏，ActivityManager维护对象的保存位置，如果在新进程中从头开始重新创建，Parcel则恢复它们的状态。Activity非常感谢@Naveed 鼓励我尝试这种做法！

对于那些仍然不了解保存实例状态的真正含义的人的注意事项：

保存您Activity的生命周期事件的实例状态意味着维护仅对您的应用程序的当前 UI 或用户的当前进度有意义的信息更改，但当您的应用程序或用户明确停止应用程序时（通过按下后退按钮) 并稍后重新启动。这种真正临时的特殊形式的信息应该保存在对象的onSaveInstanceState()回调方法中，方法是使用原始 Java 类型的方法或在自定义类中实现接口，然后在或callbakcs 中恢复。Bundleput...()ParcelableonCreate()onRestoreInstanceState()

对用户重要的所有其他数据，无论是显式关闭您的应用程序还是仅将其保留一小段时间，都应保存在持久性存储中，例如SQLite数据库或SharedPreferences系统，以便在用户或您的应用程序需要再次获得之前的进度。您应该将这种形式的数据保存在onPause()回调方法中，因为它是保证在系统能够销毁您的应用程序进程之前保证调用的最后一个方法，以防它需要恢复一些资源。如果您选择将数据保存在 , 之后调用的方法中onPause()，onStop()或者onDestroy()，您将面临无法保存数据的巨大风险，因为如果系统决定在某些非常糟糕（但不一定很少见）的情况下立即终止您的应用程序，这些方法可能永远不会被调用。

另一件事：请仅SharedPreferences在存储少量数据时使用，因为它不是为存储列表、集合或捆绑包而构建的。考虑多花几个小时来SQLite为您的应用程序实现数据库接口，并更舒适地使用它来维护大量信息。

我有一个长期运行的服务，用于执行某些后台操作。现在，我已经阅读了几个线程，Android 考虑在 RAM 不足时终止这些服务，因为必须清理一些后台 LRU 缓存以容纳更多页面。所以，我让Android杀死它，并将我的服务数据保存在onTrimMemory回调中（当级别为80时），我希望每次Android杀死我的服务进程之前都能得到这个回调。但是在某些情况下，我在 onTrimMemory 中没有得到任何回调，并且我的进程被杀死，导致数据丢失。

这是我的进程被杀死之前的日志：

我的进程是 com.example.gaurav，在我的进程被杀死之前没有 onTrimMemory 日志。这里的任何人都可以解释这些日志表明什么？我已经用谷歌搜索了，但找不到任何令人信服的东西。关于前台服务解决方案，我想避免这种情况，因为我的服务运行时间很长，并且使其成为前台会消耗大量电池。

@pskink，这是我在服务中的 onTrimMemory 回调方法：

另外，我有时会收到日志，例如：

06-15 20:43:46.000 18420 18420 V MyService: on Trim memory callback, level : 80

所以，这当然不是没有日志的问题。

我需要存储一个包含自然语言单词的大型词典——最多 120,000 个，具体取决于语言。这些需要保存在内存中，因为分析表明，利用数组的算法是系统中的时间瓶颈。（它本质上是一种拼写检查/自动更正算法，尽管细节并不重要。）在具有 16MB 内存的 Android 设备上，与 Java 相关的内存开销String导致我们空间不足。请注意，每个String都有一个38 字节的开销与之相关，这最多会产生 5MB 的开销。

乍一看，一种选择是char[]替换String. （甚至byte[]，因为 UTF-8 在这种情况下更紧凑。）但是，内存开销也是一个问题：每个 Java 数组都有 32 字节的开销。

等的一种替代方法ArrayList<String>是创建一个具有几乎相同接口的类，该接口在内部将所有字符串连接成一个巨大的字符串，例如表示为单个byte[]，然后将偏移存储到那个巨大的字符串中。每个偏移量将占用 4 个字节，从而提供更节省空间的解决方案。

我的问题是 a) 是否有任何其他解决方案可以以同样低的开销* 和 b) 是否有现成的解决方案？搜索Guava、trove和PCJ集合库一无所获。

*我知道可以将开销降低到 4 字节以下，但收益会递减。

注意。支持在 HotSpot JVM 中删除压缩字符串？表明 JVM 选项-XX:+UseCompressedStrings在这里没有帮助。

我正在实现一个具有多个活动和基于片段的应用程序。我遇到的是，如果我开始一个活动，并在片段之间转换，现在如果我按下主页按钮回到主屏幕。然后我开始使用消耗内存的应用程序。当我回到我的应用程序时，我可以知道它已被重新创建并且片段已被恢复。但是当我点击返回时，片段返回堆栈似乎是错误的，片段之间的自定义动画也不再受到影响。

就我而言，我真的不希望系统从低内存返回时重新创建。有没有办法在内存不足而不是重新创建活动时强制应用重启？