Підготовка Android-асетів: mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi

Підготовка асетів Android: де ламається графіка в релізі

Найчастіша поломка в релізі — один майстер із макета, розтягнутий системою під конкретний екран. Розробник кладе картинку в єдину папку, і на великому флагмані або планшеті іконка приходить розмитою: система інтерполює растр угору.

Зворотна ситуація — у проєкт склали файл під кожен клас щільності, і вага збірки застосунку зросла в рази без жодного нового екрана.

Android вибирає ресурс за класом щільності — від mdpi до xxxhdpi — і при промаху бере найближчий і масштабує. Звідси й розбіжності між макетом і тим, що бачить користувач: зсунуті відступи, обрізані краї, інша товщина обведення.

Адаптивна іконка android додає свій шар проблем: передній і задній плани лежать окремо, і логотип поза безпечною зоною зрізається маскою лаунчера на частині пристроїв.

Вага й чіткість лікуються одним правилом — як саме асет потрапляє в проєкт.

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

Розбираємо, як закривається підготовка асетів Android: які перевірки ставимо на макети до верстки, як налаштовуємо генерацію з майстер-файлу і куди дивимося, коли макет розходиться з реальним екраном.

Що дає керований набір асетів мобільному застосунку

Щільності екранів кратні базовій: mdpi, hdpi, xhdpi, xxhdpi і xxxhdpi — це крок 1×, 1.5×, 2×, 3× і 4×.

Графіка збирається один раз за цими коефіцієнтами, тому на будь-якому пристрої іконка, ілюстрація та фон потрапляють у свій слот без інтерполяції на боці системи — зображення залишається різким, а пропорції та відступи не роз’їжджаються.

Спільне джерело істини для палітри, заокруглень і товщини ліній тримає єдиний стиль інтерфейсу; ту саму логіку масштабування описує Material Design.

Різниця проявляється в артефактах збірки. Растрова іконка, розкладена по п’яти каталогах, важить рівно в п’ять разів більше за одну копію — ця вага переходить у вагу apk і aab, а разом із нею зростає час збірки релізу та розмір оновлення, яке завантажує користувач.

Окремо рахуємо частку відмов установлення: чим більший пакет, тим частіше переривається завантаження на слабкому зв’язку.

Оптимізація графіки застосунку починається з відмови від растру там, де немає фото й градієнтів: векторні іконки, розтягувані фони під різний контент, сучасний формат стиснення для фотоматеріалів.

Стиснення зображень без утрати якості перевіряємо порівнянням з еталоном на контрольних екранах, а не «на око», і тільки після цього закріплюємо коефіцієнт у правилах збірки.

Правки оформлення коштують однієї правки вихідника, а не синхронного оновлення п’яти копій: макет змінюється швидше, реліз збирається передбачуваніше, візуальна перевірка зводиться до кількох еталонних роздільних здатностей.

Способи роботи з графікою: варіанти й обмеження

На Android ресурс підбирається під щільність екрана: система сама бере відповідну копію, і від того, які варіанти ми поклали, залежить різкість іконки на щільному екрані та вага збірки на інших.

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

Універсального способу немає: фото живе тільки в расті, іконки вигідніше тримати вектором, масові елементи дешевше нарізати автоматично. Нижче варіанти, між якими реально обирають.

На практиці підходи комбінують: вектор — для інтерфейсу, растр — для контенту, автоматизація — для масових наборів. Ми задаємо правило за замовчуванням для проєкту й перевіряємо результат на матриці екранів, щоб різкість і вага не розходилися з очікуваннями дизайну.

Етапи впровадження: від інвентаризації до передачі команді

Перш ніж різати графіку, збираємо повну картину: де лежать вихідники, хто їх оновлює, які екрани вже розходяться за щільностями. Порядок кроків фіксований — пропущена інвентаризація обертається неповною схемою та мутними зображеннями на частині пристроїв при першому ж оновленні.

1. Аудит графічних ресурсів. Звіряємо макети з тим, що реально лежить у проєкті: знаходимо дублі, розтягнуті растрові копії, іконки, намальовані під одну щільність, і картинки в загальному каталозі без розбивки.
2. Схема нарізки ресурсів. Визначаємо набір щільнісних каталогів (від mdpi до xxxhdpi), правила іменування та те, що віддається вектором, а що растром — вектор закриває масштабування й прибирає зайві копії.
3. Налаштування збірки ресурсів. Підключаємо автоматичну генерацію наборів із майстер-файлів: нова іконка більше не з’являється вручну в п’яти каталогах і не губиться під час злиття гілок.
4. Оптимізація ваги. Перетискаємо растри, прибираємо невикористовувані файли й стежимо, щоб розмір постачання не зростав із кожною ітерацією дизайну.
5. Перевірка на пристроях. Проганяємо ключові екрани на апаратах з різною щільністю та діагоналлю: дивимося обрізання, розмиття, артефакти масштабування й час установлення збірки.
6. Передача документації. Віддаємо команді карту ресурсів, правила іменування, конфігурацію збірки та регламент додавання нової графіки — оновлення перестає бути ручною операцією.

Набори графіки, правила нарізки та регламенти передачі

Готовий комплект графіки — це не папка з картинками, а структура, яку стороння команда розгортає без листування та уточнень. Передаємо її разом із правилами: що де лежить, як називається кожен файл і що робити, коли макет оновився. Нижче — перелік артефактів, які замовник отримує на руки.

• Структура каталогів ресурсів: набори розкладені за щільностями — від mdpi до xxxhdpi, окремо загальні та тематичні групи. Нова графіка лягає у свою гілку, а не розповзається по кореню проєкту.
• Правила іменування файлів: тільки латиниця, нижній регістр, префікс за екраном і суфікс за щільністю та станом — звичайне, натиснуте, недоступне. Ім’я файлу саме пояснює призначення, без заходу в макет.
• Карта ресурсів: таблиця «елемент інтерфейсу → файл → де використовується». За нею будь-який елемент знаходиться за хвилину, а не пошуком по всьому каталогу.
• Векторні та тягнуті елементи: іконки й фони віддаємо в редагованому вигляді, растрові копії залишаються тільки там, де потрібна фактура. Це знімає перезбірку під нові роздільні здатності.
• Регламент оновлення графіки: хто ініціює перезбірку, які щільності перезбираються, як перевіряється, що застарілі набори видалені, а не лежать поруч із новими.
• Документація з ресурсів: призначення комплекту, ліміти за кількістю та масою файлів на екран — збірка перестає зростати від релізу до релізу.
• Вихідники та майстер-файли: шари, напрямні, текст без растеризації. Будь-яка правка робиться за майстром, без утрати якості та повторної відрисовки.

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

Кейс: прибрали розмиття на великих екранах і зайву вагу

Перед нами був інтерфейс, який на планшетах і великих флагманах виглядав відверто м’яким: під графіку лежав один набір растрових картинок, і система розтягувала його до потрібної щільності вже в момент відрисовки.

Паралельно кожен екран тягнув власні повнорозмірні файли, частина з яких не використовувалася взагалі.

Що зробили

• Розклали графіку за п’ятьма наборами щільності — mdpi, hdpi, xhdpi, xxhdpi і xxxhdpi, — щоб система брала готовий файл потрібного масштабу, а не рахувала його на ходу.
• Іконки, індикатори та лінійні елементи перевели у вектор: вони перестали залежати від щільності екрана зовсім.
• Розтягувані фони та кнопки зібрали в дев’ятисегментні картинки — замість десятка окремих зображень під кожен стан.
• Прописали правила експорту прямо в макетах Figma, щоб нові екрани не повертали проблему.
• Вичистили дублі та невикористовувані файли, залишивши на кожен логічний ресурс рівно один вихідник.

Результат

Вага застосунку впала з 68 до 41 МБ — майже на 40%, хоча наборів графіки стало більше. Розмиття на великих екранах зникло повністю: масштабування з растру більше не виконується.

Збірка ресурсів перестала бути найдовшою частиною релізу, а дизайнери віддають макет за одним набором правил замість листування з розробкою.

Чим векторна графіка відрізняється від растрової в проєкті

Растр зберігає готові пікселі, вектор — геометрію та правила її відрисовки. Поки зображення виводиться в початковому розмірі, різниці не видно, але при масштабуванні графіки растр інтерполюється й контури втрачають різкість, а вектор перераховується під потрібну щільність екрана.

Для Android вибір формату — це завжди компроміс між різкістю на різних екранах і вагою застосунку:

Правило просте: іконки та ілюстрації йдуть у вектор, фотоматеріал і текстури залишаються растром. Змішування форматів навпомацки дає або розмиті елементи на великих екранах, або зайві сотні кілобайтів у збірці на кожен розмір.

Ми фіксуємо це правило в регламенті проєкту й перевіряємо на етапі збірки: зайві растрові копії не потрапляють у застосунок, а іконки не розростаються в кілька файлів на кожну щільність.

Технічні сумніви, які варто зняти до старту

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

Перегляду архітектури жодне з них не потребує, але кожне впливає на обсяг підготовки асетів і на строки. Нижче — короткі відповіді, щоб зняти сумніви до оцінки.

Чи можна змінити графіку, не випускаючи нову версію?

Частину оформлення — так: банери, промо-блоки та сезонні добірки виносимо у віддалений набір ресурсів, він змінюється на боці сервера. Іконка, екран запуску та елементи навігації залишаються всередині збірки.

Перелік того й іншого фіксуємо до старту, щоб потім не з’ясувалося, що потрібний блок не можна оновити без публікації.

У нас немає вихідних макетів — тільки скриншоти

Логотип переводимо у вектор, великі елементи масштабуємо, дрібні деталі та напівпрозорі шари перемальовуємо за сіткою. Обсяг такої роботи залежить від того, що збереглося, — оцінюємо його після перегляду матеріалів.

Темна тема — це другий комплект графіки?

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

Обговоримо задачу: що надіслати для оцінки обсягу робіт

Щільності екранів — головне джерело неочевидного обсягу: одна іконка перетворюється на п’ять наборів, а ілюстрація в банері — на окрему експортну гілку. Щоб оцінка обсягу робіт спиралася на факти, а не на здогадки, потрібні вихідники та перелік екранів, де ці асети живуть.

Нижче — мінімальний набір вхідних даних; за ним ми рахуємо трудовитрати й повертаємося з планом робіт із графіки.

• Вихідники у векторі або шарах: майстер-файли іконок, логотипів, ілюстрацій — з роздільними шарами, а не «сплющеними» копіями.
• Перелік щільностей: чи потрібні mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi повністю або десь достатньо двох-трьох наборів.
• Список екранів і станів: де асет з’являється, в якому розмірі, з якими варіантами — натискання, вимкнено, завантаження, помилка.
• Іконка застосунку та системні елементи: основний значок, адаптивний і круглий варіанти, фон із переднім шаром, картинка для магазину.
• Вимоги до форматів: прозорість, WebP або PNG, допустима вага файлу та втрата якості при стисненні.
• Темна тема, додаткові теми оформлення та мовні версії — якщо макетів більше одного.
• Референси та дизайн-система: палітра, сітка, відступи, уже зібрані експорти — щоб не перезбирати те, що працює.

Для обговорення задачі достатньо описати продукт і надіслати те, що вже є. Прогалини в списку не блокують оцінку — відсутні вхідні дані ми уточнюємо питаннями та виносимо окремим пунктом у план робіт.