Question

我正在开发一个杂志应用程序并试图找到优化性能和稳定性的最佳策略。该应用程序应该能够处理+100页，并希望用户快速，顺利地在它们之间滑动。

考虑到这一切，这是我迄今为止所尝试过的。

基本结构将使用选项卡，隐藏标签栏，以允许用户滑动。由于加载带有巨大图像的100个标签将是一个错误，我总是保留三个标签：当前页面，前一页和后面的页面。通过选择监听器，我可以相应地更改位置。

我加载和处理图像作为选择更改的方式在这里是重要的。该应用程序从Internet下载图像并将其缓存在FileSystemStorage中。这些图像是768 x 1024.这是我尝试过的不同运气：

每次请求新页面时，只需从FileSystem检索图像：

    if (FileSystemStorage.getInstance().exists(rutaImagen)) {                                
        try {
            int size = (int) FileSystemStorage.getInstance().getLength(rutaImagen);
            EncodedImage imagenPubli = EncodedImage.create(FileSystemStorage.getInstance().openInputStream(rutaImagen), size);
        } catch(IOException io) {                
        }
    }

事实证明，就内存使用而言，这是低效且有风险的。我的iPad mini频繁发出低内存警告，并在一段时间后被jetsam杀死。

将图像存储在WeakHashMap中，因此图像不需要经常从FileSystemStorage加载，这似乎是问题的原因而且太昂贵。只有当它们被垃圾收集时，第一种方法才会起作用。此解决方案表现更好，内存警告显着减少，但仍然存在。在给应用程序施加压力之后，15或20分钟后，jetsam跳进来杀死了应用程序。
类似的方法：我尝试过CacheMap，而不是WeakHashMap。到目前为止，这对我来说是最好的解决方案。我不得不努力一时间看到一些内存警告，到目前为止还没有崩溃。尽管如此，仍然不高兴，因为我相信我根本不应该看到任何记忆警告。

我只在这里谈论iOS，因为无论我使用什么方法，该应用程序在Android上运行良好，而且我从来没有任何内存不足。

你怎么看？我在正确的道路上吗？你们会采用不同的方法吗？

由于

Answer 1

我相信你应该使用＆＃34; let-it-be-done＆＃34;做法。到目前为止，您已尝试自己编写所有代码，而codenameOne有许多优化的方法。最简单的方法是使用MultiList，它将显示您的图像（通过使用UrlImage）。 UrlImage将允许codenameone处理缓存等。基本上，图像将在查看时加载并随后放入缓存中。

Answer 2

从杂志页面只是图像的问题不清楚。如果是这样的话，我会建议使用ImageViewer类，因为它的设计与无限大图像列表的用例完全一致地滑动和缩放。

如果你需要比图像更精细的东西，Tabs的一般策略似乎是一个好的开始。如果效果不佳，您可以随时将Tabs替换为其他内容。

杂志应用的最佳策略

2 个答案: