Как мы делали мобильное приложение для ФК «ЗЕНИТ» и нарвались на аудит

Здравствуйте! На связи Максим Кульгин, компания Notissimus, мы много лет разрабатываем мобильные приложения. Сегодня расскажем про необычный кейс. Заказчик устроил нам целый аудит: нанял экспертов, они штудировали наш код, делали замеры. Рассказываем, как это было и чем всё закончилось — будет интересно и разработчикам, и пользователям!

«Зенит» — знаменитый футбольный клуб Санкт-Петербурга, за который болеют целыми поколениями. Ещё немного — и «Зенит» отпразднует свой столетний юбилей!

Всех достижений ФК «Зенит» за долгую историю и не счесть: обладатель Кубка СССР 1944, чемпион СССР 1984, многократный чемпион и обладатель Кубка России, Кубка УЕФА 2007 и 2008, Суперкубка УЕФА 2008, многократный обладатель Суперкубка России… И это не считая чуть менее звездных соревнований и товарищеских встреч!

Коммерческих конкурентов у ФК «Зенит» нет. Есть уже своя устоявшаяся аудитория: фанаты и болельщики из Санкт-Петербурга, а также других городов — ведь «Зенит» выходит далеко за границы местного клуба. Даже простые петербуржцы, объятые информационным ажиотажем, волей-неволей становятся болельщиками, когда бело-голубые знамена заполняют все городские билборды и первые полосы местных газет.

Конечно, руководство клуба делает всё возможное, чтобы дать болельщикам максимум удобства: легкий заказ билетов, всевозможные оповещения и уведомления, тотализатор. И тут никак не обойтись без мобильного приложения.

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

Самое главное — пользоваться мобильным приложением гораздо удобнее, чем сайтом.

Например. Пользователь может получать push-уведомления всех типов и, таким образом, следить за матчем, не отвлекаясь от дел. В браузер не придёт звуковое оповещение. Даже если в браузере и покажется какое-то всплывающее окошечко, оно не сможет быть таким же информативным, не сможет так же надежно привлечь и удерживать внимание пользователя. В мобильном приложении всё иначе.

Поэтому на мобильные приложения есть устойчивый спрос. Они «заточены» на определенные действия пользователей, всё — «в одно касание»: минимальные усилия для навигации, всё нужное под рукой, всё всегда рядом.

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

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

Наше сотрудничество с ФК «Зенит» началось в 2015 году.

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

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

Приложения одного типа чем-то похожи. Например, все приложения интернет-магазинов имеют примерно одинаковую структуру и особенности. То же самое можно сказать и про спортивные приложения. Мобильное приложение для ФК «Зенит» — не первое из разряда спортивных, которое мы делаем. Разумеется, есть отличия. Но по своей архитектуре, по своему строению спортивные приложения тоже довольно близки.

С точки зрения архитектуры и сервер, и бекенд — полностью на стороне ФК «Зенит». Дополнительно мы сделали сервер push-уведомлений, но он тоже разместился на стороне заказчика.

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

Ещё один источник непростых решений — интеграция со сторонними сервисами. Приложение ФК «Зенит» имеет несколько внешних независимых сервисов, взаимодействие с которыми должно быть отзывчивым и незаметным. Приведем несколько примеров.

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

Сервер push-уведомлений для триггерных событий работает независимо и тоже интегрирован в приложение. Все события из жизни команды — встреча с соперником, забитый гол и тому подобное — поступают на главный сервер. Тот, в свою очередь, взаимодействует с сервером push-уведомлений. В приложении есть возможность настроить перечень уведомлений, благодаря чему пользователь может оставаться в курсе интересующих его событий.

Первый тест всегда комом.

И вот, наконец, подходим к основной части рассказа — мы столкнулись с тем, что ещё не встречалось в нашей практике.

У ФК «Зенит» возник вопрос: почему иногда приложение отрабатывает медленно?

Для наглядности был выполнен небольшой эксперимент.

Участвовало три устройства: одна из последних моделей iPhone и два Android — среднего и низкого ценового сегмента. Приложение одновременно запустили на всех трёх устройствах-участниках.

Несложно догадаться, что первым отработал iPhone, затем (практически сразу) производительный Android и, наконец, с заметным отставанием слабенький Android.

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

Представители ФК «Зенит» поступили очень профессионально. Они внимательно изучили полученную от нас информацию, поблагодарили и… нашли компанию для получения независимой оценки.

Задача аудита состояла в анализе программного кода и замеров скорости работы приложения.

Действительно, приложение долго отрабатывает на старте — это неоднозначный момент. Эксперимент продолжился, но уже на совсем ином уровне. Аудиторская компания провела большое исследование, по итогу которого подготовила несколько отчетов.

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

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

Особенности проверки исходного кода были следующие:

По итогам аудита выяснилось, что:

При проверке исходного кода было определено, что выбранные библиотеки для работы с сетью соответствуют стандартам, но они не обновлены до последней доступной версии. Соответственно, от аудиторов поступила ожидаемая рекомендация — обновить выбранные библиотеки до последних версий с целью «поддержания текущих систем и стандартов шифрования данных». По мнению экспертов это теоретически могло помочь увеличить производительность, а также исправить существующие ошибки, сказывающиеся на работе Xamarin и нативных библиотек.

Вторая часть аудиторской работы состояла в тестировании отзывчивости.

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

Для аудита скорости было составлено 6 сценариев, проработано 11 параметров измерений.

Были получены следующие выводы и рекомендации:

Кроме того, были сделаны довольно обширные выводы по WebView.

Страницы с объемным контентом (например, такие как просмотр матча), реализованные в WebView, могут достаточно долго подгружаться: 15−20 c вместо ориентировочных 8−12 c. Работа с WebView осуществляется со ссылкой на основной сайт, и все проблемы, связанные с производительностью, в данном случае привязаны к производительности сайта. Рекомендовалось такие страницы перенести на нативную технологию.

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

Что можно сказать?

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

Все подробности ниже.

По результатам аудита получилась сводная таблица того, что можно улучшить.

Рекомендация обновить проекты с Net Standard — это как раз то, что мы сейчас и делаем. Процесс этот не простой и не быстрый. Поддержка Xamarin заканчивается в мае 2024 года, и мы за полгода начинаем переход. Обновление Xamarin — отдельная задача, которая касается всех проектов, обновление затронет все разработанные нами приложения, а не только ФК «Зенит».

Также можно обновить библиотеки по работе с сетью до последней стабильной версии на Android. Однако ошибки сети чрезвычайно редки. Обновление сделать можно, но это никак не повлияет на производительность.

Основное наше несогласие сводилось к разному видению подходов, используемых при создании пользовательского интерфейса.

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

Замена иконок формата png на векторные pdf для iOS — неоправданная замена, которая ни на скорость, ни на качество не повлияет. Тогда уж для iOS лучше превратить все картинки resource-png в imageset (универсальный контейнер от Apple, в котором можно использовать различные дополнительные атрибуты, такие как переключение тёмной и светлой темы, выбор разных картинок для разных устройств и так далее).

Следующая рекомендация — избавиться от бинарных файлов xib для iOS. Во-первых, xib — не бинарный формат, а текстовый всё-таки. Во-вторых, замена этому решению — верстка кода, которая экспоненциально затрудняется с усложнением дизайна. Намного проще верстать экраны в удобном редакторе интерфейса XCode и сохранять результаты в xib.

Был аргумент, что если над файлом xib работает больше одного человека, то становится сложно разрешать конфликты. Теоретически да, если разработка распределенная и децентрализованная — над одним файлом может работать параллельно несколько человек. Только это не наш случай — у нас организация, все трудятся рядом в офисе и редко бывает, чтобы задачи программистов пересекались в пределах одного экрана. Замена xib попросту усложнит верстку.

Ещё одна спорная рекомендация — заменить компонент UITableView на UICollectionView для iOS. Аргументы были следующие: первый плохо справляется с расчетом высоты вложенных элементов, второй обладает асинхронной загрузкой и отображением данных.

Это совсем не так. UITableView отлично подходит для вертикальных списков, а проблемы с расчетом высоты случаются только при недостаточно профессиональной верстке. Волшебная асинхронность UICollectionView второго компонента тоже из разряда редкостей. Протокол же prefetching, который позволяет заранее работать с ячейками списков, имеется у обоих компонентов. Данные в любом случае грузятся в ViewModel заранее и асинхронно, а во View попадают после загрузки. Так или иначе, замена UITableView на UICollectionView не окажет влияния на производительность.

Что действительно влияет на скорость?

Приложение работает с компонентом WebView, который является серьезным испытанием для производительности. При этом происходит переход на сайт для получения и отображения ресурсов.

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

Состоялся тройственный созвон. Представители ФК «Зенит» подтвердили, что работа с WebView — их требование, такова постановка задачи. Подобное ограничение связано с тем, что сейчас в приоритете другие задачи и нет необходимости заново воспроизводить весь функционал на стороне мобильного приложения — для этого надо по сути создавать второй бэкенд с разработкой методов API и так далее. Поэтому часть функциональности реализована на сайте ФК «Зенит», что более чем оправдано.

В итоге аудит пошел на пользу всем. Аудиторская компания получила новый опыт, мы — дополнительную уверенность в своей экспертности, а ФК «Зенит» — чувство спокойствия и гарантию, что всё идет наилучшим образом.

Всё, что приводило к усложнению дальнейшей работы и было чревато нехорошими последствиями, мы отбросили. Некоторые доработки согласовали с ФК «Зенит» и взяли в работу.

Аудит завершился как нельзя лучше.

Мы уже рассказывали о нашей учетной системе, которая хорошо показала себя на многих проектах и оказалась настоящей находкой. Так вот, эту учетную систему мы создали, именно занимаясь разработкой приложения для ФК «Зенит».

Суть проста.

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

У себя мы ведем параллельно свою собственную систему учета задач. В левом столбце задачи заказчика, в правом — сопоставленные им наши задачи. Со стороны заказчика имеется только описание задачи и наши уточняющие вопросы по ней. С нашей стороны видно номер задачи, разработчиков, которые трудились над её реализацией, заголовок коммита.

Работать непосредственно в системе заказчика нам неудобно и некомфортно. Поэтому мы дублируем задачи из его системы в свою. Простая табличная система позволяет легко оперировать сущностями: сортировать, фильтровать по некоторым признакам (например, по статусу) и так далее.

Так как работы много, в дополнение ведется матрица сборок, где проставлены все задачи (и наши, и заказчика), указаны платформы, для которых были сделаны сборки, отдельно выделены релизные сборки и тому подобное. Такая матрица не дает запутаться в большом количестве промежуточных сборок и всегда четко показывает состояние проекта.

Задач много, ФК «Зенит» постоянно добавляет новые. С нашей учетной системой мы чувствуем, что всё под контролем и эта уверенность неизменно передается заказчику.

Всегда есть технические рабочие моменты.

Например, сейчас мы добавляем интеграцию с сервисом, который отслеживает и анализирует действия пользователей в приложении для получения рекомендаций по оптимизации работы как самого приложения, так и бизнес-задач. Это тоже длительный процесс и наверняка придется задуматься о каких-то нюансах. Отметим высокий профессионализм представителей заказчика — работать с ними не только эффективно, но и приятно.

Не бывает беспроблемных проектов. Каждая проблема — это победа. И сотни тысяч довольных пользователей тому подтверждение.

Напоминаю, что регулярно описываю наш опыт в Телеграме-канале «Русский ИТ бизнес».

Буду рад ответить в комментариях на все вопросы.

P. S. Возможно, вам также будет интересно почитать: