Проблеми з продуктивністю можуть змусити розробників піти зайву милю. У цій публікації блогу ви можете дізнатися про проблеми з продуктивністю, з якими ми зіткнулися в Kraken, і про те, як ми розпочали шлях впровадження нової архітектури, щоб вирішити ці проблеми. Так, по дорозі були лежачі поліцейські. Ми навчилися у них, і сподіваємося, що ви теж зможете.
Нова архітектура буде стандартною, починаючи з React Native 0.76 і Expo SDK 52, наступних версій React Native і Expo. Нові функції в розробці будуть реалізовані лише для нової архітектури, а деякі бібліотеки вже припиняють підтримку старої архітектури. Ви дійсно повинні почати думати про його прийняття, якщо ви не хочете пропустити!
Огляд архітектури Kraken
Kraken — одна з найбільших, надійних і безпечних криптовалютних платформ із активною спільнотою з понад 13 мільйонів клієнтів по всьому світу. Наразі у нас є три мобільні додатки у виробництві – усі вони написані на React Native із купою користувальницьких нативних бібліотек і компонентів у Swift/Kotlin, а також бекенд у Rust.
Хоча ми не використовуємо повний пакет Expo з історичних причин, ми почали перехід на використання модулів Expo замість деяких пакетів спільноти з міркувань обслуговування та продуктивності. Продуктивність є ключовою проблемою для нас, особливо в нашому додатку Pro, який інтенсивно використовує дані та містить інтерактивні діаграми, які постійно оновлюються через WebSockets. Це створює навантаження на продуктивність, особливо на пристроях Android низького класу. Тож протягом тривалого часу ми спостерігали за прогресом у новій архітектурі та сподівалися, що це пом’якшить деякі проблеми, з якими ми зіткнулися.
Наприкінці цієї подорожі ми змогли значно покращити продуктивність наших програм у кількох сферах:
Повний рендерер додатків: у 1,3 рази швидше
Відтворення головного екрана: у 2,5 рази швидше
Візуалізація екрана потоку торгів: у 5,3 раза швидше
І більше…
Продовжуйте читати, щоб дізнатися про нашу подорож та всі інші переваги продуктивності, які з’явилися разом з нею.
Наш план впровадження нової архітектури
Наша основна мета полягала в тому, щоб підвищити продуктивність на Android. Наш перший план дій полягав у створенні швидкого підтвердження концепції за допомогою Fabric, щоб мати можливість оцінити вигоди. Незважаючи на нашу досить велику кодову базу та безліч залежностей, це було зроблено досить швидко завдяки використанню застарілого рівня взаємодії та видаленню несумісних бібліотек/компонентів. Результатом стала набагато оперативніша програма, яка була підкріплена об’єктивними показниками продуктивності.
Знаючи, що екосистема все ще перебуває на стадії міграції та очікуючи певних недоліків, ми вирішили поступово запровадити нову архітектуру, щоб зменшити інженерний ризик. Це означало працювати платформа за платформою, додаток за додатком і архітектура функція за функцією. Наш спрощений план виглядав приблизно так:
Оновіть сторонні бібліотеки компонентів і перенесіть внутрішні компоненти, щоб підтримувати як новий, так і старий рендерер
Оновіть власні бібліотеки модулів сторонніх розробників і перенесіть внутрішні бібліотеки на Native Turbo Modules
Увімкніть режим без моста
Вилучіть зворотну сумісність після повного розгортання
Прискорення впровадження нової архітектури
Під час нашого поступового впровадження ми зіткнулися з кількома лежачими поліцейськими. Цього слід було очікувати. У цьому розділі ми викличемо кожного з них, сподіваючись, що це допоможе іншим командам зорієнтуватися в них трохи швидше, ніж ми.
Свіфт
На відміну від Turbo Modules, компоненти Fabric офіційно не підтримують Swift. Це був облом, оскільки наша кодова база створена на Swift, і ми не хотіли повертатися до Objective-C. Завдяки натхненню з бібліотеки Lottie (і допомозі відео від Coding With Nobody) ми зуміли це запрацювати. Варто зазначити, що модулі Expo мають власну підтримку Swift і, можливо, кращий API. Ми також стежимо за проектом Nitro від Марка Русаві, який у майбутньому може підтримувати компоненти Fabric.
Автоматичне дозування
На деяких екранах ми помітили уповільнене рендеринг, особливо на екранах із дуже інтенсивним рендерингом, як-от інтерактивні графіки.
Хоча ми не зовсім впевнені в першопричині, ми підозрюємо, що це сталося через автоматичне пакетування, представлене в React 18, яке підтримується лише на новій архітектурі. Теорія полягала в тому, що хоча пакетування призводить до меншого навантаження на ЦП, воно також пропускає кілька проміжних кроків, які створюють швидше враження. Зрештою, компонент не був правильно зібраний, тому після рефакторингу та переходу на використання Reanimated для взаємодій, чутливих до продуктивності, проблеми були вирішені.
Безмостовий
Оскільки режим Bridgeless є останньою частиною головоломки нової архітектури, ми хотіли прийняти цей останній, хоча це була порівняно найменша руйнівна зміна (завдяки чудовому режиму взаємодії). Однак наш план не спрацював, оскільки Expo 51 не підтримує Fabric без використання безмостового режиму. Це було проблемою для нас, оскільки ми хотіли виправити React Native 0.74, що означало, що ми повинні були прийняти Bridgeless трохи раніше, ніж планувалося.
Загалом це було нескладно, за одним винятком: CodePush незабаром припиниться, і ми покладаємося на requestIdleCallback для деяких наших показників продуктивності. Зараз ми перейшли на оновлення Expo, але тим часом ми виправили підтримку через patch-package/yarn patch і backported requestIdleCallback, який підтримується з 0.75.
Шари взаємодії
Режим взаємодії для компонентів Old Renderer працював як магія для більшості компонентів Android, але для iOS ми виявили проблеми з макетом одного з наших внутрішніх компонентів. Незважаючи на це, це ніколи не було нашим запланованим кінцевим станом, і ми вирішили це, просто перенісши їх у Fabric.
Proguard
На початку нашої розробки ми помітили, що гілка, яка чудово працювала в розробці, миттєво зазнала збою у робочій збірці з дещо нечіткими повідомленнями про помилки. Після деякого копання ми виявили, що це сталося через те, що Proguard видалив певні сторонні класи та методи. Цілком можливо, що це було спричинено ледачою природою Turbo Modules, через що оптимізатор Proguard збив з пантелику думку, що вони не використовуються. Коли ми виявили проблему, було легко просто виключити ці символи з видалення.
Розгортання
Як згадувалося раніше, ми хотіли якомога поетапніше прийняти нову архітектуру. В ідеалі ми хотіли б працювати екран за екраном, і хоча нова архітектура підтримується нативно, наразі вона не підтримується React Navigation, тому нам довелося бути обережними, розгортаючи Fabric. Однак завдяки рівням взаємодії ми змогли успішно розгорнути нову арку на рівні проекту.
Маестро
Хоча у нас є багато тестів компонентів, які використовують React Testing Library, на жаль, вони не додадуть нам жодної впевненості у прийнятті нового рендерера; замість цього ми значною мірою покладалися на наші автоматизовані наскрізні тести на Maestro Cloud. Це також місце, де ми запускаємо наш набір продуктивності, щоб дати точні цифри перед тим, як почати виробництво.
Внутрішнє тестування
Зазвичай ми не покладаємося на тестування вручну, але оскільки ці зміни більш впливові, і їх неможливо легко відкотити за допомогою позначки функції, ми розповсюдили збірки всередині, щоб люди могли перевірити та перевірити, чи їхні потоки працюють належним чином. Це було особливо корисно для пошуку регресій візуалізації в нішових екранах, які спочатку були пропущені через відсутність візуального тестування.
«Канарка випускає»
Коли ми вважали, що перевірили якомога більше з автоматизацією та без неї, ми хотіли надати її невеликій кількості робочих користувачів. Традиційно ми б використовували позначки функцій у LaunchDarkly для цього, але оскільки більшість частин нової архітектури є прапорцями компіляції, це не було варіантом. Замість цього ми вибрали версію для бідних випусків Canary через поступове розгортання в Play Store.
Наші додатки випускаються щотижня, і, по суті, коли ми визнаємо випуск стабільним і повністю розгорнутим у виробництві, ми надаємо невеликому відсотку користувачів версію з увімкненою новою архітектурою. Оскільки поступові випуски в Play Store можна призупинити, ми можемо обмежити вплив на користувачів у разі будь-яких серйозних помилок або збоїв. Крім того, перехід до наступного відбувається швидше завдяки загалом швидшому процесу перегляду.
Реальний моніторинг клієнтів
Після того, як програма потрапила в руки наших клієнтів, ми ретельно перевіряли її стабільність, продуктивність і показники продукту/конверсії.
Стабільність через Sentry і Play Store
Продуктивність через Sentry з нашими власними метричними показниками
Показники продукту переважно через Mixpanel
Результати впровадження нової архітектури
Стабільність
У наших перших кількох збірках ми помітили невелике зниження стабільності через збій в одній зі сторонніх бібліотек, присутніх лише на новій архітектурі та впливаючих на досить рідкісний потік. Після того, як ми виправили цю проблему, стабільність була на рівні зі старою архітектурою на 99,9% сеансів без збоїв.
Продуктивність
Загалом наші виробничі дані показали, що час візуалізації став значно швидшим, але з великою різницею між різними екранами. Ми також помітили, що найбільші покращення були помічені на найповільніших пристроях – як в абсолютних, так і у відносних значеннях – що було щасливою несподіванкою.
Однак не все стало швидшим: рідний холодний запуск став трохи повільнішим, що було дещо дивно, враховуючи наш перехід на турбомодулі. Оскільки двійковий розмір програми збільшився з увімкненням нової архітектури, ми припускаємо, що це спричинено все ще наявними частинами старої архітектури. Ми очікуємо, що це покращиться в майбутньому, коли міграція буде повністю завершена та з такими ініціативами, як єдина об’єднана динамічна бібліотека Nicola.
React Native 0.76 постачатиметься з єдиною об’єднаною динамічною бібліотекою під назвою `https://t.co/w2nNNDov97`:https://t.co/peZ08rvbtS
Це значно економить простір для користувачів, а також підвищує продуктивність
— Нікола 
(@cortinico) 20 серпня 2024 р
Загалом наш найважливіший і більш цілісний показник впливу на користувачів під назвою App Render Complete, який включає власне завантаження, завантаження js, мережу та рендеринг, було вдосконалено.
Виміряти
P50
P95
Відтворення програми завершено
1x
1,3x
Візуалізація головного екрана
2x
2,5x
Візуалізація екрана торгового потоку
3,8x
5,3x
Рідний холодний старт
0,9x
0,7x
Загальний час блокування навігації
1x
1,1x
Наступні кроки
З успішним впровадженням нової архітектури ми шукаємо способи подальшого використання нових здобутих можливостей, таких як:
Використовуйте useDeferredValue для часто оновлюваних, але менш критичних компонентів, таких як цінові тикери
Виправте випадки стрибаючих макетів, замінивши onLayout на синхронні виклики меры().
Відкривайте наявні бібліотеки Rust із серверної частини для додатків через прив’язки JSI
дякую
Нікола Корті та команда React Native у Meta за надання неймовірно корисних ресурсів для адаптації нової архітектури та сприйнятливість до відгуків і швидке реагування на них.
Брент Ватне з Expo за сприяння переходу екосистеми на нову архітектуру та відповіді на глибокі запитання.
Уся команда Software Mansion для виконання величезного завдання з міграції багатьох основних сторонніх бібліотек, таких як reanimated, обробник жестів, екрани та svg.
Почніть роботу з Kraken
Ці матеріали призначені лише для загальної інформації та не є інвестиційними порадами чи рекомендаціями чи закликами купувати, продавати, робити ставки чи утримувати будь-які криптоактиви чи брати участь у будь-якій конкретній торговій стратегії. Kraken не дає жодних заяв чи гарантій будь-якого роду, явних чи непрямих, щодо точності, повноти, своєчасності, придатності чи дійсності будь-якої такої інформації та не несе відповідальності за будь-які помилки, пропуски чи затримки в цій інформації чи будь-які втрати, травми або збитки, спричинені його показом або використанням. Kraken не працює і не працюватиме над підвищенням або зниженням ціни будь-якого конкретного криптоактиву, який він надає. Деякі криптопродукти та ринки нерегульовані, і ви можете не бути захищені державною компенсацією та/або регуляторними схемами захисту. Непередбачуваний характер ринків криптоактивів може призвести до втрати коштів. Податок може бути сплачений за будь-яке повернення та/або будь-яке збільшення вартості ваших криптоактивів, тому вам слід отримати незалежну консультацію щодо вашої податкової позиції. Можуть застосовуватися географічні обмеження.
Публікація про поступове впровадження нової архітектури Kraken для вирішення проблем продуктивності вперше з’явилася в блозі Kraken.
Джерело: Kraken
Публікація про те, що Kraken поступово використовує нову архітектуру для вирішення проблем із продуктивністю, вперше з’явилася на Crypto Breaking News.