Как я ускорил свое мобильное приложение BookDesk на React Native в 3 раза?

Всем привет! В этом материале я поделюсь с вами практическим опытом по оптимизации своего мобильного приложения на React Native. Расскажу как ускорил свое приложение в 3 раза.

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

Я разрабатываю свое мобильное приложение BookDesk для хранения прочитанных книг. Предыдущие серии: 1, 2, 3

Я делаю проиложение для Android, но эти советы будут также полезны и для iOS версии, так как разработку веду на React Native.

React Native базируется на библиотеке react для построения пользовательских интерфейсов и все работает идентично как в веб версии так и в мобильных приложениях.

Итак, перерисовки или re-rendering компонентов это самая главная проблема многих приложений на React Native.

Для начала, давайте разберемся что же такое эти перерисовки и почему они являются проблемой.

В React Native приложениях самые "тяжелые" операции это перерисовки элементов/компонентов интерфейса. Почему? Каждое приложение имеет некую объектную модель либо иерархическую структуру пользовательских элементов (другими словами то что мы видим на экране). Например в веб-приложения[ это DOM (document object model) и она представляет собой глубоковложенную модель элементов со всеми свойствами, атрибутами, тегами и т.д.

Все зависит от сложности интерфейса и количества элементов. Схожая модель и в мобильных приложениях.

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

В приложениях с малым количеством элементов или простым интерфейсом этого может быть достаточно и, возможно, не надо проводить дополнительных работ по оптимизации (но я советую применять оптимизацию не зависимо от размера или сложности приложения). Любое приложение имеет свойство разрастаться и увеличиваться в масштабе и здесь без оптимизации будет тяжело получить качественный продукт. В какой-то момент времени придется столкнуться с проблемами в виде тормозов и фризов. Такие элементы как списки, сетки (grids) для отображения данных, при этом списки могут содержать большое количество динамических элементов с картинками, формами, контролами, кнопками и т.д. все это создает определенную нагрузку на интерфейс и на саму модель. В этом случае без оптимизации можно получить множество проблем в виде задержек, лагов при работе с интерфейсом и виной тому все те же перерисовки. А причина этому кроется в неправильной структуре приложения, поэтому грамотная структура это уже полдела.

Давайте теперь разберемся почему срабатывают перерисовки. Здесь все очень просто.

Вот основные причины перерисовки компонентов:

1. Изменение props компонента приведет его к перерисовке.

2. Изменение значений локального состояния компонента. Например, когда мы объявляем локальное состояние через хук useState.

3. Изменение значений глобального состояния любого из менеджеров состояний (redux, mobx, zustand и т.д.)

4. Изменение значений контекста через хук useContext

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

У нас есть компонент Book который содержит локальное состояние description, title, rating и id и также есть вложенный тяжелый компонент HeavyWeightComponent. При изменении любого из состояний произойдет перерисовка компонента Book и вложенных компонентов и дальше по цепочке, если у вложенных компонентов есть вложенные они также будут перерисованы. Другими словами, если мы нажмем на кнопку которая меняет рейтинг - произойдет перерисовка компонента Book и компонента HeavyWeightComponent, хотя данный компонент принимает в качестве пропса только id и нам не хотелось бы его перерисовывать. Как предотвратить его перерисовку?

У этой задачи существует несколько решений. Я предпочитаю искать решения без использования дополнительных библиотек, хуков, утилит и прочего.

1. Использовать HOC (Higher order component) memo из библиотеки react. Он позволяет избегать перерисовок компонента если пропсы не изменились. Для этого компонент HeavyWeightComponent необходимо переделать:

Необходимо импортировать memo из библиотеки react и далее создать мемоизрованную копию компонента и использовать ее. В данном случае мы избавимся от лишних перерисовок и получим ожидаемое поведение нашего тяжелого компонента. HeavyWeightComponent будет перерисовываться только при изменении свойства bookId куда мы прокидываем id из локального состояния компонента Book. Это хорошее, наглядное и понятное решение, но если переделать немного структуру компонента Book, мы можем избавиться и от использования memo.

Мы можем разбить наш компонент Book на несколько более мелких компонентов, которые будут отвечать за свои области. В данном случае, мы можем создать компонент BookHeader и вынести туда все локальные состояния кроме id.

Теперь у нас есть 2 соседних компонента BookHeader и наш тяжелый компонент. При изменении любого из локальных состояний в BookHeader перерисовка будет происходить только в внутри самого BookHeader. А наш тяжелый компонент не будет перерисовываться и зависеть от BookHeader.

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

В react существует несколько хуков для добавления кэширования. Ранее мы немного познакомились с этим понятием на примере использовании HOC memo для кэширования компонентов.

Хук для кеширования результатов вычислений, массивов данных. Если Ваши компоненты используют какие-то тяжелые вычисления, перебор массивов и изменения с помощью методов map, filter, reduce - то необходимо обязательно использовать useMemo. Таким образом, при перерисовке компонента, react будет брать закешированное значение результата вычислений и отдавать его мгновенно (если зависимые значения не изменились) вместо постоянного пересчета на каждой перерисовке компонента.

Пример использования

Все вышеописанные сущности которые я использую в компонентах всегда пропускю через useMemo.

Хук для кэширования функций. При каждой перерисовке компонентов, react пересоздает все сущности которые находятся внутри компонента. Сюда относятся переменные, объекты, функции, массивы, элементы и т.д. Для того, чтобы избежать пересоздания функций мы должны использовать useCallback. Я рекомендую его использовать для всех функций которые Вы создаете внутри компонентов.

Пример использования

Практически все функции компонентов я пропускаю через useCallback, особенно в тех случаях когда эти функции используются в хуках useEffect или прокидываются далее в качестве пропсов в дочерние компоненты.

HOC для кэширования компонентов. Помогает избежать ненужных перерисовок если значения пропсов компонента не изменились. В качестве второго аргумента он может принимать условие для перерисовки компонента. Например, если в качестве пропса приходит объект с некоторой вложенностью, мы можем задать условие, что при изменении определнных свойство этого объекта перерисовывать компонент, а во всех остальных случаях нет. Очень полезно, особенно, для использования в сетках и списках. Я активно использую memo в большинстве компонентов которые имеют пропсы.

В своем приложении я использую все эти подходы. Зная эти подходы, Вы легко сможете начать проектировать оптимизированные компоненты.

Эти 3 сущности кэширования и мемоизации помогут в значительной степени увеличить производительность Вашего приложения и избавиться от ненужных перерисовок. Мобильные приложения, в отличие от веб или десктопных приложений, более чувствительны к перерисовкам т.к. существует большое количество слабых мобильных устройств, а это значит мы не можем себе позволить впустую использовать лишние перерисовки и потреблять ресурсы устройств. В моем случае, после внедрения вышеописанных методик я увеличил отлик некоторых функций в разы. Если раньше открытие меню со статусом книги составляло ~3 секунды (при худшем сценарии, когда было загружено большое количество книг и запускалась перерисовка всех элементов на досках), то теперь это время менее чем ~0.5 секунды, разница в ~6 раз.

Сегодня сложно себе представить мобильное приложение, которое не использует гриды, списки в том или ином виде. Мое приложение BookDesk построено и базируется на основе гридов и списокв. У нас есть несколько досок с которыми можно работать одновременно, и все эти доски это гриды. А это значит, что у нас всегда подгружено некоторое количество книг на каждой из этих досок. Оптимизации гридов следует уделять особое внимание.

Для работы с гридами React Native предоставляет компоненты FlatList и SectionList. Они работают на базе VirtualizedList и позволяют подгружать сущности по мере необходимости, имеют неплохую оптимизацию и функциональность. Однако, их необходимо дополнительно оптимизировать. React Native дает рекомендации по оптимизиации своих гридов. Я не буду подробно останавливаться на каждом пункте из этой статьи, т.к. эта тема стоит отдельного материала.

Скажу лишь самое важное - необходимо обязательно использовать кэширование в виде memo для item компонента и useCallback для всех функций типа renderItem, keyExtractor и т.д. чтобы избежать лишних перерисовок. Ну и конечно же использовать "keyExtractor" для оптимизации, это свойство добавляет уникальный ключ для каэждого элемента и при изменении/удалении элементов из грида React Native легко сможет определить с каким элементом произошли изменения и быстро все перерисовать.

В react веб-приложениях используется JSX для возможности использовать html внутри JS и привычным является использование функции map для отрисовки списков или чего-то из массивов. Но в React Native этого необходимо избегать, потому как все это дело надо оборачивать дополнительно в компонент ScrollView чтобы создать скролл. В этом подходе есть ряд минусов и сам React Native рекомендует использовать FlatList вместо map + ScrollView.

В своем приложении я использую все виды списков включая FlatList и SectionList. Их я предпочитаю использовать для небольших списков, где не нужно использовать виртульную подгрузку по скроллу.

Для основных больших виртуальных списков с книгами я использую компонент FlashList от компании Shopify. Она использует React Native для построения своего мобильного приложения. Их приложение базируется на огромных списках с картинками и прочими элементами. Им необходима максимальная производительность и поэтому они разработали свой компонент для списков. Shopify сумели добиться лучшей производительности в сравнении с FlatList.

Я в этом лично убедился. Рендеринг, перерисовка и скроллинг списков работает безупречно и молниеносно, без фризов и пустых областей, все работает мгновенно. У Shopify, также, есть рекомендации по оптимизации. В отличие от FlatList во FlashList есть свойство "estimatedItemSize" обязательное к использованию и на котором базируется оптимизация всего списка. Это горизонтальная или вертикальная величина элемента списка (в зависимости от типа списка горизонтальный или вертикальный) которую можно получить в инспекторе. Также есть свойство "getItemType"которое необходимо для того чтобы определить тип элемента, может быть текст, картинка, объект. Я не буду все перечислять, сможете ознакомиться по ссылке выше, но во FlashList таких техник меньше, т.к. из коробки он уже хорошо оптимизирован.

Как и во FlatList не забывайте про использование useCallback для всех функций которые прокидываете в компонент FlashList а также memo для компонента элемента списка.

Если необходимо добавить локальное состояние, лучше создать маленький компонент и в нем определить состояние а его в свою очередь добавить в компонент элемента списка. И все дочерние компоненты необходимо оптимизировать с использование memo, useCallback и useMemo, не забывайте об этом важном правиле.

Как и хук useMemo, библиотеку Reselect можно использовать для создания мемоизированных селекторов для оптимизации дорогостоящих вычислений. Однако, в отличие от useMemo, это нужно использовать с Redux.

В своем приложении я использую Reselect для получения переработанных данных из redux, как и в случае с useMemo, где используются методы массивов map, filter, reduce и т.д. или какие-то сложные вычисления.

Reselect для кэширования результатов из redux.

Из коробки react позволяет загружать компоненты по требованию. Пока пользователь не перешел на определенный экран, react не будет загружать компоненты. Это отличная возможность, чтобы снизить время начальной загрузки приложения. Например, зачем нам сразу грузить все экраны если новый пользователь попадает на страницу Входа? Мы загружаем только страницу Входа а все остальные по мере необходимости. Точно также, если пользователь уже залогинен и при запуске попадает на страницу с досками книг, зачем ему загружать экраны Входа, Регистрации, Статистики, Профиля и т.д. которые он сейчас не использует. Это мощный инструмент оптимизации, который я советую использовать.

Мы можем импортировать функцию lazy из react и обернуть все наши компоненты в нее.

Используйте lazy как обертку для импорта компонента и в том месте где отображается компонент оборачивайте его в Suspense. Таким образом мы создаем оптимизацию для загрузки только нужных, в данный момент времени, компонентов.

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

Ко всему прочему я использую компонент FastImg для отрисовки и кэширования картинок. Официальная рекомендация этого компонента есть от команды React Native.

Во-первых, я использую настройку Proguard для уменьшения размера сборки. Proguard — это инструмент, который может немного уменьшить размер APK. Он делает это, удаляя части байт-кода React Native Java (и его зависимости), которые ваше приложение не использует. Работает это только с Android приложениями. Как настроить.

Во-вторых я использую удаление всех логов из кода при помощи настройки. Вызовы конослей также кушают память и от них следует избавляться в production сборке.

React Native использует 2 потока: JS Thread и UI thread, подробнее можно почитать здесь. Запуск анимации в потоке JavaScript — плохая идея. Поток JS можно легко заблокировать, и это может замедлить работу анимации или не запустить ее вообще. Поскольку API Animated является сериализуемым, можно передать детали анимации в нативный код до начала анимации. Таким образом, нативные коды будут выполнять анимацию в потоке пользовательского интерфейса. Это гарантирует, что анимация будет работать плавно, даже если поток JavaScript заблокирован.

Hermes - это движок JavaScript с открытым исходным кодом, оптимизированный для React Native. Для многих приложений использование Hermes приведет к улучшению времени запуска, уменьшению использования памяти и уменьшению размера приложения по сравнению с JavaScriptCore. Hermes используется React Native по умолчанию, и для его включения не требуется дополнительной настройки.

Старайтесь периодичски проводить ревизии версий библиотек и зависимостей в файле package.json, которые Вы используете. Старайтесь использовать последние версии библиотек, особенно это касается react-native, react т.к. в новых версих улучшают оптимизацию и производительность. Старайтесь находить альтернативы использования функций из некоторых библиотек. В данный момент JavaScript предоставляет широкие возможности для работы с массивами, объектами, поэтому можете легко найти замену lodash, ramda библиотекам в виде нативного использования js функций. Прежде чем искать решения с помощью сторонних библиотек всегда старайтесь найти решение из коробки React Native или на JS, ведь использование дополнительных библиотек увеличивает размер Вашего приложения а также скорость его загрузки. Но если Вам необходимо установить пакет, смотрите на количество звезд, дату последнего релиза и количество недельных скачиваний и это даст понимание о популярности пакета и о целесообразности его использования.

Я придерживаюсь принципа: меньше пакетов - лучше!

И еще одна рекомендация, периодически проводить ревизию пакетов на предмет размера при помощи react-native-bundle-visualizer он поможет проанализировать все пакеты и выявить самые тяжеловесные.

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

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

Но работа над оптимизацией на этом не заканчивается, я постоянно в поиске различных вариантов и улучшений. Развиваю приложение методом проб и ошибок. Ведь, самый ценный опыт это опыт полученный собственным путем. Оптимизация приложения это очень кропотливая и важная работа. Если Вы примените все советы из данного материала, Ваше приложение станет работать быстрее, а в некоторых случаях - в разы быстрее.

Буду очень благодарен если Вы установите мое приложение для хранения прочитанных книг BookDesk и оставите отзыв и рейтинг!

Давайте делать оптимизированные приложения!

Всем спасибо!