Comments 19
Давайте представим, что вы пользователь Облака Mail. Сеть пропала, а вам срочно нужны сканы паспорта из загруженных файлов, например, для подтверждения возраста
Хранить сканы паспорта в публичном облаке - это безумие.
Мы знали, что вы про это напишите.)
О, кстати, давно хотел спросить: а что может злоумышленник сделать со сканом паспорта? Фото или его распечатка вроде бы не могут быть основанием ни для чего, для чего может быть использован реальный паспорт. Кредит по скану не оформят, счёт не откроют. Подтвердить или опровергнуть грузите ли вы свой паспорт или чужой онлайн-сервисы компетенции не имеют, а значит и считать его реальным документом - тоже не имеют права.
нужно ли открыть код фреймворка Kotlett, сделав его народным? Хотели бы увидеть его в open source? Решает ли он ваши боли?
А чтоб это понять, действительно ли он решает боли или добавит новых - нужно попробовать на нём пописать ;-)
Звучит резонно. Но получается, что интерес попробовать есть, верно?)
Определённо) BDUI всегда казался очень полезной в определённых ситуациях, но всё же тяжеловесной штукой. Тут подход интереснее...
Хотел ещё уточнить: вроде ходила "всем известная" (но я ни разу её не проверял) информация, что Apple не разрешает сторонние интерпретаторы кода тащить с собой в приложение. Я так понимаю, сейчас такого ограничения уже нет?
Вместе с Kotlett мы не добавляем новых интерпретаторов кода в iOS — код фичей написанных на Kotlin транспилируется в обычный JS, JS по воздуху прилетает пользователям на устройство и исполняется во встроенном в iOS движке JavaScriptCore. Всё взаимодействие между JS и нативом происходит посредством бриджей, которые в обычном порядке регистрируются в JSRuntime.
Я уже видел два проекта с похожим подходом - в обоих неистово текла память - потому что мост между js/native (js/java в случае андроид) - требует ручного управления памятью (v8 вам не сообщит - когда он собрал объект js сборщиком мусора). Как вы это победили? Или тут всё как обычно - храним все объекты в рамках какого нибудь контекста, надеемся что контекст умрет раньше, чем кончится память.
В целом мы стараемся сократить время жизни бридж объектов до минимума, чтобы они существовали только пока нужно с ними взаимодействовать. Сам код взаимодействия с V8/JSCore полностью генерируемый, кроме нескольких исключительных случаев.
На Android все сгенерированные сущности наследуются от Closable и почти всегда освобождаются сразу после использования. В случае коллбэков это происходит после их срабатывания - очищаются как входные параметры так и промежуточные обёртки.
Опасные, с точки зрения утечек, сценарии с долго живующими коллбэками (например, подписки на состояние) со стороны Kotlin JS закрыты фасадом в виде Kotlin Flow, который отвечает за вызов нужного метода удаления коллбэка со стороны нативной реализации.
На iOS JSCore сам очищает JSValue если он не был явно превращён в JSManagedValue. Если в экземпляре JSValue были ссылки на объект из ObjC/Swift, то количество ссылок на него уменьшится и он очистится стандартным образом.
Как будто тонкое место должно быть там, где сгенерированный js код инстанцирует обертку натива, которую он потом должен явно закрыть (и как будто closable на стороне натива может привести к преждевременной кончине объекта), вызов close должен передаваться именно из js контекста в момент когда использование объекта завершено. Особенно интересно как это с долгоживущими сервисами типо соединения с базой данных / управление нативными сенсорами / мультимедиа.
Короче выкладывайте в openSource - очень интересно было бы посмотреть, особенно на предмет утечек)
Так точно
Хотели бы увидеть его в open source?
Да, было бы интересно взглянуть
Что-то непонятно насчет BDUI, цитирую:
Самая принципиальная проблема — классический BDUI абсолютно зависим от бэкенда в режиме реального времени для получения вёрстки и данных. Нет сети — нет интерфейса, нет функционала.
Да, мы используем DivKit как транспорт UI верстки из JS в native
Приложение (с интегрированным Kotlett SDK) получает ссылку, загружает бандл по HTTPS.
Не чувствуете противоречия? Теперь загружается и в лифте и на парковке? Вас случайно коллеги из Макса не кусали? А если серьезно, ваша постановка проблемы выдуманная. DivKit рендерит в оффлайне последнюю загруженную версию лейаута. Ну накрайняк можно было еще раз покешировать руками для верности
Сравним с BDUI. Для примера примем ряд архитектурных допущений:
Клиент получает полностью «запечённое» состояние в виде слепка вёрстки;
Клиент не знает, какие бизнес-сущности он отображает;
Шаблонизация состояния в вёрстку выполняется отдельным сервисом Backend-for-Frontend (BFF);
BFF — stateless-сервис.
С чего вы это взяли? Разберитесь как работает DivKit. Никакого слепка верстки нет, вроде отрендеренного на сервере html. Верстка приходит в виде json схемы с состояниями, переходами, экшенами, которые будут выполнены вью-моделями. Кешируется. Части схемы могут быть переиспользованы в других лейаутах. Можно в схеме передать флоу с несколькими экранами. Короче пацаны, накодили вы знатно, героически, затянули JS движки и тд и тп и теперь вы обладатели таких котлет, которые плотно облепили мухи.
Бандл загруженный в приложение по HTTPS кэшируется приложением и при последующих запусках уже может работать без подключения к сети. На случай отсутствия сети при первом запуске в приложении также есть вшитый бандл - когда сеть появится, бандл сможет обновится до более актуального. При такой схеме в приложении всегда имеется бандл с функционалом, который может работать в оффлайне
Если говорить про использование DivKit в чистом виде не только для отрисовки UI, но и для полного цикла работы фичи, возникает вопрос в том, как выполнять бизнес-логику (запросить данные из кеша/запросить обновление данных в кеше с сервера/считать состояние remote config'а и т.д.). Тут мы видим два варианта:
вынести всю бизнес-логику на бэкенд, который будет присылать только слепки экранов в приложение,
либо в схеме DivKit иметь экшны, которые будут запускать эту логику в нативе. В первом случае мы получаем схему описанную в статье, во втором мы можем доставлять динамически логику формирования UI, но лишаемся возможности доставлять всю бизнес-логику.
Я может быть глупый вопрос задам, но:
Почему не использовать обычный WebView для этих целей? Сами бандлы можно точно так же хранить в оффлайне и отображать на клиенте. Точно так же можно прокидывать экшны юзера обратно нативный код и влиять на вью из нативного кода.
Бонусом получаем полноценную вёрстку с поддержкой полноценной адаптивности, поддержку логики любой сложности без завязки на ограниченность DSL
С моей стороны это выглядит как лютый оверинжиниринг с большим количеством минусов: свой по определению ограниченный DSL; необходимость писать на котлине (даже при наличии DSL); специальные средства для разработки (из фигмы уже так просто не экспортнёшь); не упомянута тема с адаптивным дизайном, хотя это тоже скорее продолжение DSL, но всё же цель всего это - кроссплатформенность, поэтому адаптивность - это важный вопрос
В нашем случае от идеи WebView + бандлы решили отказаться, чтобы весь цикл разработки мобильной фичи мог остаться в руках одного разработчика. При использовании WebView для подобной разработки нужны двое - мобильный разработчик для реализации бриджей между JS и нативом и Web-разработчик для написания самой фичи. В случае с Kotlett весь функционал может быть написан одним мобильным разработчиком.
Потенциально DSL Kotlett для описания UI ничем существенно не ограничен и позволяет реализовать любые UI решения, доступные при нативной разработке. На текущем этапе, конечно же, он требует доработок, но при необходимости всегда может быть расширен.
Kotlin Multiplatform нами был выбран как уже неоднократно опробованный в деле кроссплатформенный инструмент, а сам по себе язык уже является стандартом для Android разработчиков и дружелюбен для iOS (Swift) разработчиков.
Адаптивность дизайна достигается за счёт специального сервиса (моста между JS и нативом), который передаёт в код фичи всю информацию о текущем контексте выполнения (размер, разрешение и ориентация экрана/тёмная тема/язык устройства и т.д.). На основании этих параметров формируются ресурсы с помощью которых и строится адаптивный дизайн. Этот механизм очень схож с механизмом ресурсов и адаптивного дизайна в нативной разработке Android.
У меня возник тот же вопрос, что и у комментатора выше. Понятно ваше желание сохранить всю разработку на стороне команды мобильных разработчиков, но оптимально ли такое решение технически?
Замеряли ли вы перформанс приложение после перехода на Kotlett? Как он изменился?
Мы пока не переводим наши приложения на Kotlett целиком, но уже пишем на нём большую часть новых фичей. По перформансу на текущем этапе полёт нормальный.
Так как весь рендеринг у нас остаётся в нативной части, его производительность и отзывчивость UI не уступают нативным фичам и превосходят возможности WebView. Также Kotlett позволяет размещать множество независимых фичей на одном экране без потери производительности, благодаря переиспользованию между ними одного инстанса JS рантайма. WebView всё-таки достаточно тяжеловесная сущность, чтобы размещать на экране большое количество её экземпляров.
Помимо этого мы уже сталкивались с проблемами, когда у некоторых пользователей Android-устройств WebView просто не работало. Подробнее об этом мы писали в статье Как и зачем мы затащили GeckoView в Почту.
Для Kotlett мы завернули DivKit в простой и понятный DSL, который взял на себя все проблемные места DivKit
Зачем писать свою dsl обертку над divkit, если на гитхаб странице дивкита уже есть такая обертка, причем не только для kotlin.
Человеческие ресурсы: кто-то должен поддерживать код BFF при каждом изменении API.
В нативном коде разве не нужно поддерживать код при изменении api? Какой-то непонятный минус)
Фокус на мобильных разработчиках. Решение должно быть:
максимально дружелюбным к нашим основным мобильным командам;
без необходимости привлекать армию JS-/бэкенд-спецов или переучиваться.
Можно же использовать kotlin dsl для построения верстки на бекенд
Offline-first: фичи должны работать без доступа к сети, как вшитый код
А разве нельзя решуть эту проблему с помощью кэширования?
В целом статься довольно интересная. Сама технология выглядит занимательно. Однако есть чувство, что плюсы и минусы в данной статье преувеличины.
Также хотелось бы отметить, что имхо дивкит дает не слишком нативный ui/ux. Возможно, легче было бы использовать web, а не переизобретать его
Отделяем мух от Kotlett. Динамические обновления без релизов и BDUI