Системний дизайн мобільних застосунків давно вийшов за межі вибору «MVVM чи MVI» та улюбленої бібліотеки для мережі. Для розробників, які готуються до співбесід або проєктують складні продукти, ключовим стає інше запитання: що саме має робити застосунок і за яких умов він повинен це робити.
У розмові про системний дизайн мобільних застосунків Android‑розробник та автор освітнього контенту Філіп Лакнер розкладає цей процес на зрозумілі кроки: від формулювання вимог до вибору архітектури й технічних рішень. Центральна ідея — чітко розділяти функціональні та нефункціональні вимоги й усвідомлено будувати навколо них дизайн системи.
З чого починається системний дизайн: не з коду, а з вимог
Початковий рівень системного дизайну — це не діаграми класів і не вибір бази даних. Це опис того, для кого створюється застосунок, які задачі він вирішує і в яких умовах працює.
Перший крок — визначити користувацьку базу. Вік, технічна обізнаність, тип пристроїв, регіони, мови, навіть професія — усе це безпосередньо впливає на те, яким буде застосунок. Якщо цільова аудиторія — молоді користувачі з новими смартфонами, можна сміливіше використовувати сучасні API, складніші анімації, більш насичені інтерфейси. Якщо ж продукт орієнтований на старшу аудиторію, картина кардинально змінюється.
Для старших або менш технічно підкованих користувачів доводиться закладати інші UX‑принципи: більші шрифти, простіші сценарії, мінімум прихованих жестів, очевидні кнопки й підказки. До цього додається ще один важливий наслідок: підтримка старіших Android‑пристроїв і версій ОС. Це автоматично обмежує доступні технології, впливає на вибір бібліотек, підхід до оптимізації пам’яті й продуктивності.
Другий крок — перелік функцій. Не на рівні «це соцмережа», а на рівні конкретних можливостей: профіль користувача, стрічка постів, список друзів, редагування профілю, редактор постів, система підписок. На цьому етапі важливо не думати про те, як це реалізувати, а зафіксувати, що саме має бути в продукті.
Саме тут починається формалізація функціональних вимог — опису того, що застосунок повинен уміти робити. Наприклад, якщо є профіль, то користувач має мати змогу завантажити аватар, змінити ім’я користувача, мати приховану e‑mail‑адресу, яка не відображається публічно. Це конкретні, перевірювані можливості, які можна протестувати: «може / не може», «працює / не працює».
Лише після того, як список функцій і сценаріїв зрозумілий, має сенс переходити до обговорення архітектури й технічних деталей. Інакше є ризик витратити час на елегантну реалізацію того, що взагалі не потрібне продукту.
Функціональні проти нефункціональних: що робить застосунок і як саме він це робить
У системному дизайні важливо чітко розділяти два типи вимог. Функціональні відповідають на запитання «що застосунок робить». Нефункціональні — «як саме він це робить за різних умов».
Функціональні вимоги описують поведінку системи. Умовна соцмережа повинна дозволяти реєстрацію, авторизацію, створення постів, підписку на інших користувачів, перегляд стрічки, коментування. Для кожної функції можна розписати деталі: які поля є в профілі, які типи медіа підтримуються, які обмеження на довжину тексту, чи можна редагувати пости після публікації.
Нефункціональні вимоги не додають нових можливостей, але визначають якість і характеристики роботи цих можливостей. Сюди потрапляють час запуску застосунку, розмір APK, затримки мережі, споживання батареї, використання пам’яті, поведінка за нестабільного інтернету, локалізація, масштабованість.
Це не «додаткові побажання», а повноцінні драйвери архітектурних рішень. Наприклад, вимога «застосунок повинен запускатися менш ніж за X мілісекунд» вплине на те, що саме ініціалізується під час старту, а що відкладається. Обмеження на розмір APK змусить переглянути набір бібліотек, підхід до ресурсів, використання нативного коду. Вимога до мережевої затримки визначить, чи можна дозволити собі важкі запити, чи потрібно агресивно кешувати дані й мінімізувати кількість звернень до сервера.
У добре спроєктованому мобільному застосунку нефункціональні вимоги формулюються так само явно, як і функціональні. Наприклад, можна задати цільове споживання батареї на 10 хвилин активного використання, максимальний обсяг оперативної пам’яті для певного екрану, допустимий час відгуку на дії користувача. Це перетворює абстрактне «має працювати швидко» на конкретні критерії, під які вже можна підбирати технічні рішення.
Нефункціональні вимоги мобільних застосунків: батарея, мережа, пам’ять, локалізація
У мобільному світі нефункціональні вимоги часто важливіші за сам набір функцій. Два застосунки можуть уміти одне й те саме, але той, що швидше запускається, менше «їсть» батарею й не ламається в метро, виграє ринок.
Одним із ключових параметрів стає споживання батареї. Постійні real‑time‑з’єднання, інтенсивна обробка медіа, часті фонові задачі — усе це швидко розряджає пристрій. Якщо в нефункціональних вимогах зафіксовано обмеження на використання батареї, це автоматично впливає на дизайн: кількість одночасних real‑time‑з’єднань, частоту оновлення даних, підхід до push‑сповіщень, обробку медіа на клієнті проти сервера.
Другий критичний блок — мережеві умови. Важливо не тільки те, що застосунок працює з інтернетом, а й те, де й як саме користувачі ним користуються. Якщо основний сценарій — робота вдома чи в офісі зі стабільним Wi‑Fi, можна розраховувати на відносно надійний канал. Якщо ж застосунок активно використовують «у полі» — у транспорті, на вулиці, у зонах зі слабким покриттям — дизайн доведеться будувати з урахуванням постійних обривів, затримок, падіння швидкості.
Це означає іншу стратегію повторних спроб, кешування, чергування запитів, обробки помилок. Застосунок має коректно переживати ситуації, коли користувач заходить у тунель, втрачає зв’язок, а потім знову його отримує. Нефункціональна вимога «поведінка за нестабільної мережі» перетворюється на конкретні рішення: які дані зберігати локально, які операції можна виконувати офлайн, як синхронізуватися після відновлення зв’язку.
Третій аспект — використання пам’яті. На мобільних пристроях RAM обмежена, особливо якщо йдеться про старі Android‑моделі, які все ще масово в обігу. Робота з великими файлами, наприклад відео чи високоякісними зображеннями, вимагає обережності. Замість того, щоб завантажувати весь файл у пам’ять, доводиться розбивати його на частини, використовувати потокову обробку, chunked‑завантаження. Це не просто оптимізація, а відповідь на нефункціональну вимогу «не виходити за межі доступної пам’яті й не падати з OutOfMemory».
До нефункціональних вимог також належать продуктивність і час запуску. Якщо встановлено цільовий час старту, архітектура має мінімізувати важкі операції в onCreate, відкладати ініціалізацію другорядних сервісів, використовувати lazy‑завантаження. Обмеження на розмір APK змушує відмовлятися від надлишкових бібліотек, оптимізувати ресурси, обережно ставитися до вбудованих шрифтів і зображень.
Локалізація виходить за межі перекладу текстів. Потрібно враховувати підтримку різних мов і регіонів, формати дат і чисел, а також специфічні вимоги на кшталт підтримки right‑to‑left‑інтерфейсів для арабських мов. Це впливає на верстку, компонування елементів, вибір UI‑компонентів, які коректно працюють у двох напрямках.
Нарешті, масштабованість. Хоча основний тягар масштабування зазвичай лягає на бекенд, кількість користувачів і обсяг даних впливають і на мобільний клієнт. Якщо кожен користувач потенційно може мати величезну кількість записів, чатів, медіа, застосунок має бути готовий до роботи з великими списками, агресивного кешування, продуманої пагінації.
Коли користувачі старші: старі Android‑пристрої й інший UX за замовчуванням
Вікова й технічна характеристика аудиторії — один із найсильніших факторів, що впливають на системний дизайн. Якщо цільова група — люди старшого віку, це автоматично створює низку нефункціональних вимог.
По‑перше, підтримка старіших пристроїв. Багато користувачів похилого віку не оновлюють смартфони щороку й часто користуються моделями кількарічної давності. Це означає старіші версії Android, менший обсяг оперативної пам’яті, повільніші процесори, гірші модулі зв’язку. Вимога «застосунок повинен коректно працювати на таких пристроях» впливає на вибір мінімальної версії SDK, використання важких анімацій, обсяг кешу, підхід до фонових задач.
По‑друге, UX‑принципи. Інтерфейс для старшої аудиторії має бути максимально «дуростійким» — із великими клікабельними зонами, очевидними кнопками, мінімумом прихованих функцій, зрозумілими повідомленнями про помилки. Складні жести, багаторівневі меню, агресивні анімації, дрібний текст — усе це стає ризиком, а не перевагою.
По‑третє, очікування від стабільності. Менш технічно обізнані користувачі гірше переносять збої, незрозумілі стани, «зависання» інтерфейсу. Для них нефункціональні вимоги до надійності й передбачуваності поведінки застосунку стають критичними. Це означає більш консервативний підхід до експериментів, ретельніше тестування на реальних пристроях, продуману обробку помилок мережі й бекенду.
Ці фактори не просто впливають на дизайн екранів. Вони змінюють пріоритети в архітектурі: відмова від надмірно складних патернів, які важко підтримувати на старих пристроях, спрощення навігації, обмеження кількості одночасно активних фонових процесів. Усе це — прямий наслідок нефункціональних вимог, що випливають із портрета користувача.
WhatsApp як приклад: коли нефункціональні вимоги керують усім дизайном
Класичний приклад, який часто з’являється на співбесідах із системного дизайну, — месенджер на кшталт WhatsApp. На перший погляд, його функціональні вимоги досить прості: обмін текстовими повідомленнями, надсилання медіа, групові чати, дзвінки. Але справжня складність ховається в нефункціональних вимогах.
Для такого застосунку критично важливі швидкість обміну повідомленнями й надійність роботи за нестабільної мережі. Користувач очікує, що повідомлення буде відправлено й доставлено максимально швидко, навіть якщо він у поїзді, у тунелі чи в зоні з поганим покриттям. Це означає, що дизайн має враховувати часті обриви з’єднання, повторні спроби відправлення, локальне кешування повідомлень, чіткі стани «відправлено / доставлено / прочитано».
Ще одна ключова вимога — мінімальне споживання батареї. Месенджер — це застосунок, який працює постійно: у фоні, з push‑сповіщеннями, із періодичними синхронізаціями. Якщо він надто агресивно використовує мережу чи тримає забагато активних з’єднань, батарея тане на очах. Тому нефункціональна вимога «мінімізувати споживання енергії» стає одним із головних драйверів рішень: скільки одночасних real‑time‑з’єднань допустимо, як організувати фонову синхронізацію, як часто оновлювати статуси.
Окрема проблема — довга історія чатів. Користувачі можуть мати роки листування з тисячами повідомлень і сотнями медіафайлів у кожному чаті. Якщо спробувати завантажити всю історію одразу, застосунок швидко упреться в обмеження пам’яті й продуктивності. Звідси випливають явні нефункціональні вимоги до роботи зі списками: обов’язкова пагінація, підвантаження історії частинами, оптимізована робота зі скролом.
Це стосується й медіа. Повноцінні зображення й відео занадто важкі, щоб завантажувати їх усі одразу в чаті. Тому дизайн передбачає роботу з мініатюрами: зберігання й відображення невеликих прев’ю, відкладене завантаження повнорозмірних файлів, кешування часто використовуваних медіа. Усе це — відповідь на нефункціональні вимоги щодо продуктивності, пам’яті, мережевих витрат.
У результаті саме нефункціональні вимоги — швидкість, надійність за поганого зв’язку, економія батареї, ефективна робота з великими історіями — визначають архітектуру месенджера значно сильніше, ніж перелік функцій. І це хороший приклад того, як системний дизайн у мобільному світі починається не з вибору патерну, а з чесної відповіді на запитання: у яких реальних умовах житиме цей застосунок.
Висновок: системний дизайн починається з правильних запитань
У мобільній розробці системний дизайн — це не спроба вгадати, як влаштований продакшн‑WhatsApp чи Instagram. Це вміння послідовно пройти шлях від ідеї продукту до чітко сформульованих функціональних і нефункціональних вимог, а вже потім — до архітектури й технічних рішень.
Спочатку потрібно зрозуміти, хто користуватиметься застосунком, у яких умовах, на яких пристроях і з якими очікуваннями. Потім — явно перелічити функції й розкласти їх на конкретні функціональні вимоги. Паралельно — зафіксувати нефункціональні вимоги: до батареї, мережі, пам’яті, продуктивності, локалізації, масштабованості.
Саме ці нефункціональні обмеження часто визначають, як виглядатиме архітектура, які протоколи зв’язку буде обрано, як організують кешування й роботу зі списками, як поводитиметься застосунок за нестабільного інтернету. Приклади на кшталт WhatsApp лише підкреслюють: у реальних продуктах саме «як» часто важливіше за «що».
Для розробників, які готуються до співбесід із системного дизайну або планують складні мобільні продукти, це означає одне: перш ніж говорити про MVVM, GraphQL чи WebSockets, варто навчитися ставити правильні запитання про користувачів, сценарії й обмеження. Відповіді на них і є справжнім фундаментом системного дизайну.
Джерело
Beginner’s Guide to Mobile App System Design (+ Tips for Interviews!)