Migrating an Ecosystem: An Empirical Study of How React Native Libraries Adopted the New Architecture
这项实证研究分析了 React Native 生态系统向其新架构的迁移过程，揭示了虽然重大里程碑加速了热门库的采用，但仍有相当一部分处于休眠状态且未迁移的软件包在被使用，从而导致了一个兼容层已成为长期基础设施的碎片化景观。
原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
在软件世界中，平台是无数应用程序赖以构建的基础。正如城市的基础设施决定了建筑物的建造方式一样，这些数字基础提供了必要的工具和规则，允许开发者创建移动应用。偶尔，这些平台的拥有者必须更换其核心系统，以提高性能或增加新功能。这是一项巨大的工程，不仅是对平台本身，对于依赖于它的成千上万个独立工具和库而言也是如此。当基础发生变化时，所有构建在其之上的结构最终都必须做出调整，否则将无法匹配。这创造了一个复杂的挑战：当脚下的土地发生位移时，一个庞大且去中心化的独立创造者生态系统该如何应对？这个问题不仅仅是技术性的；它是一项关于人类协作、维护以及数字工具生命周期的研究。
独立研究员 Revanth Krishna Maddula 最近的一项研究探讨了 React Native 生态系统中的这一确切场景，React Native 是一个用于构建移动应用程序的流行框架。React Native 最近将其旧的通信系统（被称为“桥接”，the bridge）替换为一种新的、更快的架构。这次转型并非一蹴而就，而是经过了数年间三个不同的阶段。首先，新系统作为一种可选方案提供；接着，它成为了标准设置，尽管开发者仍可以选择切换回旧系统；最后，旧系统被完全关闭，使得新架构成为唯一的选择。Maddula 着手衡量了生态系统对这些变化的反应。他不仅查看了官方公告或最受欢迎的应用，还分析了社区目录中列出的近 2,800 个库的整个目录，特别关注了其中包含原生代码（native code）的 1,444 个库，因为这些库必须进行重写才能适配新系统。
结果揭示了一个由两个移动速度截然不同的群体组成的故事。在包含原生代码的库中，约 62% 已成功迁移到新架构。这些成功的库是生态系统的“主力军”，占据了所有每周下载量的 95%。这意味着对于绝大多数用户而言，转型实际上已经完成。然而，存在一个由 519 个库组成的显著“长尾”尚未迁移。这些大多是多年未更新的陈旧、休眠项目。虽然它们代表了较小的总使用份额，但每周仍有数百万次下载。研究发现，这 519 个未迁移的库中有 115 个每周下载量至少达到 10,000 次，41 个超过 100,000 次。它们并非无名小卒；其中包括用于处理文件系统、视频、支付和通知的广泛使用的组件。由于如此多的应用程序仍然依赖于它们，平台拥有者不能简单地移除旧系统，否则会破坏生态系统的很大一部分。
这些迁移的时机讲述了一个关于压力与响应的具体故事。随着平台从可选方案转变为默认设置，再到最终成为强制要求，库的更新速率有所提高。每月转换的库数量从缓慢的滴流增长到了稳定的溪流。然而，数据表明，这些官方截止日期并未迫使那些未迁移的库进行改变。那些停滞不前的库并不是因为缺乏时间或缺乏警告而被阻碍，而是因为它们的维护者已经不在了。研究发现，预测一个库是否会迁移的最强指标，仅仅在于它是否仍在被更新。那些多年未发布新版本的库不太可能迁移，无论平台的规则如何。即使在那些仍在积极维护的库中，不到一半的库在新系统成为默认设置后的两年内完成了迁移。
关于这些库是如何被更新的，出现了一个令人惊讶的发现。平台拥有者设计了一条特定的官方迁移路径，即一种名为 Codegen 的方法，它可以自动生成必要的代码。然而，生态系统并未遵循这条单一路径。相反，迁移目标发生了碎片化。近一半成功迁移的库选择了使用第三方框架，特别是被称为 Expo Modules 和 Nitro Modules 的工具，而不是官方路径。这些第三方工具提供了一种更简单或更快速的构建新系统的方法，有效地吸收了大部分迁移工作。这意味着，生态系统现在对这些外部框架的依赖程度，已与对平台自身官方工具的依赖程度不相上下，甚至可能更高。研究指出，这创造了一个新的依赖层，整个生态系统的稳定性现在部分取决于这些中间层。
研究人员还调查了这些未迁移库的创造者在表达什么。他们发现，极少数人（不到十分之一）在文档中针对新架构或自身的维护状态写下了任何声明。大多数人则保持沉默。在那些发表了言论的人中，信息往往带有“放弃”的意味。一些库被明确标记为弃用（deprecated），而另一些则被归档或列为正在寻找新维护者。少部分库声称支持新系统，但仔细观察其代码后发现，它们仍在运行旧系统，依靠一个兼容层来运行。这个层充当了一个翻译器，允许旧代码在新系统上运行，但这并不是一个永久的解决方案。研究表明，对于生态系统的很大一部分而言，这个兼容层已不再是临时的桥梁，而成为了一个永久的目的地。
这些发现对于任何在该平台上构建应用的人来说，其意义都是明确的。库上的官方“支持”（supported）标签并不保证它已被完全更新；它可能仅仅意味着该库通过兼容层在运行。对于开发者而言，这意味着检查一个库的状态需要看比表面声明更深的内容。研究强调，最危险的依赖通常是那些具有高下载量的休眠依赖，因为如果兼容层最终被移除，它们最容易引发问题。对于平台拥有者来说，教训是：设定截止日期对活跃的维护者很有效，但对生态系统中沉睡的“长尾”部分却毫无作用。研究结论认为，兼容层必须被规划为长期基础设施，并且平台必须与那些已成为迁移过程中不可或向的第三方框架进行对接。转型不是一个可以宣布完成的单一事件，而是一个生态系统已经找到了属于自己的、碎片化的前进方式的持续过程。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。