Когда мы используем react-native-reanimated для анимации таких свойств, как translateX, scale или opacity, react-native-reanimated запускает анимацию в «нативном» потоке пользовательского интерфейса. Эти свойства не влияют на механизм компоновки, поэтому мы можем завершить компоновку в основном потоке (JS), передать значения по мосту в поток пользовательского интерфейса и затем анимировать содержимое без участия механизма компоновки.
Однако, когда анимируются такие свойства, как height, padding или margin, это не так ясно. Эти свойства влияют на макет, и нам нужно обновить макет при изменении свойств. Но макет сделан основной темой в Javascript. Если бы механизм компоновки должен был быть активен в каждом кадре, потому что height или padding изменился, это наверняка сильно повлияло бы на производительность.
И действительно, в настоящее время у меня возникают серьезные проблемы с производительностью, когдаанимация padding. Профилировщик говорит мне, что проблемы с производительностью происходят от моста. Похоже, что поток пользовательского интерфейса вызывает Javascript каждый кадр, может быть, чтобы макет обновлялся основным потоком, а затем макет снова передается через мост в native.
Однако react-native-reanimated предлагаетпример widthandheight/index.js, который явно анимирует свойства типа width, height и fontSize, которые влияют на макет. Этот пример работает со скоростью 60 кадров в секунду.
Как react-native-reanimated обрабатывает анимации, которые влияют на макет? Есть ли процесс макета в начале и в конце анимации, а между ними - только поток пользовательского интерфейса (это звучит как экспериментальная функция переходов, но я не говорю о переходах). Есть ли какой-то особый рецепт, которому нужно следовать, чтобы добиться хорошей производительности?