我正在启动一个服务=>后台服务，并开始检查“new Thread”中的文件，在我得到以下内容的日志中，服务/应用程序被暂停。
日志：I/art: Explicit concurrent mark sweep GC freed 25935(1686KB) AllocSpace objects, 13(903KB) LOS objects, 39% free, 13MB/22MB, paused 649us total 43.569ms
它只是扫描SD卡中MyData中的文件，其中包含一堆图片（约20张图片）。
**扫描 = 获取图片名称并将其保存到字符串 。
所有这些都意味着垃圾回收器正在完成其工作并释放内存。
如果您经常（或始终如一地）看到这种情况，则可能分配了太多对象。一个常见的原因是在循环中分配许多（或几个大）对象，如下所示：
for (int i = 0; i < 100; i++) {
Bitmap bmp = Bitmap.create(100, 100, Bitmap.Config.ARGB_4444);
}
每次我们点击此循环时，我们都会分配一百个新的位图对象。
防止 GC 扫描的最佳方法是不分配对象。当然，您必须在Java中分配对象，因此您需要确保不会不必要地分配。
这是Google发布的众多YouTube视频之一，其中包含有关避免GC事件和正确管理内存的提示。
正如布莱恩·赫伯斯特（Bryan Herbst）所说：“如果你经常看到这种情况”，那就意味着你有问题。此问题可能由失灵的侦听器（也称为内存泄漏）引起。
现在。。我不太确定如果某些东西被反复收集垃圾，它怎么会是内存泄漏！？
所以我的理由是...（我不太确定）订阅本身的实际联合不能被垃圾回收，但是在 lambda/侦听器输出越过订阅联合/屏障的边缘（在使用者和生产者之间）之后发生的任何情况实际上都可能符合垃圾回收的条件，但由于订阅仍然连接，输出会重复重新语境化。
另一方面，由于图形的工作方式，可能是图形“引擎”背后的实际循环正在重复发送信息，并且由于没有对此数据执行任何操作，因此在失效的下标器接收到流后，它会被垃圾回收。
