Mobile system design base

Яка основна мета мобільних інтерв'ю з системного дизайну?

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

Яка мета етапу "Вступ (Introductions)" на інтерв'ю?

Метою є розтопити лід та підкреслити відповідні навички кандидата, коротко поділившись своїм досвідом.

Як визначається обсяг завдання (Defining The Task) під час інтерв'ю з системного дизайну?

Обсяг завдання може бути: Client-side Only (дизайн лише додатку), Client-side + API (дизайн додатку та API, найпоширеніший варіант), або Client-side + API + Backend (дизайн додатку, API та бекенду, менш імовірно). Важливо бути прозорим, якщо ваш досвід роботи з бекендом обмежений.

На які категорії слід розділяти вимоги під час етапу "Збір вимог (Gathering Requirements)"?

Вимоги слід категоризувати на Функціональні, Нефункціональні та Поза межами обговорення (Out-of-Scope).

Наведіть приклади функціональних вимог для завдання "Design Twitter Feed".

Для "Design Twitter Feed" функціональні вимоги можуть включати: користувачі можуть прокручувати нескінченну стрічку твітів, користувачі можуть "лайкати" твіт, та користувачі можуть переглядати коментарі для певного твіту (лише для читання).

Наведіть приклади нефункціональних вимог для завдання "Design Twitter Feed".

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

Наведіть приклади функцій, які зазвичай виходять за межі обговорення (Out-of-Scope) для інтерв'ю на тему "Design Twitter Feed".

Зазвичай поза межами обговорення є такі функції, як: Логін/Автентифікація, Надсилання твітів, Відстеження/Ретвіти та Аналітика.

Яка мета етапу "Уточнюючі питання (Clarifying Questions)" та які типи питань слід ставити?

Мета – надати "сигнал" інтерв'юеру щодо вашої обізнаності у виборі функцій, компромісах та потенційних проблемах. Слід ставити питання, що охоплюють різноманітні аспекти, такі як: підтримка ринків, очікувана кількість користувачів, розмір команди, цільові версії ОС та типи пристроїв, необхідні показники продуктивності, рівень консистентності даних, частота оновлення даних та очікувані типи медіа.

Які переваги створення "Діаграми високого рівня (High-Level Diagram)" під час інтерв'ю?

Діаграма високого рівня має такі переваги: управління часом (швидко окреслює систему), модульність (кожен компонент може бути окремим модулем для командної роботи) та кращі практики (відображає дизайн бекенд-систем та модель C4 для візуалізації архітектури). До типових компонентів належать: Backend, Push Provider, CDN (серверна сторона) та API Service, Persistence, Repository, Image Loader, Coordinator (клієнтська сторона).

Яка мета вступної частини інтерв'ю?

Мета вступної частини полягає в тому, щоб розтопити лід та підкреслити відповідні навички кандидата, коротко розповівши про свій релевантний досвід.

Які типові рівні деталізації завдання можуть бути представлені інтерв'юером під час визначення завдання?

Інтерв'юер може представити завдання на трьох рівнях деталізації:

• Тільки клієнтська сторона: Розробити додаток, маючи готовий бекенд та API.
• Клієнтська сторона + API (найпоширеніший варіант): Розробити як клієнтський додаток, так і API.
• Клієнтська сторона + API + Бекенд (менш імовірно): Розробити додаток, API та бекенд.

Як слід реагувати, якщо у вас обмежений досвід роботи з бекендом, але завдання вимагає його дизайну?

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

На які три основні категорії слід розділяти вимоги під час етапу їх збору?

Вимоги слід розділяти на Функціональні, Нефункціональні та Поза сферою застосування (Out-of-Scope).

Наведіть приклади функціональних вимог для "Дизайну стрічки Twitter".

Приклади функціональних вимог для "Дизайну стрічки Twitter" включають:

• Користувачі можуть прокручувати нескінченну стрічку твітів.
• Користувачі можуть "вподобати" твіт.
• Користувачі можуть переглядати коментарі до певного твіту (тільки для читання).

Які нефункціональні вимоги є критично важливими для успіху продукту?

Нефункціональні вимоги включають:

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

Які функції часто вважаються поза сферою застосування для інтерв'ю з системного дизайну, щоб зосередитися на ключовому завданні?

Функції, які часто виключаються зі сфери застосування, включають:

• Вхід/Аутентифікація
• Надсилання твітів
• Підписка/Ретвіти
• Аналітика.

Який підхід рекомендується для постановки уточнюючих питань під час збору вимог?

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

Які питання слід поставити щодо кількості користувачів та розміру команди, і чому це важливо?

• Очікувана кількість користувачів: Велика кількість користувачів впливає на навантаження на бекенд, що вимагає обговорення експоненційного відкату (Exponential Backoff) та обмеження швидкості API (API Rate Limiting).
• Розмір команди розробників: Менші команди (2-4) вимагають інших міркувань, ніж більші (20-100). Важливо зосередитися на модульності та структурі проєкту для забезпечення паралельної розробки (наприклад, monorepo проти multi-repo).

Які питання стосовно характеристик даних є важливими для обговорення?

Важливо обговорити:

• Рівень узгодженості даних: Чи можна допустити кінцеву узгодженість для лайків/коментарів, чи потрібна сильна узгодженість? Це впливає на рішення щодо офлайн-поведінки та синхронізації.
• Частота оновлення даних: Якщо дані оновлюються дуже часто, пуш-сповіщення або SSE можуть бути доречнішими, ніж pull-стратегія.
• Очікувані типи медіа: Розміри та формати зображень/відео впливатимуть на стратегії кешування, мережевої взаємодії, транскодування та підтримки CDN.

Який підхід рекомендується для постановки уточнюючих питань під час збору вимог?

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

Яке питання слід поставити щодо очікуваної кількості користувачів, і чому це важливо?

Слід запитати: "Яка очікувана кількість користувачів?". Велика кількість користувачів впливає на навантаження на бекенд, що вимагає обговорення експоненційного відкату (Exponential Backoff) та обмеження швидкості API (API Rate Limiting), щоб запобігти ненавмисному DDoS.

Чому важливо запитати про розмір команди розробників під час збору вимог?

Важливо запитати: "Наскільки велика команда розробників?". Менші команди (2-4) вимагають інших міркувань, ніж більші (20-100). Слід зосередитися на модульності та структурі проєкту для забезпечення паралельної розробки, обговорюючи, наприклад, monorepo проти multi-repo стратегії.

Яке питання щодо узгодженості даних є важливим для обговорення?

Важливо запитати: "Який рівень узгодженості даних потрібен?". Чи можна допустити кінцеву узгодженість для лайків/коментарів, чи потрібна сильна узгодженість?. Це впливає на рішення щодо офлайн-поведінки та стратегій синхронізації даних.

Яке питання стосовно частоти оновлення даних має бути поставлене, і як це впливає на вибір стратегії?

Слід запитати: "Як часто оновлюються дані?". Якщо дані оновлюються дуже часто, пуш-сповіщення або Server-Sent Events (SSE) можуть бути доречнішими, ніж стратегія оновлення на основі запитів (pull-based refresh), яка може перевантажити сервер.

Назвіть переваги представлення діаграми високого рівня під час інтерв'ю з системного дизайну.

Переваги діаграми високого рівня:

• Управління часом: Швидко окреслює систему та порушує дискусійні питання.
• Модульність: Кожен компонент може бути окремим модулем для командної співпраці.
• Найкращі практики: Відображає дизайн бекенд-системи та модель C4 для візуалізації архітектури.

Які серверні компоненти слід розглянути для включення до діаграми високого рівня?

Серверні компоненти, які слід розглянути, включають:

• Бекенд: Загальна серверна інфраструктура (з фокусом на клієнтських аспектах).
• Push Provider: Інфраструктура для мобільних пуш-сповіщень.
• CDN (Content Delivery Network): Доставляє статичний контент (зображення, відео) клієнтам ефективно.

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

Ключові клієнтські компоненти, які можуть бути відображені, включають:

• API Service: Чистий інтерфейс для взаємодії з бекендом.
• Persistence: Єдине джерело істини для даних на пристрої.
• Repository: Посередник між API Service та Persistence.
• Image Loader: Завантажує та кешує зображення.
• Coordinator: Керує навігацією та логікою потоку між компонентами.

Що інтерв'юер оцінює під час етапу постановки уточнюючих питань?

Інтерв'юер оцінює:

• Обґрунтування вашого вибору функцій.
• Відповідні уточнюючі питання, які ви ставите.
• Усвідомлення компромісів та потенційних проблем.

Як слід реагувати, якщо інтерв'юер хоче зосередитися на технології, з якою ви не дуже знайомі під час збору вимог або обговорення дизайну?

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

Які архітектурні патерни (наприклад, MVP, MVVM, MVI, Clean Architecture, Redux) ви б розглядали для реалізації "Tweet Feed Flow", і які переваги та недоліки кожного з них у цьому контексті? MVC зазвичай не рекомендується, чому?

При обговоренні "Tweet Feed Flow" слід розглянути архітектурні патерни, такі як MVP, MVVM, MVI, Clean Architecture або Redux. MVC зазвичай не рекомендується, а вибір добре відомого патерну полегшує онбординг. Інтерв'юер оцінює вашу знайомство з поширеними патернами MVx, розділення бізнес-логіки та UI, розуміння впровадження залежностей та здатність проєктувати самостійні модулі.

Як би ви реалізували пагінацію для нескінченної стрічки твітів? Який тип пагінації – курсорна, за ключами (Keyset) або за зміщенням (Offset) – є найбільш підходящим для "Design Twitter Feed" і чому, враховуючи можливі вставки/видалення даних та продуктивність?

Пагінація є суттєвою для нескінченного прокручування. Курсорна пагінація (також відома як Token-Based Pagination) є відповідною для "Design Twitter Feed", оскільки вона відокремлює пагінацію від базового сховища даних і може добре обробляти вставки/видалення. Вона використовує непрозорі курсори або токени, що інкапсулюють стан пагінації, і не розкриває деталей про базове сховище даних або впорядкування. Проте, вона вимагає складнішого бекенду для генерації та керування курсорами. Якщо набір даних змінюється нечасто, а API є переважно для читання, пагінація за ключами (Keyset pagination) може бути простішою та продуктивнішою альтернативою. Пагінація за зміщенням (Offset pagination) зазвичай не рекомендується, якщо набір даних не є малим і не змінюється нечасто.

Поясніть, як впровадження залежностей (Dependency Injection) використовується у "Tweet Feed Flow" для покращення ізоляції модулів та тестування?

Впровадження залежностей (Dependency Injection) покращує ізоляцію модулів та тестування. Воно сприяє вільному зв'язуванню та тестуванню, використовуючи графік впровадження залежностей (DI Graph), наприклад, Dagger/Hilt для Android або Swinject/Typhoon для iOS.

Як ви спроєктуєте "Feed API Service" для абстрагування клієнта Twitter Feed API та ефективного отримання сторінкових даних?

"Feed API Service" відповідає за абстрагування клієнта Twitter Feed API та отримання сторінкових даних. Він повинен надавати чистий інтерфейс для взаємодії з бекендом, і для цього можна використовувати бібліотеки, такі як Retrofit (Android) або Alamofire (iOS).

Як ви реалізуєте "Feed Persistence" як єдине джерело істини для кешованих сторінкових даних стрічки на пристрої, щоб забезпечити офлайн-доступ?

"Feed Persistence" реалізується як єдине джерело істини для даних на пристрої. Дані зберігаються локально спочатку, а потім розповсюджуються на інші компоненти, що забезпечує офлайн-доступ та зменшує залежність від мережі. Для зберігання пагінованих даних стрічки можна використовувати Room (Android) або CoreData (iOS). Схема таблиці може включати такі атрибути, як itemId, authorId, likes, comments, attachments, createdAt, а також cursorNextId та cursorPrevId для спрощення навігації по сторінках.

Опишіть роль "Remote Mediator" у процесі отримання даних стрічки, зокрема, як він фечить наступні/попередні сторінки даних і зберігає їх у шар постійного зберігання.

"Remote Mediator" відповідає за отримання даних наступної/попередньої сторінки та збереження їх у шар постійного зберігання. Це компонент, який працює між джерелом даних API та локальним сховищем.

Як "Feed Repository" виступає посередником між "Feed API Service" та "Feed Persistence", консолідуючи віддалені та кешовані відповіді в об'єкті "Pager"?

"Feed Repository" є посередником між "Feed API Service" та "Feed Persistence". Він консолідує віддалені та кешовані відповіді в об'єкті "Pager", використовуючи "Remote Mediator". Цей репозиторій відокремлює джерела даних від UI.

Яка функція об'єкта "Pager" у контексті "Tweet Feed Flow", і як він запускає отримання даних та надає спостережуваний потік сторінкових даних до UI?

Об'єкт "Pager" запускає отримання даних від "Remote Mediator" і надає спостережуваний потік сторінкових даних до UI.

Як би ви реалізували окремі варіанти використання для операцій, таких як "Лайк твіту" та "Перегляд деталей твіту", і як вони інтегруються у загальний потік стрічки?

Для операцій, таких як "Лайк твіту" та "Перегляд деталей твіту", слід реалізувати окремі варіанти використання (use cases). Вони мають бути впроваджені через DI та інтегруватися у відповідні потоки, наприклад, "Tweet Feed Flow" та "Tweet Details Flow".

Як ви спроєктуєте "Image Loader" для ефективного завантаження та кешування зображень у стрічці твітів, включаючи вибір відповідних бібліотек (наприклад, Glide/Coil для Android, SDWebImage/Kingfisher для iOS)?

"Image Loader" призначений для завантаження та кешування зображень. Він абстрагує логіку завантаження зображень від конкретної бібліотеки. Для Android це можуть бути Glide або Coil, а для iOS – SDWebImage або Kingfisher. Цей компонент має бути впроваджений через DI та ефективно використовувати внутрішнє кешоване сховище для файлів зображень. Також слід обмежити розмір кешу (наприклад, 200-400 МБ) та використовувати політику витіснення LRU (Least Recently Used).

Чому цей підхід працює і чому цей посібник необхідний?

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

Чи можете ви заглибитись у [конкретну технологію/шаблон/компонент]?

Цей посібник має на меті надати широкий огляд ключових концепцій, а не заглиблюватися в надмірні деталі будь-якої конкретної технології чи реалізації. Мета полягає в тому, щоб забезпечити фундаментальне розуміння, заохочуючи вас використовувати свій особистий досвід та експертизу для надання конкретних рішень під час інтерв'ю. Інтерв'юер оцінює ваші навички вирішення проблем та здатність адаптуватися й застосовувати свої знання.

Чи варто мені запам'ятовувати рішення, щоб "шахраювати" під час інтерв'ю?

Системний дизайн набагато більш нюансований, ніж завдання з кодування, і запам'ятовування конкретного рішення рідко є достатнім, оскільки інтерв'юери можуть легко адаптувати проблему або ввести нові обмеження. Успіх залежить від здатності кандидата критично мислити, творчо застосовувати свої знання та чітко формулювати свій хід думок. Зазвичай досить очевидно, коли кандидат покладається лише на запам'ятовування, а не демонструє справжнє розуміння.

Що робити, якщо інтерв'юер хоче зосередитися на технології, з якою я не дуже знайомий?

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

Наскільки важливо малювати діаграму? Що робити, якщо я не візуальний мислитель?

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

Як мені реагувати на розбіжності з інтерв'юером?

Допустимо мати різні думки з інтерв'юером. Проте, підходьте до обговорення з повагою та професіоналізмом. Чітко формулюйте свої міркування та будьте готові розглядати альтернативні точки зору. Уникайте суперечок або відкидання чужої думки. Якщо ви категорично не згодні, ввічливо визнайте точку зору інтерв'юера, водночас підтверджуючи власні обґрунтування. Мета — продемонструвати свої навички критичного мислення та здатність вести конструктивний діалог.

Що робити, якщо я застряг і не можу придумати рішення?

Не панікуйте! Нормально зупинитися і взяти паузу, щоб зібратися з думками. Проговорюйте свій хід думок вголос. Поясніть, що ви розглядаєте, і з якими проблемами стикаєтеся. Ставте уточнюючі питання, щоб краще зрозуміти проблему. Якщо ви все ще застрягли, попросіть інтерв'юера підказку або настанови. Інтерв'юер більше зацікавлений у тому, як ви підходите до складної проблеми, а не у пошуку ідеального рішення.

Скільки деталей мені слід надавати?

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

Як мені обирати між різними архітектурними патернами (MVP, MVVM, MVI тощо)?

Не існує єдиного "найкращого" архітектурного патерну. Кожен патерн має свої переваги та недоліки, і найкращий вибір залежить від конкретних вимог проєкту. Будьте готові пояснити плюси та мінуси різних патернів та обґрунтувати свій вибір на основі таких факторів, як складність, тестування та зручність обслуговування. Знайомство з поширеними патернами, такими як MVVM з односпрямованим потоком даних (наприклад, MVI або Redux), зазвичай є перевагою.

Як я можу покращити свої комунікативні навички для інтерв'ю з системного дизайну?

• Практикуйте пояснення складних технічних концепцій чітко та лаконічно.

• Використовуйте діаграми та візуальні засоби для ілюстрації своїх ідей.

• Практикуйте активне слухання та ставте уточнюючі питання, щоб переконатися, що ви розумієте точку зору інтерв'юера.

• Записуйте себе, пояснюючи технічні концепції, та аналізуйте свою роботу.

• Зосередьтеся на тому, щоб бути чітким, лаконічним та впевненим у своєму спілкуванні.

Які переваги Push Notifications?

• Легше впровадити: Потребує менше інженерних зусиль з боку клієнта та сервера порівняно з постійними з'єднаннями.
• Може розбудити додаток у фоновому режимі: Дозволяє доставляти оновлення, навіть коли додаток неактивний, в межах обмежень операційної системи.
• Енергоефективно (при правильному використанні): Операційна система керує з'єднанням та доставкою, оптимізуючи термін служби батареї.

Які недоліки Push Notifications?

• Не 100% надійно: Доставка не гарантована через стан мережі, пристрою або обмеження платформи (наприклад, Doze mode на Android).
• Можливі затримки: Латентність доставки може варіюватися залежно від умов мережі та провайдера push-сповіщень.
• Залежить від стороннього сервісу: Система залежить від Apple APNs (iOS) або Google FCM (Android), що створює єдину точку відмови та потенційну прив'язку до постачальника.
• Користувачі можуть відмовитися: Користувачі мають можливість вимкнути push-сповіщення.
• Ризик надмірності: Надмірне надсилання неактуальних або надмірних сповіщень може призвести до розчарування користувачів та видалення програми.

Які переваги HTTP-polling (Short polling)?

• Простота впровадження: Відносно проста логіка на стороні клієнта та сервера.
• Відсутність постійного з'єднання: Дозволяє уникнути складнощів керування та підтримки постійних з'єднань.
• Сумісність з брандмауерами та проксі-серверами: Менш ймовірно буде заблоковано обмежувальними мережевими середовищами.
• Легко масштабується горизонтально: Безстатевий характер HTTP полегшує розподіл навантаження між кількома серверами.
• Дешевше (якщо нечасто): Менше використання серверних ресурсів, якщо інтервал опитування великий.
• Може бути корисним для пакетних оновлень: Опитування можна використовувати для отримання кількох оновлень за один запит.

Які недоліки HTTP-polling (Short polling)?

• Потенційні значні затримки: Доставка сповіщень обмежена інтервалом опитування.
• Накладні витрати на повторні з'єднання: Повторні з'єднання призводять до значних накладних витрат, особливо для невеликих оновлень.
• Неефективне використання пропускної здатності: Клієнт надсилає запити, навіть якщо оновлень немає.
• Високе навантаження на сервер: Часте опитування може перевантажувати серверні ресурси, особливо при великій кількості клієнтів.

Які переваги HTTP-polling (Long polling)?

• Миттєві сповіщення (майже): Сервер тримає з'єднання відкритим, поки не з'явиться оновлення, мінімізуючи затримки.

Які недоліки HTTP-polling (Long polling)?

• Більш складно, потребує більше серверних ресурсів: Потребує більш складну логіку на стороні сервера для керування з'єднаннями та відстеження оновлень.
• Підтримує постійне з'єднання (до певної міри): Хоча це не справжнє постійне з'єднання, як WebSockets, воно імітує його, і керування таймаутами є критичним.
• Все ще вводить певну затримку: Залежить від часу відповіді сервера, навіть якщо оновлення доступні.
• Чутливий до таймаутів та переривань з'єднання: Вимагає надійної обробки помилок та логіки повторного підключення.
• Потребує механізмів для маршрутизації клієнтів: У разі кількох серверів може знадобитися використання "липких сесій" або інших механізмів, щоб забезпечити підключення клієнта до правильного екземпляра сервера.

Які переваги Server-Sent Events (SSE)?

• Оновлення в реальному часі за допомогою єдиного з'єднання: Встановлює односпрямований (сервер-клієнт) потік для ефективної доставки оновлень.
• Простіше, ніж WebSockets: Легше впроваджувати та керувати порівняно з двоспрямованими протоколами зв'язку.
• Стандартний протокол: Використовує стандартний протокол HTTP, що полегшує інтеграцію з існуючою інфраструктурою.
• Менші накладні витрати, ніж Long polling: Уникає накладних витрат, пов'язаних з багаторазовим встановленням та розривом з'єднань.
• Текстовий протокол: Легше налагоджувати та перевіряти порівняно з бінарними протоколами.

Які недоліки Server-Sent Events (SSE)?

• Підтримує постійне з'єднання: Потребує серверних ресурсів для підтримки з'єднання.
• Односпрямований: Підтримує лише зв'язок від сервера до клієнта, що робить його непридатним для програм, які потребують частих оновлень від клієнта до сервера.
• Обмежена підтримка браузерів (старі браузери): Можуть бути обмеження, накладені браузерами або проксі-серверами.

Які переваги WebSockets?

• Може передавати бінарні та текстові дані: Підтримує як текстові, так і бінарні дані, що дозволяє використовувати його в широкому спектрі додатків.
• Повнодуплексний зв'язок: Забезпечує зв'язок у реальному часі, двоспрямований зв'язок між клієнтом та сервером.
• Нижча затримка, ніж HTTP polling: Уникає накладних витрат, пов'язаних з багаторазовим встановленням та розривом з'єднань.
• Ефективне використання пропускної здатності: Зменшує споживання пропускної здатності шляхом підтримки постійного з'єднання.

Які недоліки WebSockets?

• Більш складний у налаштуванні: Потребує більш складної логіки на стороні сервера та клієнта порівняно з HTTP-протоколами.
• Підтримує постійне з'єднання: Потребує серверних ресурсів для підтримки з'єднання.
• Більш складний у масштабуванні: Потребує спеціалізованої інфраструктури та методів для обробки великої кількості одночасних з'єднань.
• Проблеми з брандмауерами: Може бути заблоковано брандмауерами або проксі-серверами, які не підтримують WebSockets.
• Підвищені проблеми безпеки: Вимагає ретельної уваги до безпеки, щоб запобігти зловмисним запитам та несанкціонованому доступу.
• Вище споживання батареї: Підтримка постійного з'єднання може розряджати батарею на мобільних пристроях.
• Складніше налагоджувати порівняно з HTTP: Бінарні повідомлення може бути важко перевіряти.
• Обмежена кількість активних з'єднань на сервер: Хоча теоретичне обмеження становить 65 тисяч, фактична межа залежить від операційної системи та обладнання сервера.
• Зберігає стан: Сервер повинен підтримувати стан кожного клієнтського з'єднання, що може ускладнити масштабування та відмовостійкість.

Які переваги REST (Representational State Transfer)?

• Легко вивчити, зрозуміти та впровадити: Широко застосовується та добре документований, з численними доступними бібліотеками та фреймворками.
• Легко кешувати за допомогою HTTP-кешування: Використовує вбудовані механізми HTTP-кешування (наприклад, заголовки Cache-Control) для підвищення продуктивності. CDN дуже ефективні з RESTful API.
• Безстатевий: Кожен запит містить всю інформацію, необхідну серверу для його розуміння та обробки, що спрощує логіку на стороні сервера та масштабованість.
• Широко підтримується: Підтримується практично всіма клієнтами (браузери, мобільні додатки тощо) та серверами.
• Зручний для читання людиною: Текстові повідомлення легко налагоджувати та перевіряти.

Які недоліки REST (Representational State Transfer)?

• Менш ефективний на мобільних пристроях через окремі з'єднання: Кожен запит вимагає нового TCP-з'єднання (хоча HTTP/2 дещо пом'якшує це за допомогою мультиплексування з'єднань). Все ще може сприяти розрядженню батареї.
• Безсхемний: Важко перевірити цілісність та формат даних на клієнті без власної логіки валідації або зовнішніх визначень схеми (наприклад, OpenAPI/Swagger). Це також робить рефакторинг більш ризикованим.
• Безстатевий: Вимагає додаткової функціональності для підтримки стану сесії, такої як файли cookie або токени, що додає складності до автентифікації та авторизації.
• Накладні витрати від метаданих та заголовків: Кожен запит містить контекстні метадані та заголовки, що може додавати значних накладних витрат, особливо для невеликих корисних навантажень.
• Надлишкове/недостатнє отримання даних (Over-fetching/Under-fetching): Клієнти часто отримують більше даних, ніж їм потрібно (over-fetching), або потребують кількох запитів для отримання всіх необхідних даних (under-fetching).

Які переваги GraphQL?

• Запити на основі схеми, типізовані запити: Клієнти можуть перевіряти цілісність та формат даних за допомогою чітко визначеної схеми, покращуючи досвід розробника та зменшуючи кількість помилок. Дозволяє інтроспекцію API.
• Висока гнучкість налаштування: Клієнти можуть запитувати лише потрібні їм дані, зменшуючи обсяг HTTP-трафіку та покращуючи продуктивність. Усуває надлишкове отримання даних.
• Двонаправлений зв'язок за допомогою GraphQL Subscriptions (на основі WebSocket): Підтримує оновлення в реальному часі через WebSockets, дозволяючи такі функції, як живі стрічки та сповіщення.
• Сильна типізація: Дозволяє перевірки під час компіляції, зменшуючи кількість помилок під час виконання.
• Версіонування менш критичне: Оскільки клієнти запитують лише конкретні дані, зміни на серверній частині з меншою ймовірністю порушать роботу існуючих клієнтів.
• Інструменти розробника: Відмінні інструменти для розробки, включаючи GraphiQL для дослідження та тестування запитів.

Які недоліки GraphQL?

• Більш складна серверна частина: Вимагає більш складної реалізації на стороні сервера порівняно з REST, включаючи GraphQL-сервер та резолвери.
• "Дірява абстракція" – тісне зв'язування клієнта та сервера: Клієнти тісно пов'язані зі схемою сервера, що ускладнює розвиток API без порушення роботи існуючих клієнтів. Може ускладнити рефакторинг.
• Продуктивність запитів залежить від найповільнішої служби: Особливо в федеративній архітектурі, де дані розподілені між кількома службами. Проблема N+1 може виникнути без ретельного розгляду.
• Складність з кешуванням: HTTP-кешування складніше реалізувати порівняно з REST, вимагаючи спеціалізованих рішень.
• Міркування безпеки: Вимагає ретельної уваги до безпеки для запобігання зловмисним запитам та несанкціонованому доступу.

Які переваги gRPC (gRPC Remote Procedure Calls)?

• Легкі двійкові повідомлення (менші, ніж текстові): Використовує Protocol Buffers (Protobuf) для серіалізації повідомлень, що призводить до менших розмірів повідомлень та покращеної продуктивності.
• Підтримує різні типи потокової передачі: Двонаправлена потокова передача, потокова передача на стороні сервера та потокова передача на стороні клієнта, що дозволяє використовувати його в широкому діапазоні сценаріїв.
• Кілька паралельних запитів: Використовує мультиплексування HTTP/2 для надсилання кількох запитів через одне з'єднання.
• Висока продуктивність: Оптимізований для низької затримки та високої пропускної здатності.
• Сильна типізація: Забезпечує сильну типізацію як для запитів, так і для відповідей, зменшуючи кількість помилок під час виконання.
• Хороша продуктивність в ненадійних мережах: Protocol Buffers розроблені таким чином, щоб бути стійкими до пошкодження даних та перебоїв у мережі.

Які недоліки gRPC (gRPC Remote Procedure Calls)?

• Обмежена підтримка браузерів: Вимагає gRPC-Web для клієнтів браузера, що додає складності. Хоча підтримка покращилася, вона все ще не така безшовна, як REST або GraphQL.
• Нечитабельний для людини формат: Двійкові повідомлення важко налагоджувати та перевіряти без спеціалізованих інструментів.
• Крутіша крива навчання: Вимагає знайомства з Protocol Buffers та концепціями gRPC.
• Збільшена складність порівняно з REST: Більш складний у налаштуванні та конфігурації порівняно з REST.
• Більш вимогливий до клієнта: Бібліотека клієнта, необхідна для gRPC, як правило, більша порівняно з REST, що може вплинути на розмір програми.
• Не так широко зрозумілий, як REST: REST значно ширше зрозумілий, і розробники, швидше за все, будуть з ним знайомі.

Які переваги MQTT?

• Легкий: Мінімальне використання пропускної здатності та низькі накладні витрати, ідеально підходить для мереж з обмеженими можливостями.
• Видавець-Підписник (Publish-Subscribe): Розділяє виробників та споживачів повідомлень.
• Зв'язок у реальному часі: Низька затримка та швидка доставка повідомлень.
• Рівні якості обслуговування (QoS Levels): Забезпечує різні рівні якості обслуговування (QoS) для забезпечення доставки повідомлень залежно від важливості (не більше одного разу, щонайменше один раз, точно один раз).

Які недоліки MQTT?

• Двійковий протокол: Важко налагоджувати та перевіряти.
• Не так широко використовується, як HTTP-протоколи: Менш зріла екосистема порівняно з REST, GraphQL та WebSockets.
• Зберігає стан (Stateful): Вимагає керування клієнтськими з'єднаннями та підписками.
• Міркування безпеки: Вимагає ретельної конфігурації для захисту MQTT-брокера та клієнтських з'єднань.
• Залежність від брокера: Покладається на центральний MQTT-брокер для маршрутизації повідомлень, що може бути єдиною точкою відмови.

Offset Pagination: Визначення

Цей тип пагінації використовує параметри limit та offset. offset вказує індекс, з якого починаються результати, а limit — максимальну кількість результатів для повернення. Приклад: GET /feed?offset=100&limit=20.

Offset Pagination: Переваги

• Легкість реалізації: Параметри можна безпосередньо передавати до SQL-запиту (наприклад, SELECT * FROM tweets LIMIT 20 OFFSET 100).
• Безстатевий на сервері: Серверу не потрібно підтримувати жодного стану щодо попередніх запитів.
• Простота розуміння: Концепція є інтуїтивно зрозумілою як для розробників, так і для споживачів API.

Offset Pagination: Недоліки

• Низька продуктивність при великих зміщеннях: База даних повинна сканувати велику кількість рядків, що збільшує затримку, особливо для великих таблиць.
• Непослідовність (Page Drift): Якщо нові елементи вставляються або видаляються перед поточною сторінкою, це може призвести до пропущених або дубльованих елементів. Це також відомо як проблема "відсутнього елемента" або "дублікату елемента".
• Не підходить для стрічок у реальному часі: Через Page Drift не придатний для швидкозмінних наборів даних.
• Вразливий до маніпуляцій з параметрами: Клієнти можуть легко маніпулювати параметром offset, потенційно отримуючи доступ до несанкціонованих даних або викликаючи проблеми з продуктивністю.
• Загалом не рекомендується, якщо набір даних великий і часто змінюється.

Keyset Pagination: Визначення

Цей метод використовує значення з останнього елемента попередньої сторінки (наприклад, мітку часу або ID), щоб визначити, звідки починати наступну сторінку. Приклад: GET /feed?after=2021-05-25T00:00:00&limit=20.

Keyset Pagination: Переваги

• Легко перетворюється на SQL: Може бути ефективно реалізований за допомогою WHERE clause в SQL (наприклад, SELECT * FROM tweets WHERE created_at > '2021-05-25T00:00:00' ORDER BY created_at ASC LIMIT 20).
• Хороша продуктивність з великими наборами даних: Уникає проблем з продуктивністю offset pagination, оскільки база даних може використовувати індекс за полем впорядкування.
• Безстатевий на сервері: Серверу не потрібно підтримувати жодного стану щодо попередніх запитів.
• Більш стійкий до вставок: Вставки, що відбуваються після значення "after", не призведуть до пропуску або дублювання елементів (хоча вставки перед цим значенням вплинуть на загальну кількість).

Keyset Pagination: Недоліки

• "Дірява абстракція": API розкриває деталі базового сховища даних (поле впорядкування), що збільшує ризик критичних змін, якщо змінюється схема бази даних. Споживачі API повинні знати, за яким полем пагінувати.
• Працює лише з полями з природним порядком: Вимагає поля (наприклад, мітки часу, ID), яке можна використовувати для послідовного впорядкування результатів. Не працює добре, якщо немає чіткого порядку.
• Можливі проблеми з "нічиєю": Якщо кілька елементів мають однакове значення для поля впорядкування, пагінація може бути непослідовною (що вирішується за допомогою складеної Keyset Pagination).
• Чутливий до модифікацій даних: Видалення елементів усередині сторінки все ще може викликати проблеми.
• Менш гнучкий для довільного доступу: Важко перейти до певної сторінки без ітерації по всіх попередніх.

Cursor/Seek Pagination: Визначення

Цей метод використовує непрозорі курсори або токени, які інкапсулюють стан пагінації. Ці курсори зазвичай кодуються в base64 та можуть бути зашифровані. Сервер генерує курсор для наступної (або попередньої) сторінки та повертає його у відповіді. Клієнт потім використовує цей курсор для запиту наступної сторінки. Приклад: GET /feed?after_id=t1234xzy&limit=20.

Cursor/Seek Pagination: Переваги

• Приховує деталі реалізації: Клієнтам не потрібно знати, яке поле використовується для сортування/пагінації, і API не розкриває подробиць базового сховища даних.
• Послідовне впорядкування при вставці/видаленні: Більш стійкий до модифікацій даних, ніж offset pagination.
• Більш гнучкий: Може підтримувати різні критерії впорядкування та складні запити.

Cursor/Seek Pagination: Недоліки

• Більш складний бекенд: Потребує генерування, керування (кодування, шифрування) та валідації курсорів. Також вимагає декодування та валідації курсора при наступних запитах.
• Проблеми з курсорами, що закінчуються або стають недійсними: Вимагає ретельного керування життєвим циклом та анулюванням курсорів. Видалення всіх елементів між 'after_id' та наступним елементом може зробити курсор недійсним.
• Все ще потенційно чутливий до видалення елементів: Якщо елементи видаляються та ID повторно використовуються.
• Менш прозорий: Важче налагоджувати проблеми, оскільки курсор є непрозорим токеном.
• Нелегко додати в закладки: Курсори можуть закінчитися, що ускладнює додавання сторінок у закладки.

Page Number Pagination: Визначення, Переваги та Недоліки

• Визначення: Використовує параметри номера сторінки (page) та розміру сторінки (pageSize). Приклад: GET /feed?page=3&pageSize=10. Цей метод подібний до offset pagination.
• Переваги:
  • Легкий для розуміння користувачами: Інтуїтивно зрозумілий для користувачів, знайомих з традиційною пагінацією.
  • Простий у реалізації (спочатку): Може бути реалізований за допомогою offset pagination на бекенді.
• Недоліки:
  • Успадковує всі недоліки offset pagination: Включаючи низьку продуктивність при великих номерах сторінок та проблеми з "page drift".
  • Не підходить для нескінченного прокручування: Не масштабується для додатків з великою кількістю сторінок.
  • Не підходить для даних у реальному часі: Через проблеми з "page drift".

Key-Value Storage: Опис, Переваги, Недоліки

• Опис: Зберігає примітивні дані з рядковими ключами. Найкраще підходить для простих, неструктурованих, нереляційних даних. Для Android можна розглянути використання MMKV для підвищення продуктивності.
• Переваги:
  • Легкий у використанні вбудований API: Прості API для зберігання та отримання даних.
  • Швидкий для простих операцій: Ефективний для невеликих обсягів даних.
  • Низькі накладні витрати: Мінімальне використання пам'яті.
• Недоліки:
  • Небезпечний за замовчуванням: Вимагає шифрування для чутливих даних (наприклад, EncryptedSharedPreferences на Android, сторонніх обгорток або Keychain на iOS).
  • Не підходить для великих даних: Продуктивність значно знижується при великих наборах даних.
  • Відсутність схеми або запитів: Обмежені можливості запитів, відсутність обмежень цілісності даних.
  • Відсутність міграції даних: Важко керувати змінами схеми.
  • Низька продуктивність для складних операцій: Неефективний для складних структур даних або операцій.
  • Не відповідає ACID: Немає гарантії атомарності, узгодженості, ізольованості або довговічності.

Database/ORM: Опис, Переваги, Недоліки

• Опис: Реляційна або об'єктна база даних. Призначена для великих, структурованих, реляційних даних, що вимагають складних запитів, транзакцій та цілісності даних. На Android варто розглянути Room для сучасної, типізованої абстракції SQLite.
• Переваги:
  • Об'єктно-реляційне відображення (ORM): Спрощує доступ до даних та маніпуляції з ними за допомогою об'єктно-орієнтованих парадигм.
  • Схема та запити: Підтримує структуровані дані з визначеними схемами та потужними можливостями запитів за допомогою SQL або мов запитів, специфічних для ORM.
  • Міграція даних: Надає механізми для керування змінами схеми та міграції даних.
  • Відповідність ACID: Забезпечує атомарність, узгодженість, ізольованість та довговічність.
  • Ефективність для складних операцій: Оптимізована для складних структур даних та операцій.
• Недоліки:
  • Складніша настройка: Вимагає визначення схем, налаштування з'єднань з базою даних та керування конфігураціями ORM.
  • Потенційно небезпечна: Вимагає використання SQLCipher або інших бібліотек шифрування, належним чином налаштованих.
  • Більше використання пам'яті: Файли бази даних можуть займати значний обсяг місця для зберігання.
  • Накладні витрати на продуктивність: ORM може створювати накладні витрати на продуктивність порівняно з прямими SQL-запитами.
  • Крутіша крива навчання: Вимагає знайомства з концепціями SQL або ORM.

Custom/Binary Storage: Опис, Переваги, Недоліки

• Опис: Низькорівневе зберігання та завантаження. Для користувацьких конвеєрів серіалізації та зберігання даних, де потрібен максимальний контроль над продуктивністю та форматом даних. Розгляньте Protocol Buffers для ефективної серіалізації та десеріалізації. DataStore на Android пропонує продуктивне рішення без накладних витрат ORM.
• Переваги:
  • Висока гнучкість налаштувань: Дозволяє тонкий контроль над серіалізацією та зберіганням даних.
  • Висока продуктивність: Може бути оптимізована для конкретних форматів даних та моделей доступу, дозволяючи створювати власні структури даних та прямо контролювати серіалізацію, уникаючи накладних витрат ORM.
• Недоліки:
  • Відсутність схеми/міграції: Вимагає ручного керування змінами схеми та міграцією даних.
  • Багато ручної роботи: Вимагає написання власного коду серіалізації та десеріалізації.
  • Підвищена складність: Вимагає глибокого розуміння структур даних та методів серіалізації.
  • Схильність до помилок: Код серіалізації та десеріалізації може бути складним і схильним до помилок.
  • Важче налагоджувати: Бінарні формати важко перевіряти та налагоджувати без спеціалізованих інструментів.

On-Device Secure Storage: Опис, Переваги, Недоліки

• Опис: Апаратно-підтримуване або зашифроване ОС зберігання для чутливих даних, ключів шифрування, сертифікатів та облікових даних користувача. Для безпечної аутентифікації за допомогою біометричних датчиків використовуйте Android Biometrics API.
• Переваги:
  • Безпека: Забезпечує апаратно-підтримуване або системне шифрування для чутливих даних. Захищає від несанкціонованого доступу та витоків даних.
  • Інтеграція з безпекою пристрою: Використовує функції безпеки на рівні пристрою, такі як біометрія та аутентифікація за допомогою PIN/пароля.
• Недоліки:
  • Накладні витрати на шифрування/дешифрування: Може спричинити накладні витрати на продуктивність для операцій шифрування та дешифрування.
  • Відсутність схеми/міграції: Обмежені можливості запитів. Важко керувати змінами схеми.
  • Складний API: Може бути складним у правильному використанні.
  • Обмежений обсяг зберігання: Існують обмеження на обсяг доступного місця для зберігання.
  • Залежність від користувача: Залежить від того, чи налаштував користувач екран блокування.

File Storage: Опис, Переваги, Недоліки

• Опис: Зберігання даних у вигляді файлів, підходить для великих неструктурованих даних, таких як зображення, відео та документи.
  • Внутрішнє сховище (Internal Storage): Ізольоване, приватне для програми та недоступне для читання іншими програмами (за деякими винятками). Дані видаляються при видаленні програми.
  • Зовнішнє сховище (External Storage):
    • Медіа/Обмежене (Media/Scoped): Обмежена підмножина зовнішнього сховища спеціально для медіафайлів. Забезпечує підвищену конфіденційність та безпеку порівняно з традиційним зовнішнім сховищем. Вимагає відповідних дозволів та дотримується конкретних схем доступу.
    • Документи (Documents - Automatically Backed Up): Створені користувачем дані, які не можуть бути легко перегенеровані (наприклад, профілі користувачів, документи, налаштування). Автоматично створюється резервна копія в хмарному сховищі (наприклад, iCloud, Google Drive), якщо не виключено явно.
    • Кеш (Cache): Дані, які можна відновити, тобто завантажити знову або відтворити (наприклад, завантажені зображення, кешовані відповіді API). Можуть бути видалені системою для звільнення місця. Не повинні містити критично важливих даних.
    • Тимчасові файли (Temp): Тимчасові дані, які використовуються лише короткий період і повинні бути видалені, коли більше не потрібні (наприклад, тимчасові файли, створені під час обробки). Не створюються резервні копії та можуть бути видалені системою в будь-який час.
• Переваги:
  • Простий у реалізації.
  • Підходить для зберігання великих, неструктурованих даних.
• Недоліки:
  • Відсутність схеми.
  • Обмежені можливості запитів.
  • Може бути повільним для довільного доступу.
  • Вимагає ретельного керування шляхами до файлів та дозволами.

Що таке сховище "Медіа/Обмежене" (Media/Scoped) та які його особливості? **

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

Для яких даних призначене сховище "Документи" (Documents) і як воно пов'язане з резервним копіюванням? **

** Сховище "Документи" призначене для даних, створених користувачем, які не можуть бути легко повторно згенеровані (наприклад, профілі користувачів, документи, налаштування). Ці дані автоматично створюють резервні копії в хмарне сховище (наприклад, iCloud, Google Drive), якщо їх явно не виключено.

Коли слід використовувати сховище "Кеш" (Cache) і які його особливості? **

** Сховище "Кеш" використовується для відновлюваних даних, які можуть бути завантажені знову або відтворені (наприклад, завантажені зображення, кешовані відповіді API). Воно може бути видалене системою для звільнення місця і не повинно містити критично важливих даних.

Яке призначення сховища "Тимчасові файли" (Temp) на мобільних пристроях? **

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

Що таке сховище "Ключ-Значення" (Key-Value Storage) та для яких типів даних воно підходить? **

** Це сховище зберігає примітивні дані з рядковими ключами. Найкраще підходить для простих, неструктурованих, нереляційних даних. На Android для підвищення продуктивності можна розглянути використання MMKV.

Для яких сценаріїв використовується "База Даних/ORM" (Database/ORM) як варіант зберігання даних? **

** "База Даних/ORM" (наприклад, SQLite/Room на Android або Core Data/Realm на iOS) використовується для великих, структурованих, реляційних даних, що вимагають складних запитів, транзакцій та цілісності даних.

Які найкращі практики щодо зберігання чутливих даних на пристрої? **

** Необхідно зберігати якомога менше чутливих даних. Для чутливих даних використовуйте зашифроване сховище (наприклад, EncryptedSharedPreferences на Android, Keychain на iOS або SQLCipher). Ключі шифрування слід зберігати безпечно в KeyStore/KeyChain або апаратному модулі безпеки (HSM). Навіть при використанні KeyStore/KeyChain, слід припускати, що сховище на пристрої не є абсолютно безпечним.

Чи слід зберігати секрети або ключі API безпосередньо в коді додатку або у файлах конфігурації? **

** Ні, уникайте зберігання секретів або ключів API безпосередньо в коді або у файлах конфігурації.

Як керувати зростанням обсягу сховища, яке використовує додаток? **

** Потрібно запобігати неконтрольованому зростанню сховища. Реалізуйте політики очищення кешу та керуйте розмірами файлів. Для кешування медіа (зображень, відео) рекомендується обмежувати загальну кількість записів (наприклад, 500) та використовувати політику витіснення Least Recently Used (LRU) для видалення старих елементів. Для кешу зображень також рекомендується обмежувати розмір (наприклад, 200-400 МБ).

Які міркування щодо резервного копіювання та відновлення даних на мобільних пристроях? **

** Слід розглянути стратегії резервного копіювання та відновлення для даних, створених користувачем. Наприклад, сховище "Документи" автоматично створює резервні копії, якщо вони не виключені.

Що таке конфіденційність даних користувача і чому вона є ключовою проблемою в мобільній розробці? **

** Конфіденційність даних користувача є однією з основних проблем мобільної розробки, оскільки її порушення може нанести шкоду репутації бізнесу та призвести до юридичних наслідків. Важливо забезпечувати дотримання норм конфіденційності, таких як GDPR та CCPA.

Які аспекти безпеки додатку потрібно враховувати в мобільній розробці? **

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

Як зміни цільової платформи впливають на мобільну розробку? **

** Нові версії операційних систем можуть обмежувати функціональність та посилювати правила конфіденційності. Розробникам необхідно бути в курсі змін платформи та відповідно адаптувати додаток. Для цього можна використовувати шари сумісності або умовну компіляцію для управління відмінностями між ОС.

Як керувати використанням мобільного трафіку для оптимізації продуктивності? **

** Оскільки використання мобільного трафіку може бути дорогим, необхідно оптимізувати мережеві запити та мінімізувати передачу даних. Рекомендується використовувати методи стиснення даних. Також, постійне використання радіомодуля витрачає заряд батареї, тому слід пакетувати мережеві запити та використовувати ефективні мережеві протоколи.

Які особливості використання CPU потрібно враховувати для оптимальної продуктивності мобільних додатків? **

** Висока завантаженість центрального процесора (CPU) призводить до розрядження батареї та перегріву пристрою. Щоб уникнути цього, необхідно оптимізувати алгоритми та використовувати фонові потоки для ресурсомістких завдань.

Як управління пам'яттю впливає на стабільність мобільних додатків? **

** Високе споживання пам'яті підвищує ризик примусового завершення роботи додатку у фоновому режимі. Важливо використовувати інструменти профілювання пам'яті для виявлення та виправлення витоків пам'яті.

Як мінімізувати споживання батареї мобільним додатком? **

** Для мінімізації споживання батареї необхідно оптимізувати мережеві запити, використання CPU та фонову обробку. Слід використовувати інструменти профілювання батареї для виявлення та усунення проблем, пов'язаних з її розрядженням.

Чому час запуску додатку є важливою метрикою продуктивності? **

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