效能难题会让开发人员付出更多努力。在这篇文章中，您可以了解我们在 Kraken 遇到的效能问题以及我们如何开启新架构采用之旅来解决这些问题。是的，一路上有减速带。我们向他们学习，希望您也能做到。
从 React Native 0.76 和 Expo SDK 52（React Native 和 Expo 的下一个版本）开始，新架构将成为预设架构。新的开发中功能将仅针对新架构实现，一些程式库已经放弃对旧架构的支援。如果您不想错过，您真的应该开始考虑采用它！
Kraken 架构概述
Kraken 是最大、最值得信赖和安全的加密货币平台之一，在全球拥有超过 1,300 万名客户的充满活力的社群。目前，我们有三个正在生产的行动应用程式——全部用 React Native 编写，并带有一堆 Swift/Kotlin 中的自订本机程式库和元件，以及 Rust 的后端。
虽然由于历史原因我们没有使用完整的 Expo 套件，但出于维护和性能方面的原因，我们已经开始迁移到使用 Expo 模组而不是某些社群包。效能是我们关注的关键问题，尤其是在我们的 Pro 应用程式中，该应用程式是资料密集型的，并且充满了互动式图表，这些图表透过 WebSocket 不断更新。这会对效能造成压力，尤其是在低阶 Android 装置上。因此，很长一段时间以来，我们一直在关注新架构的进展，并希望它能缓解我们面临的一些问题。
在此旅程结束时，我们能够在多个方面显著提高应用程式的效能：
完整的应用程式渲染器：速度提高 1.3 倍
主萤幕渲染器：速度提高 2.5 倍
交易流程画面渲染：速度提高 5.3 倍
还有更多…
继续阅读以了解我们的旅程以及随之而来的所有其他性能优势。
我们的新架构采用计划
我们的主要目标是提高 Android 上的效能。我们的第一个行动方案是使用 Fabric 建立一个快速概念验证，以便能够估计收益。尽管我们有相当大的程式码库和大量的依赖项，但透过利用遗留互通层并删除不相容的程式库/元件，这很快就完成了。结果是一个感觉更加敏捷的应用程序，并有客观的性能指标作为支持。
知道生态系统仍处于迁移阶段并预期会出现一些粗糙的情况，我们决定以增量方式采用新架构以降低工程风险。这意味著逐个平台、逐一应用程式、逐一功能地建立架构。我们的简化计划看起来像这样：
更新第三方元件库并迁移内部元件以支援新旧渲染器
更新第三方本机模组库并将内部库迁移到本机 Turbo 模组
启用无桥模式
全面推出后删除向后相容性
新架构采用速度放缓
在我们的渐进采用之旅中，我们遇到了一些减速带。这是意料之中的事。在本节中，我们将逐一列出，希望能帮助其他团队比我们更快掌握它们。
迅速
与 Turbo Modules 不同，Fabric 元件没有正式支援 Swift。这很糟糕，因为我们的程式码库是 Swift 的，我们不想回到 Objective-C。借助 Lottie 库的一些灵感（以及来自 Coding With Nothing 的视频的帮助），我们让它发挥了作用。值得注意的是，Expo Modules 具有原生 Swift 支援和可以说更好的 API。我们也正在关注 Marc Rousavy 的 Nitro 项目，该项目将来可能支援 Fabric 组件。
自动配料
在某些萤幕中，我们注意到渲染速度较慢，尤其是渲染量很大的萤幕，例如互动式图表。
虽然我们不完全确定根本原因，但我们怀疑这是由于 React 18 中引入的自动批次造成的，该功能仅在新架构上支援。其理论是，虽然批次处理可以减少 CPU 负载，但它也跳过了一些中间步骤，从而给人更快的印象。最终，该组件没有正确构建，因此在重构和迁移到使用 Reanimated 进行性能敏感交互后，问题得到了解决。
无桥
由于无桥模式是新架构难题中最新的一部分，因此我们希望采用最后的模式，尽管它是相对而言破坏性最小的变更（得益于出色的互通模式）。然而，我们的计划并没有成功，因为 Expo 51 在不使用无桥模式的情况下不支援 Fabric。这对我们来说是一个问题，因为我们希望在 React Native 0.74 中进行一些修复，这意味著我们必须比计划稍早采用 Bridgeless。
总的来说，它并不复杂，但有一个例外：CodePush 很快就会被弃用，我们依赖 requestIdleCallback 来衡量我们的一些效能指标。我们目前正在迁移到 Expo 更新，但与此同时，我们已经透过 patch-package/yarn patch 和向后移植的 requestIdleCallback 修复了支持，该支援从 0.75 开始支援。
互通层
旧渲染器元件的互通模式对于大多数 Android 元件来说就像魔法一样，但对于 iOS，我们发现它在我们的内部本机元件之一上存在布局问题。无论如何，这从来都不是我们预期的最终状态，我们透过简单地将它们迁移到 Fabric 来解决它。
混淆者
在我们开发的早期，我们注意到一个在开发中运作良好的分支在生产版本中崩溃了，并带有一些模糊的错误讯息。经过一番挖掘，我们发现这是由于 Proguard 删除了某些第三方类别和方法造成的。这可能是由 Turbo Modules 的惰性本质引起的，这使得 Proguard 优化器误认为它们没有被使用。一旦我们发现问题，就很容易排除那些被剥离的符号。
推出
如前所述，我们希望尽可能以渐进方式采用新架构。理想情况下，我们希望逐屏浏览，虽然新架构本身受支持，但 React Navigation 目前不支援它，因此我们在推出 Fabric 时必须小心。然而，由于互通层，我们能够在专案层级成功推出新的架构。
大师
虽然我们使用 React 测试库进行了许多元件测试，但不幸的是，它们不会让我们对采用新的渲染器有任何信心；相反，我们严重依赖 Maestro Cloud 上的自动化端对端测试。这也是我们运行性能套件的地方，以便在投入生产之前为我们提供确切的数据。
内部测试
通常我们不依赖手动测试，但由于这些变更影响更大，并且无法透过功能标志轻松回滚，因此我们在内部分发构建，供人们测试和验证他们的流程是否按预期工作。这对于寻找利基萤幕中的渲染回归特别有用，这些回归最初由于缺乏视觉测试而错过。
“金丝雀发布”
当我们相信我们已经在有或没有自动化的情况下进行了尽可能多的测试时，我们希望将其提供给少数生产用户。传统上，我们会在 LaunchDarkly 中使用功能标志来实现此目的，但由于新架构的大部分部分都是编译标志，因此这不是一个选择。相反，我们选择了透过在 Play 商店上逐步推出的穷人版本的金丝雀版本。
我们的应用程式每周发布一次，基本上，一旦我们认为版本稳定并完全投入生产，我们就会为一小部分用户提供启用了新架构的版本。由于 Play 商店上的逐步发布可以停止，因此我们可以限制任何严重错误或崩溃时对用户的影响。此外，由于审核过程通常更快，因此前滚速度更快。
真实客户端监控
一旦应用程式到达客户手中，我们就会认真监控他们的稳定性、效能和产品/转换指标。
透过 Sentry 和 Play Store 实现稳定性
透过 Sentry 和我们自己的自订指标实现的效能
主要透过 Mixpanel 进行产品指标
新架构采用结果
稳定
在我们的前几个版本中，我们注意到稳定性略有下降，因为仅存在于新架构上的第三方库之一崩溃并影响了相当罕见的流程。一旦我们解决了这个问题，稳定性就与旧架构相当，会话无崩溃率高达 99.9%。
表现
整体而言，我们的生产数据显示渲染时间明显加快，但不同萤幕之间的差异很大。我们还注意到，最大的改进出现在最慢的设备上——无论是绝对值还是相对值——这是一个令人高兴的惊喜。
但并非一切都变得更快：本机冷启动速度有点慢，考虑到我们迁移到 Turbo 模组，这有点令人惊讶。由于应用程式二进位档案大小随著新架构的启用而增加，我们目前的假设是这是由旧架构中仍然存在的部分引起的。我们预计，当迁移完全完成并透过 Nicola 的单一合并动态库等措施后，情况会变得更好。
React Native 0.76 将附带一个名为「https://t.co/w2nNNDov97」的合并动态函式库：https://t.co/peZ08rvbtS
这将为用户节省大量空间并提高效能
— 尼古拉 
（@cortinico）2024 年 8 月 20 日
整体而言，我们最重要、更全面的使用者影响指标「App Render Complete」（包括本机启动、js 启动、网路和渲染）都得到了改进。
措施
P50
P95
应用程式渲染完成
1x
1.3倍
主画面渲染
2x
2.5倍
交易流程画面渲染
3.8倍
5.3倍
本机冷启动
0.9倍
0.7倍
导航总阻塞时间
1x
1.1倍
后续步骤
随著新架构的成功实施，我们正在研究如何进一步利用所获得的新功能，例如：
将 useDeferredValue 用于经常更新但不太重要的元件，例如价格行情指示器
透过同步的measure()呼叫取代onLayout来修复跳转布局的实例
透过 JSI 绑定将现有的 Rust 库从后端公开到应用程式
谢谢
Nicola Corti 和 Meta 的 React Native 团队为采用新架构、接受并快速解决回馈提供了非常有用的资源。
Brent Vatne 在世博会上推动生态系统迁移到新架构并回答了深入的问题。
整个 Software Mansion 团队完成了迁移许多核心第三方函式库（例如 reanimated、手势处理程序、萤幕和 svg）的艰巨任务。
开始使用 Kraken
这些资料仅用于一般资讯目的，并非投资建议或购买、出售、持有或持有任何加密资产或参与任何特定交易策略的推荐或招揽。 Kraken 对任何此类资讯的准确性、完整性、及时性、适用性或有效性不作任何形式的明示或暗示的陈述或保证，并且不会对该资讯中的任何错误、遗漏或延迟或任何损失承担责任，因展示或使用而造成的伤害或损坏。 Kraken 不会也不会努力提高或降低其提供的任何特定加密资产的价格。一些加密产品和市场不受监管，您可能不受政府补偿和/或监管保护计划的保护。加密资产市场的不可预测性可能会导致资金损失。任何回报和/或您的加密资产价值的任何增加都可能需要纳税，您应该就您的税务状况寻求独立建议。可能存在地理限制。
Kraken 逐步采用新架构来解决效能问题的文章首先出现在 Kraken 部落格上。
来源：海妖
Kraken 逐步采用新架构来解决效能问题的贴文首先出现在《加密突发新闻》上。
