Что я пропустил? Чем уже lazy людям не нравится?

Они, к счастью, нигде лишними не будут:) Но мне интересен именно кейс с findViewById. Что с ним не так?

Ну мы давно перестали экономить на этих спичках, не удивляйся)) но есть тебе не нравится, не делай так)

Ну хз. Типа в одну строку наверно

> А что с ним так? Меня волнует, что именно не так. Если речь только о том, что ты описал, то это капля в море. Кастомный геттер с findViewById будет вызывать поиск вьюхи каждый раз. Чем оно лучше?

> не предлагал искать вьюху кастомным геттером. А чем тогда? >Где у тебя заспецифицирована капля в море? Как ты отличаешь адекватный оверхед от неадекватного? Сколько у тебя таким образом будет ссылок на вьюхи в худшем случае? Штук 10? 20? 30? 100? 100 лишних объектов даже древний телефон переживёт. Не нравится синхронизированность — можно сделать lazy без неё. Если тебе хочется на этом экономить — на здоровье. Но не надо пропагандировать это как самый лучший путь, а то все тут утонут в этих оптимизациях.

Да пох

У нас на каждой риб только силед классов под 50 - 100 может быть

Если мы так общаемся, то можно пример, где от нескольких lazy вьюх приложение лагало? :)

ну это напрямую к лейзи не относится. это ж лямбды вроде

У нас был свой uiLazy() чтобы бес синхронизации. Мы явно его выпилили и стали использовать обычный lazy. Потому что это невозможно измерить в этих кейсах. Это не хайлод.

Подожди, ты куда-то перебегаешь. Покажи мне проект, где именно от lazy вьюх экран начинает лагать. Например, при обращении к ним. От, о боже, анонимных классов и синхронизации.

Разве lazy не от тормозов при создании?

Оно всё будет тормозить при создании. Мы всё-таки в андроиде. Но вот эта экономия на нескольких анонимных классах — ерунда. Оптимизации ради оптимизаций бывают весёлыми, но обычно бесполезными.

ну при создании их не будет. а потом при обращении будут. я так это понял

Ну так это и есть функция лейзи

я о ней и говорю

Суть, как я понял, в том, что у тебя на каждую вью при создании экрана всё равно создастся по лишнему (анонимному) классу. @Harmonizr против этого.

А чего? Мне кажется скорость открытия и показа экрана для юзера самая важная

но вообще об этом. давайте тогда писать не view.setOnClickListener { } А view.setOnClickListener(object : OnClickListener { override fun onClick(v: View) { } })

Нет, пока ты не покажешь мне, где приложение лагает от лейзи вьюх. А то какой-то сумбур выходит, я тебе там что-то должен, а сам спрятался:)

Я, конечно, уважаю Мишу, но иногда он больше похож на разумный компилятор, чем на человека. :)

Уверен, что иногда это даже полезно:)

для андроида, который до джавы с лямбдами будут генериться синтаксические классы, как вы показали на скрине. там же не от лейзи это, а от лямбды lazy { /* от этого */ }

В данном кейсе, скорее, надо создать один OnClickListener на всех, чтобы что-то реально сэкономить.

> может, синтетические? да-да, я хз какую-то фигню написал.

ну тогда лейзи тоже не является проблемой.

А без lazy? :-)

Ну теперь все, не используем анонимные классы?

Я не фанат файндвью в лейзи. Вообще первый раз такое вижу. Но понятно что некоторые синтаксические сахары внезапно требуют под капотом каких-то действий. Это какбы и есть преждевременная оптимизация. Но согласен что все подряд называть тем же лейзи смысла не имеет. Ну короче, правда как всегда посередине.

Это да

А то как работает kotlin extension прям ясно и понятно. )

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

в чём проблема с вью холдерами? это ж просто проперти расширения к View

Довольно легко можно сделать ошибку где работа будет неоптимальной. Нужно имено через вью обращаться.

я вообще когда ещё писал на андроиде так делал: class BaseHolder(val v: View) ... fun onBindViewHolder(holder: BaseHolder, ...) { holder.v.titleTextView.text = "..." }