Dev Easy Notes

Баги
Баги, баги баги. Класс View развивался с самой первой версии Android, а это уже как 14 лет. Даже несмотря на это, во View все еще есть недочеты. Ожидать что Compose, которому всего пару лет, сразу будет работать идеально это довольно оптимистично. Естественно Compose еще поуши в багах, которые со временем (я надеюсь) пофиксят. Поэтому если и внедрять его в существующие проекты то очень аккуратно и желательно под каким-нибудь фиче флагом.

Гугл, который любит Deprecated
Это не относится напрямую к самому фреймворку Compose, однако частично его касается. Compose делают инженеры из компании Гугл. А Гугл славится чем, что любит депрекейтить свои же решения. Реально, они в одном из релизов, задепрекейтили аннотацию Deprecated. Support Library, Billing Library, Synthetics, Volley (формально она не deprecated, но ее поддерживает всего один разраб, а пользуются еще 2.5, что не особо вдохновляет) это те немногие решения от которых Гугл просто отказались.

Разумеется нет никаких оснований полагать, что от разработки и поддержки Compose откажутся просто так. Однако нужно понимать, что Compose закрытый проект, который поддерживает одна компания и в случае чего будет достаточно трудно с него слезть. Будет конечно сюр, если они через пару лет выпустят ComposeX и скажут, все что было до этого deprecated, пожалуйста, не используйте.

Производительность 
Один из плюсов Compose по обещаниям разработчиков это производительность. В целом так оно и есть, благодаря подходу позиционной мемоизации (поставьте пару сердец если хотите про это отдельный пост). Compose функции и правда очень производительны и перерисовывается только малая часть экрана которая изменилась.

Однако ходят слухи о том, что в Compose тормозят списки. Списки действительно тормозят, но только в debug сборке, потому как в релизной сборке включается куча оптимизаций про которые забывают. Некоторые разработчики проводили тесты которые показывают что, Compose и правда медленнее текущего решения примерно на 10% в релизной сборке, что для нового фреймворка терпимо. 

В итоге можно сказать, что Compose существенно не влияет на производительность. Однако в дебажной сборке он будет безбожно тормозить. Помимо этого плохая идея смешивать RecyclerView и Compose, вот тут оптимизации идут лесом и списки правда будут тормозить даже в релизной сборке. Если решили делать списки на Compose, то делайте их полностью на Compose.

Диалоги
Вот тут пока грустно. Если посмотреть на базовый пример того, как показываются диалоги. Решение выглядит мягко говоря костыльно. Нельзя как раньше сказать системе покажи диалог и забить на него. 

Сейчас показывая диалог вы должны полностью контролировать его показ, он как бы становится частью вашей верстки. Диалог в Compose обязывает создавать состояние, чтобы контролировать показ этого самого диалога. Удобно это или нет, уже решать вам.

Скоуп ViewModel
С ViewModel тоже не все однозначно. Изначально ViewModel проектировались именно под скоуп фрагмента или activity, другими словами ViewModel умирали со смертью компонента в котором используются. Фишка в том, что если мы используем Compose без фрагментов или activity у нас нет компонентов, которые бы позволяли отлеживать ЖЦ. Точнее говоря он есть, та самая первая Acitivty с которой начинается запуск Compose и если вы будете просто использовать ViewModel они будут жить пока не умрет та самая первая Activity. Вот только она нихера не умрет, пока приложение используется и это может доставить гемороя.

Частично эту проблему решили. Однако решили тем, что вы обязаны использовать библиотеку навигации от гугла, если хотите что-то другое, то делайте все на фрагментах. Вот такой тоталитаризм от гугла.

P.S прикиньте в телеге есть пользователь с ником “Deprecated” и если писать эту аннотацию с @ то телега считает что я указываю именно его. Забавно, вот у него наверное оповещений навалом с разных каналов про разработку)

UPD: Compose не закрытый проект, а open source тут я вас обманул. Однако если Гугл откажется от его поддержки не факт, что кто-то возмется

❤46👍5

www.tgoop.com/dev_easy_notes/131

2.07K viewsedited  Jun 30, 2022 at 07:53

Баги
Баги, баги баги. Класс View развивался с самой первой версии Android, а это уже как 14 лет. Даже несмотря на это, во View все еще есть недочеты. Ожидать что Compose, которому всего пару лет, сразу будет работать идеально это довольно оптимистично. Естественно Compose еще поуши в багах, которые со временем (я надеюсь) пофиксят. Поэтому если и внедрять его в существующие проекты то очень аккуратно и желательно под каким-нибудь фиче флагом.

Гугл, который любит Deprecated
Это не относится напрямую к самому фреймворку Compose, однако частично его касается. Compose делают инженеры из компании Гугл. А Гугл славится чем, что любит депрекейтить свои же решения. Реально, они в одном из релизов, задепрекейтили аннотацию Deprecated. Support Library, Billing Library, Synthetics, Volley (формально она не deprecated, но ее поддерживает всего один разраб, а пользуются еще 2.5, что не особо вдохновляет) это те немногие решения от которых Гугл просто отказались.

Разумеется нет никаких оснований полагать, что от разработки и поддержки Compose откажутся просто так. Однако нужно понимать, что Compose закрытый проект, который поддерживает одна компания и в случае чего будет достаточно трудно с него слезть. Будет конечно сюр, если они через пару лет выпустят ComposeX и скажут, все что было до этого deprecated, пожалуйста, не используйте.

Производительность 
Один из плюсов Compose по обещаниям разработчиков это производительность. В целом так оно и есть, благодаря подходу позиционной мемоизации (поставьте пару сердец если хотите про это отдельный пост). Compose функции и правда очень производительны и перерисовывается только малая часть экрана которая изменилась.

Однако ходят слухи о том, что в Compose тормозят списки. Списки действительно тормозят, но только в debug сборке, потому как в релизной сборке включается куча оптимизаций про которые забывают. Некоторые разработчики проводили тесты которые показывают что, Compose и правда медленнее текущего решения примерно на 10% в релизной сборке, что для нового фреймворка терпимо. 

В итоге можно сказать, что Compose существенно не влияет на производительность. Однако в дебажной сборке он будет безбожно тормозить. Помимо этого плохая идея смешивать RecyclerView и Compose, вот тут оптимизации идут лесом и списки правда будут тормозить даже в релизной сборке. Если решили делать списки на Compose, то делайте их полностью на Compose.

Диалоги
Вот тут пока грустно. Если посмотреть на базовый пример того, как показываются диалоги. Решение выглядит мягко говоря костыльно. Нельзя как раньше сказать системе покажи диалог и забить на него. 

Сейчас показывая диалог вы должны полностью контролировать его показ, он как бы становится частью вашей верстки. Диалог в Compose обязывает создавать состояние, чтобы контролировать показ этого самого диалога. Удобно это или нет, уже решать вам.

Скоуп ViewModel
С ViewModel тоже не все однозначно. Изначально ViewModel проектировались именно под скоуп фрагмента или activity, другими словами ViewModel умирали со смертью компонента в котором используются. Фишка в том, что если мы используем Compose без фрагментов или activity у нас нет компонентов, которые бы позволяли отлеживать ЖЦ. Точнее говоря он есть, та самая первая Acitivty с которой начинается запуск Compose и если вы будете просто использовать ViewModel они будут жить пока не умрет та самая первая Activity. Вот только она нихера не умрет, пока приложение используется и это может доставить гемороя.

Частично эту проблему решили. Однако решили тем, что вы обязаны использовать библиотеку навигации от гугла, если хотите что-то другое, то делайте все на фрагментах. Вот такой тоталитаризм от гугла.

P.S прикиньте в телеге есть пользователь с ником “Deprecated” и если писать эту аннотацию с @ то телега считает что я указываю именно его. Забавно, вот у него наверное оповещений навалом с разных каналов про разработку)

UPD: Compose не закрытый проект, а open source тут я вас обманул. Однако если Гугл откажется от его поддержки не факт, что кто-то возмется

BY Dev Easy Notes