当前位置: 首页 > 知识库问答 >
问题:

内存泄漏LibGDX ANdroid

左丘恩
2023-03-14

我正在使用libgdx制作一个实时壁纸应用程序,根据时间改变资产。对于e、 g从早上6点到下午6点,我有“早上图形”,之后我有“晚上图形”,从下午6点到早上6点。

我构建资产的方式如下

我有12个AtlasRegion类型的静态数组,1个静态纹理区域变量和1个静态纹理变量。

我有两个静态函数load晨()和loadEnight()用于加载资产。

在funcions中,我加载如下

对于所有数组,如果它们不是null,array.clear()然后加载区域。在重置它们的值之前,释放TexureArea变量并将纹理变量设置为null。

发生的事情是,在每次资产变更后,从用户的角度来看,内存似乎在增加。我使用这个应用程序来查看内存

https://play.google.com/store/apps/details?id=mem.usage

当我第一次启动我的应用程序时...它在应用程序中显示为68MB,

第一天早晨统计

第 1 天

ID      Heap Size       Allocated       Free            %Used    #Objects
1       10.812 MB       3.186 MB        7.626 MB        29.47%    45,405    



                   Pss  Private  Private  Swapped     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap        0        0        0        0    16620     4285       38
  Dalvik Heap     8692     8604        0        0    11072     3293     7779
 Dalvik Other     1374     1216        0        0
        Stack       96       96        0        0
    Other dev    33016     4908        4        0
     .so mmap     1266      692      136        0
    .apk mmap      160        0      116        0
    .dex mmap      287       20        8        0
   Other mmap        5        4        0        0
      Unknown     1431     1412        0        0
        TOTAL    46327    16952      264        0    27692     7578     7817

 Objects
               Views:        1         ViewRootImpl:        0
         AppContexts:        3           Activities:        0
              Assets:        2        AssetManagers:        2
       Local Binders:       11        Proxy Binders:       19
    Death Recipients:        0
     OpenSSL Sockets:        0

 SQL
         MEMORY_USED:        0
  PAGECACHE_OVERFLOW:        0          MALLOC_SIZE:        0

第一天晚上的统计

加载晚间资产后的adb日志

D/dalvikvm(2451):GC_FOR_ALLOC释放1619K,71%释放3281K/11072K,暂停14ms,总计15ms

D/dalvikvm(2451):GC_FOR_ALLOC释放1517K,71%自由3281K/11072K,暂停11ms,共11ms

I/dalvikvm-heap(2451):对于1331595字节的分配,将堆(碎片情况)增大到6.548MB

D/dalvikvm(2451):GC_CONCURRENT释放1862K,67%自由4127K/12376K,暂停2ms 2ms,总计13ms

D/dalvikvm(2451):GC_EXPLICIT释放2384K,74%释放3268K/12376K,暂停2ms和3ms,总计27ms

ID      Heap Size       Allocated       Free            %Used    #Objects
1        10.816 MB      3.191 MB        7.625 MB        29.50%    45,525    


This adb log right after change


                   Pss  Private  Private  Swapped     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap        0        0        0        0    16728     4346       29
  Dalvik Heap     1654     1576        0        0    11076     3348     7728
 Dalvik Other     1435     1296        0        0
        Stack      100      100        0        0
    Other dev    63332    32644        4        0
     .so mmap     1110      692      116        0
    .apk mmap        7        0        4        0
    .dex mmap      586       20      368        0
   Other mmap        5        4        0        0
      Unknown     1504     1488        0        0
        TOTAL    69733    37820      492        0    27804     7694     7757

 Objects
               Views:        1         ViewRootImpl:        0
         AppContexts:        3           Activities:        0
              Assets:        2        AssetManagers:        2
       Local Binders:       10        Proxy Binders:       17
    Death Recipients:        0
     OpenSSL Sockets:        0

 SQL
         MEMORY_USED:        0
  PAGECACHE_OVERFLOW:        0          MALLOC_SIZE:        0

应用程序中显示的内存现在是117MB这一直在增加,第二天早上应用程序中显示的大小约为150 MB。

我需要一些指点,在哪里可以更好地理解这一点。

共有1个答案

缑文栋
2023-03-14

针对代码中无法控制的资源泄漏的一种补救措施是重新启动应用程序。您可以终止进程或执行System.exit()。

但在此之前,您必须安排重新启动。

请注意,虽然不同的android版本应该都是兼容的,但它们在应用程序重启行为上不兼容。至少,v2.x和v4.0确实有所不同(在v2.x中,System.exit()导致应用程序在最顶层活动关闭的情况下重新启动),不确定最新版本。

 类似资料:
  • 问题内容: 我认为我的android应用正在泄漏内存。我不是绝对确定这是问题所在。 应用程序打开时经常崩溃,并且logcat尝试加载位图图像时会显示“内存不足”异常。 崩溃后,我重新打开了该应用程序,它运行正常。Logcat会显示许多“ gc”,并且JIT表会不时地向上调整大小,而不会向下调整,直到应用程序因内存不足错误而崩溃。 这听起来像是内存泄漏吗?如果是这样,我该如何定位和关闭泄漏点。 这是

  • 问题内容: 我一直在追寻内存泄漏(由“ valgrind –leak-check = yes”报告),它似乎来自ALSA。这段代码已经存在于自由世界中一段时间​​了,所以我猜这是我做错的事情。 输出看起来像这样: 并继续一些页面 这是由于我在一个项目中使用ALSA并开始看到这种巨大的泄漏……或者至少是所说泄漏的报告。 所以问题是:是我,ALSA或valgrind在这里遇到问题吗? 问题答案: ht

  • 问题内容: 我有一个长时间运行的脚本,如果让脚本运行足够长的时间,它将消耗系统上的所有内存。 在不详细介绍脚本的情况下,我有两个问题: 是否有可遵循的“最佳实践”,以防止泄漏发生? 有什么技术可以调试Python中的内存泄漏? 问题答案: 看看这篇文章:跟踪python内存泄漏 另外,请注意,垃圾收集模块实际上可以设置调试标志。看一下功能。此外,请查看Gnibbler的这段代码,以确定调用后已创建

  • 本文向大家介绍Java 内存泄漏,包括了Java 内存泄漏的使用技巧和注意事项,需要的朋友参考一下 在Java中,垃圾回收(析构函数的工作)是使用垃圾回收自动完成的。但是,如果代码中有引用它们的对象怎么办?它无法取消分配,即无法清除其内存。如果这种情况一再发生,并且创建或引用的对象根本没有被使用,它们就会变得无用。这就是所谓的内存泄漏。 如果超过了内存限制,则程序将通过抛出错误(即“ OutOfM

  • 问题内容: 我使用Informix遇到了一个奇怪的问题(具体来说,我使用的是IBM.Data.Informix命名空间,即4.10 Client SDK)。我正在使用ODBC连接到IBM Informix数据库,并且遇到内存泄漏问题。该文档相当稀疏,并且我只能使用当前安装的驱动程序/ SDK。这是我用于数据库上下文的代码: } 我已尝试处置并关闭所有可以的连接,但这似乎无济于事。我是否缺少某些东西

  • 我们有一个基于go-socket.io(socket.ioGo语言实现)和大猩猩网络插座的网络插座服务,但是似乎有内存泄漏问题。即使我使用调试,HeapAlloc也总是在增加。FreeOSMemroy强制释放内存。 服务很简单。它将使用jwt令牌对传入请求进行身份验证,如果身份验证成功,则将创建一个go套接字。io conn基于gorilla websocket conn。但现在似乎是net/te

  • 问题内容: 我发现使用是众所周知的与相关的内存问题。 使用中是否存在内存泄漏? 如果是,解决方法是什么? 以下链接显示了Java中子字符串的正确用法。 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513622 另外一个博客谈论子字符串中可能的MLK。 http://nflath.com/2009/07/the-dangers-of- st

  • 我有一个这样的静态ExpressJS服务器: 当我启动服务器时,它使用20MB的v8堆。如果我每秒重新加载一个页面,则使用的堆会不断增长。4小时后,使用的v8堆将达到40MB。v8堆的总容量达到80MB,RSS(进程使用的总内存)达到130MB。 为什么这个简单而静态的服务器使用这么多内存?这似乎是内存泄漏。如果我不停止页面重新加载,使用的内存会继续增长。 如果像这样一个简单的静态服务器使用了太多