ok google -> google play store vs app store revenue

ок google -> доход компании != playstore revenue

Яндекс - трафик колосальный на андроид, почему сказать?

порой достаточно загуглить чтобы понять, что "общеизвестный факт" говорят не просто так, лул)

приведу в пример свой продукт, в нем 51% мобильного трафика, 2/3 из него - андроид, угадай с одного раза откуда больше денег приходит?

отличная выборка из целого одного приложения 😁

отличная выборка из целого одного приложения 😁

статистика так и работает) если при двух бросках монета в орле- решки не существует

с тобой нет смысла говорить, городишь что попало

приведу в пример свой продукт, в нем 51% мобильного трафика, 2/3 из него - андроид, угадай с одного раза откуда больше денег приходит?

60fps это давний миф и погоня за белым единорогом, ещё со времен геймдева.. ну и это ещё хороший маркетинговый поинт, который можно размазывать на презентациях

каждый геймдевелопер будет заявлять, что его игра не выдаёт 60fps только потому что “ у вас плохое железо, интернет коннекшен и это ваши проблемы, или это баги движка игрового”, а просадки fps были в играх везде и всегда, как с тем же юнити, так и с анрилом, потому что как только игра становится сложнее, начинает страдать перфоманс

такая же суть и во флаттере

не могу понять, отчего люди так яро сопротивляются данному факту ссылаясь на плохой код)) тесты золотых 60fps всегда проводят на бенчмарках с высокой нагрузкой и кучей динамических объектов, то бишь большим количеством рендеринга
никто не тестирует 60fps на “низких” требованиях, и потому всякие выпады в сторону “много setState”, “плохо код написан, вы слишком часто вызываете build” и прочее звучат нелепо

флаттер не идеален и у него нету чистого 60fps  в приложениях (без больших дополнительных энергозатратных телодвижений) со сложной анимацией или тяжёлым рендерингом, в простых примерах можно вытянуть мифические и идеальные 60fps, но это лишь простые примеры

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

защищать билдеры тем, что они рендерит не весь экран тоже выглядит как-то непонятно, потому что никто не мешает ту часть кода, которая обёрнута билдером, обернуть в отдельный стейтфул и вызывать там тот же setState - это всё будет ровным счётом тоже самое, что и билдер (истересно, как много людей заглядывали в код этих самых билдеров).. остаётся ещё упомянуть о полезных методах didChangeDependencies и didUpdateWidget, о которых люди любят не упоминать, забывать.. а многие и вовсе их не понимают и зачем они вообще..

повторюсь, какой смысл спорить о 60fps, когда флаттер ещё очень и очень молод, и все эти споры о сравнении с айос или андроидом выглядят глупо, потому что оптимизация рендера как в айосе (а там метал на рендеринге, знает ли кто разницу?), так и в андроиде улучшалась годами, и почему-то люди уже позабыли страшные лаги андроида на многоядерных и многогигабайтных девайсах, или лаги рендера того же айоса, когда они много лет назад только-только перешли на новый дизайн

60fps можно более-менее достичь, но только после немалых телодвижений, оптимизаций и фантазий разработчика
но опять же, это всё решается в конкретном приложении с конкретным кодом и конкретными кейсами

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

Однако соглашусь про 60 фпс, не всегда 60, но когда речь заходит за фризы - тут уже дело в коде, не в фреймворке.

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

Однако соглашусь про 60 фпс, не всегда 60, но когда речь заходит за фризы - тут уже дело в коде, не в фреймворке.

а на что именно смотрите?

Смотрю какой метод или функция долго выполняется и уже решаю как отрефакторить