Быстрое переключение приложений - медленное переключение приложений в Mango

Question

У меня есть проблема, с которой я надеюсь, что кто-то может помочь. У меня есть приложение, которое во всех отношениях отлично работает. Это в основном приложение для просмотра изображений - для чего-то очень специфического. Что это около 500 фотографий.

У меня все картинки установлены как Контент, и я загружаю / выгружаю по одной за раз. Для 500 изображений у меня есть класс, который используется в качестве данных о каждом изображении. Таким образом, такие вещи, как «занято», «индекс», «краткое описание» и т. Д. Мне никогда не нужно вставлять или удалять из этого списка, но мне может потребоваться внести некоторые изменения в каждый отдельный, например, «пользователь просматривал эту картинку на ... "(дата) или" избранное = истина "(логическое значение, когда пользователь помечает изображение как избранное).

При развертывании приложения эти «метаданные изображения» находятся в файле XML. Затем он десериализуется и сохраняется в IsoStorage при первом запуске. Его копия сохраняется в памяти, и именно это используется для запуска всего моего приложения. У меня есть 3 разные страницы, которые все используют эти данные, которые установлены как статическое свойство в app.xaml.cs. После деактивации / закрытия данные сериализуются обратно в xml - при повторном запуске они десериализуются. Все работает хорошо и быстро - везде. Включая надгробие.

Проблема возобновляется после деактивации, когда приложение не захоронено. Это может занять до 10-15 секунд и определенно возвращается из e.IsApplicationInstancePreserved в Application_Activated (т.е. это не захоронено).

Для активации из нового приложения требуется около 3-4 секунд. Возвращение из надгробия также занимает около 3 секунд.

Я не понимаю, почему возвращение из e.IsApplicationInstancePreserved = true; занимает так много времени (и это не позволит мне пройти сертификацию). Я проверил и обнаружил, что если в List это около 10 пунктов, это невероятно быстро для FAS. Если в List около 50 пунктов, это не сразу. Если есть 100 пунктов, это первый раз, когда вы видите «Возобновление ...» (да, это слово происходит от ФАС, а не надгробной плиты). Где у меня это, в 500 в List, мучительно медленно наблюдать за FAS, то есть SAS.

Интересно, что в эмуляторе FAS отлично работает даже с 1000 объектами в памяти. Это на реальном устройстве, где он невероятно медленный (Samsung Focus) как в режиме отладки, так и в режиме выпуска.

Теперь я знаю, что простым ответом может быть что-то вроде «зачем поддерживать класс со списком из 500 объектов все время?», Но вся моя архитектура и пользовательский опыт основаны на наличии данных о рисунках, доступных на всех трех страницах все время. Linq активно используется везде для представления данных.

Есть какие-нибудь мысли или указания на эту ситуацию?

Answer 1

Рад слышать, что вы нашли проблему.

"звучит для меня проблема сериализации / десериализации. Вы храните список в« переменной »состояния? Где среда будет сериализоваться при выходе из приложения и десериализацииэто когда ты вернешься "

Answer 2

Помните, что ваш ПК + эмулятор работает НАМНОГО быстрее и мощнее, чем одноядерный ARM-процессор вашего телефона с 500 МБ ОЗУ!

Когда ваше приложение активируется с помощью e.IsApplicationInstancePreserved == true, вам не нужновосстановите любое состояние, и вы сможете определить, где остановился пользователь.

Если вы говорите, что, когда ваш список каталогизирует 500 элементов, производительность при возобновлении работы приложения становится ужасно низкой, интересно,Вы также сохраняете 500 изображений в памяти, и ваш телефон должен перенести все эти данные в область памяти вашего приложения.Это будет еще более усложнено, если в вашем приложении есть несколько страниц, каждая из которых содержит копии ваших 500 изображений!

I сильно рекомендует вам профилировать ваше приложение чтобы измерить объем памяти и увидеть, где большие проблемы с памятью, памятью, вводом-выводом и производительностью.