快速回答： 使用 expo-splash-screen 配合 配置插件 中的 app.json 或 app.config.js 当应用运行时 Expo （包括 dev clients 和 EAS builds）。调用 SplashScreen.preventAutoHideAsync() 中的 全局作用域，然后 SplashScreen.hideAsync() 在字体、认证和导航就绪时。在 原生 React Native CLI中，新项目优先使用 react-native-bootsplash ；维护旧应用时继续使用 react-native-splash-screen 直到迁移完成。保持 原生 splash 为静态，当首个真实屏幕可渲染时将其隐藏，并迁移 动态启动页 品牌展示到首个 React 屏幕。使用 Web 技术构建？ Capacitor 使用 @capacitor/splash-screen 遵循相同的就绪规则，并且 Capgo 无需商店构建即可发布 Web 层 Live Update。原生启动页资源仍需新的二进制文件。
在真机上点击应用图标，用户会看到一瞬间的白屏、拉伸的 Logo 或冻结的启动画面，直到有用内容准备好才消失。这段间隙正是 react native splash screen 配置旨在覆盖的部分：在 JavaScript 能渲染稳定首帧之前，显示原生启动 UI。
目录
- 为什么专业启动屏很重要
- 准备完美的启动屏资源
- 使用 Expo Go 和 Development Client 工作流实现
- 为 Bare React Native CLI 项目配置
- 带动画且高性能启动页的高级技巧
- React Native 与 Capacitor：启动屏与快速修复发布
- 常见 Splash Screen 问题排查
- 常见问题
为什么专业启动屏很重要
用户从主屏幕点开你的 App，在第一个 UI 出现前，启动过程会先显示一片空白白屏。在生产环境里，这看起来就是不稳定。即使 React Native 还在后台加载 JavaScript bundle 或恢复状态也没用，第一印象已经毁了。
在 React Native 中，启动屏是你的 App 控制的第一个原生界面。它覆盖了从进程启动到第一个可用的 React 渲染帧之间的交接。因此，它不仅是品牌素材，更是启动工具。时机把握得好，用户会看到一个稳定、像是刻意设计过的启动过程；隐藏得太早，用户就会在身份验证、导航或远程配置跟上之前，看到布局偏移、字体缺失，或者像死机的屏幕。
启动屏实际在做什么
生产环境的启动屏通常需要处理四个启动问题：
- 覆盖原生到 JS 的启动工作： 字体加载、持久化会话恢复、feature flag 读取和初始导航状态，都在争抢首帧。
- 避免视觉异常： 避免系统白屏闪烁、无样式文本，或根视图只挂载了一半。
- 让启动过程视觉一致： 背景色和 logo 可以与 App 外壳保持一致，让过渡显得可控。
- 强制启动决策： 团队必须在移除启动屏幕之前定义“就绪”的含义。
实战规则： 当第一个真实屏幕能干净地渲染时隐藏启动画面，而不是在任意延迟之后。
这也是 Expo 托管和裸 CLI 工作流开始分道扬镳的地方。在 Expo 托管项目中，启动画面配置主要是声明式的，主要的工程决策是根据应用就绪状态何时调用隐藏 API。在裸 React Native CLI 项目中，你需要自行处理 Android 和 iOS 上的更多原生设置，这提供了更多控制权，但也增加了引入启动闪烁、主题不匹配或平台特定回归问题的可能性。
这种权衡在实际项目中很重要。Expo 配置更快，更容易在不同环境中保持一致。当应用已经依赖自定义原生模块、自定义启动行为或对启动路径有更严格的控制时，裸项目通常是正确的选择。
将启动视为产品质量一部分的团队通常会将其与更广泛的 UX 工作一起审查，而不是将其视为孤立的原生任务。这与以下文章涵盖的理念相同 Capgo 的应用用户体验指南。如果你在权衡 React Native 对比 Capacitor 如果是全新项目，请阅读 React Native 与 Capacitor 对比 在确定启动工具链之前。Capacitor 团队在原生项目中配置启动画面，并使用 @capacitor/splash-screen 在应用初始化期间，如 Capacitor 应用初始化指南.
准备完美的启动屏资源
大多数启动画面 bug 源于设计文件，而非 code。如果基础资源有误，无论怎么调整 Android XML 或 iOS storyboard 都无济于事。
最稳妥的方法是将启动画面视为一个 布局系统，而非单张全屏图片。使用背景色加居中的 Logo 或插图。相比试图将一张细节丰富的海报式图片适配到所有设备，这种方式在长屏 Android 设备、iPhone、平板及横屏模式下更具可预测性。
编码前要准备什么
从设计提供的干净源文件开始。矢量格式最适合交付，即使最终导出的启动资源是 PNG。
使用此检查清单：
- 源素材： 保留 SVG、AI 或其他可编辑源格式的主 Logo 或标识，确保导出保持一致。
- 背景颜色： 预先确定确切的启动屏背景色，并确保它与首屏或应用外壳背景一致。
- 安全边距： 在 Logo 周围留出足够的空白，避免在非常规宽高比下被激进裁剪而破坏设计。
- 平台变体： 按工作流需要导出对应尺寸的图像，而不是在所有地方拉伸同一个文件。
- 深色模式检查： 如果你的应用支持深色界面，请确认 Logo 在所选背景上依然清晰可辨。
Expo 的指南在此很有用，因为它强调了启动资源现在是 build pipeline 的一部分，而非事后补救。其文档建议采用 1024×1024 的方形 PNG 作为应用图标，并指出 EAS Build 可以为使用 npx create-expo-app创建的项目生成所需尺寸，这表明资源生成已融入现代工具链，而非依赖手动重复。
常见资源错误
最常见的视觉问题通常是可以预见的：
| 问题 | 可能原因 | 更好的做法 |
|---|---|---|
| 模糊的 Logo | 从低分辨率位图导出 | 从矢量源重新导出 |
| 边缘被裁剪 | 素材离边界太近 | 增加安全边距 |
| 画面拉伸 | 全屏图片被强制适配多种宽高比 | 使用背景色配合居中图片 |
| 过渡不匹配 | 启动页背景与首屏不一致 | 统一启动页与 App 外壳颜色 |
Splash 图不应包含大量文字、微小细节或营销文案。启动页只显示一瞬间，而且要在严格的原生限制下渲染。
对于频繁发布视觉更新的团队，图片规范的重要性不仅限于启动页。同样的习惯也适用于交付 bundle 和二进制体积，这也是为什么像这样的指南 优化更新中的图片 在标准化资源导出时，这些内容值得复查。
实用的导出工作流
在实际项目中效果良好的配置如下：
- 设计一个居中构图 置于纯色背景上。
- 导出透明 Logo PNG 如果你的工作流支持单独设置背景色。
- 保持命名一致 跨平台保持命名一致，资源替换时就不用猜。
- 尽早在小屏和长屏模拟器上测试 在接入 Splash 生命周期之前。
- 资源变更后重新构建 因为启动资源常常留在原生缓存里。
这一点比预想的更重要。许多看起来像配置错误的启动页问题，其实只是原生资源过期了。
Expo 启动屏（expo-splash-screen)
如果你正在搜索 Expo 启动屏、 或 React Native Expo 启动屏），请从该 expo-splash-screen package 开始。它适用于 managed 和 prebuild 工作流，将启动资源保留在 config 中，并提供 JavaScript API，用于在 store 构建中控制可见性。
需要理解的关键行为很简单。 保持原生启动画面可见，直到首个有意义的 UI 帧准备就绪。 Expo 文档 preventAutoHideAsync() 以便配置的启动画面保持显示，直到你调用 hideAsync(). 调用 preventAutoHideAsync() 在全局作用域中，且不要 await，而不是在 hook 内部，否则启动画面可能会在 code 运行前自动隐藏。过早隐藏可能会在 iOS 和 Android 上短暂暴露空白屏幕。
加载期间保持显示启动画面 (Expo)
这是常见的 React Native 加载屏幕 模式：原生启动画面覆盖字体加载、持久化认证和远程配置，同时 React 返回 null。当 isReady 变为 true 时，调用 hideAsync()。可选 SplashScreen.setOptions() 调整隐藏时的淡出行为。请在 开发客户端, 预览，或 生产环境 构建中测试启动图资源；Expo 文档指出 Expo Go 并非原生启动图配置的权威环境。
以声明式方式配置原生启动画面
在 Expo 项目中，视觉部分通常位于 app.json, app.config.js，或 app.config.ts 下的 expo-splash-screen config 插件，正如 Expo 启动屏与应用图标指南.
典型的 app.json 配置如下：
{
"expo": {
"plugins": [
[
"expo-splash-screen",
{
"backgroundColor": "#111111",
"image": "./assets/splash-icon.png",
"imageWidth": 200
}
]
]
}
}具体字段可能因项目配置而异，但模式保持一致。你在 config 中定义原生启动外观，然后通过 JavaScript 控制可见性。
这里有几个实用的选择：
- 使用接近初始屏幕的背景色 让过渡更连贯。
- 保持图片简洁 因为启动界面不是放复杂视觉素材的地方。
- 避免人为的品牌展示延迟 即在应用已经就绪时，仍让用户停留在 Logo 上。
根据就绪状态而非时间隐藏 Splash
许多教程经常跑偏。它们使用 setTimeout，这种做法便于演示，但在生产环境中行不通。
请改用启动状态。常见的根级写法如下：
import { useCallback, useEffect, useState } from 'react';
import { View } from 'react-native';
import * as SplashScreen from 'expo-splash-screen';
SplashScreen.preventAutoHideAsync();
export default function App() {
const [isReady, setIsReady] = useState(false);
useEffect(() => {
async function prepare() {
try {
// Load fonts
// Restore auth state
// Read persisted settings
} finally {
setIsReady(true);
}
}
prepare();
}, []);
const onLayoutRootView = useCallback(async () => {
if (isReady) {
await SplashScreen.hideAsync();
}
}, [isReady]);
if (!isReady) {
return null;
}
return (
<View style={{ flex: 1 }} onLayout={onLayoutRootView}>
{/* Your real app UI */}
</View>
);
}有两个细节让这种模式更可靠。
首先， preventAutoHideAsync() 是在应用开始渲染有意义的 UI 之前调用的。其次，只有根视图准备好布局后才会执行隐藏，这降低了原生 Splash 与 React 树之间出现闪烁的几率。
别在异步任务开始收尾时就隐藏 Splash。要等依赖它的 UI 真正能渲染时再隐藏。
当启动过程包含登录态恢复、远程配置或字体加载时，这种区别最关键。如果你的首页依赖自定义字体和已登录状态，Splash 就应该覆盖这段空档。
以下是关于更广泛的 React Native 落地与启动生态的实用指南：
Expo Go 和开发构建中的预期表现
Expo 还带来一个额外的麻烦。你在独立构建中预期的启动屏行为，可能与在 Expo Go 中看到的并不一致。
这种不一致让很多团队感到困惑。你修改了资源或时序逻辑，在 Expo Go 中测试，然后断定配置有问题，而真正的问题其实是开发环境的行为与生产二进制文件不同。
请采用以下心智模型：
- Expo Go 适合快速迭代 但它并不是原生启动屏行为的最终权威。
- 开发客户端更接近真实情况 因为它们包含了你生成的原生项目。
- 独立构建是最终检查 用于验证启动时序、主题行为和资源的正确性。
如果启动屏仍然闪烁或停留过久，问题通常出在三者之一：隐藏得太早、渲染 null 在隐藏后停留过久，或在无法反映发布行为的环境中测试。
Bare React Native CLI 启动画面
原生 React Native 应用让你能直接控制启动行为。对于 新的原生 CLI 项目, react-native-bootsplash 是受维护的选项（2026 年前持续发布，并符合当前 React Native 支持策略）。许多生产环境应用仍在使用 react-native-splash-screen；除非你已集成，否则将其视为 遗留维护 。
动画启动画面（React Native 或 Expo）： iOS LaunchScreen.storyboard 保持静态。Android 12+ 可以短暂显示 动画矢量图标 在系统启动画面中，但 expo-splash-screen 大多数原生 CLI 配置仍然使用 静态 PNG 并将动效移至首个 React 屏幕（例如 Lottie）。在启动任务完成后隐藏原生启动屏，然后在那里进行动画。参见 Capacitor 应用中的动画性能 在另一个技术栈上保持同样的启动规范。
在 CLI 项目中，原生交接的目标不变：立即显示启动界面，等有意义的 UI 能渲染后再隐藏。
bare 项目中的 Android 配置
Android 的 splash 配置同时分布在几个地方：主题资源、drawable 资源、 AndroidManifest.xml，以及 MainActivity这种分散正是小错误造成明显闪烁的原因。
常规流程很简单：
- 为你支持的 Android 资源文件夹生成启动图资源。
- 定义包含正确背景色和启动图 drawable 的启动主题。
- 将该主题应用于以下路径的 launcher activity：
AndroidManifest.xml. - 在以下位置初始化启动页：
MainActivity. - 在完成阻塞首次渲染的启动任务后，通过 JavaScript 隐藏它。
一种简化的 MainActivity.kt 模式通常如下所示：
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// initialize splash handling here depending on the library
}该代码片段故意写得比较通用，因为具体的调用方式取决于所使用的库。原生集成点通常比较简单，错误往往出现在资源配置和主题过渡上。
以下是生产环境中常见的 Android 问题：
- 主题不匹配： 如果启动主题的背景色与 App 首屏不一致，用户在切换时会看到闪烁。
- 资源目录配置错误： Android 会拉伸或模糊预期密度文件夹中缺失的资源。
- 仅使用 Metro 测试： 原生资源变更通常需要 clean rebuild。Hot reload 无法验证启动行为。
- Android 12 启动规则： 较新的 Android 版本会优先应用其自身的启动画面行为，因此自定义配置需要遵守这些平台限制。
- 隐藏后 JS 响应缓慢： 如果 React 在根视图完成渲染前就隐藏了启动画面，用户看到的将是空白帧，而非平滑过渡。
最后一点比图片本身更重要。时序问题通常会被用户感知为性能问题。
Bare 项目中的 iOS 配置
在 iOS 上，重心在于 LaunchScreen.storyboard 外加一个小的原生钩子，位于 AppDelegate。平台期望启动画面是静态且轻量的。请将其视为首屏视觉结构的快照，而非一个迷你 onboarding 流程。
可靠的配置如下：
- 将资源添加到 Xcode 资源目录中。
- 配置
LaunchScreen.storyboard使用简单的约束。 - 保持布局静态。背景色、Logo 和安全间距通常就足够了。
- 在
AppDelegate. - 仅在应用完全准备好渲染后，再从 JavaScript 隐藏启动画面。
刚接触 iOS 的团队往往会在 storyboard 中过度设计。这通常会适得其反。复杂的约束、多层嵌套视图或尝试对启动屏幕进行动画处理，都会使配置更难维护，并更容易在不同设备尺寸上出错。
简单的启动屏幕是更安全的选择。
Bare CLI 让你更灵活地控制交接过程
这是 Expo 托管模式和裸 CLI 之间的关键区别。Expo 为你提供了快速获得正确默认值的路径。裸模式则让你完全负责原生启动流程。
当启动过程不仅仅是加载 bundle 时，这种权衡就变得很有用。具有身份验证恢复、加密存储读取、自定义原生 SDK 初始化或白标品牌规则的应用，通常需要额外的控制权。裸项目允许你将启动画面的时机与该工作对齐，而不是强制所有操作都通过更高层级的配置。
如果你计划在启动后加入动画过渡，iOS 上请保持原生启动屏为静态，Android 上也优先使用静态资源，除非你特意配置 Android 12 的动画图标。把动效移到第一个 React 屏幕里。这些性能取舍，和任何移动端启动路径中真正重要的点类似：首次绘制（first paint）期间做重活，代价很高。这 Capacitor 应用动画性能指南 介绍了另一技术栈中的同一原理，这些经验也能顺利迁移到 React Native。
Expo 托管 vs Bare CLI
实际比较的重点与其说是图片显示，不如说是启动复杂度落在哪里。
| 决策点 | Expo 托管 | 纯 CLI |
|---|---|---|
| 搭建速度 | 初始搭建更快 | 更多原生工作量 |
| 原生自定义 | 更受限 | 完全掌控 |
| 资源生成流程 | 更声明式 | 更手动 |
| 调试范围 | JS 配置加生成的原生层 | 直接的 Android 和 iOS 文件 |
| 最合适 | 追求速度和一致性的团队 | 需要深度原生控制的团队 |
如果应用已在 Expo 中且启动需求标准，留在那里通常能节省时间。如果启动路径依赖原生初始化顺序、自定义主题或平台特定的启动逻辑，裸 CLI 通常是更干净的长期选择。
两种工作流都能交付精致的启动页。区别在于启动 pipeline 归谁掌控：是你的 framework，还是你的团队。
带动画且高性能启动页的高级技巧
带动画的启动页只要配合启动 pipeline，就会显得精致；一旦干扰它，就会显得廉价。
这就是为什么我把动画当作增强层，而不是基础层。首要任务仍然是时机控制。如果 App 还没准备好，启动页就保持显示；如果 App 已就绪，过渡应迅速进入第一个可用界面。
动画应贴合启动实际情况
常见模式是让原生启动页保持简单，然后在启动后的第一个 React 屏幕播放轻量品牌动画。这比直接给真正的原生启动界面做动画更灵活。
对于这种衔接，Lottie 是个实用选择，因为它无需在首屏构建笨重的自定义动画栈就能实现动态效果。关键在于执行顺序：
- 关键启动工作期间，原生启动页保持可见。
- React 挂载第一个真实界面或受控的过渡界面。
- 可选动画只有在不会让交互阻塞超过必要时间时才播放。
行不通的是旧有的 setTimeout(2000) 模式。在快速设备上，这会让 App 无故等待；在慢速设备上，它往往只是用一种加载状态替换另一种。
把启动当作编排
更好的心智模型是 启动编排。Splash screen 应覆盖应用展示有意义内容前必须完成的确切任务。
通常包括以下几项的组合：
- Auth 初始化： 恢复会话，或决定是否跳转到登录页。
- 关键存储读取： 主题、语言区域、onboarding 状态，以及上次已知的关键偏好。
- 字体就绪： 尤其当首屏依赖自定义字体来保证布局稳定时。
- 控制 UI 展示的远程配置： 仅当首屏在没有它时无法安全渲染才使用。
还有一个很多教程都会忽略的细节：Splash screen 的行为会因环境而异。关于 Expo 在开发和生产环境中处理 splash 的讨论 指出 Expo Go 中的行为可能与 standalone builds 不同，而且一旦你接管手动控制，自动可见性管理也会改变。这也是基于延迟的示例很快过时的原因：它们掩盖了真实的启动流程，而不是与之对齐。
启动页不应用来伪造速度，而应防止用户看到未完成的 UI。
如果你正在混合技术栈中添加动效，或者在评估整体渲染性能， 这份 Capacitor 应用动画性能指南 会提供有用的背景，因为同样的原则也适用：保持启动工作精简，避免不必要的阻塞，让动画提升响应性，而不是与之竞争。
对于在完整二进制发布之外发布视觉修复的团队，有一个实用提醒：像 Capgo 这样的平台可以处理 Capacitor 和 Electron 应用的 JavaScript、CSS、文案、配置和资源更新，但 React Native 中的原生 splash 变更仍属于原生构建流程，因为真正的 splash screen 会在 JavaScript 应用运行之前出现。
React Native 与 Capacitor：启动屏与快速修复发布
如果你读到这里，是因为你正在开发新应用，或者你的团队已有 React、Vue、Angular 或 Svelte 的 Web 应用，那么值得对比一下启动屏在 Capacitor中如何工作。原生启动页的概念相同，但对 Web 团队来说，日常工作流更简单。
Capacitor 中的启动屏
Capacitor 应用使用官方的 @capacitor/splash-screen 插件。你只需在 capacitor.config.ts 中配置一次，并在应用就绪时从你的 Web code 中隐藏它：
// capacitor.config.ts
import type { CapacitorConfig } from '@capacitor/cli'
const config: CapacitorConfig = {
appId: 'com.example.app',
appName: 'Example',
webDir: 'dist',
plugins: {
SplashScreen: {
launchAutoHide: false,
backgroundColor: '#ffffff',
},
},
}
export default config// main.ts, after your router, fonts, and auth are ready
import { SplashScreen } from '@capacitor/splash-screen'
await SplashScreen.hide()本指南中的“就绪规则”完全一致：保持原生启动屏静态，在首个真实界面可以绘制时将其隐藏，并在应用的首个页面中运行任何动画。对于原生资源， @capacitor/assets 会根据你的源图标和启动图生成 Android 和 iOS 的图标及启动图文件（例如 icon-only.png 以及 splash.png 放在一个 assets 文件夹中）。分步流程见 Capacitor 应用初始化.
为什么 Web 团队选择 Capacitor 而非 React Native
- 复用你现有的应用： Capacitor 将现有的 Web 应用封装在原生外壳中，因此你的组件、CSS 和构建工具链可以继续使用。React Native 则需要使用 React Native 组件重写 UI。
- 支持任意框架： React、Vue、Angular、Svelte 或纯 JavaScript 均可使用。你不必局限于 React。
- 需要时访问原生功能： 官方和社区插件涵盖相机、推送、生物识别等功能，你还可以编写自己的 Swift 或 Kotlin 插件。
- 应用层的 Live Update： 配合 Capgo，你可以在用户下次启动时推送 JavaScript、HTML、CSS 和资源修复，支持渠道、分阶段发布和一键回滚，无需在每次 Web 层变更时等待商店审核。原生变更（包括原生启动屏本身）仍需通过商店发布。参见 Capgo Live Updates 文档.
如需全面对比性能、工具链及团队契合度，请阅读 React Native 与 Capacitor 对比。如果你目前正在使用 Expo 并考虑迁移， Expo 的替代方案 会逐一介绍各种方案。
常见 Splash Screen 问题排查
大多数启动屏问题都集中在少数几类常见原因上。只要把以下几类问题区分开，修复就会容易得多： 资源问题, 时机问题，以及 原生集成问题.
近期 React Native 指南中的社区实践已趋于一致，其核心流程为：添加库、配置原生启动资源、在 show 启动期间调用，并在应用就绪后隐藏。Android 的配置通常涉及 MainActivity 以及 XML 或 drawable 资源，而 iOS 则侧重于 LaunchScreen.storyboard 以及 AppDelegate。同一篇综述还指出，Expo 建议使用正方形的 1024×1024 PNG 作为应用图标，且 EAS Build 可为使用 npx create-expo-app，正如 这篇 React Native 启动屏指南创建的项目生成所需尺寸.
启动图拉伸或模糊
现象： Logo 看起来模糊、被裁剪或缩放比例异常。
原因： 基础图片未正确导出，或者布局依赖于无法良好适配的全屏位图。
修复： 将海报风格的艺术图替换为纯色背景上的居中 Logo。从原始设计源重新导出，重新生成不同密度的资源，并验证 Android drawables 或 iOS asset catalog 中包含预期的文件。
启动页隐藏后出现白屏
现象： 原生启动页消失后，用户在首个界面加载前会看到空白框架。
原因： 您的应用在根 UI 渲染出有意义的内容之前就隐藏了启动页。
修复： 启动页的关闭应取决于就绪状态，而不是经过的时间。在 Expo 中，这通常意味着在根视图完成布局前保持启动页显示。在 bare 项目中，采用同样的模式，并确保首个渲染的屏幕不会立刻被更多异步任务阻塞。
某个平台缺少启动页
现象： Android 上显示，iOS 上不显示，或者反过来。
原因： 其中一端原生配置不完整。常见原因是漏掉 storyboard 引用、主题关联问题，或资源未添加到正确的 target。
修复： 逐一检查平台相关文件。在 Android 上，检查启动主题和资源引用。在 iOS 上，确认 LaunchScreen.storyboardasset catalog 成员关系，以及 Xcode 中的 app target 设置。
添加 Splash 配置后构建失败
现象： 添加库或修改 Splash 文件后，App 无法编译。
原因： Native 项目文件和生成的配置可能会不同步，尤其是在插件或资源变更后。
修复： 清理构建，必要时重新安装依赖，并完整重新构建 Native 项目。如果你在 Expo 中使用生成的 Native 层，请谨慎重新生成并验证插件配置。如果你使用的是 Bare App，请检查 MainActivity, AppDelegate资源名称，以及 plist 或 manifest 的任何修改是否有细微不一致。
最高效的团队会把 Splash Screen 视为发布工程的一部分，而不是一次性的视觉任务。当启动资源、UI 文案或 App Shell 行为需要在上线后快速更改时，这一点尤其重要。 Capgo 为 Capacitor 和 Electron 团队提供了一种方式，可在下次启动时发布 JavaScript、CSS、文案、配置和资源修复，并带有发布控制和回滚支持；当问题出在 App 层而非 Native 启动屏本身时，这非常有用。
常见问题
如何在 Expo 中添加启动画面（expo splash screen）？
添加 expo-splash-screen 插件来 app.json 或 app.config.js，设置 backgroundColor 以及 image，重新构建原生二进制文件，调用 preventAutoHideAsync() 在全局作用域中，并且 hideAsync() 当第一个屏幕准备就绪时。请在开发客户端或生产构建中验证，而不仅仅是 Expo Go。
如何在 React Native 应用加载期间保持启动画面可见？
在 Expo 中， preventAutoHideAsync() 加上返回 null 直到异步工作完成，然后 hideAsync()中。由于 react-native-splash-screen，调用 SplashScreen.show(this) 在 Android 中 MainActivity 或 [RNSplashScreen show] 在 iOS 中 AppDelegate，然后 SplashScreen.hide() 在就绪时从 JavaScript。使用 react-native-bootsplash，按平台原生初始化，然后调用 BootSplash.hide() ，在相同的就绪检查之后。
react-native-splash-screen 和 react-native-bootsplash 有什么区别？
Bootsplash 正在积极维护，并提供启动资源生成器。 react-native-splash-screen 在旧仓库中仍很常见，但维护速度较慢；对于新的裸 CLI 应用，建议优先使用 bootsplash。
如何在没有 Expo 的裸 React Native 中设置启动画面？
安装 react-native-bootsplash，生成资源，调用 RNBootSplash.init(this, R.style.BootTheme) 在 Android 上，或 RNBootSplash.initWithStoryboard("BootSplash", rootView: rootView) 在 iOS 上，然后 BootSplash.hide() 在启动完成时从 JS 调用。旧项目可以使用 SplashScreen.show(this) / [RNSplashScreen show] 配合 SplashScreen.hide() 替代。原生资源变更后需重新构建。
React Native 或 Expo 中可以使用动画启动屏吗？
当 iOS，请保持启动屏为静态。在 Android 12+，系统启动屏可以使用简短的动画图标，但大多数团队会保持 expo-splash-screen 或将 bootsplash 资源保持静态，准备就绪后隐藏，再在 React 中做动画（例如 Lottie）。不要依赖 setTimeout 来伪造加载时间。
React Native 与 Capacitor 的启动屏设置有何不同？
React Native 使用 expo-splash-screen 或在 JS 运行前使用 bare CLI 库。Capacitor 则使用原生启动屏加上 @capacitor/splash-screen 在 WebView 栈中。请参阅 React Native 与 Capacitor 对比 以及 Capacitor 应用初始化.
使用 Capgo 更快发布你的 Capacitor 应用
正在使用 Capacitor 构建应用，或计划将 Web 应用迁移到移动端？ 创建免费的 Capgo 账户 几分钟内推送你的首个 live update。Capgo 会在下次启动时将 JavaScript、CSS 和资源修复推送给用户，支持分阶段发布和即时回滚，因此应用层的 bug 无需等待商店审核。
继续阅读 React Native 启动屏（Expo 和 bare CLI）
如果你正在使用 本指南 来规划原生媒体和界面行为，并将其与 使用 @capgo/capacitor-live-activities 用于使用 @capgo/capacitor-live-activities 时的原生能力， @capgo/capacitor-live-activities 在 @capgo/capacitor-live-activities 中的实现细节， 使用 @capgo/capacitor-video-player 用于使用 @capgo/capacitor-video-player 时的原生能力， @capgo/capacitor-video-player 在 @capgo/capacitor-video-player 中的实现细节，以及 使用 @capgo/capacitor-native-navigation 用于使用 @capgo/capacitor-native-navigation. 时的原生能力
