Лучшая стратегия для приложения журнала

Question

Я разрабатываю приложение для журнала и пытаюсь найти лучшую стратегию для оптимизации производительности и стабильности. Приложение должно иметь возможность обрабатывать +100 страниц и ожидать, что пользователи будут быстро и плавно перемещаться между ними.

Имея это в виду, это то, что я пробовал до сих пор.

Основная структура будет заключаться в использовании вкладок с скрытыми скрытыми вкладками, позволяющими пользователю прокручивать. Так как загрузка + 100 вкладок с огромными изображениями будет ошибкой, я всегда использую три вкладки: текущую страницу, предыдущую и следующую. С помощью приемника выбора я меняю позиции соответственно.

То, как я загружаю и удаляю изображения в качестве изменений выбора, здесь имеет большое значение. Приложение загружает изображения из Интернета и кэширует их в FileSystemStorage. Эти изображения 768 х 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 прыгает и убивает приложение.

• Аналогичный подход: вместо WeakHashMap, я попробовал CacheMap. Это было лучшее решение для меня до сих пор. Я должен выдвинуть трудно, чтобы увидеть некоторые предупреждения памяти один раз в то время, и не аварии до сих пор. Тем не менее, не очень счастливо, потому что я считаю, что вообще не вижу никаких предупреждений о памяти.

Я говорю только о iOS только потому, что приложение отлично работает на Android, независимо от того, какой метод я использую, и у меня никогда не было памяти.

Как вы думаете? Я на правильном пути? Вы, ребята, используете другой подход?

Благодаря

Answer 1

Непонятно, из-за того, что страница журнала - это просто изображение. Если это так, я бы предложил использовать класс ImageViewer, так как он был разработан точно с использованием случайного списка больших изображений для прокрутки и масштабирования.

Общая стратегия с Tabs кажется хорошим началом, если вам нужно что-то более сложное, чем изображения. Если он не работает хорошо, вы всегда можете заменить Tabs на что-то еще.

Answer 2

Я считаю, что вы должны использовать «пусть-это будет сделано» подход. До сих пор вы пытались все кодировать самостоятельно, в то время как codenameOne имеет множество оптимизированных способов сделать это. Самый простой способ - использовать MultiList, который отобразит ваши изображения (используя UrlImage). UrlImage позволит codenameone обрабатывать кеширование и другое. В принципе, изображение будет загружаться при просмотре и затем помещаться в кеш.