Question

Android上的我的Xamarin应用创建了大约。每秒30个新参考（我猜一个参考占用大约100个字节 - 但这并不重要）。我故意创建这些对象，它们应该在应用程序的整个生命周期中存在。

我可以在日志输出中更频繁地看到这个，因为我的应用程序运行时间较长：

04-11 16:46:22.658 D/Mono    (14892): GC_BRIDGE waiting for bridge processing to finish
04-11 16:46:22.661 D/Mono    (14892): GC_TAR_BRIDGE bridges 424 objects 2303 colors 445 ignored 814 sccs 424 xref 150 cache 0/0 setup 0.16ms tarjan 2.39ms scc-setup 0.20ms gather-xref 0.06ms xref-setup 0.02ms cleanup 0.31ms
04-11 16:46:22.661 D/Mono    (14892): GC_BRIDGE: Complete, was running for 49.28ms
04-11 16:46:22.661 D/Mono    (14892): GC_MAJOR: (LOS overflow) time 27.89ms, stw 29.64ms los size: 2048K in use: 467K
04-11 16:46:22.661 D/Mono    (14892): GC_MAJOR_SWEEP: major size: 3936K in use: 2558K

一小时后，我的应用程序运行频率为每秒1次。

结果是我可以看到我的应用程序滞后（因为GC需要几十毫秒）。

我能解决这个问题吗？

Answer 1

使用

android:largeHeap="true"

在应用程序标签的清单中告诉系统您的应用程序需要额外的RAM（也称为“堆”）。运行垃圾收集是因为您使用了大量内存 - 并且因为最大内存受系统限制，您需要请求额外的内存。你不能声明你的应用需要x MB，系统会自动为你提供RAM - 声明largeHeap可确保你的应用获得足够的内存来处理你的所有对象。它会自动缩放。我的一个应用程序崩溃了，因为它被分配了10 MB左右的ram（这很大程度上取决于我的设备的默认设置）。在我声明largeHeap之后，它使用大约30 MB的ram（平均）并且不会崩溃。如果需要更多，Android会在垃圾收集事件后分配更多

Answer 2

我在运行Android后台服务时遇到了这个问题。通过确保在另一个类中保留对服务的引用来解决此问题。我将尝试确保对要释放的类/对象的引用退出。如果应用程序仍然具有对内存的引用，则GC无法收集。希望这会有所帮助。

Answer 3

在我的情况下，我使用FFImage并经常致电ImageService.Instance.InvalidateMemoryCache();。确保您没有明确调用它，让Android在OnTrimMemory覆盖较低的情况下自动执行此操作。

Answer 4

在我的例子中，ListView CachingStrategy 选项设置为 CachingStrategy="RecycleElement" 导致了与仅在调试模式下在 android 上描述的相同的 GC 问题。

删除它并使用默认值解决了 GC 问题。

Xamarin garba集合经常运行

4 个答案: