React Native 团队核心原则
本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →
Facebook 的 React Native 团队遵循一系列指导原则来决定我们工作的优先级。这些原则代表我们团队自身的立场，并不必然反映 React Native 生态中所有参与者的观点。我们在此分享这些原则，旨在更透明地展示我们的驱动力、决策依据以及工作重心。
原生体验优先
React Native 的首要目标是满足用户对各平台的体验预期。正因如此，React Native 直接渲染为平台原生组件。相较于跨平台一致性，我们更重视原生观感和操作体验。
例如，React Native 的 TextInput 在 iOS 上会渲染为 UITextField 组件。这确保了与密码管理器和键盘控制功能的无缝集成。通过使用平台原生组件，React Native 应用还能自动适配 Android 和 iOS 新版本的设计与行为变更。
要实现原生应用的观感与体验，性能也必须与之匹配。这正是我们投入最多雄心的领域。例如 Facebook 专门为 Android 版 React Native 开发了 Hermes 引擎，这个从零构建的 JavaScript 引擎显著提升了应用启动速度。同时我们还在推进重大架构改进，优化线程模型并增强与原生代码的互操作性。
海量规模支撑
Facebook 应用中有数百个界面由 React Native 实现，这个应用被数十亿用户通过各类设备访问。正因如此，我们专注于解决大规模场景下的极端挑战。
在自身产品中部署 React Native 使我们能发现小规模场景无法暴露的问题。例如 Facebook 着力优化从最新 iPhone 到多代旧款 Android 设备的全频谱性能表现。这种专注驱动了 Hermes、Fabric 和 TurboModules 等架构级项目。
我们已证明 React Native 同样适用于超大型组织。当数百名开发者协作开发同一应用时，渐进式采用成为刚需。为此我们确保 React Native 支持逐屏迁移。很快还将进一步实现：将现有原生界面中的单个视图迁移到 React Native。
对海量规模的专注意味着我们暂不涉足某些领域。例如团队不主导行业推广 React Native，也不会主动解决小规模场景未暴露的问题。值得自豪的是，我们拥有众多合作伙伴与核心贡献者，他们正致力于解决社区关注的这些重要领域。
开发效能提升
卓越的用户体验源自持续迭代。代码变更应能在数秒内呈现在运行中的应用中。React Native 的架构使其能在开发过程中提供近乎实时的反馈。
众多团队反馈采用 React Native 后开发效能显著提升。即时反馈机制让尝试新创意和打磨细节变得轻松——开发者无需因微小改动中断编码流程。我们在改进 React Native 时始终确保保留这一核心开发体验。
即时反馈并非 React Native 提升效能的唯一途径。团队可利用快速增长的高质量开源生态，还能在 Android、iOS 和 Web 平台间共享业务逻辑。这加速了版本迭代，并消除了跨平台团队间的协作壁垒。
全平台覆盖
2014 年推出 React Native 时，我们提出"学习一次，编写任何平台"的愿景——这里的"任何平台"具有字面意义。开发者应能触达最广泛的用户群体，不受设备型号或操作系统的限制。
React Native 的目标平台非常多样化，涵盖移动设备、桌面端、网页、电视、VR、游戏主机等。我们致力于让每个平台都能提供丰富的体验，而不是要求开发者按照最低标准进行构建。为此，我们专注于支持各平台的独特功能——从多样化的输入方式（如触控、手写笔、鼠标）到 VR 中的 3D 环境等根本性差异化的交互体验。
这一原则促使我们决定使用跨平台的 C++ 实现 React Native 的新核心架构，以提升多平台一致性。同时，我们正在为 Windows 和 macOS 等平台维护者（如微软）优化公共接口，力求让任何平台都能支持 React Native。
声明式用户界面
我们不追求在每个平台部署完全相同的用户界面，而是主张通过相同的声明式编程模型来展现每个平台的独特功能。我们的声明式编程模型就是 React。
实践证明，React 推广的单向数据流能让应用更易于理解。我们更倾向于将界面视为声明式组件的组合，而非命令式管理的视图。React 在 Web 领域的成功，以及新版原生 Android 和 iOS 框架的发展方向，都表明行业同样拥抱了声明式 UI。
React 引领了声明式用户界面的潮流，但仍有诸多未解难题需要 React 发挥独特优势。React Native 将持续构建在 React 的创新之上，保持在声明式用户界面运动的前沿。