Развеиваем мифы о Stability в Compose: оптимизации Strong Skipping

[Rusrst]

Спасибо, это было полезно.

[glider_skobb]

Всегда пожалуйста)

[kirich1409]

Спасибо за проделанную практическую работу

[Scotty_pwnz]

Спасибо за статью и любопытные факты про strong skipping mode. Я только не очень понял про лямбу и значение из делегата, почему значение не добавляется как ключ?

И, наверное, утверждать, что компоуз сравнивает нестабильные параметры по адресу в памяти не совсем верно, так как после GC адрес может поменяться для объекта. Тут все же скорее всего идет сравнение по Identity объекта, а это и есть стандартный непереопределенный equals. Это легко проверить, если в классе OrderData переопределить equals & hashCode, чтобы equals всегда возвращал true. Тогда даже при изменении singleOrder на новый объект рекпомпозиции не будет.

[glider_skobb]

По поводу делегата - точнее будет сказать, что для переменных с делегатом ключом в remember добавляется делегат, а не значение. В байткоде это тоже видно

Третья строка снизу: композер проверяет изменение делегата. В этом случае пересоздавать лямбду не имеет смысла, потому что делегат при обращении всегда предоставит актуальное значение.
Аналогично, кстати, работает derivedStateOf, добавлять ключ в remember не нужно:

var imagesCount by remember { mutableStateOf(10) }
val isEmpty by remember { derivedStateOf { imagesCount == 0 } }

По поводу адреса в памяти - выразился так для простоты, в соответствии с гайдом гугла по strong skipping: "Unstable parameters are compared using instance equality (===)" (https://developer.android.com/develop/ui/compose/performance/stability/strongskipping). За что купил, за то и продаю)
Насчет equals действительно хорошее наблюдение, проверка по инстансу в памяти это дефолтная реализация equals, очевидно имеется в виду она. При этом если переопределить equals на вечный true, проверка по инстансу не сработает. Гугловая дока врет.

[glider_skobb]

В целом термины reference equality (сравнение по ссылке), instance equality (сравнение по экземпляру/инстансу) и "сравнение по адресу в памяти" используются в статье синонимично, потому что reference equality это по определению проверка, что две ссылки в стеке указывают на один и тот же адрес в куче (формулировка грубая, но вроде не грешащая против основ JMM).

И да, вы совершенно правы, это дефолтная реализация equals.