Есть определенный набор библиотек, которые все используют, набор больше относится к KMP (примеры наборов можно посмотреть в семплах от JB) нежели к CMP. При работе с CMP добавляется выбор навигации, пока нет единого решения, но есть 3 основных варианта: Jetpack navigation, Decompose, Voyager
Про архитектуру и прочее - можно брать рекомендуемый гуглом подход 1 в 1 (во флаттере кстати он такой же). Если не подходит - адаптируете под свои нужды.
1. было ли в случае с вашим проектом оправданно отказаться от кмп с учетом сказанного в выводах?
В случае, когда ваше приложение объемное, в нем вы хотите видеть множество сложных бизнес-задач, насыщенных логикой и вычислениями, если планируемое мобильное приложение будет лицом немаленькой компании с большим сроком поддержки и ведения новых функциональных механик, то разработка на нативной кодовой базе для каждой платформы станет более надежным проверенным временем решением.
если да, то почему не пошли в эту сторону? одно из преимуществ KMP - вы можете шарить только то, что вам нужно. то есть возможно совмещать нативный подход и KMP только в части проекта, поэтому переход был бы возможен, переписывание приложения не потребовалось бы.
в целом, не могу согласиться с этим пунктом, тк если в приложении много сложной логики, то ее шаринг (хотя бы частичный) даст больше выгоды, чем в мелком проекте: в разработке, исправлении багов, тестировании, поддержке.
2. по поводу команды:
пробовали ли подход когда ios-разработчики пишут shared код наряду с android-разработчиками?
по нашему опыту вкатиться ios-разработчикам в KMP не составляет проблем, а на рынке уже есть люди с этим опытом.
таким образом, не придется временно подключать android-разработчиков в проект и блокироваться разработкой общей части, разработчики становятся более универсальными, затраты на разработку сокращаются.
3. по поводу языка Kotlin:
на самом деле ios-разработчику не сложно вникнуть в kotlin, нужна только мотивация. современные языки достаточно похожи. при разработке проекта редко приходится затрагивать внутренности языка и сложные конструкции, на которых не хватит ios-разработчика. плюс можно в любое время проконсультироваться с android-разработчиком.
кстати, иосеры кайфуют от android studio )
4.
При этом, если в проекте используется подход DDD (domain-driven development), то разработка любой из платформ затруднительна, либо невозможна вовсе без бизнес-логики общего модуля.
эта же проблема будет и в нативной разработке, но если вы разрабатываете полностью нативно и android уже реализовал доменную логику, то ios это только предстоит сделать, а не переиспользовать уже готовое решение на KMP.
в задачах почти всегда есть информация о дизайне, поэтому можно договориться заранее о контракте между нативными частями и KMP. и разрабатывать логику и ui параллельно. но по нашему опыту эффективнее все-таки объединить.
5. вытекают ли проблемы приложения, о которых вы пишете, из технологии KMP: необходимость рефакторинга, трудности и ошибки у пользователей? это ведь присуще проекту на любой технологии)
К сожалению, вы невнимательно читаете. Речь идет не об уменьшении времени компиляции на 94%, аоб увеличении производительности (скорости) компилятора на 94%.
Таким образом:
Раньше я мог выполнять работу X за время Y - начальная производительность.
Теперь я могу выполнять работу X за время Y / 2 - конечная производительность.
Итого: конечная производительность в 2 раза больше начальной.
Выгода здесь понятно в рефакторинге. И два бонуса. Основной - это масштабирование на несколько целевых архитектур. Я думаю, ради этого всё затевалось. Второй - ускорение компиляции - это бонусом.
Языку уже 13 лет, цели изменились, много нового добавилось.
Из-за появления новых целевых архитектур замедлялась разработка фичей языка. Поэтому JB в последних релизах и в том числе в 2.0 не выпускают ничего нового. Но в будущем новый компилятор открывает дорогу.
Я бы не сказал что была основная цель, а что-то далось бонусом. Тк ускорение фронтенда и масштабирование на разные архитектуры происходит в разных частях компилятора. Поэтому логично предположить что работа над этими улучшениями была разделена.
Ничего особенного с точки зрения компиляторов. Одна из возможных архитектур в развитии.
Чем плоха классическая архитектура, если она решает нужные задачи и уже опробована в действии много раз. Kotlin не экспериментальный язык, чтобы испытывать что-то особенное в компиляторе)
Из альтернатив, тоже довольно стандартных, является построение по синтаксису отдельного семантического дерева. Здесь есть свои преимущества и недостатки, но их никто толком не анализировал.
Тк компилятор переписывался то я думаю что в JB анализировали разные подходы.
Наличие нескольких структур данных в предыдущей версии компилятора ухудшала JIT-оптимизацию и кеширование процессора. Видится, что в варианте с наличием нескольких деревьев может быть аналогичная проблема.
Но, конечно, интересно, какие альтернативы JB рассматривали. Я эту информацию в открытых источниках не нашел.
Про сахарные преобразования в статье сказано скупо, что этот этап есть. А это самое интернюесное, потому что именно здесь могут быть конфликты - некоторые сахарные преобразования можно выполнять только до других, а иные рекурсивно зависят от других, и нет регулярной литературы, описывающей решения. Наконец, понятно, что в сахарных преобразованиях участвует семантика, но проблема в том, что семантика может быть на момент сахарных преобразований еще не до конца выведена.
Так это часть алгоритма компилятора. Благо компилятор открытый. Статья и так получилась нагруженной и не было задачи разобрать все нюансы работы компилятора.
94% это ускорение по чистому билду. Помимо этого в статье с замерами есть и другие сценарии.
Замеры проведены на реальных развивающихся опенсорсных проектах: Anki-Android, Exposed. Понятно, что эти проекты не эталонные, и будет интересно увидеть цифры от крупных компаний в будущем.
ViewModel может использоваться не только для пережития ЖЦ вьюхи как в андроиде, но и как архитектурная сущность. Мы используем ViewModel в KMP-части, они шарятся между ios и android. Поэтому с этим проблем нет.
Все-таки не нужно смешивать KMP и Compose multiplatform. KMP не нацелен на реализацию кроссплатформенного UI.
А различия верстки на мобильном устройстве и десктопе придется учитывать при использовании любой технологии. Но это не значит что нельзя создать адаптивную верстку и переиспользовать UI-элементы.
Из платформ поддерживаются Windows, MacOS, Linux. В Compose Multiplatftorm для отрисовки используется Skia. В качестве skia backend могут быть использованы OpenGL/Vulkan/Metal/DirectX
1. Думаю, для коренных катарцев своя система «мотивации», но о ней мы честно не знаем. Мы рассказали о механизмах, которые применяют к иностранцам
2. Те двое были мусульмане, из Кыргызстана. На не-мусульман телесные наказания не распространяются
Также стоит иметь в виду распространение языка среди специалистов на рынке. Котлин в этом плане выигрывает.
Есть определенный набор библиотек, которые все используют, набор больше относится к KMP (примеры наборов можно посмотреть в семплах от JB) нежели к CMP. При работе с CMP добавляется выбор навигации, пока нет единого решения, но есть 3 основных варианта: Jetpack navigation, Decompose, Voyager
Про архитектуру и прочее - можно брать рекомендуемый гуглом подход 1 в 1 (во флаттере кстати он такой же). Если не подходит - адаптируете под свои нужды.
Во флаттере то тоже есть куча разных подходов
Открывать Xcode для сборки не нужно, все работает из Android Studio
См инструкцию
Во flutter по дефолту используется Impeller
Спасибо за статью!
1. было ли в случае с вашим проектом оправданно отказаться от кмп с учетом сказанного в выводах?
если да, то почему не пошли в эту сторону? одно из преимуществ KMP - вы можете шарить только то, что вам нужно. то есть возможно совмещать нативный подход и KMP только в части проекта, поэтому переход был бы возможен, переписывание приложения не потребовалось бы.
в целом, не могу согласиться с этим пунктом, тк если в приложении много сложной логики, то ее шаринг (хотя бы частичный) даст больше выгоды, чем в мелком проекте: в разработке, исправлении багов, тестировании, поддержке.
2. по поводу команды:
пробовали ли подход когда ios-разработчики пишут shared код наряду с android-разработчиками?
по нашему опыту вкатиться ios-разработчикам в KMP не составляет проблем, а на рынке уже есть люди с этим опытом.
таким образом, не придется временно подключать android-разработчиков в проект и блокироваться разработкой общей части, разработчики становятся более универсальными, затраты на разработку сокращаются.
3. по поводу языка Kotlin:
на самом деле ios-разработчику не сложно вникнуть в kotlin, нужна только мотивация. современные языки достаточно похожи. при разработке проекта редко приходится затрагивать внутренности языка и сложные конструкции, на которых не хватит ios-разработчика. плюс можно в любое время проконсультироваться с android-разработчиком.
кстати, иосеры кайфуют от android studio )
4.
эта же проблема будет и в нативной разработке, но если вы разрабатываете полностью нативно и android уже реализовал доменную логику, то ios это только предстоит сделать, а не переиспользовать уже готовое решение на KMP.
в задачах почти всегда есть информация о дизайне, поэтому можно договориться заранее о контракте между нативными частями и KMP. и разрабатывать логику и ui параллельно. но по нашему опыту эффективнее все-таки объединить.
5. вытекают ли проблемы приложения, о которых вы пишете, из технологии KMP: необходимость рефакторинга, трудности и ошибки у пользователей? это ведь присуще проекту на любой технологии)
Спасибо за решение!
На конфе показывали сценарии:
patreon: выжимка важной информации из непрочитанных сообщений в чате
grammarly: умные подсказки по улучшению написанного текста
В статье говорится об ускорении компилятора на 94%, а не уменьшении времени компиляции на 94%. См объяснение выше.
К сожалению, вы невнимательно читаете. Речь идет не об уменьшении времени компиляции на 94%, а об увеличении производительности (скорости) компилятора на 94%.
Таким образом:
Раньше я мог выполнять работу X за время Y - начальная производительность.
Теперь я могу выполнять работу X за время Y / 2 - конечная производительность.
Итого: конечная производительность в 2 раза больше начальной.
Языку уже 13 лет, цели изменились, много нового добавилось.
Из-за появления новых целевых архитектур замедлялась разработка фичей языка. Поэтому JB в последних релизах и в том числе в 2.0 не выпускают ничего нового. Но в будущем новый компилятор открывает дорогу.
Я бы не сказал что была основная цель, а что-то далось бонусом. Тк ускорение фронтенда и масштабирование на разные архитектуры происходит в разных частях компилятора. Поэтому логично предположить что работа над этими улучшениями была разделена.
Чем плоха классическая архитектура, если она решает нужные задачи и уже опробована в действии много раз. Kotlin не экспериментальный язык, чтобы испытывать что-то особенное в компиляторе)
Тк компилятор переписывался то я думаю что в JB анализировали разные подходы.
Наличие нескольких структур данных в предыдущей версии компилятора ухудшала JIT-оптимизацию и кеширование процессора. Видится, что в варианте с наличием нескольких деревьев может быть аналогичная проблема.
Но, конечно, интересно, какие альтернативы JB рассматривали. Я эту информацию в открытых источниках не нашел.
Так это часть алгоритма компилятора. Благо компилятор открытый. Статья и так получилась нагруженной и не было задачи разобрать все нюансы работы компилятора.
94% это ускорение по чистому билду. Помимо этого в статье с замерами есть и другие сценарии.
Замеры проведены на реальных развивающихся опенсорсных проектах: Anki-Android, Exposed. Понятно, что эти проекты не эталонные, и будет интересно увидеть цифры от крупных компаний в будущем.
Вы неправильно трактуете это число. Как трактовать эти числа можете почитать в статье.
Также в этой статье привожу пример на официальные замеры JB. Там явно видно числа: 94% это не в 16 раз ускорение, у чуть меньше чем в 2.
Вакансии постят, видимо, живут
Вчера JB провели вебинар и ответили на этот вопрос. Не планируют в ближайшее время, сейчас фокус на другом
ViewModel может использоваться не только для пережития ЖЦ вьюхи как в андроиде, но и как архитектурная сущность. Мы используем ViewModel в KMP-части, они шарятся между ios и android. Поэтому с этим проблем нет.
По этому поводу уже заведено несколько issue 1, 2
Все-таки не нужно смешивать KMP и Compose multiplatform. KMP не нацелен на реализацию кроссплатформенного UI.
А различия верстки на мобильном устройстве и десктопе придется учитывать при использовании любой технологии. Но это не значит что нельзя создать адаптивную верстку и переиспользовать UI-элементы.
Из платформ поддерживаются Windows, MacOS, Linux. В Compose Multiplatftorm для отрисовки используется Skia. В качестве skia backend могут быть использованы OpenGL/Vulkan/Metal/DirectX
как уже подсвечивал в статье, знание 2 языков не является обязательным требованием
с использованием Compose multiplatform количество Swift-кода уменьшается
ну и для написания платформенно-специфичного кода во flutter swift тоже нужен.