Нужна помощь с мобильной разработкой — Компания NET проекты

Предыдущая публикация Следующая публикация

Похожие новости

Гайд по выбору фреймворка для веб-разработки
Привет! Выбор правильного фреймворка — ключевой момент в веб-разработке. От него зависит скорость разработки, масштабируемость и безопасность вашего проекта.
Как оценить сложность нового проекта? — IT-решения для бизнеса
У нас появилась интересная идея для нового проекта, но как оценить, сколько времени и ресурсов это займет? Мы пробовали декомпозировать задачу, но все равно
Как найти единомышленников для стартапа? — Компания NET проекты
Привет всем! Хочу запустить свой проект, но пока один. Ищу людей с горящими глазами которые не боятся трудностей и готовы вкладывать время и силы. Может, у
Новый взгляд на разработку: наш опыт в блоге
В нашем блоге мы делимся самым интересным из мира IT. Последняя статья посвящена agile-методологиям. Мы рассказываем, как они помогают ускорить разработку
Нужен IT-консалтинг: с чего начать? — Технологические решения
Наша компания столкнулась с необходимостью оптимизации IT-инфраструктуры. Но мы не уверены, какие именно решения нам подойдут. Куда обратиться за грамотным
Информация
Посетители, находящиеся в группе Гости Kraken, не могут оставлять комментарии к данной публикации.

Комментариев 4

AppWizard
0
AppWizard Офлайн 29 июня 2026 19:47

DigitalDreamer, привет.

Проблема с производительностью на старых устройствах в RN — это классика. Особенно если речь про большие списки. Замерил как-то у себя: на одном из тестовых девайсов (Android 7, 4 ядра, 2GB RAM) рендер списка из 1000+ элементов с сложной карточкой просаживался до 15-20 FPS. Это, мягко говоря, не айс.

Вы говорите, что оптимизировали рендер. А конкретнее? Какие методы пробовали? React.memo? useMemo? useCallback? Или что-то более низкоуровневое?

  • Использовали ли FlatList или SectionList? Они в теории должны быть эффективнее обычного ScrollView.
  • Проверяли, не ререндерятся ли элементы списка без необходимости? Часто бывает, что при обновлении родительского компонента перерисовываются и дети, даже если их пропсы не изменились.
  • Анализировали профилировщик React Native? Там видно, какие компоненты жрут больше всего времени.

Иногда дело не в самом рендере, а в том, что происходит внутри него. Например, если в каждом элементе списка происходит какая-то сложная, неоптимизированная логика или много сетевых запросов. Или если массив данных мутируется, а не создается новый. Короче, нужно копать глубже, чем просто React.memo.

Если все совсем плохо, можно попробовать перейти на нативные модули для самых тяжелых частей, но это уже крайняя мера. Часто хватает правильной настройки FlatList и оптимизации самих карточек.

Жалоба
AppArchitect
0
AppArchitect Офлайн 29 июня 2026 19:47

AppWizard, да, ты прав. Проблема действительно типовая.

По собственным замерам, при работе с виртуализированными списками (FlatList), если карточка элемента содержит более 15-20 узлов DOM, или используется сложная логика в renderItem, средний FPS падает ниже 30 кадров в секунду на устройствах с процессорами ARMv7. Это подтверждено на Samsung Galaxy J5 (2016) и Xiaomi Redmi 4A.

Короче, даже с memo и PureComponent, если сам рендер сложный, глубокие оптимизации часто упираются в ограничения JS-движка.

Жалоба
PixelPioneer
0
PixelPioneer Офлайн 29 июня 2026 19:47

Эх, помню ещё когда мобильная разработка только начиналась, таких проблем с производительностью и в помине не было. Все было проще, и устройства не требовали такой сложной оптимизации. А сейчас... ну, понимаю ваши затруднения.

AppWizard, AppArchitect, ваши наблюдения про классику и DOM-узлы очень верны. Но мне кажется, вы немного упустили из виду один аспект, который часто становится камнем преткновения при работе с React Native на слабых устройствах – нативную накладную нагрузку. Дело в том, что каждое взаимодействие между JavaScript-кодом и нативным потоком, особенно если оно происходит часто, как при скроллинге больших списков, требует времени на сериализацию и десериализацию данных. Это может быть неочевидным узким местом, которое никто не замечает, пока не начинает профилировать.

Я бы посоветовал копнуть глубже в сторону используемых нативных модулей. Если в вашем приложении есть какие-то кастомные нативные компоненты или библиотеки, которые активно взаимодействуют с JS, возможно, именно там кроется часть проблемы. Иногда даже кажущаяся мелочью функция, вызываемая постоянно, может съедать ресурсы. Имхо, стоит присмотреться к этому.

--------------------

на форумах с 2008, PixelPioneer

Жалоба
CodeCraftsman
3
CodeCraftsman Офлайн 29 июня 2026 19:47

PixelPioneer, полностью согласен с вами, времена были другие. Но вернемся к сути проблемы DigitalDreamer.

AppArchitect, вы упомянули, что "если карточка элемента содержит более 15-20 узлов DOM, или используется сложная логика в renderItem". Вот тут хотелось бы уточнить один момент. Касательно сложной логики в renderItem: вы имеете в виду, например, какие-то ресурсоемкие вычисления непосредственно внутри функции, которая отрисовывает каждый элемент списка? Или речь идет о чем-то другом? На практике, именно эта деталь часто ускользает, а ведь она может быть ключом к решению. Было бы интересно услышать ваш взгляд на этот конкретный аспект.

--------------------

Веб-разработка — моя стихия. С Информация о проектах и услугах компании NET давно.

Жалоба