Телеграм-каналы

ViewPager2. Подглядываем красиво

#mobile_native #android #java

20 ноября 2019 года вышла в релиз стабильная версия нового инструмента для пошагового показа экранов в ОС Android — ViewPager2. Переход с первой версии облегчается преемственностью синтаксиса ViewPager. Также новый компонент использует адаптеры на основе абстрактных классов RecyclerView.Adapter или FragmentStateAdapter при работе с фрагментом.

Произведем инициализацию ViewPager2 таким образом, чтобы были видны половинки предыдущей и последующей страниц.

Реализуем свой адаптер и сверстаем элемент, используемый в нем. YourAdapter готов к работе.

Реализацию фрагмента, содержащего ViewPager2, можно посмотреть здесь.

Необходимо заставить объект viewPager игнорировать padding-ограничения. За это отвечают строки 14 и 15 класса YourFragment.java.

В качестве объекта-трансформера страницы мы устанавливаем экземпляр класса YourPagerTransformer, который позволяет показывать часть левого и правого элемента списка при скролле.

Если ширина экрана WIDTH пикселей, а контент в layout/item.xml занимает x пикселей, то величина marginPx, которая будет передаваться в YourPagerTransformer, должна находиться в пределах WIDTH - x < marginPx < (WIDTH - x) / 2, чтобы левый и правый элемент были видны. Иначе они сдвинутся недостаточно далеко, чтобы показаться, или наложатся друг на друга.

Стоит отметить, что с помощью различных реализаций PageTransformer можно применять разные эффекты прокрутки.

Отлично, оптимизируем дальше

#backend #php #orm

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

Первоначально, в пострелизный период, сервис хранил и обрабатывал около 300 квартир с сопутствующими номенклатурными данными. Для обеспечения реактивности интерфейсов и удобства вывода данные о сущностях и их атрибутах собирались в единую структуру. Это позволяло достаточно быстро перестраивать клиентский вывод без дополнительных REST-запросов, при этом фильтруя и сортируя данные.

Сервис развивался, и в какой-то момент нам выгрузили 1200 квартир. С учетом всех реляций количество связанных объектов стало достаточно большим — на одну квартиру приходилось около 12 связанных объектов с нетривиальной выборкой через ActiveRecord-модели. Конечный набор json-данных стал формироваться за 4 секунды.

«Хватит это терпеть», — сказал разработчик Илья и принялся оптимизировать, вооружившись профайлером и литром пива. Исходные данные профайлера: 4 секунды, 64 Мб памяти и более 140 запросов в Б. Д. Используя эти данные, мы добавили недостающие индексы по ключам на уровне СУБД, а самое главное — мы оптимизировали реляции в ActiveRecord-моделях и сократили количество запросов к Б. Д. После первой итерации профайлер показал следующее: 3 секунды, 32 Мб памяти и 80 запросов в БД.

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

После этой итерации мы получили следующие результаты: 1,5 секунды исполнения, 24 Мб и 54 запроса. Профайлер показал, что бОльшая часть времени тратится на манипуляции с ActiveRecord-моделями — инициализация и маппинг данных в объекты.

«Не на массивах же все это делать»

На последнем этапе оптимизации мы отказались от использования ORM. ActiveRecord-модели были заменены на заполнение простых DTO-объектов. Общение с БД и выборку данных мы реализовали через построитель запросов фреймворка Yii. Финальный результат: 0,4 секунды, 18 Мб памяти и около 32 запросов в БД.

Отлично, оптимизируем дальше

#backend #php

Разрабатывая веб-сервис для крупного застройщика, мы сделали ставку на архитектуру проекта для удобства сопровождения и расширения. В [прошлой заметки](https://t.me/chulakov_dev/103) мы рассказали про оптимизацию импорта с сохранением удобства разработки, а сегодня поделимся судьбой импортированных данных при доставке их конечному пользователю.

Первоначально, в пострелизный период, сервис хранил и обрабатывал порядка 300 квартир с сопутствующими номенклатурными данными. Для обеспечения реактивности интерфейсов и удобства вывода, данные о сущностях и их атрибутах собирались в единую структуру. Это позволяло достаточно быстро перестраивать клиентский вывод без дополнительных REST-запросов, при этом фильтруя и сортируя данные.

Сервис развивался и в какой-то момент нам выгрузили 1200 квартир. С учетом всех реляций, количество связанных объектов стало достаточно большим — на одну квартиру приходилось порядка 16 связанных объектов с нетривиальной выборкой через ActiveRecord-модели. Формирование конечного набора json-данных стало работать около 4-х секунд.

«Хватит это терпеть», — сказал разработчик Илья и принялся оптимизировать, вооружившись профайлером и литром пива. Исходные данные профайлера: 4 секунды, 64 Мб памяти и более 140 запросов в Б. Д. Используя эти данные, нам удалось добавить недостающие индексы по ключам на уровне СУБД, а самое главное — мы оптимизировали реляции в ActiveRecord-моделях и сократили количество запросов к Б. Д. После первой итерации профайлер показал следующее: 3 секунды, 32 Мб памяти и 80 запросов в БД.

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

После этой итерации мы сократились до 1,5 секунд исполнения, 24 Мб и 54 запросов. Профайлер показал, что бОльшая часть времени тратится на манипуляции с ActiveRecord-моделями — инициализация и маппинг данных в объекты.

«Не на массивах же все это делать»

На последнем этапе оптимизации мы отказались от использования ORM. ActiveRecord-модели были заменены для заполнение простых [DTO-объектов](http://design-pattern.ru/patterns/data-transfer-object.html). Общение с БД и выборку данных мы реализовали через [построитель запросов](https://www.yiiframework.com/doc/guide/2.0/en/db-query-builder) фреймворка Yii. Финальный результат 0,4 секунды, 18 Мб памяти и порядка 32 запросов в БД.

Сделано в Лаборатории Студии Чулакова

Студия Олега Чулакова

Дизайн-студия № 1 в России по версии Tagline, лучший usability / UX в стране по версии Золотого Сайта.

Специализируется на создании сложных систем и сервисов для крупных компаний. Среди клиентов Студии Tele2, ИКЕА, МегаФон, БКС Банк, Yota и другие крупнейшие российские бренды.