Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Было довольно интересно. Но складывается такое впечатление, что альфа сразу пошла в прод.
Вы имеете ввиду альфу нашего приложения? Оно шло в параллели с основным (нативным) приложением, как дополнительный вариант, в котором мы тестировали некоторые продуктовые гипотезы. Мы не ставили себе целью сразу сделать полноценное и оптимальное приложение. И трафика в нём тоже было мало. Поэтому, по мере развития закономерно дошли до точки, в которой уже стоило задуматься о производительности, чем мы, собственно, и занялись.
Простите, не в обиду будет сказано, но «бессмысленная» оптимизация должна лежать в базисе проекта. Оптимизировать код с самого начала там, где это на начальный момент кажется ненужным — это залог будущего развития приложения «без тормозов». На старте должна быть задана средняя рабочая загрузка и все в дальнейшем должно от не отталкиваться, включая тесты на производительность. Жертвовать этим можно лишь при условии, что время разработки равно нулю и проект неизбежно ждёт глубокий рефакторинг прямо на старте.
В нашем случае это был компромисс между скоростью продуктовой разработки и производительностью приложения. Вектор был в сторону первого, и второе до поры до времени не страдало. Причин этому несколько, начиная с того, что новое приложение могло просто оказаться бесполезным, и заканчивая тем, что часть разработчиков вообще не имела опыта разработки на JS и React Native. По мере того, как мы убеждались в востребованности приложения и набирались опыта, вопросы производительности стали выходить на первый план, и теперь мы, разумеется, следим и за этим тоже.
Я не считаю, что мы допустили ошибку в распределении ресурсов. Done is better than perfect.
Я не считаю, что мы допустили ошибку в распределении ресурсов. Done is better than perfect.
Средний fps очень плохой ориентир для показателя «не тормозит». Приложение может работать плавно и при 30, 45 fps. Главное тут — время кадра, и кадры рендерящиеся заметно дольше 1/60 сек. (если требуется 60 fps). Я не знаю, можно ли выводить график времени кадров, но ориентироваться нужно именно на него.
Можно использовать Profiler, встроенный в React Native, он делает раскадровку по 1/60 сек в проекции на потоки, на которой видно, какой процесс занимает больше отведённого времени. FPS в данном случае это индикатор проблемы. На своём примере могу сказать, что даже просадка до 45 FPS даёт себя почувствовать.
Вот profiling для Andrid, например: reactnative.dev/docs/performance#profiling-android-ui-performance-with-systrace
Есть полезный пакет для дебага ре-рендеров. Позволяет избежать гаданий на кофейной гуще и чётко говорит, почему же таки произошёл рендер :)
Чтобы решить эту проблему, можно выделить отдельный стиль, который объединит body и item, или, например, вынести объявление массива [styles.body, styles.item] в глобальную переменную.
Но в примере кода по ссылки этого решения нет:
style={[styles.body, styles.item]}Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Война с тормозами. Оптимизация количества рендеров компонентов в React Native