持续的原生生成 (CNG)
了解如何使用持续原生生成 (CNG) 和预构建来管理你的原生项目。
单个原生项目本身就很难维护、扩展和更新。在跨平台应用中，你有多个原生项目需要维护，并且必须随时更新以跟上最新的操作系统版本，以避免在任何第三方依赖上落后太多。
🌐 A single native project on its own is complicated to maintain, scale, and update. In a cross-platform app, you have multiple native projects that you must maintain and keep up to date with the latest operating system releases to avoid falling too far behind in any third-party dependencies.
随着你的原生项目不断发展，来自第三方依赖的复杂性也在增加，这会使升级变得更加困难，并减缓开发者的工作进度。这会阻碍添加高级原生功能，从而导致应用功能不够强大。在跨平台应用中，这种复杂性会在每个平台上被成倍放大。
🌐 As your native project grows, the complexity from third-party dependencies increases, complicating upgrades and slowing down developer momentum. This discourages adding advanced native functionality and leads to less powerful apps. In cross-platform apps, this complexity is multiplied across each platform.
为了解决这个问题，我们引入了持续本地生成的概念。与其一次性创建本地项目并在整个代码库生命周期中维护这些本地项目的自定义内容，不如仅在需要时生成短期本地项目，例如在调试或构建时。这些项目是从标准模板加上定义模板如何定制的配置或自定义代码生成的。其结果是一个可以编译成本地应用的本地项目，并包含开发者所需的任何自定义内容。然而，开发者只需维护其自定义定义，而不需要维护所有的本地项目代码。
🌐 To address this, we've introduced the concept of Continuous Native Generation. Instead of creating native projects a single time and maintaining customizations to those native projects for the lifetime of the codebase, short-lived native projects are generated only when needed, such as when debugging or building. These projects are generated from a standard template plus configuration or custom code that defines how the template should be customized. The result is a native project that can be compiled into a native app with any customizations desired by the developer. However, the developer is responsible for only maintaining the definition of their customizations, rather than all of the native project code.
React Native 应用中的 CNG
🌐 CNG in React Native apps
React Native 应用可以通过使用 Prebuild 来使用 CNG，以自动升级、安装或卸载库、应用白标自定义、在多个应用之间共享配置、减少孤立代码 等等。
🌐 React Native apps can use CNG by using Prebuild to automate upgrades, install or uninstall libraries, apply white label customizations, share configuration across multiple apps, reduce orphaned code, and more.
Expo 作为一个框架 通过结合以下工具来实现 CNG:
- 应用配置 文件。
- 传递给
npx expo prebuild命令的参数。 - 项目中安装的
expo版本及相应的 预构建模板。 - 自动链接，用于链接在 package.json 中找到的 原生模块。
- 原生订阅者，用于减少入口文件（如 MainApplication 或 AppDelegate）中原生代码的副作用。
- 用于代码签名附加目标和权利的 EAS 凭证。
最终的结果是一个工作流程，开发者可以用应用配置表达任何原生应用，并通过运行 npx expo prebuild 持续生成该项目。
🌐 The end result is a workflow where a developer can express any native application with the app config and generate that project continuously — by running npx expo prebuild.
用法
🌐 Usage
可以通过运行以下命令来使用预构建：
🌐 Prebuild can be used by running:
- npx expo prebuild这会创建用于运行你的 React 代码的 android 和 ios 目录。如果你手动修改生成的目录，下次运行 npx expo prebuild --clean 时可能会丢失你的更改。相反，请使用 config 插件，它们是在预构建过程中对原生项目进行修改的函数。
🌐 This creates the android and ios directories for running your React code. If you modify the generated directories manually then you risk losing your changes the next time you run npx expo prebuild --clean. Instead, use config plugins , which are functions that perform modifications on native projects during prebuild.
我们强烈建议出于常见问题部分列出的原因使用 Prebuild，但该系统是完全可选的，你可以随时停止使用它。
🌐 We highly recommend using Prebuild for the reasons listed in the common questions section, but the system is fully optional, and you can stop using it at any time.
与 EAS 构建一起使用
🌐 Usage with EAS Build
如果你的项目不包含 android 和 ios 目录，EAS Build 将在编译前运行 Prebuild 来生成这些原生目录。这是使用 npx create-expo-app 创建的任何项目的默认行为。
🌐 If your project does not contain android and ios directories, EAS Build will run Prebuild to generate these native directories before compilation. This is the default behavior for any project created using npx create-expo-app.
对于包含 android 和 ios 目录的项目，EAS Build 不会运行 Prebuild，以避免覆盖你对原生目录所做的任何修改。
🌐 For a project that has android and ios directories, EAS Build will not run Prebuild to avoid overwriting any changes you've made to the native directories.
如果你通过在本地编译（运行 npx expo prebuild、npx expo run:android 或 npx expo run:ios）来排查应用问题，你仍然可以在构建过程中使用 EAS Build 的 Prebuild 来生成新的原生目录。android 和 ios 目录在创建新项目时会自动添加到 .gitignore 中，但如果你需要手动添加，可以将它们添加到 .gitignore 或 .easignore 文件中：
🌐 If you troubleshoot your app by compiling it locally (running npx expo prebuild, or npx expo run:android or npx expo run:ios), you can still use Prebuild with EAS Build to generate fresh native directories during the build process. The android and ios directories are automatically added to .gitignore when you create a new project, but if you need to add them manually, you can add them to .gitignore or .easignore files:
| 1 | /android | |
| 2 | /ios | |
| 0 | 3 |
与 Expo CLI 运行命令一起使用
🌐 Usage with Expo CLI run commands
你可以通过运行以下命令在本地执行原生构建：
🌐 You can perform a native build locally by running:
# Build your native Android project- npx expo run:android# Build your native iOS project- npx expo run:ios如果本地目录不存在，npx expo prebuild 将针对特定平台运行一次。在随后使用这些 run 命令时，请手动运行 npx expo prebuild --clean，以确保本地代码与你的本地配置保持最新同步。
🌐 If native directories are absent, npx expo prebuild will run once for the specific platform. On subsequent uses of these run commands, manually run npx expo prebuild --clean to ensure the native code is freshly synchronized with your local configuration.
平台支持
🌐 Platform support
Prebuild 目前支持 Android 和 iOS。不需要支持 Web，因为没有需要为 Web 生成的本地项目，Web 应用是在浏览器中运行的。使用 --platform 选项可以为单个平台运行 prebuild：
🌐 Prebuild currently supports Android and iOS. Web support is not required because there is no native project to generate for the web and the web app it runs in a web browser. Use the --platform option to run prebuild for individual platforms:
- npx expo prebuild --platform ios依赖
🌐 Dependencies
Prebuild 首先通过从对应每个 Expo SDK 版本的模板初始化新的原生项目来开始。这也与特定的 React 和 React Native 版本保持一致。当运行 npx expo prebuild 时，如果你的项目的 React 和 React Native 版本与 模板的 package.json 中 dependencies 字段指定的预期版本不一致，你将会看到警告。
🌐 Prebuild begins by initializing new native projects from a template corresponding to each Expo SDK version. This also aligns with specific React and React Native versions. You will see a warning when running npx expo prebuild when your project's React and React Native versions differ from the expected versions from specified in the dependencies field of the template's package.json if they differ.
你可以使用 --skip-dependency-update 选项跳过更改 npm 包版本：
🌐 You can skip changing npm package versions with the --skip-dependency-update option:
- npx expo prebuild --skip-dependency-update react-native,react包管理器
🌐 Package managers
当依赖发生更改时，Prebuild 将使用当前项目中正在使用的包管理器重新安装库（这可以从锁文件中推断）。你可以通过提供以下之一来强制使用特定的包管理器：--npm、--yarn、--pnpm。
🌐 When the dependencies are changed, Prebuild will reinstall libraries using the package manager that is currently used in the project (this is inferred from the lockfile). You can force a specific package manager by providing one of: --npm, --yarn, --pnpm.
通过传递 --no-install 命令可以跳过所有安装，这对于快速测试生成非常有用。
🌐 All installations can be skipped by passing the --no-install command, which is useful for testing generation quickly.
清理
🌐 Clean
--clean 选项会在生成之前删除任何现有的本地目录。再次运行 npx expo prebuild 时，如果不使用 --clean 选项，会在现有文件上叠加更改，这样更快，但在某些情况下可能不会产生相同的结果。
🌐 The --clean option deletes any existing native directories before generating. Re-running npx expo prebuild without the --clean option will layer changes on top of the existing files, which is faster, but may not produce the same results in some cases.
例如，一些配置插件不是幂等的。当一个项目使用多个“危险修改器”向应用的代码添加正则表达式更改时，可能会导致意想不到的行为。这就是为什么使用 --clean 选项是使用 prebuild 命令最安全的方式，并且在大多数情况下通常是推荐的。
🌐 For example, some config plugins aren't idempotent. When a project utilizes multiple "dangerous modifiers" to add regex changes to an app's code, it can lead to unexpected behavior. This is why using the --clean option is the safest way to use the prebuild command and is generally recommended in most cases.
使用 --clean 选项
🌐 Using --clean option
使用 --clean 选项时，如果你的 git 代码库中有未提交的更改，你会收到警告，因为该选项会删除并重新创建所有本地项目文件。此提示是可选的，在 CI 中遇到时会被跳过。你可以通过启用环境变量 EXPO_NO_GIT_STATUS=1 来禁用此检查。
🌐 When using the --clean option, you'll be warned if you have any uncommitted changes to your git code repository, as this option will delete and recreate all of your native project files. This prompt is optional and will be skipped when encountered in CI. You can disable this check by enabling the environment variable EXPO_NO_GIT_STATUS=1.
有些情况下，开发者可能希望经常在不同的工作流之间切换。例如，你可能希望在 Android Studio 和 Xcode 中本地构建自定义功能，然后再将这些功能移到本地配置插件中。
🌐 There are cases where developers may want to swap between workflows often. For example, you may want to build custom functionality natively in Android Studio and Xcode, and then move that functionality into local config plugins.
模板
🌐 Templates
你可以通过 配置插件 自定义原生目录的生成方式。许多配置插件已经存在用于各种修改，社区库通常也会附带自己的插件。你可以 查看一些流行插件的列表 以获取更多信息。
🌐 You can customize how the native directories are generated by config plugins. Many config plugins already exist for lots of modifications, and community libraries often ship their own as well. You can see a list of some popular plugins for more information.
Prebuild 从模板文件开始，然后通过配置插件进行修改。模板文件基于 Expo SDK 版本，并来自 npm 包 expo-template-bare-minimum。你可以通过将 --template /path/to/template.tgz 传递给 npx expo prebuild 命令来更改使用的模板。一般不推荐这样做，因为 @expo/prebuild-config 中的基础修改器对模板文件做了一些未公开的假设，因此维护自定义模板可能会比较棘手。
🌐 Prebuild starts from template files, which are then modified with config plugins. The template files are based on the Expo SDK version and come from the npm package expo-template-bare-minimum. You can change the template used by passing --template /path/to/template.tgz to the npx expo prebuild command. This is not generally recommended because the base modifiers in @expo/prebuild-config make some undocumented assumptions about the template files, so it may be tricky to maintain your custom template.
注意： 在所有包都从私有注册表下载且 npm 公共注册表访问被阻止的网络环境中，必须将本地可用的模板传递给 prebuild 命令。 了解更多关于使用默认模板本地版本的信息。
副作用
🌐 Side effects
npx expo prebuild 在生成 android 和 ios 目录之外还会执行一些副作用。正在进行工作以消除这些副作用——理想情况下，运行 npx expo prebuild 将生成 Android 和 iOS 项目，而不影响项目的其他部分。
除了生成原生目录外，prebuild 还进行了以下修改：
🌐 In addition to generating the native directories, prebuild also makes the following modifications:
- 修改 package.json 中的
scripts字段，将expo start --android和expo start --ios替换为expo run:android和expo run:ios - 修改 package.json 中的
dependencies字段
scripts 字段的便利性更改是唯一会改变开发者在预构建前后处理应用方式的副作用。所有其他更改都可以保留并提交到 git，以在运行预构建时最小化差异。
🌐 The convenience change to the scripts field is the only side effect that alters how a developer works on their app before/after prebuild. All other changes can be left in place and committed to git to minimize the diff when running prebuild.
可选
🌐 Optionality
预构建是可选的，并且可以与所有 Expo 工具和服务无缝配合。对于现有的 React Native 项目，如果本地项目是手动管理的，请不要使用 npx expo prebuild，因为那可能会覆盖任何手动定制。开发者在采用其他 Expo 工具和工作流程的同时，可以继续对他们的本地项目进行（直接修改）。随后，他们可以将手动定制迁移到应用配置和/或配置插件中，然后再采用 CNG。
🌐 Prebuild is optional and works seamlessly with all Expo tools and services. For existing React Native projects, where the native projects are managed manually, do not use npx expo prebuild, as that may overwrite any manual customizations. Developers can continue to make (direct changes to their native projects) while adopting other Expo tools and workflows. Later on, they can move their manual customizations to app config and/or config plugins, and then adopt CNG.
Expo 提供的所有内容，包括 EAS、Expo CLI 以及 Expo SDK 中的库，都构建为完全支持裸 React Native 项目，这是支持使用 npx expo prebuild 的项目的最低要求。唯一的例外是 Expo Go 应用，它只能在包含缺失于 Expo Go 运行时的本地代码的 JavaScript 回退时加载任意 React Native 项目。
🌐 Everything offered by Expo including EAS, Expo CLI, and the libraries in the Expo SDK are built to fully support bare React Native projects as this is a minimum requirement for supporting projects using npx expo prebuild. The only exception is the Expo Go app, which can load arbitrary React Native projects only if they include JavaScript fallbacks for native code absent in the Expo Go runtime.
常见问题
🌐 Common questions
压缩天然气
🌐 CNG
压缩天然气（CNG）如何帮助项目升级？
没有使用 Continuous Native Generation 的 React Native 开发者报告称，根据 React Native 调查（2022），将他们的应用升级到最新版本的 React Native 是该库的最大弱点。
🌐 React Native developers who don't use Continuous Native Generation have reported that upgrading their apps to the latest version of React Native is the number one weakness of the library as per React Native Survey (2022).
使用 CNG 时，升级过程只需升级 npm 依赖、应用配置，然后重新运行 npx expo prebuild --clean。
🌐 When using CNG, the upgrade process simply involves upgrading the npm dependencies, app config, and re-running npx expo prebuild --clean.
React Native 库的作者如何采用 CNG？
React Native 库的作者可以通过多种方式采用 CNG，这取决于他们库的复杂性。以下是几种情况：
🌐 React Native library authors can adopt CNG in several ways. It depends on the complexity of their libraries. Here are a few scenarios:
- 无本地代码或配置副作用：没有本地代码或配置副作用的库，例如
react-native-blurhash，可以无缝集成到npx expo prebuild中。它们可以依赖 Node 模块解析，无需任何额外配置。 - 安装后无需额外设置的原生代码：具有原生代码的库通常可以通过 Expo 自动链接 自动安装和关联，该过程在原生应用构建之前执行。
- 额外的配置副作用和设置：需要额外配置副作用的库可以通过为其库创建 Expo 配置插件 来采用 CNG。这种方法使库的作者能够自动添加例如权限提示信息到 Info.plist，或在 Xcode 项目中注入目标。
- 依赖本地运行时钩子的库：依赖特定本地运行时钩子的库，例如通过
AppDelegate、MainActivity、MainApplication等拦截初始启动 URL，可以在 Expo 模块 API 中使用 生命周期监听器。这些生命周期监听器允许通过 Expo 自动链接应用这些运行时钩子，而无需修改这些标准的本地项目文件，从而无需配置插件。
许多复杂的库和服务已经通过 Expo Prebuild 支持 CNG，例如 MapBox、Sentry、Stripe 和 React Native Firebase。
🌐 Many complex libraries and services already support CNG via Expo Prebuild such as, MapBox, Sentry, Stripe, and React Native Firebase.
库作者采用 CNG 并不是使用 npx expo prebuild 的前提。如果库作者没有采用 CNG，开发者仍然可以通过创建本地 配置插件 来修改原生生成流程，从而使用 npx expo prebuild。这种灵活性使得 CNG 对 React Native 社区的所有开发者都可访问并带来好处。
🌐 Adopting CNG by library authors is not a preqrequisite for using npx expo prebuild. If a library author has not adopted CNG, developers can still use npx expo prebuild by creating local Config Plugins to modify the native generation pipeline. This flexibility makes CNG accessible and beneficial to all developers within the React Native community.
CNG 是否仅限于 React Native 项目？
不，CNG 是一种多功能模式，可以应用于任何原生项目。虽然 Expo Prebuild 是一个专门为 React Native 项目实现 CNG 的工具，但其概念本身并不限于该框架。
🌐 No, CNG is a versatile pattern that can be applied to any native project. While Expo Prebuild is a tool that implements CNG specifically for React Native projects, the concept itself is not limited to this framework.
社区如何使用压缩天然气（CNG）？
以下是一些社区示例，展示了将复杂的本地功能转换为简单配置文件的情况，这使开发者能够在不降低迭代速度的情况下构建更强大的应用：
🌐 Here are a few community examples of difficult native features converted into simple configuration files, which have allowed developers to build more powerful apps without compromising on iteration speed:
- iOS Safari 扩展：在这里，为 iOS 创建 Safari 扩展的过程——这一功能向来难以实现——被简化为几行 JSON 就可以完成。
- iMessage 贴纸应用：此 Expo 配置插件可以从 JSON 对象生成完整的 iMessage 贴纸应用。
- 跨平台端到端测试：配置原生应用以支持使用 Detox 进行端到端测试，只需一行代码。
- 整个 Firebase 套件：在这里，你可以看到完整的原生 Firebase 套件，从跨多个 IDE 的多步骤原生配置过程，到基本的 JSON 配置。
- 跨平台主屏幕小部件：这个 Expo 配置插件可以为 Android 和 iOS 生成主屏幕小部件。
- Apple App Clips：这个 Expo 配置插件将从多个步骤生成 Apple App Clip 的过程（涉及多个目标）简化为单行命令
["react-native-app-clip", { "name": "My App Clip" }]。
在任何时候，这些功能都可以轻松添加或删除，而不会产生任何副作用。CNG 允许开发者尝试复杂功能，并快速迭代，而无需担心长期的维护成本或项目中可能出现的孤立代码。
🌐 At any point, these features can be easily added and removed, without any side effects. CNG allows developers to experiment with complex features and iterate on them quickly without worrying about the long-term maintenance costs or potential orphaned code in their project.
CNG 能用于除 Android 和 iOS 之外的操作系统吗？
当然！CNG 是一个抽象概念，可以应用于任何操作系统。虽然 Expo Prebuild 官方为 Android 和 iOS 实现了 CNG，但它也为开发者提供了抽象的平台支持，以便为其他平台创建实现。
🌐 Absolutely! CNG is an abstract concept that can be applied to any operating system. Although Expo Prebuild officially implements CNG for Android and iOS, it also provides abstract platform support for developers to create implementations for additional platforms.
使用 Expo 是 CNG 的要求吗？
一点也不。CNG 是一个开放模式，任何社区都可以采用。我们以抽象的方式定义了这个模式，以帮助其他社区理解他们如何将 CNG 应用于自己的项目。
🌐 Not at all. CNG is an open pattern that can be adopted by any community. We've defined the pattern abstractly to help other communities understand how they can adopt CNG for their own projects.
CNG 与静态网站生成（SSG）等网页开发模式相比如何？
CNG 与 SSG 相似，都可以根据一组输入生成项目。然而，CNG 与 SSG 的输出不同。它生成的是原生运行时代码，而不是静态网站代码。这意味着原生项目是按需生成的，并且一旦原生项目被编译成原生应用，生成的源代码和配置就会被丢弃。
🌐 CNG shares similarities with SSG in that it generates a project from a set of inputs. However, CNG differs from SSG in its output. It generates native runtime code instead of static website code. This means the native project is generated on-demand, and the generated source code and configuration are discarded once the native project is compiled into a native app.
是否可以在现有的棕地项目中使用压缩天然气（CNG）？
CNG 的设计目的是持续管理原生项目的整体状态。因此，它并不适用于现有的棕地项目。然而，你可以使用 CNG 生成一个新的原生项目，然后将其集成到现有的棕地项目中。
🌐 CNG is designed to manage the entire state of a native project continuously. As a result, it's not intended for use with existing brownfield projects. However, you can use CNG to generate a new native project, which can then be integrated into an existing brownfield project.
预建
🌐 Prebuild
Expo Prebuild 简化了 CNG 的处理。以下是 Prebuild 解决的 React Native 开发周期中的一些问题：
🌐 Expo Prebuild streamlines CNG processing. Here are some issues in the React Native development cycle that are addressed by Prebuild:
Prebuild 如何帮助进行合理的项目升级？
构建本地代码需要熟悉平台的工具，这会导致一个陡峭的学习曲线。在跨平台开发中，由于涉及多个平台，这一挑战会加剧。如果必须在特定平台的本地代码中实现许多功能，跨平台工具也无济于事。
🌐 Building native code requires familiarity with the platform's tooling, creating a steep learning curve. This challenge intensifies in cross-platform development due to multiple platforms. Cross-platform tooling doesn't help if you must implement many features in platform-specific native code.
在引导一个原生应用时，初始代码和配置可能不太容易理解。然而，你不负责维护这些代码。最终，你需要理解这些代码，以便安全地升级你的应用。这个挑战常常导致开发者错误地升级应用，或者重新开始一个新应用，复制现有的源代码。
🌐 When bootstrapping a native app, there's initial code and configuration that you may not understand. Yet you are not responsible for maintaining it. Eventually, you'll need to understand this code to upgrade your app safely. This challenge often leads developers to upgrade incorrectly or start a new app, copying existing source code.
使用 Prebuild，升级更像是升级一个纯 JavaScript 应用。在你的 package.json 中提升版本号，重新生成本地项目，然后你就可以继续开发了。
Prebuild 如何简化跨平台配置？
跨平台配置，例如应用图标、名称、启动屏幕等，必须在原生代码中手动实现。这些实现通常在每个平台上都有很大差异。
🌐 Cross-platform configurations such as the app icon, name, splash screen, and so on must be implemented manually in native code. These implementations are often quite different for each platform.
使用 Prebuild 时，跨平台配置由配置插件层处理，开发者只需设置一个值，例如 "icon": "./icon.png"，就能完成所有图标的生成。
我如何使用 Prebuild 管理依赖的副作用？
许多复杂的原生包除了安装和自动链接之外，还需要额外的设置。例如，相机库需要在 Android 的 AndroidManifest.xml 和 iOS 的 Info.plist 中添加权限设置。这些额外的设置可以视为包的配置副作用。将所需的副作用代码粘贴到项目的原生文件中可能会导致难以解决的原生编译错误，而且这些代码现在也需要你来拥有和维护。
🌐 Many complex native packages require additional setup beyond installing and autolinking. For example, a camera library requires permission settings to be added AndroidManifest.xml for Android and Info.plist for iOS. This additional setup can be considered a configuration side effect of a package. Pasting the required side effect code into your project's native files can lead to difficult native compilation errors, and it's also code that you now own and maintain.
使用 Prebuild 库的作者，比任何人都更懂如何配置他们的库，可以创建一个可测试且版本化的脚本，称为 配置插件，用于自动添加库所需的配置副作用。这意味着库的副作用可以更加直观、强大且稳定。对于原生代码的副作用，我们还提供了 Android 生命周期监听器 和 AppDelegate 订阅者，它们在默认的 prebuild 模板 中是标准配备。
Prebuild 如何帮助处理孤立代码？
当你卸载一个软件包时，你必须确保已经移除了使该软件包正常工作的所有副作用。如果遗漏任何内容，就会导致无法追溯到任何特定软件包的孤立代码，这些代码会不断积累，使你的项目更难理解和维护。
🌐 When you uninstall a package, you have to be certain you removed all of the side effects required to make that package work. If you miss anything, it leads to orphaned code that you cannot trace back to any particular package, this code builds up and makes your project harder to understand and maintain.
使用 Prebuild 的唯一副作用是项目的 Expo 配置 (app.json) 中的 配置插件，当对应的 Node 模块被卸载时，它会抛出错误，这意味着孤立配置会少得多。
何时 Prebuild 可能不适合某个项目
以下是一些原因，说明 Expo Prebuild 可能不适合某个特定项目：
🌐 Here are some reasons Expo Prebuild might not be the right fit for a particular project:
平台兼容性
🌐 Platform compatibility
Prebuild 只能用于 Expo SDK 支持的原生平台。这意味着目前仅支持 Android 和 iOS。除了 Web 平台，它不需要 npx expo prebuild，因为 Web 使用的是浏览器而不是自定义的原生运行时。
🌐 Prebuild can only be used for native platforms that are supported by the Expo SDK. This means Android and iOS for the time being. Except for web, which doesn't require npx expo prebuild since it uses the browser instead of a custom native runtime.
直接进行更改比模块化和自动化更快
🌐 Making changes directly is quicker than modularizing and automating
所有原生更改都必须使用原生模块（使用 React Native 内置的原生模块 API 或 Expo 模块 API）和配置插件来添加。这意味着如果你想快速向项目中添加原生文件进行实验，那么你可能更适合先运行预构建（prebuild）并手动添加文件，然后再通过 monorepo 的方式将其整合回系统。我们计划通过为 Expo Autolinking 添加功能来加快这一过程，该功能可以在构建前找到原生目录之外的原生项目文件并进行链接。
🌐 All native changes must be added with native modules (using React Native's built-in Native Module APIs or the Expo Modules API) and config plugins. This means if you want to quickly add a native file to your project to experiment, then you may be better off running prebuild and adding the file manually, then working your way back into the system with a monorepo. We plan to speed this process up by adding functionality to Expo Autolinking that finds native project files outside of the native directories and links them before building.
如果你想修改配置，例如 gradle.properties 文件，你需要编写一个插件（示例）。这可以通过辅助插件库轻松自动化，但如果需要经常操作的话，速度会稍慢一些。
🌐 If you want to modify the configuration, such as the gradle.properties file, you'll have to write a plugin (example). This can be easily automated with helper plugin libraries, however, it is a bit slower if you need to do it often.
社区中的配置插件支持
🌐 Config plugin support in the community
并非所有的包都支持 Expo 预构建。如果你发现某个库在安装后需要额外的设置，并且尚未有配置插件，我们建议你提交一个拉取请求或问题，以便维护者了解此功能请求。
🌐 Not all packages support Expo Prebuild yet. If you find a library that requires extra setup after installation and doesn't yet have a config plugin, we recommend opening a pull request or an issue so that the maintainer is aware of the feature request.
许多包，例如 react-native-blurhash，除了由 自动链接 处理的内容外，不需要任何额外的本地配置，因此不需要配置插件。
🌐 Many packages, such as react-native-blurhash, don't require any additional native configuration beyond what is handled by autolinking and so no config plugin is required.
其他包，例如 react-native-ble-plx，确实需要额外的设置，因此在与 npx expo prebuild 一起使用时需要配置插件（在这种情况下，有一个名为 @config-plugins/react-native-ble-plx 的外部插件）。
🌐 Other packages, such as react-native-ble-plx, do require additional setup and therefore require a config plugin to be used with npx expo prebuild (in this case there's an external plugin called @config-plugins/react-native-ble-plx).
另外，我们也有一个用于非内置配置插件的仓库，它为尚未采用该系统的流行软件包提供插件。可以把它想象成 TypeScript 的 DefinitelyTyped。我们更希望软件包自己提供配置插件，但如果它们尚未采用该系统，社区可以使用仓库中列出的软件包。
🌐 Alternatively, we also have a repo for out-of-tree config plugins which provides plugins for popular packages that haven't adopted the system yet. Think of this like DefinitelyTyped for TypeScript. We prefer packages ship their own config plugin, but if they haven't adopted the system yet, the community can use the packages listed in the repo.