Весьма показательным примером может служить работа с XML. Теоретически, разработчик может добиться абсолютного максимума производительности, выполняя синтаксический анализ необходимых данных путем непосредственного использования файловых потоков ввода-вывода. Однако такой подход будет крайне неразумным, чреватым ошибками и ничем не оправданным, если существуют хорошо спроектированные и проверенные высокоуровневые API-интерфейсы, которые позволяют выполнить данную задачу без заметного ущерба для производительности.
Идеальнее всего, если разработчику для загрузки и сохранения своих данных в виде XML-дерева удается использовать объектную модель документов (Document Object Model — DOM). Эта модель прекрасно подходит для работы с XML-данными среднего объема. Однако разработчики не должны забывать о том, что XML DOM в значительной мере основана на использовании состояний; при загрузке XML-данных в память они в действительности сохраняются в памяти в виде дерева объектов, представляющих XML-документ. В случае крупных документов создание такого дерева может приводить к дефициту памяти. В противоположность этому сама модель XML DOM строится поверх классов XMLReader и XMLWriter, которые не имеют состояния и осуществляют лишь однонаправленный доступ к данным; эти классы осуществляют синтаксический анализ или генерируют XML-данные, основываясь на состоянии лишь в самой минимальной степени. Эти классы удерживают в памяти ровно столько информации, сколько необходимо для того, чтобы иметь возможность осуществлять разбор XML-данных или записывать их в поток; они и не генерируют, и не используют хранящиеся в памяти деревья данных.
При работе с крупными XML-документами на мобильных устройствах с ограниченными ресурсами памяти наиболее подходящей является модель однонаправленного доступа к данным без сохранения состояния. Это остается справедливым даже при условии привлечения программистом низкоуровневых API-интерфейсов для синтаксического разбора XML-данных. Чтобы выбрать наиболее подходящий уровень абстракции API-интерфейса, необходимо хорошо себе представлять, какие объемы данных перемещаются и какие накладные расходы связаны с привлечением высокоуровневых абстракций.
Связь производительности с организацией пользовательского интерфейса и работы с графикой
Первые и самые глубокие впечатления от вашего приложения конечные пользователи получают при знакомстве с его пользовательским интерфейсом и графикой.
О приложении можно говорить, что оно имеет отличный внешний вид и прекрасный интерактивный интерфейс лишь постольку, поскольку таковым его воспринимают конечные пользователи. Для представления данных и взаимодействия с конечным пользователем существует практически бесчисленное количество способов, поэтому перед вами, как проектировщиком, простирается весьма широкий набор возможных для выбора вариантов. Такая ситуация может как вдохновлять, так и обескураживать вас, поэтому некоторые рекомендации здесь будут вполне уместными. При заполнении пользовательского интерфейса данными очень важно учитывать, какие данные могут действительно понадобиться пользователю, и не тратить время на разработку элементов управления с огромными списками или деревьями данных, до которых пользователь, скорее всего, не будет даже пытаться добраться; в противном случае вы зря потратите и время и ресурсы. Лучше затратьте это время на проектирование таких пользовательских интерфейсов, которые дают пользователю возможность легко переходить к нужным данным, и откладывайте вывод необязательных элементов управления пользовательского интерфейса до тех пор, пока в них не возникнет реальная необходимость. Возможно, прежде чем вы получите модель, которая вас устроит, вам придется много экспериментировать, поэтому будьте готовы к неоднократным переделкам интерфейса.
Вы должны тщательно исследовать пользовательский интерфейс, чтобы хорошо понимать тонкости его взаимодействия с кодом мобильного приложения. Особенно важно разобраться в том, как каркас пользовательского интерфейса активизирует код обработки событий приложения. Очень часто одного лишь просмотра кода еще не достаточно для того, чтобы с уверенностью сказать, когда именно будут запускаться те или иные события и каким образом код обработки событий взаимодействует со свойствами и методами, которые могут вызываться вашим приложением. Организация в коде средств контроля его выполнения и осуществление периодических проверок того, когда именно вызываются обработчики событий пользовательского интерфейса, помогут вам значительно глубже разобраться в характере взаимодействия каркаса этого интерфейса с вашим кодом.
Читать дальше