Мы пока не переводим наши приложения на Kotlett целиком, но уже пишем на нём большую часть новых фичей. По перформансу на текущем этапе полёт нормальный.
Так как весь рендеринг у нас остаётся в нативной части, его производительность и отзывчивость UI не уступают нативным фичам и превосходят возможности WebView. Также Kotlett позволяет размещать множество независимых фичей на одном экране без потери производительности, благодаря переиспользованию между ними одного инстанса JS рантайма. WebView всё-таки достаточно тяжеловесная сущность, чтобы размещать на экране большое количество её экземпляров.
Помимо этого мы уже сталкивались с проблемами, когда у некоторых пользователей Android-устройств WebView просто не работало. Подробнее об этом мы писали в статье Как и зачем мы затащили GeckoView в Почту.
В нашем случае от идеи WebView + бандлы решили отказаться, чтобы весь цикл разработки мобильной фичи мог остаться в руках одного разработчика. При использовании WebView для подобной разработки нужны двое - мобильный разработчик для реализации бриджей между JS и нативом и Web-разработчик для написания самой фичи. В случае с Kotlett весь функционал может быть написан одним мобильным разработчиком.
Потенциально DSL Kotlett для описания UI ничем существенно не ограничен и позволяет реализовать любые UI решения, доступные при нативной разработке. На текущем этапе, конечно же, он требует доработок, но при необходимости всегда может быть расширен. Kotlin Multiplatform нами был выбран как уже неоднократно опробованный в деле кроссплатформенный инструмент, а сам по себе язык уже является стандартом для Android разработчиков и дружелюбен для iOS (Swift) разработчиков. Адаптивность дизайна достигается за счёт специального сервиса (моста между JS и нативом), который передаёт в код фичи всю информацию о текущем контексте выполнения (размер, разрешение и ориентация экрана/тёмная тема/язык устройства и т.д.). На основании этих параметров формируются ресурсы с помощью которых и строится адаптивный дизайн. Этот механизм очень схож с механизмом ресурсов и адаптивного дизайна в нативной разработке Android.
Бандл загруженный в приложение по HTTPS кэшируется приложением и при последующих запусках уже может работать без подключения к сети. На случай отсутствия сети при первом запуске в приложении также есть вшитый бандл - когда сеть появится, бандл сможет обновится до более актуального. При такой схеме в приложении всегда имеется бандл с функционалом, который может работать в оффлайне
Если говорить про использование DivKit в чистом виде не только для отрисовки UI, но и для полного цикла работы фичи, возникает вопрос в том, как выполнять бизнес-логику (запросить данные из кеша/запросить обновление данных в кеше с сервера/считать состояние remote config'а и т.д.). Тут мы видим два варианта:
вынести всю бизнес-логику на бэкенд, который будет присылать только слепки экранов в приложение,
либо в схеме DivKit иметь экшны, которые будут запускать эту логику в нативе. В первом случае мы получаем схему описанную в статье, во втором мы можем доставлять динамически логику формирования UI, но лишаемся возможности доставлять всю бизнес-логику.
Мы пока не переводим наши приложения на Kotlett целиком, но уже пишем на нём большую часть новых фичей. По перформансу на текущем этапе полёт нормальный.
Так как весь рендеринг у нас остаётся в нативной части, его производительность и отзывчивость UI не уступают нативным фичам и превосходят возможности WebView. Также Kotlett позволяет размещать множество независимых фичей на одном экране без потери производительности, благодаря переиспользованию между ними одного инстанса JS рантайма. WebView всё-таки достаточно тяжеловесная сущность, чтобы размещать на экране большое количество её экземпляров.
Помимо этого мы уже сталкивались с проблемами, когда у некоторых пользователей Android-устройств WebView просто не работало. Подробнее об этом мы писали в статье Как и зачем мы затащили GeckoView в Почту.
В нашем случае от идеи WebView + бандлы решили отказаться, чтобы весь цикл разработки мобильной фичи мог остаться в руках одного разработчика. При использовании WebView для подобной разработки нужны двое - мобильный разработчик для реализации бриджей между JS и нативом и Web-разработчик для написания самой фичи. В случае с Kotlett весь функционал может быть написан одним мобильным разработчиком.
Потенциально DSL Kotlett для описания UI ничем существенно не ограничен и позволяет реализовать любые UI решения, доступные при нативной разработке. На текущем этапе, конечно же, он требует доработок, но при необходимости всегда может быть расширен.
Kotlin Multiplatform нами был выбран как уже неоднократно опробованный в деле кроссплатформенный инструмент, а сам по себе язык уже является стандартом для Android разработчиков и дружелюбен для iOS (Swift) разработчиков.
Адаптивность дизайна достигается за счёт специального сервиса (моста между JS и нативом), который передаёт в код фичи всю информацию о текущем контексте выполнения (размер, разрешение и ориентация экрана/тёмная тема/язык устройства и т.д.). На основании этих параметров формируются ресурсы с помощью которых и строится адаптивный дизайн. Этот механизм очень схож с механизмом ресурсов и адаптивного дизайна в нативной разработке Android.
Бандл загруженный в приложение по HTTPS кэшируется приложением и при последующих запусках уже может работать без подключения к сети. На случай отсутствия сети при первом запуске в приложении также есть вшитый бандл - когда сеть появится, бандл сможет обновится до более актуального. При такой схеме в приложении всегда имеется бандл с функционалом, который может работать в оффлайне
Если говорить про использование DivKit в чистом виде не только для отрисовки UI, но и для полного цикла работы фичи, возникает вопрос в том, как выполнять бизнес-логику (запросить данные из кеша/запросить обновление данных в кеше с сервера/считать состояние remote config'а и т.д.). Тут мы видим два варианта:
вынести всю бизнес-логику на бэкенд, который будет присылать только слепки экранов в приложение,
либо в схеме DivKit иметь экшны, которые будут запускать эту логику в нативе. В первом случае мы получаем схему описанную в статье, во втором мы можем доставлять динамически логику формирования UI, но лишаемся возможности доставлять всю бизнес-логику.