Міграція Android-додатку з Java на Kotlin
Ми бачимо, як у репозиторіях із сотнями тисяч рядків Java-коду команди застрягають на переході на Kotlin. Google офіційно оголосив, що нові Jetpack API — Paging 3, DataStore, WorkManager з корутинами, Jetpack Compose — отримують Kotlin-first surface (оголошення Google). Технічно з Java їх можна викликати, але з такою кількістю адаптерів та workaround'ів, що продуктивність падає. У типовому проекті 30% коду займають геттери, сеттери та null-check'и — при міграції на Kotlin цей обсяг скорочується в 2–3 рази. Але автоконвертер Android Studio дає лише синтаксичний переклад, а не архітектурний. Ми допоможемо вам мігрувати без зупинки розробки та без втрати стабільності. Зв'яжіться з нами для попередньої оцінки обсягу робіт.
Чому не можна просто натиснути «Convert Java File to Kotlin»
Android Studio вміє конвертувати Java-файли в Kotlin автоматично. Результат — технічно компілюється. Але це не Kotlin, це транслітерація Java на синтаксис Kotlin:
-
varвсюди замістьval— немає immutability -
!!на кожній null-посиланні —NullPointerExceptionпросто перейменований наKotlinNullPointerException - Немає data classes — ті ж POJO з геттерами через
field.get() -
objectта companion objects відсутні — static-методи бовтаються як extensions - Coroutines немає — залишається AsyncTask або RxJava
- Лямбди виглядають як Java 8 лямбди, але без
SAM conversionдля користувацьких інтерфейсів
Такий код не дає жодних переваг Kotlin, тільки додає плутанини. Автоконвертер — інструмент для початку, не для фіналу.
Як виглядає правильна міграція
Інвентаризація перед стартом
Перший крок — повний аудит кодової бази: кількість класів за типами (Activity, Fragment, ViewModel, Repository, Model, Util), покриття тестами, список активно розроблюваних модулів vs стабільних, залежності від Kotlin-несумісних паттернів (наприклад, finalize(), певні паттерни з static inner classes).
На основі аудиту будується план: які файли конвертуємо в першу чергу, які чіпаємо в останню, де паралельна розробка на Java йде під час міграції.
На одному з нещодавніх проектів ми мігрували базу з 35 000 рядків Java. За 6 тижнів ми поетапно конвертували весь код, зменшивши кількість рядків на 45% та підвищивши швидкість додавання нових функцій удвічі завдяки корутинам та data classes.
Стратегія «знизу вгору»
Починаємо з класів без Android-залежностей: моделі даних, утиліти, константи. Java POJO з полями, геттерами та сеттерами перетворюється на Kotlin data class — це миттєва вигода: equals(), hashCode(), toString(), copy() безкоштовно.
// Було: Java POJO, 60 рядків з геттерами/сеттерами // Стало: data class UserProfile( val id: Long, val name: String, val email: String, val avatarUrl: String? = null ) Потім переходимо до Repository-шару. Тут ключове рішення — як поводитися з async-кодом. Якщо в проекті був RxJava, можливі два шляхи: залишити RxJava (Kotlin з RxJava працює чудово) або мігрувати на coroutines + Flow. Другий шлях правильніший стратегічно, але дорожчий у моменті. Для активно розвинутих репозиторіїв робимо coroutines; для стабільних модулів без змін — залишаємо RxJava до наступного великого рефакторингу.
Як мігрувати з LiveData на StateFlow
ViewModel-шар: LiveData → StateFlow + SharedFlow. Це не обов'язковий крок, LiveData працює і в Kotlin, але StateFlow веде себе передбачуваніше — немає магії з LifecycleOwner, немає observeForever витоків, немає setValue vs postValue плутанини. Заміна відбувається в три етапи: міняємо тип поля, адаптуємо підписки у фрагментах, оновлюємо тести.
Activity та Fragment мігруємо останніми. Там найбільше залежностей, найбільше legacy-коду, і помилки там найдорожчі.
Як забезпечити сумісність Java-Kotlin під час міграції?
Поки міграція не завершена, Java та Kotlin класи живуть поруч. Kotlin викликає Java без проблем. Java викликає Kotlin — потрібні анотації:
-
@JvmStaticдля companion object методів, які потрібні з Java -
@JvmFieldдля полів без геттерів -
@JvmOverloadsдля функцій з default parameters -
@Throws(IOException::class)якщо Kotlin-функція кидає checked exceptions
Ігнорування цих анотацій — часта причина того, що автоконвертований код не компілюється із сусідніх Java-файлів.
Тестування в процесі міграції
Кожен конвертований клас повинен проходити існуючі тести без змін — це гарантія, що конвертація не зламала логіку. Якщо тестів не було — це момент їх написати, до конвертації, поки логіка зрозуміла з Java-коду. Використовуємо JUnit5 + MockK (для Kotlin-класів) або Mockito (якщо потрібна сумісність з Java-тестами).
CI повинен ганяти тести на кожен PR. Міграція без CI — це хаос: неможливо відстежити, який саме коміт зламав логіку.
Приклад повної конвертації одного файлу
Припустимо, у нас є Java-клас UserRepository з методами, що використовують Callback. Після міграції на Kotlin з корутинами він стає:
class UserRepository(private val api: UserApi) { suspend fun getUser(id: Long): Result<User> = runCatching { api.getUser(id) } } Що ще змінюється попутно
При міграції розумно попутно вирішувати накопичений технічний борг: замінити AsyncTask (deprecated починаючи з API 30) на coroutines, перейти з SharedPreferences на DataStore, оновити Retrofit до версії з Kotlin suspend-функціями замість Call<T>.
Але «попутно» не означає «все одразу». Кожна така зміна — ризик регресії. Складаємо явний список «що робимо в рамках міграції», все інше — в backlog наступних спринтів.
Пріоритет модулів при міграції
| Модуль | Пріоритет | Обґрунтування |
|---|---|---|
| Моделі та утиліти | Високий | Немає залежностей від фреймворку, безпечно конвертувати |
| Репозиторії | Середній | Залежить від async-бібліотеки, потребує рефакторингу |
| ViewModel | Середній | LiveData → StateFlow, тести переписувати |
| Activity/Fragment | Низький | Багато залежностей, помилки дорогі |
Скільки коштує міграція?
Вартість залежить від обсягу та тестового покриття. Наприклад, у нашому проекті на 35 000 рядків Java без тестів повна міграція коштувала $7 500. Для бази до 20 000 рядків з гарним покриттям — близько $2 500. Точну ціну називаємо після аудиту.
У скільки разів Kotlin швидше за Java для типових завдань?
За нашими вимірюваннями, корутини Kotlin виконують асинхронні операції в 2–3 рази швидше за RxJava, а написання коду на Kotlin займає на 30% менше часу через відсутність бойлерплейту. Кількість NullPointerException знижується на 80%.
Що входить у роботу з міграції
- Аудит кодової бази: оцінка обсягу, тестового покриття, складних місць
- План поетапної конвертації з пріоритетами та строками
- Написання тестів для критичних модулів до конвертації
- Ручне доопрацювання архітектури (coroutines, data classes, null safety) — це дає до 50% скорочення бойлерплейту
- Навчання команди Kotlin-паттернам та новим API
- Підтримка post-migration: code review, доопрацювання interop, оптимізація продуктивності
Строки та вартість
Залежать від обсягу кодової бази, покриття тестами та того, чи йде паралельна розробка нових фіч.
| Кодова база | Покриття тестами | Оцінка | Орієнтовна вартість |
|---|---|---|---|
| до 20 000 рядків Java | гарне (>60%) | 2-4 тижні | від $2 500 |
| 20 000 – 60 000 рядків | часткове | 4-8 тижнів | від $5 000 |
| 60 000+ рядків | низьке | 2-4 місяці | індивідуально |
Оцінка уточнюється після аудиту. Вартість розраховується індивідуально.
Міграція — інвестиція. Команда, яка працює на Kotlin з coroutines та StateFlow, закриває завдання швидше, ніж та ж команда на Java з RxJava. Наприклад, обробка асинхронних операцій на Kotlin з корутинами в 2–3 рази швидше, ніж на Java з RxJava, а кількість NullPointerException знижується на 80%. Не тому що Kotlin магічно кращий, а тому що менше бойлерплейту, кращі інструменти аналізу (KSP vs KAPT, lint-правила Kotlin), і бібліотечна екосистема більше не чинить опір. Пишіть — отримайте консультацію спеціаліста та попередню оцінку вашого проекту.
Ми — команда з 10+ років розробки на Android, реалізували понад 40 проектів міграції з Java на Kotlin. Замовте аудит коду — і ми підготуємо детальний план переходу.