Война с тормозами. Оптимизация количества рендеров компонентов в React Native

[Schrodingers_Kater]

Было довольно интересно. Но складывается такое впечатление, что альфа сразу пошла в прод.

[sc_pro_ion]

Вы имеете ввиду альфу нашего приложения? Оно шло в параллели с основным (нативным) приложением, как дополнительный вариант, в котором мы тестировали некоторые продуктовые гипотезы. Мы не ставили себе целью сразу сделать полноценное и оптимальное приложение. И трафика в нём тоже было мало. Поэтому, по мере развития закономерно дошли до точки, в которой уже стоило задуматься о производительности, чем мы, собственно, и занялись.

[Schrodingers_Kater]

Простите, не в обиду будет сказано, но «бессмысленная» оптимизация должна лежать в базисе проекта. Оптимизировать код с самого начала там, где это на начальный момент кажется ненужным — это залог будущего развития приложения «без тормозов». На старте должна быть задана средняя рабочая загрузка и все в дальнейшем должно от не отталкиваться, включая тесты на производительность. Жертвовать этим можно лишь при условии, что время разработки равно нулю и проект неизбежно ждёт глубокий рефакторинг прямо на старте.

[sc_pro_ion]

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

Я не считаю, что мы допустили ошибку в распределении ресурсов. Done is better than perfect.

[Schrodingers_Kater]

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

[sc_pro_ion]

Статья другой направленности, поэтому я просто вскользь указал про предпосылки.

[dimka11]

Средний fps очень плохой ориентир для показателя «не тормозит». Приложение может работать плавно и при 30, 45 fps. Главное тут — время кадра, и кадры рендерящиеся заметно дольше 1/60 сек. (если требуется 60 fps). Я не знаю, можно ли выводить график времени кадров, но ориентироваться нужно именно на него.

[sc_pro_ion]

Можно использовать Profiler, встроенный в React Native, он делает раскадровку по 1/60 сек в проекции на потоки, на которой видно, какой процесс занимает больше отведённого времени. FPS в данном случае это индикатор проблемы. На своём примере могу сказать, что даже просадка до 45 FPS даёт себя почувствовать.

[sc_pro_ion]

Вот profiling для Andrid, например: reactnative.dev/docs/performance#profiling-android-ui-performance-with-systrace

[bohdan-shulha]

Есть полезный пакет для дебага ре-рендеров. Позволяет избежать гаданий на кофейной гуще и чётко говорит, почему же таки произошёл рендер :)

[sashavoloh]

Чтобы решить эту проблему, можно выделить отдельный стиль, который объединит body и item, или, например, вынести объявление массива [styles.body, styles.item] в глобальную переменную.

Но в примере кода по ссылки этого решения нет:

style={[styles.body, styles.item]}

[sc_pro_ion]

Да, в данном случае пример кода иллюстрирует саму проблему, а не её решение