减少视频对内存的影响，防止崩溃答案

【问题标题】：Reduce the impact of videos in memory to prevent crashes减少视频对内存的影响，防止崩溃
【发布时间】：2021-02-16 10:39:13
【问题描述】：

我的应用可能包含大量图片和视频，具体取决于用户发布的帖子数量。

已经在开发中，包含图片和视频标签的帖子相对较少，有时应用程序在真实设备上崩溃，我担心内存使用量过多。

是否有任何优化资源使用的技巧和策略？

对于图像，我只使用中等分辨率的常规 EncodedImages（没有多图像），作为固定大小标签中的背景。

至于视频，我只用短视频。

对于帖子和视频（位于具有许多选项卡的复杂多层层次结构中），我使用我自己的 InfiniteContainer 自定义版本，与“默认”版本不同，它在刷新期间从不使用“removeAll”，而只是添加了新的帖子，如果有的话：这已经在性能方面给了我很大的好处。我还尝试重用 InfiniteContainer 的同一个实例，其中包含图像和视频，因此我不必每次都重新创建 Media 实例：在这种情况下也有性能优势，但所有内容仍然加载在内存中。

垃圾收集器是否处理视频？

我不清楚 Media.cleanup() 是否对视频进行了处理。

感谢您的建议。

【问题讨论】：

标签： codenameone

【解决方案1】：

我建议使用 Android 内存分析器来尝试跟踪潜在的内存泄漏以及此类泄漏的来源。您也可以在模拟器上使用内存跟踪，但这更具挑战性，因为存储在“本机系统”中的一些开销将对基于 Java 的分析器隐藏。

EncodedImage 非常适合未显示的图像。当它们被显示时，它们被“锁定”并占用大量 RAM。那时他们无法获得GC。确保您的无限容器解锁不再属于它的组件。如果你不断地向无限容器中添加东西，你最终会耗尽内存。对此你无能为力。

图像在使用时会得到“locked”（例如，以当前形式但不一定可见）。解锁它们是表单的责任，否则图像根本不会被 GCd。您可以使用isLocked() 来确定编码图像是否占用了全部 RAM。请注意，解锁的图像可能会表现得很差，因为它们会破坏 GC，因此请小心处理...

我建议将FileEncodedImageAsync 用于数据，以便可以从 RAM 中完全删除文件并将其用于视频（使用缩略图。我建议仅在播放开始时放置视频本身。

与EncodedImage 的区别在于：即使是GCd，EncodedImage 也会保留“编码”部分（PNG、JPEG 数据）。 FileEncodedImageAsync 在FileSystem 中有数据，因此可以将缓存作为文件进行管理。此外，假设图像未锁定，图像仅占用 RAM 中图像文件的名称。

【讨论】：

你能给我一些进一步的解释吗？也许我没明白。如果我在表单中使用 EncodedImage，当图像不再显示时，因为我更改了表单（但留下了对有问题的 EncodedImage 的引用，在这种情况下，在内存中保留一个包含 EncodedImage 的 InfiniteContainer 变量），不是t EncodedImage 会自动从 RAM 中删除，直到它再次显示？我的假设是否对 EncodedImages 无效，而仅对 FileEncodedImageAsync 有效？另外，我不知道 FileEncodedImageAsync 对于视频存在什么等价物。
我采纳了您的建议，在视频暂停时用带有视频预览的标签替换所有 MediaPlayers：在亮度方面的优势似乎非常显着，并且为我解决了一些问题。顺便说一句，这是stackoverflow.com/q/66144759/1277576 问题的有效解决方法，比我提出的解决方案要好得多。
我添加了一些澄清的 cmets。我记得写了很多关于图像锁定的文章，但我找不到它
第一印象是使用 FileEncodedImageAsync + image.unlock() 解决了我的应用程序崩溃。我会在开发过程中做更多的测试，但这似乎是要走的路。我注意到 InfiniteContainer 滚动在滚动大量内容后会减慢很多，持续一到两秒钟：这可能是 GC 进入以挽救原本无法避免的崩溃的时刻。也许对于 InfiniteContainer，解锁的使用几乎是必须的？
这可能是因为解锁。当您解锁并需要再次显示图像时，就会产生开销。您还应该在图像处于可见区域时将其锁定，以防止 GC 不断收集它们。