übersetze den Title auf deutsch How Kraken fixed performance issues via incremental adoption of the React Native New Architecture

By Ben Irving, Kraken Sr. Software Engineer

Performance pain can make developers go the extra mile. In this blog post, you can learn from the performance issues we experienced at Kraken and how we embarked on a New Architecture adoption journey to solve those issues. Yes, there were speed bumps along the way. We learned from them, and we hope you can, too. 

The New Architecture is going to be the default, starting from React Native 0.76 and Expo SDK 52, the very next releases of React Native and Expo. New in-development features will be implemented only for the New Architecture and some libraries are already dropping support for the old architecture. You should really start thinking about adopting it if you don’t want to miss out!

Kraken architecture overview

Kraken is one of the largest, most trusted and secure cryptocurrency platforms, with a vibrant community of over 13 million clients worldwide. We currently have three mobile apps in production – all written in React Native with a bunch of custom native libraries and components in Swift/Kotlin, and a backend in Rust. 

While we don’t use the full Expo suite for historical reasons, we have started migrating to use Expo modules over some of the community packages for maintenance and performance reasons. Performance is a key concern for us, especially in our Pro app, which is data intensive and filled with interactive charts which are constantly being updated via WebSockets. This puts a strain on performance, especially on low end Android devices. So for a long time we had kept our eyes on the New Architecture progress and hoped it would alleviate some of the issues we were facing.

At the end of this journey, we were able to improve the performance of our apps significantly in several areas: 

• Complete app renderer: 1.3x faster
• Home screen renderer: 2.5x faster
• Trading flow screen render: 5.3x faster
• And more…

Keep reading to learn about our journey and all the other performance benefits that came along with it.

Our New Architecture adoption plan

Our primary goal was to improve performance on Android. Our first course of action was to create a quick proof-of-concept using Fabric to be able to estimate the gains. Despite our fairly large codebase and multitude of dependencies, this was done pretty quickly by leveraging the legacy interop layer and stubbing out incompatible libraries/components. The result was a much snappier feeling app which was backed up with objective performance metrics.

Knowing the ecosystem was still in a migratory phase and expecting some rough edges, we decided to adopt the New Architecture in an incremental manner to reduce the engineering risk. This meant going platform by platform, app by app, and architecture feature by feature. Our simplified plan looked something like this:

1. Update third party component libraries and migrate internal components to support both the new and old renderer
2. Update third party native module libraries and migrate internal libraries to Native Turbo Modules
3. Enable bridgeless mode
4. Remove backwards compatibility once fully rolled out

New Architecture adoption speed bumps

On our incremental adoption journey we ran into a handful of speed bumps. This was to be expected. In this section we’ll call out each one in the hopes that it will help other teams navigate them a little more swiftly than we did.

Swift

Unlike Turbo Modules, Fabric components don’t officially have Swift support. This was a bummer because our codebase is in Swift and we didn’t want to go back to Objective-C. With some inspiration from the Lottie library (and help from a video from Coding With Nobody) we got it working. It’s worth noting that Expo Modules have native Swift support and an arguably nicer API. We’re also keeping an eye on the Nitro project from Marc Rousavy which might support Fabric components in the future.

Automatic batching

In some screens we noticed perceived slower rendering, especially very render-heavy screens such as the interactive graphs:

While we’re not completely sure of the root cause, we suspect that this was due to the automatic batching introduced in React 18, which is only supported on the New Architecture. The theory was that while batching leads to less CPU load, it also skipped a few intermediary steps that gave a faster impression. Ultimately, the component was not correctly built, so after a refactor and migration to use Reanimated for performance sensitive interactions the issues were solved.

Bridgeless

Because Bridgeless mode is the most recent piece of the New Architecture puzzle, we wanted to adopt this last, even though it was the comparatively least disruptive change (thanks to a great interop mode). However, our plan didn’t work out because Expo 51 doesn’t support Fabric without also using Bridgeless mode. This was a problem for us because we wanted some fixes in React Native 0.74 which meant that we had to adopt Bridgeless slightly sooner than planned. 

Overall it was uncomplicated, with one exception: CodePush will be deprecated soon and we rely on requestIdleCallback for some of our performance metrics. We’re currently in the process of migrating to Expo updates instead, but in the meantime we’ve fixed support through patch-package/yarn patch and backported requestIdleCallback, which is supported from 0.75.

Interop layers

The interop mode for Old Renderer components worked like magic for most Android components, but for iOS we found that it had layout issues on one of our internal native components. This was never our intended end-state regardless, and we solved it by simply migrating them to Fabric.

Proguard

Early on in our development we noticed that a branch that worked great in development insta-crashed in a production build with somewhat vague error messages. After some digging, we found that this was caused by Proguard removing certain third party classes and methods. It’s possible that it was caused by the lazy nature of Turbo Modules, which confused the Proguard optimizer into thinking that they were not used. Once we discovered the problem it was easy to simply exclude those symbols from being stripped.

Rollout

As previously mentioned we wanted to adopt the New Architecture as incrementally as possible. Ideally we would have wanted to go screen by screen, and while the New Architecture is supported natively, it’s not currently supported by React Navigation, so we had to be careful when rolling out Fabric. However, due to the interop layers we were able to successfully roll out the new arch at a project level.

Maestro

While we have many component tests using React Testing Library, unfortunately, they will not give us any confidence in adopting the new renderer; instead we relied heavily on our automated end-to-end tests on Maestro Cloud. This is also where we run our performance suite to give us hard numbers before hitting production.

Internal testing

Normally we don’t rely on manual testing, but since these changes are more impactful and cannot easily be rolled back with a feature flag we distributed builds internally for people to test and verify that their flows were working as expected. This was especially useful for finding rendering regressions in niche screens that were initially missed due to lack of visual testing.

“Canary releases”

When we believed we had tested as much as we could with and without automation, we wanted to serve it to a small number of production users. We would traditionally use feature flags in LaunchDarkly for this, but since most of the pieces of the New Architecture are compile flags this was not an option. Instead we opted for a poor man’s version of canary releases via gradual rollouts on Play Store. 

Our apps are released on a weekly cadence, and essentially once we deem a release stable and fully rolled out to production we serve a small percentage of users a version with the New Architecture enabled. Since gradual releases on Play Store can be halted, we could limit user impact in case of any serious bugs or crashes. Additionally, rolling forward is faster due to the generally faster review process.

Real client monitoring

Once the app was in our clients’ hands we religiously monitored them on stability, performance and product/conversion metrics. 

• Stability through Sentry and Play Store 
• Performance through Sentry with our own custom metrics
• Product metrics primarily through Mixpanel

New Architecture adoption results

Stability

In our first few builds we noticed a slight decrease in stability due to a crash in one of the third party libraries only present on the New Architecture and affecting a quite rare flow. Once we fixed this issue the stability was on par with old architecture at 99.9% crash free sessions.

Performance

Overall, our production data showed that render times got significantly faster, but with large variability between different screens. We also noticed that the biggest improvements were seen on the slowest devices – both in absolute and relative terms – which was a happy surprise. 

Not everything got faster though: The native cold start got a little bit slower which was somewhat surprising given our migration to Turbo Modules. Since the app binary size increased with the New Architecture enabled, our current assumption is that this is caused by still-present parts of the old architecture. We expect this to get better in the future when the migration is fully completed and with initiatives like Nicola’s single merged dynamic library.

React Native 0.76 will ship with a single merged dynamic library called `https://t.co/w2nNNDov97`:https://t.co/peZ08rvbtS

This comes with major space savings for users as well as performance wins

— Nicola 🏳️‍🌈 (@cortinico) August 20, 2024

As a whole, our most important and more holistic user-impacting metric called App Render Complete –which includes native boot, js boot, networking and rendering — was improved. 

Next steps

With the New Architecture successfully in place we’re looking at how to further leverage the new capabilities gained, such as:

• Use useDeferredValue for frequently updated, but less critical components such as price tickers
• Fix instances of jumpy layouts by replacing onLayout with synchronous measure() calls
• Expose existing Rust libraries from the backend to the apps via JSI bindings

Thanks

• Nicola Corti and the React Native team at Meta for providing the incredibly useful resources for adopting the new architecture and being receptive to, and quickly addressing feedback. 
• Brent Vatne at Expo for driving the effort of making the ecosystem migrate to the new architecture and answering in-depth questions.
• The whole Software Mansion team for doing the mammoth task of migrating many of the core third party libraries such as reanimated, gesture handler, screens and svg.