21 июня у нас в Parcsis состоялся день открытых дверей, на котором я в числе прочих докладчиков рассказал, как мы разрабатываем программы под Android. Под катом текст моего выступления, несколько дополненный и переработанный с учётом заданных вопросов.
Конечно, начать рассказ о разработке ПО следует с описания бизнес-процессов. Итак, начнем!
Рабочий процесс
Для разработчика у нас существует два важных документа.
Первый — это беклог. Он представляет собой простую таблицу в Google Docs, в которую менеджер проекта заносит высокоуровневые задачи по мере их появления. Ничего сложного.
Вторым по важности документом является макет приложения, нарисованный дизайнерами.
Макет представляет собой pdf документ, каждая страница которого — один из экранов приложения в одном из состояний, отрисованный пиксель-в-пиксель как оно должно выглядеть на устройстве. Чуть забегая вперёд, скажу, что часто мы просим дизайнеров сохранять каждую страницу макета в виде отдельной картинки png, чтобы потом использовать Pixel Perfect для корректировки вёртски.
Процесс разработки делится на итерации. Каждая итерация — две недели. Перед началом итерации ведущий разработчик совместно с менеджером выбирают задачи из беклога, которые следует реализовать. На их основе в Jira заводятся задачи на конкретных исполнителей. Время на задачу определяется исходя из опыта предыдущих разработок и навыков конкретного разработчика, плюс риски. Более чем на день (восемь часов) задачи не назначаются. Если вдруг оценка задачи переваливает за восемь часов, она разбивается на более мелкие.
Первая неделя итерации отводится под разработку, вторая — под тестирование и багофикс.
У нас выделено две фазы тестирования: функциональное тестирование, выполняемое отделом тестирования, и дизайнерское ревью (включающее в себя юзабилити-тестирование), выполняемое непосредственно тем дизайнером, который создал макет программы. По обеих фаз в Jira ставятся баги.
Совсем не обязательно итерация заканчивается релизом. Завершение итерации означает лишь завершённость некого небольшого функционала.
В работе мы активно используем прототипирование. Если непонятно, как реализовать тот или иной функционал, или не ясно, возможна ли реализация вообще, мы создаём прототипы.
Исходный код хранится в svn. Для сложных задач и для прототипов мы моздаём бранчи. Живут бранчи вплоть до завершения работы над задачей, затем они мёржатся с транком и удаляются.
Сложности
Далее следует рассказать о сложностях, с которыми ежедневно сталкивается андроид-разработчик.
Вёрстка
Первая сложность — это вёрстка. Существуют сотни разных конфигураций экранов андроид-устройств. В идеале, программа должна корректно работать на любом устройстве. Следует заметить, что деление устройств на телефоны и планшеты весьма формально (что бы об этом ни говорили маркетологи). С программной точки зрения и телефоны, и планшеты — одни и те же устройства, за исключением, может быть, третьего Андроида, который работает исключительно на планшетах.
К счастью, всё множество экранов разделено на группы по двум признакам.
Первый признак — это физический размер экрана. Сейчас в продаже имеются устройства с диагональю экрана он трёх до десяти с половиной дюймов. Всё множество размеров экранов поделено на четыре большие группы. Это маленькие (small), нормальные (normal), большие (large) и очень большие (xlarge) экраны. И не нужно забывать о двух ориентациях экрана — альбомной и книжной.
Для экранов разного размера и разной ориентации характерны разные сценарии использования. Например, устройства с маленьким экраном обычно держат в одной руке, с большим — двумя руками либо кладут на стол или на колени, и так далее. Соответственно, для каждого размера и каждой ориентации экрана нужна своя вёртска и своё расположение контролов.
Второй признак — это плотность экрана, то есть количество пикселей на единицу площади. Сейчас существуют четыре плотности экрана: низкая (ldpi), средняя (mdpi), высокая (hdpi) и очень высокая (xhdpi). На расположение элементов пользовательского интерфейса этот параметр сказываться не должен. Для разных плотностней используется разная графика. То есть, в идеальном случае, любая картинка, любая иконка, должна быть включена в проект четыре раза — по одному разу для каждой из возможных плотностей экрана, с разным размером и разной детализацией.
На портале для андроид-разработчиков регулярно обнолвяется статисткика использования устройств с различными характеристиками.
Управление памятью
Разобравшись с вёрcткой, мы сталкиваемся с особенностью освобождения памяти.
Никто не любит закрывать программы. Например, на десктопе какой-нибудь бухгалтер может держать открытыми несколько десятков документов Ворд, 1C, Аутлук и Лайнс. Но на мобильном устройстве ресурсы сильно ограничены, и множество незакрытых приложений могут значительно замедлить работу. В ОС Андроид эта проблема решена весьма элегантно — операционная система сама решает, в какой момент закрыть приложение. Каждому работающему приложению присваивается приоритет, и, в случае нехватки памяти, приложения закрываются согласно этому приоритету до тех пор, пока памяти не будет хватать. Последним закрывается приложение, которое в настоящий момент показывается на экране.
Проблема возникает тогда, когда разрушается экран, который регулярно обновляется из фонового процесса. Например, прогресс-бар загрузки файла. Для решения это проблемы следует отвязывать асинхронные процессы от пользовательского интерфейса — для этого в Андроиде существует стандартное средство — сервисы.
Работа с сетью
Согласно закону Мерфи, неприятность случается всегда. Но особенно часто неприятность случается, когда мы используем GPRS соединение. На деcктопе, как правило, всё просто — интернет либо есть, либо его нет. Но в программе для мобильного устройства мало предусмотреть возможность разрыва соединения в любой момент. Следует так же предусмотреть ситуацию, когда скорость соединения станет чрезвычайно низкой, но соединение всё же не будет разорвано (падением скорости грешат многие тарифы с «безлимитным» интернетом). Иногда операторы сотовой связи вторгаются в передаваемый трафик, вставляя в ответы сервиса, например, информацию о балансе. Эту ситуацию также следует иметь ввиду.
Кроме того, частые соединения с сетью быстро сажают батарею, поэтому желательно минимизировать количество соединений, кешируя данные.
Хранение данных
Сложность в том, что на скорость доступа к карте памяти очень сильно зависит от модели этой карты. Сейчас в продаже есть карты со скоростью чтения от 10 до 50 Мбс и со скоростью записи от 2 до 40 Мбс. Разница в 5 раз для чтения и в 20 раз для записи! Как правило, даже пользователи топовых моделей устройств абсолютно не задумываются об используемой карте памяти. Если приложение будет слишком активно читать или писать на карту памяти, работа замедлится. Опять-таки, как и в случае с интернет-соединением, для часто используемых данных следует продумать механизм кеширования.
Заключение
Под Android мы разрабатываем чуть больше года. Сейчас у нас в Play Store выложено пять приложений:
- Право.ru — клиент для одноимённой справочно-правовой системы
- Две версии Картотеки арбитражных дел — старая и новая
- Где суд? — справочная информация о любом из 113 судов Российской Федерации
- Selloby — мобильный сервис частных объявлений
Мы активно дорабатываем эти приложения, прислушиваясь ко всем пожеланиям пользователей. А на подхоже ещё несколько программ, о которых я пока не стану говорить.
Фото в начале статьи — Дмитрий Нечаев
Автор: ilichme
