Что это простыми словами

kotlinx.serialization — это переводчик между данными в программе и текстом, который можно сохранить или отправить.

Аналогия: в телефоне контакт хранится как набор полей — имя, номер, email. Чтобы отправить контакт другу, телефон упаковывает его в файл (например, vCard). Это и есть сериализация: превратить живой объект в программе в текст. Друг получает файл, его телефон распаковывает обратно — десериализация.

Библиотека kotlinx.serialization делает то же самое: превращает объекты в Kotlin-коде в JSON (или другой формат), чтобы отправить на сервер или сохранить в файл, и обратно.

Официальное определение

Теперь, когда суть понятна, вот как это описывают в вакансиях и документации. Эту формулировку вы встретите у заказчика и в резюме — теперь будете понимать, что за ней стоит.

«kotlinx.serialization — официальная библиотека сериализации для Kotlin, использующая compile-time генерацию кода для преобразования Kotlin-объектов в форматы JSON, CBOR, Protobuf и обратно».

Разберём по словам. «Сериализация» — превращение объекта в памяти в текст или байты, которые можно сохранить, отправить по сети или передать другой программе. «Compile-time генерация» значит, что код для преобразования создаётся при сборке проекта, а не во время работы программы — это быстрее и безопаснее. «JSON, CBOR, Protobuf» — форматы данных: JSON самый популярный, текстовый, читаемый глазами; CBOR и Protobuf бинарные, компактнее, но не читаются напрямую.

Какую задачу решает

Программы постоянно обмениваются данными: backend отдаёт список товаров мобильному приложению, приложение сохраняет настройки пользователя в файл. Данные передаются как текст (обычно JSON), а в программе с ними работают как с объектами.

Без библиотеки разработчику пришлось бы вручную писать: взять поле name из объекта, вставить в строку «name»:«значение», то же для каждого поля — скучно и легко ошибиться. kotlinx.serialization делает это автоматически: вы помечаете класс, и библиотека сама превращает его в JSON и обратно.

Особенно полезно в Kotlin Multiplatform: один и тот же код сериализации работает на Android, iOS и backend одновременно.

К какой экосистеме относится

Если в резюме встретится связка «Kotlin Multiplatform + kotlinx.serialization», рядом могут быть упомянуты Compose Multiplatform (для интерфейса) и SQLDelight (для работы с базой данных) — они все входят в экосистему Kotlin Multiplatform, но решают разные задачи и используются вместе, а не вместо друг друга.

Чем заменяется

Ту же задачу — превращение объектов в JSON и обратно — решают Gson (от Google), Jackson (самый популярный в Java/Kotlin-бэкенде) и Moshi (от Square). В проекте обычно используют что-то одно.

Главное: переход между ними дешёвый. Задача одна — превратить объект в JSON, отличается синтаксис. Разработчик, который работал с Gson, освоит kotlinx.serialization за несколько дней.

Но есть нюанс: kotlinx.serialization — официальная библиотека от создателей Kotlin (JetBrains), лучше интегрирована с языком и безопаснее по типам. Для новых Kotlin-проектов, особенно Kotlin Multiplatform, её предпочитают. Gson и Jackson пришли из мира Java, работают в Kotlin, но не так элегантно.

Что не путать

Насколько это важно при отборе

Короткий ответ: обычно это НЕ повод отбраковывать кандидата.

Самая частая ошибка — искать строго «Kotlin + kotlinx.serialization» и отсеивать сильного разработчика, у которого в резюме Jackson или Gson. Задача одна и та же: превратить объект в JSON. Он освоит kotlinx.serialization за считаные дни. Отсеивая по конкретной библиотеке сериализации, вы теряете хороших людей.

Правильный подход: смотрите, есть ли у кандидата опыт с любой библиотекой сериализации. Если есть — достаточно. Конкретная библиотека — дело пары дней.

Есть один нюанс. Если вакансия под Kotlin Multiplatform, где код пишется один раз для нескольких платформ, kotlinx.serialization там действительно предпочтительнее: она изначально спроектирована под эту задачу. Jackson и Gson из мира Java, в мультиплатформе работают хуже. Если кандидат указал опыт с Kotlin Multiplatform, но в инструментах только Gson — это повод уточнить, насколько глубоко он работал с кроссплатформой. Но это не причина отказать — скорее, вопрос на интервью.

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