Comments 14
Спасибо за статью, может где-нибудь уже есть хороший курс где объяснят все основы и подводные камни Compose?
А где у вас используется compose? Я вот открыл приложение ozon основное - нигде не видно, везде вьюхи. Открыл озон банк, там вообще web view.
Единственное у кого в большом приложении видел - циан, у них прям в проде есть
Ozon Seller - для продавцов. Там 99.9% компоуза. Сейчас в процессе отказа от фрагментов.
Хм, ну я так быстро поглядел и в 99.9 верю с трудом - даже экран ввода телефона при регистрации на вьюхах :)
Но да, тоже в проде, интересно.
Чего ж вы инсеты не обрабатываете? И анимацию раскрытия клавиатуры?
Что касается статьи... Compose конечно крутой, но вот rv никак до конца не заменит... Да и его unspecified реализации у offset и прочих тоже могут добавить проблем... Кстати, а почему вы так упираетесь в рекомпозиции? Ведь если они адекватно случаются (ну там картинки лоадер загрузил), ничего в них плохого нет, производительность не страдает.
99.9% - скорее в самом коде проекте. Авторизация - это внешний озоновский сдк, за которой отвечает уже не наша команда. На View в нашем коде осталось 2-3 экрана, которые давно не трогали.
Инсеты - зависят от фичи. Если это не авторизация/мессенджер, то тогда скорее всего наш код. И в нём полную поддержку инсетов планируем завести после отказа от фрагментов. Пока что точечно на костылях это делаем.
В рекомпозицию уже давно не упираемся. На них смотрели в основном в начальной стадии оптимизации, когда было много лишних рекомпозиций. Про неё была 1-ая часть статьи как раз. Сейчас уже смотрим больше в сторону разгрузки самих (ре)композиций по длительности и нагрузке, а не по числу.
По поводу замены rv - у нас в целом всё ок со списками сейчас. По лагу на время скролла на 90 перцентиле - одни нули (максимум 0.5%). Года 1.5 назад до оптимизаций и на Compose 1.1-1.2 этот показатель был 15-20%, что очень плохо. Поэтому на Compose 1.5 ленивые списки уже вполне норм. Не говоря про Compose 1.6.
Ну нет, с ними все не так хорошо как могло бы - сами анимации все никак стандартный item animator не догонят, а те что есть (я правда несколько месяцев назад смотрел последний раз), выглядят не так красиво. Да и есть проблемы при скроле все равно. Но да, 1.5.0 прям кардинально повлиял на производительность, тоже на macro benchmark смотрели, было это видно. Дубликаты ключей падают - я над ios-никами смеялся, а тут гугл так подсобил. Могут быть сюрпризы при постраничный загрузках, если мы не на нулевую, а например на 5 страницу придем (по Линке например), то могут быть проблемы с позиционированием (надо как-то позицию сохранять в стейте). В общем нюансов то хватает до сих пор.
А уж как гугл выпустил в стабильный релиз progress indicator который падал, это вообще был цирк (но к спискам это уже не относится)
Я больше со стороны производительности и в целом использования говорил. Так как я платформенный разработчик, то могу не знать кейсы анимаций, в которых списки Compose проигрывают rv. Поэтому по моему опыту использования они уже круче и удобнее, чем rv. Но я с rv работал последний раз года два назад, будучи ещё джуном-мидлом)
А дубликаты ключей, которые роняют приложение - это нормально в плане использования? :)
Мы генерируем свой id (ключ) для такого внутри класса для пагинации, так как тоже могут прийти несколько элементов с одинаковым id. Не вижу особой проблемы. В противном случае разработчикам Compose пришлось бы делать неявное поведение. И тогда это сводится к дискуссионному вопросу: крашить, но не скрывать проблему или скрывать (делая любое другое поведение), но не крашить.
Другой контракт списка относительно rv - это не плохо и не хорошо. Плохо может быть только с той стороны, что про это многие не знают, но со временем узнают)
А так всё явно прописано в доке к параметру key - "дубликаты не допустимы".
Про нормально в плане использования я говорю со стороны знания, как их правильно использовать. Мне чисто приятнее использовать и кратче писать, чем в xml с rv.
Сейчас довольно легко судить с той стороны, когда rv изучен всеми от начала до конца и все знают его проблемы и как на нём не стоит писать, а как стоит. Но вы всегда можете помочь с этим сообществу и написать статью о таких особенностях ленивых списках в Compose относительно rv и как их решать, чтобы поднять общий уровень осведомлённости)
Так можно везде не видеть особой проблемы, что-то уникальное всегда можно генерить, например any() отдавать, но что-то мне подсказывает, что такое в коде вы бы увидеть не хотели. И откуда берется дискуссионные поведение - мы не можем отобразить два абсолютно одинаковых элемента разве? Да можем конечно, т.е. это так-то возможный вариант, который нам просто отрезали. Но вашу точку зрения я понял
Если в key не передавать ничего, то он будет использовать порядковый номер как ключ и спокойно отображать одинаковые элементы. Есть требование: ключ должен быть стабильный и уникальный. Если ничего не передать key - то порядковый номер вполне выполняет это требование. Если нам нужно обновлять список, то нужно предоставлять свой ключ для более правильной работы внутреннего механизма (а ля diffutil). И вот вы предоставили два одинаковых ключа по разным индексам. И тут начинается дискуссионный вопрос, что делать?
В теории можно было бы под капотом в Compose генерировать свой псевдоключ для таких кейсов. Но откуда разрабы Compose могут быть уверены, что дальнейшее поведение на основе таких псевдоключей будет устраивать вас? Вдруг если новый псевдоключ будет конфликтовать с другим вашим ключом? И так куча разветвлений проблемных вопросов начинается.
Второй вариант - как раз крашить при таком. Обоснование простое: вы нарушили контракт, а разрабы не хотят за вас думать, как вы хотели, чтобы это работало. Поэтому для даже одинаковых айтемов нужен разные ключи.
Когда в бд вы добавляете строчку с таким же id, то вы же не ругаетесь, что он крашит, хотя вам и нужно два одинаковых айтема в таблице. Если вам нужно два одинаковых id, то вы делаете ещё один столбец, который будет реальным id для таблицы и всегда уникальным, а тот id, который был у айтема изначально делаете обычным столбцом с информацией. В случае со списком ситуация аналогична.
Да, эта проблема может быть не очевидна изначально. И да, этот подход может кому-то не нравится. Но он более чистый.
В случае rv вы сами отвечаете за diff util, поэтому этот вопрос перекладывается на вас.
Пока что можно только плохо относится со стороны того, что разрабы не предоставили разные стратегии. Вы можете завести им issue (либо найти существующие) и описать, что вам не нравится стратегия по умолчанию (краш) и вы хотели бы, чтобы была ещё стратегия, которая бы сама решала конфликт одинаковых ключей по разным индексам.
У нас была неожиданная для нас логика обновления Subcompose. Мы завели issue, уже в альфа 1.7 она пофикшена. Поэтому не вижу проблемы и вам предложить ваш вариант и описать как решить все его корнер кейсы.
Поэтому я и написал, что вопрос стратегии по умолчанию дискуссионный.
Кстати, насчет painter в стейбл конфиг, что-то не работает как ожидалось, painterResources все равно рекомпозит Image, зачастую лучше использовать ImageVectore.vectorResource, который как раз возврашается стабильный класс
Осознанная оптимизация Compose 2: В борьбе с композицией