Alex009
commented
3 years ago Привет! Сам подход к утечкам привести не должен. Если утечки и возникнут то по другим причинам (чаще всего циклы с участием swift объектов этому виной - если цикл состоит из объектов созданных самим котлином то сборщик мусора это заметит и почитстит, а вот при участии свифтовых объектов сборщик не справится - нужны слабые ссылки в правильных местах). гарантированная заморозка перед передачей на платформу несет явную пользу - не надо задумываться о том что объект полученный с котлина нельзя на другие потоки кидать, а с данной реализацией можно кидать объект по потокам и все будет ок. главное чтобы интерфейс этих объектов не содержал никаких возможностей для редактирования (то есть иммутабельные классы использовать как результаты) - иначе если кто-то с натива дернет метод редактирования то получит креш о попытке мутировать замороженный объект
Для общения с KMM кодом используем прокладку в виде типа, который похож на cold Single Rx тип.
https://gist.github.com/d249f04577a72fae3874b08b31a2c39f
Чтобы на iOS не было проблем с обращением к Kotlin объектам на разных потоках, есть расширение, которое фризит результаты перед возвратом на платформу.
https://gist.github.com/41d9bf9a1f7e2d3c2993997a5888ac9f
Есть ли какие-то подводные камни, что это может привести к утечкам памяти или другим проблемам? Спасибо за ответ.