Мифы

обсудили только что, и ещё несколько раз в прошлом) Неявный стейт UI, если в двух словах.

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

Но если они есть в мвиай, то они и в мвп будут

А конкуррент гц в андроиде на самом деле удивительно хорош, ООМ обычно происходит в нативной памяти (битмапы etc.) или если вы аллоцируете очень много очень больших листов

Не согласен про "если есть MVI то есть в MVP", никто не станет в мвп вешать на кнопку rx  и обмазывать все вокруг rx'ом это как раз и есть "плодить без необходимости" плюс мы имеем дело с потоком, для каждого из потоков нужен свой стек (память 512кб), также переключение контекста и прочее, все это лишняя избыточность, также shallow copy отнюдь не значит что они будут быстро чиститься, это уже зависит от работы GC

дифы придется ручками считать, если это не ресайклер, либо обновлять сразу всю страничку при изменении стейта

да вот тоже хорошее дополнение, что будет в случае с Async Diff Utils и AsyncLayoutInflater

не встречал ещё ни разу просадку производительности из-за оверхеда на работу Rx. Обычно фризы из-за плохих layout или ещё какой-нибудь глупости. в баду вот всё приложение на MVI, и ничо, работает)

А причем здесь ркс? "Большие вычисления" - это пресловутые статик леяуты обсчитать, например
Потоки давно уже все засунуты в тредпул, а переключение контекста нужно очень постараться в рксе получить, когда это все колбеки на FJP

А про GC я серьезно. Почитайте как и когда он вызывается
Плюс STW паузы там едва ли достигают 100 наносекунд, и то они на его собственном потоке

в конечном итоге работа любого приложения зависит от людей, которые его делают поэтому можно любой паттерн запилить прекрасно, тут скорее обсуждаем in average ( средняя по больнице)

важно ни то когда и как он вызывается, важнее что он удаляет, плюс мы все знаем что большинство вызовов minor (не major) и если в стеке есть ссылка на кучу, а потоков может быть много, то minor это удалять не будет

также хотел сказать, что я не стараюсь спорить, скорее мне интересно мнение участников и спасибо вам за полезную информацию

спасибо за мнение очень полезно было

Миноров вполне хватает, чтобы вычистить недолгоживущие стейты
Последний раз когда я замерял, у меня он вызывался раза три в секунду 🌚

Аналогично, складывал в стейт относительно громоздкие структуры, никаких фризов непосредственно при обработке событий не было

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

Слабых мест не так много - можно облажаться при проектировании стейта, тогда будет очень тяжело вытянуть это костылями в момент, когда лажа всплывёт; много кода, но с помощью дженериков, фантазии и возможностей котлина дублирование можно очень сильно подрезать; и в целом наличие проблем сильнее зависит от опыта разработчика, т.к. из-за более жесткой завязки на типы уменьшается пространство для костылей. Если в MVP можно было спорную ситуацию "разрулить" положившись, например, на то, что первый отправленный запрос и вернётся первым, то в MVI это не будет так работать.

Получается что-то вроде "или делаешь хорошо, или никак"