Иво Салмре

Книги → Программирование мобильных устройств на платформе .NET Compact Framework → Заключительные замечания и рекомендации

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

■ Принимайте осознанные заблаговременные решения, касающиеся управления памятью приложения. Не допускайте, чтобы используемая в вашем приложении модель памяти формировалась просто как пассивный или произвольный продукт других проектных решений. Явным образом указывайте в проекте, какие именно объекты должны удерживаться в памяти и когда именно память должна освобождаться от них. 

■ Определяйте дискретные состояния приложения и указывайте ресурсы, требуемые в каждом из этих состояний. В реализации этой разновидности управления памятью вам может очень пригодиться конечный автомат. Ваше мобильное приложение должно поддерживать список состояний и варианты поведения приложения при смене состояний, что позволит вам регулировать использование памяти. 

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

■ Используйте курсор ожидания и обеспечивайте обратную связь с пользователями для любой задачи, выполнение которой длится более одного мгновения. Если выполнение любой задачи занимает более половины секунды, следует использовать курсор ожидания. Если выполнение задачи длится более двух секунд или может занять неопределенное время, пользователь должен получать регулярно обновляемую информацию о состоянии ее выполнения. 

■ В процессе разработки и тестирования, приложения используйте реальные размеры данных и модели сетевых соединений. Важно тестировать мобильное приложение в условиях программной среды, близких к тем, с которыми будут сталкиваться конечные пользователи в процессе работы. Это касается как вероятных объемов данных, с которыми будут работать конечные пользователи, так и параметров подключения к сети (например, скорость передачи данных и длительности задержки) в реальных условиях. Если ваше приложение характеризуется определенными пороговыми значениями некоторых параметров состояния, при превышении которых приложение начинает работать значительно хуже, предусмотрите явные запреты, препятствующие переходу приложения в такие состояния; разрешая приложению переходить в состояния, в которых нормальное функционирование приложения нарушается, вы оказываете конечным пользователям "медвежью услугу". 

■ Осмотрительно выбирайте размеры применяемых вами растровых изображений. В наши дни размеры обычных цифровых изображений значительно превышают те, которые еще допустимы при выводе изображений на экраны мобильных устройств. При больших размерах изображений вы будете напрасно терять время на их пересылку по сети, место, необходимое для их хранения на устройстве, и память, занимаемую ими при загрузке. Лишние 0,5 Мбайт данных изображения, загруженных в память, эквивалентны сотням или даже тысячам других удерживаемых в памяти элементов, не являющихся изображениями; 500 Кбайт пикселей по занимаемому объему равносильны 500000 целочисленных элементов данных. При любом удобном случае прежде, чем загружать изображение, уменьшайте его размеры, сообразуясь с возможностями экрана целевого устройства. Если это сделать невозможно или в память должны загружаться изображения с высоким разрешением, подумайте, нельзя ли сразу же создать в памяти копии этих изображений с низким разрешением, после чего уничтожить их объемистый в отношении используемой памяти оригинал, чтобы за приложением не было закреплено большое количество лишней памяти. 

← предущий раздел следующая →

Страницы раздела: 1 2

Публикация компанией Dropbox кода Zulip – средства общения для IT-разработчиков

20.11.2015
Одной из одобрительно встреченных программистами инициатив, реализующихся в рамках акции Hack Week, стала публикация исходного кода приложения Zulip – веб-приложения для общения между собой разработчиков в сфере IT-технологий.

Объединение ОС Android и Chrome

17.11.2015
Слухи об объединении двух крупнейших ОС компании Google, Android и Chrome, гуляют по Интернету уже более 5 лет, но до сих пор этого не случилось, хотя очевидно, что с течением времени эти ОС становятся всё более похожими: так, в последнее время появилось немало Android-устройств, к которым прилагаются клавиатуры, а Chrome OS «научилась» работать с сенсорными экранами.

Конференция Linux Piter 2015

15.11.2015
Уже почти через неделю в Санкт-Петербурге впервые в истории пройдёт конференция, посвящённая проблемам свободного программного обеспечения – Linux Piter 2015.