Как стать автором
Обновить

Многопоточность и Kotlin в Яндекс.Картах: как не допустить падения новых фич на iOS

Время на прочтение12 мин
Количество просмотров12K
Всего голосов 24: ↑22 и ↓2+27
Комментарии9

Комментарии 9

Думали будет все по красоте, а оказалось как всегда. Халявы не бывает

В чем тогда преимущество перед С++, когда тут с памятью даже сложнее и непонятнее работать?

Плюс как я понимаю тут не доступна вся JDK библиотека (Date, Calendar, ...), как это обходите?

У C++ дорогой интероп с JVM. Kotlin проще. Его со старта знала половина команды. А вторая половина знала Swift, на который Kotlin довольно сильно похож.

Для большинства простых задач уже есть неплохие мультиплатформенные библиотеки. Если подходящей библиотеки нет, но API на iOS и Android похожи, пишем свои expect-actual. Если же поведение на платформах сильно различается, такую функциональность лучше вынести за интерфейс, реализуемый каждым клиентом независимо. В конце концов, не все фичи стоит выносить в мультиплатформу.

Проблем у нас изначально не было, поскольку всё работало на одном потоке. Ну а теперь и мы сами, конечно, очень ждём релиза новой модели памяти Kotlin/Native.

Насколько я знаю kotlin/native доступен для андроид

Возможно ли что все будет проще если компилить в нэйтив под все платформы? Как я понимаю баги идут именно из-за различия моделей памяти jvm и native билдов

Да, можно собирать Kotlin/Native под Android. Но тогда потеряется прямой интероп с Kotlin/JVM, придётся использовать JNI.

И, самое главное, описываемые проблемы Kotlin/Native не исчезнут. Просто они начнут воспроизводиться ещё и на Android.

есть сомнения, что лучше было бы отдельно вести проект на iOS(swift) и на Android(kotlin/jvm), без Kotlin Multiplatform и Kotlin Native

рекламу выпилите из навигатора лучше.

Что то мне кажется было проще транслятор, который бы котлин в свифт переводил. Помню был такой лет 15 назад, который Си Шарп в джаву переводил.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий