Se tocchi l'icona del tuo app su un dispositivo reale, per un attimo l'utente riceve un flash bianco, un logo allungato o uno schermo di avvio bloccato che scompare prima che qualcosa di utile sia pronto. È di solito il momento in cui un'app React Native smette di sentirsi di livello di produzione.
Un buon schermo di avvio in React Native risolve più che la branding. Copre il divario tra l'avvio nativo e il primo frame React significativo. Inoltre, ti costringe a pensare chiaramente all'ordine di avvio, alla preparazione degli asset e alla differenza tra cosa accade in Expo Go, un client di sviluppo, e un build di negozio reale. Se sbagli il timing, gli utenti vedono le crepe immediatamente.
Tavola dei contenuti
- Perché un schermo di avvio professionale conta
- Preparazione di Asset di Splash Screen Perfetti
- Implementare con il Flusso di Lavoro di Expo Go e Client di sviluppo
- Configurazione per progetti React Native Bare CLI
- Tecniche avanzate per schermate di avvio animate e performanti
- Risolvere problemi comuni di schermate di avvio
Why a Professional Splash Screen Matters
Un utente tocca il tuo app dalla schermata iniziale e la sequenza di avvio mostra un riquadro bianco vuoto prima che il primo UI venga visualizzato. In produzione, questo si legge come instabilità. Non importa che React Native stia ancora caricando il bundle JavaScript o ripristinando lo stato in background. La prima impressione è già sbagliata.
In React Native, lo schermo di caricamento è la prima superficie nativa che il tuo app controlla. Copre il passaggio tra l'avvio del processo e il primo frame React visualizzato. Ciò lo rende uno strumento di avvio, non solo un bene di marchio. Se lo sincronizzi bene, gli utenti vedono un avvio stabile che sembra intenzionale. Se lo nascondi troppo presto, vedono scostamenti di layout, caratteri mancanti o uno schermo morto mentre l'autenticazione, la navigazione o la configurazione remota si aggiorna.
Cosa sta realmente facendo la schermata di attesa
Un splash screen di produzione solitamente deve gestire quattro preoccupazioni di avvio:
- Coprire il lavoro di avvio nativo-JS: caricamento di caratteri, ripristino della sessione persistente, lettura di flag di feature e stato di navigazione iniziale competono per il primo frame.
- Prevenire i glitch visivi: evita flash di bianco del sistema, testo non stilizzato o una root view parzialmente montata.
- Conserva la visualizzazione di lancio coerente: the background color and logo can match your app shell so the transition feels controlled.
- Forza le decisioni di avvio: le squadre devono definire cosa significa “pronto” prima di rimuovere lo schermo di lancio.
Regola pratica: Hide the splash when the first real screen can render cleanly, not after an arbitrary delay.
This is also where the Expo-managed and bare CLI workflows start to diverge. In Expo-managed projects, splash setup is mostly declarative, and the main engineering decision is when to call the hide API based on app readiness. In bare React Native CLI projects, you own more native setup on Android and iOS, which gives you more control but also more ways to introduce launch flicker, theme mismatches, or platform-specific regressions.
Questa scelta è importante nei progetti reali. Expo è più veloce da configurare e più facile da mantenere coerente all'interno di diversi ambienti. I progetti nudi sono spesso la scelta giusta quando l'app già dipende da moduli nativi personalizzati, da comportamenti di lancio personalizzati o da un controllo più stretto sulla via di avvio.
Gli team che trattano il lancio come parte della qualità del prodotto lo valutano di solito insieme al lavoro di UX più ampio, non come un compito nativo isolato. È la stessa mentalità trattata nel guida di Capgo all'esperienza utente dell'appSe stai anche valutando la pila React Native più ampia per un nuovo progetto o una migrazione, soluzioni Nerdify per le app React Native fornisce un'overview produttiva utile.
Preparazione di Asset di Splash Perfetti
La maggior parte dei bug di splash screen inizia nei file di progettazione, non code. Se l'asset base è sbagliato, nessuna quantità di pulizia di XML Android o storyboard iOS può salvarlo.
L'approccio più sicuro è trattare la splash come un sistema di layout, non un'immagine a schermo intero unica. Utilizza un colore di sfondo più un logo o un'illustrazione centrata. Questo scala in modo più prevedibile su dispositivi Android alti, iPhone, tablet e orientamenti di dispositivo più ampi rispetto a provare a inserire un'immagine di stile poster dettagliato in ogni parte.
Cosa preparare prima di codificare
Inizia con un file di origine pulito dal design. Il vettore è ideale per la consegna, anche se l'asset di lancio esportato è un PNG.
Utilizza questa checklist:
- Artwork di origine: Mantieni un logo o marchio master in formato SVG, AI o un'altra fonte editabile per garantire la coerenza delle esportazioni.
- Colore di sfondo: Define the exact splash background color up front and make sure it matches the first screen or app shell background.
- Marginali sicuri: Lascia abbastanza spazio vuoto intorno al logo affinché la tagliatura aggressiva su rapporti di aspetto insoliti non tagli nel design.
- Varianti di piattaforma: Esporta le dimensioni dell'immagine che il tuo workflow richiede, anziché allungare un file in tutti i luoghi.
- Recensione del dark mode: Se il tuo app supporta superfici scure, conferma che il logo legge ancora chiaramente contro il background scelto.
Expo’s guidance is useful here because it reinforces that launch assets are now part of the build pipeline, not an afterthought. Its docs recommend a immagine a 1024×1024 in formato PNG per icone dell'app e notano che EAS Build può generare le dimensioni richieste per i progetti creati con npx create-expo-appche mostra come la generazione di asset sia entrata nel tooling moderno piuttosto che nella ripetizione manuale.
Error comuni nell'asset
I più comuni errori visivi sono prevedibili:
| Problema | Causa probabile | Approccio migliore |
|---|---|---|
| Logo sfocato | Esportato da una raster di bassa risoluzione | Rieporta da una fonte vettoriale |
| Corna tagliate | L'arte è stata collocata troppo vicino ai bordi | Aumenta il padding di sicurezza |
| Stiramento | Immagine a schermo forzata in molti rapporti di aspetto | Usa colore di sfondo con immagine centrata |
| Transizione non allineata | Sfondo di splash diverso dalla prima schermata | Allinea colori di lancio e shell dell'app |
A splash image shouldn’t carry dense text, tiny details, or marketing copy. Launch screens are viewed briefly and rendered under tight native constraints.
For teams shipping frequent visual updates, image discipline matters beyond launch. The same habits apply to delivery bundles and binary size, which is why guides like ottimizzare le immagini per gli aggiornamenti sono da rivedere quando si standardizzano le esportazioni di asset.
Un flusso di lavoro di esportazione pratico
Un setup che funziona bene nei progetti reali assomiglia a questo:
- Progetta una composizione centrata On un fondo piano.
- Esporta un logo PNG trasparente. Se il tuo workflow supporta un colore di sfondo separato.
- Tieni coerente il nome. così che gli scambi di asset non diventino un problema.
- Testa su simulatori piccoli e alti presto. prima di collegare la vita del splash screen.
- Riavvia dopo le modifiche agli asset. perché i risorse di avvio spesso si trovano in cache native.
Questo ultimo punto conta più di quanto si pensi. Molte problematiche relative alla schermata che sembrano essere bug di configurazione sono solo asset native obsoleti.
Implementare con il Flusso di Lavoro di Expo Go e Client di sviluppo
Se stai utilizzando Expo, inizia con expo-splash-screen. It fits the managed workflow, keeps most configuration declarative, and gives you explicit control over when the splash should leave.
Il comportamento chiave da comprendere è semplice. Keep the native splash visible until the first meaningful UI frame is ready. Expo's SplashScreen API supporta esattamente quel modello con preventAutoHideAsync() __CAPGO_KEEP_0__ e hideAsync() una volta terminato il caricamento critico, e Expo avverte che nascondere troppo presto può brevemente esporre uno schermo vuoto in entrambe le versioni iOS e Android, come documentato nel Schermo di benvenuto Expo API.
Configure the native splash declaratively
In un progetto Expo, l'aspetto visivo solitamente vive in app.json o app.config.js.
A un tipico app.json setup assomiglia questo:
{
"expo": {
"plugins": [
[
"expo-splash-screen",
{
"backgroundColor": "#111111",
"image": "./assets/splash-icon.png",
"imageWidth": 200
}
]
]
}
}I campi esatti possono variare a seconda della configurazione del progetto, ma il pattern rimane lo stesso. Definisci l'aspetto di lancio nativo nella configurazione, quindi controlla la visibilità da JavaScript.
A poche scelte pratiche contano qui:
- Usa un colore di sfondo vicino alla schermata iniziale perché la transizione sembra continua.
- Tieni l'immagine semplice perché le superfici di lancio non sono il posto per l'arte densa.
- Evita i "ritardi di branding" finti che tengono gli utenti su un logo quando l'app è già pronta.
Nascondi lo splash in base alla prontezza, non al tempo
Molti tutorial spesso si allontanano dal percorso. Usano setTimeoutche è facile da dimostrare e sbagliato per la produzione.
Usa lo stato di avvio al posto suo. Un modello di base comune ha questo aspetto:
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>
);
}Due dettagli rendono questo modello affidabile.
Primo, preventAutoHideAsync() si chiama prima che l'app inizi a renderizzare l'interfaccia utente significativa. Secondo, il nascondere avviene solo dopo che la vista radice è pronta per disporre gli elementi, il che riduce la possibilità di un lampo tra la schermata nativa e l'albero React.
Don’t hide the splash when your async work starts finishing. Hide it when the UI that depends on that work can actually render.
That distinction matters most when startup includes auth restoration, remote configuration, or font loading. If your home screen depends on custom fonts and a signed-in state, the splash should cover that gap.
Un utile walkthrough dell'ecosistema React Native più ampio e dell'avvio è riportato di seguito:
Cosa aspettarsi in Expo Go e build di sviluppo
Expo adds one extra wrinkle. The splash behavior you expect in a standalone build may not match what you see in Expo Go.
Questa dissonanza confonde molti team. Cambi la logica o il tempo degli asset, testa in Expo Go e conclude che la configurazione è rotta quando il problema reale è che l'ambiente di sviluppo non si comporta come un binario di produzione.
Usa questo modello mentale:
- Expo Go è comodo per l'iterazione but it isn’t the final authority on native splash behavior.
- Il client di sviluppo è più vicino alla realtà poiché include il tuo progetto nativo generato.
- Il build autonomo è il controllo finale for launch timing, theme behavior, and asset correctness.
Se il tuo splash continua a lampeggiare o a rimanere, il bug è di solito uno dei tre seguenti: nascondere troppo presto, rendering null per troppo tempo dopo nascondere, o testare in un ambiente che non riflette il comportamento di rilascio.
Configurazione per Progetti React Native Bare CLI
Un'app React Native Bare ti dà il controllo diretto sul comportamento di lancio, utile quando lo schermo di benvenuto deve corrispondere al lavoro di avvio reale invece di mostrare un logo per un ritardo fissato. Quel controllo comporta la responsabilità nativa. Devi collegare correttamente Android e iOS, ricostruire spesso e testare il passaggio tra l'interfaccia di lancio nativa e la prima schermata React su dispositivi reali.
In CLI progetti, consiglio di solito react-native-bootsplash for new work. It fits current React Native projects better than older splash libraries, and the native setup is easier to reason about during upgrades. Older apps still ship with react-native-splash-screen, quindi incontrerai sicuramente durante il lavoro di manutenzione, ma per una configurazione fresca lo scopo rimane lo stesso. Mostra una superficie di avvio nativa immediatamente, poi nascondila solo dopo che l'app può rendere una UI significativa.
Configurazione Android in un progetto nudo
Android splash setup lives in a few places at once: theme resources, drawables, AndroidManifest.xmle MainActivity. Quel divario è il motivo per cui piccoli errori creano lampi visibili.
Il flusso usuale è lineare:
- Genera gli asset di schermata per le cartelle di risorse Android che supporti.
- Definisci un tema di avvio con il colore di sfondo corretto e lo schermata disegnabile.
- Applica quel tema all'attività di lancio in
AndroidManifest.xml. - Inizializza la schermata di avvio in
MainActivity. - Nascondilo dopo le attività di avvio che bloccano la prima renderizzazione sono terminate.
A un modello semplificato MainActivity.kt un modello semplificato spesso assomiglia a questo:
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// initialize splash handling here depending on the library
}Quel frammento è intenzionalmente generico perché la chiamata esatta dipende dalla libreria. Il punto di integrazione nativo è di solito la parte facile. Gli errori tendono a venire da risorse e transizioni di tema.
Ecco gli errori Android che si verificano in produzione:
- Mancanza di tema: Se il tema di avvio utilizza un colore di sfondo diverso dalla prima schermata dell'app, gli utenti vedono un lampo durante il passaggio di mano.
- Raccolte di asset errate: Android allungherà o sfocerà gli asset che mancano dalle cartelle di densità previste.
- Test con Metro solo: Native resource changes usually need a clean rebuild. Hot reload will not validate launch behavior.
- Regole di avvio per Android 12: Nuove versioni di Android applicano il loro comportamento di splash prima, quindi i settaggi personalizzati devono rispettare quelle restrizioni del sistema.
- Slow JS dopo nascondere: Se React nasconde lo splash prima che la vista radice possa dipingere, gli utenti ottengono un riquadro vuoto invece di una transizione liscia.
Quel punto ultimo conta più dell'immagine stessa. I problemi di timing vengono spesso percepiti come problemi di prestazioni.
Configurazione iOS in un progetto nudo
Sul iOS, il centro di gravità è LaunchScreen.storyboard più un piccolo hook nativo in AppDelegate. La piattaforma aspetta che lo schermo di lancio sia statico e leggero. Trattalo come un snapshot della struttura visiva della prima schermata, non come un mini flusso di onboarding.
Il setup affidabile assomiglia a questo:
- Aggiungi risorse al catalogo di asset di Xcode.
- Configura
LaunchScreen.storyboardcon vincoli semplici. - Tieni la disposizione statica. Colore di sfondo, logo e spaziature sicure sono abbastanza spesso sufficienti.
- Aggiungi il chiamata di avvio nativo della libreria in
AppDelegate. - Nascondi lo splash solo dal JavaScript dopo che l'app è completamente pronta per renderizzare.
Teams new to iOS often overbuild the storyboard. That usually backfires. Complex constraints, multiple nested views, or attempts to animate the launch screen make the setup harder to maintain and easier to break across device sizes.
A plain launch screen is the safer choice.
Un CLI nudo ti dà più controllo sulla consegna delle mani
Questa è la differenza chiave tra Expo-gestito e CLI nudo. Expo ti offre una via più veloce per un default corretto. CLI nudo ti dà la piena responsabilità del flusso di avvio nativo.
That trade-off becomes useful when startup is doing more than loading a bundle. Apps with auth restoration, encrypted storage reads, custom native SDK initialization, or white-label branding rules often need the extra control. Bare projects let you align the splash timing with that work instead of forcing everything through higher-level configuration.
Se hai in programma di aggiungere una transizione animata dopo l'avvio, mantieni lo splash nativo statico e sposta la motilità nella prima schermata React. I trade-off di prestazioni sono simili a quelli che contano in qualsiasi percorso di avvio mobile. Lavoro pesante durante la prima pittura è costoso. Questo guida alla prestazione dell'animazione nelle app Capacitor copre lo stesso principio da un'altra pila, e la lezione si trasferisce pulitamente a React Native.
CLI gestito da Expo contro CLI nudo
La comparazione pratica è meno legata alla visualizzazione dell'immagine e più alla complessità della fase di avvio.
| Osservatorio di decisione | Gestito da Expo | Setup bare CLI |
|---|---|---|
| Velocità di setup | Setup iniziale più veloce | Piu' lavoro nativo |
| Personalizzazione nativa | Piu' vincolato | Controllo completo |
| Flusso di generazione di asset | Piu' dichiarativo | Più manuale |
| Superficie di debug | Configurazione JS più layer nativo generato | File Android e iOS diretti |
| Adatto | Team ottimizzati per velocità e consistenza | Team necessitano controllo nativo profondo |
Se l'app è già in Expo e i requisiti di avvio sono standard, rimanere lì salva spesso tempo. Se il percorso di avvio dipende dall'ordine di inizializzazione nativa, temi personalizzati o logica di avvio specifica della piattaforma, CLI è spesso la scelta a lungo termine più pulita.
Entrambe le modalità possono distribuire uno schermo di benvenuto finito. La differenza è chi possiede la pipeline di lancio, il tuo framework o il tuo team.
Tecniche avanzate per schermi di avvio animati e performanti
Gli schermi di avvio animati sembrano lisci quando rispettano la pipeline di avvio. Sembrano economici quando distruggono la pipeline.
Per questo motivo trattare l'animazione come un layer di miglioramento, non la base. Il primo compito è ancora il timing. Se l'app non è pronta, lo schermo di avvio rimane. Se l'app è pronta, la transizione dovrebbe muoversi velocemente nello schermo utile più presto.
La animazione dovrebbe seguire la realtà di avvio.
Un modello comune è mantenere la schermata di avvio nativa semplice, quindi eseguire un'animazione leggera personalizzata nella prima schermata di React dopo l'avvio. Ciò ti dà più flessibilità rispetto a provare a animare la superficie di avvio nativa vera e propria.
Lottie è una scelta pratica per questo tipo di handoff perché può fornire movimento senza costruire un stack di animazione personalizzata pesante nella prima schermata. La parte importante è la sequenziazione:
- Native splash remains visible during critical startup work.
- React monta la prima schermata reale o una transizione controllata.
- L'animazione facoltativa gioca solo se non blocca l'interazione per più tempo del necessario.
Cosa non funziona è il vecchio setTimeout(2000) modello. Su un dispositivo veloce, ciò fa attendere l'app senza motivo. Su un dispositivo lento, spesso sostituisce uno stato di caricamento con un altro.
Tratta l'avvio come orchestrazione
Un modello mentale migliore è l'orchestrazione di avvio. La schermata di avvio dovrebbe coprire le esatte attività che devono completarsi prima che l'app possa mostrare contenuto significativo.
Di solito include una miscela di:
- Autenticazione iniziale: Ripristino di una sessione o decisione di reindirizzare al login.
- Lettura di archiviazione essenziale: Tema, lingua, stato di onboarding e preferenze critiche note.
- Prontezza dei caratteri: Especially if the first screen depends on custom typography for layout stability.
- Configurazione remota che regola l'interfaccia utente: Only if the first screen cannot safely render without it.
Esiste un altro aspetto che molti tutorial trascurano. Il comportamento della schermata di caricamento cambia a seconda dell'ambiente. La discussion of Expo splash handling in development and production sottolinea che il comportamento potrebbe non apparire lo stesso in Expo Go rispetto a edizioni standalone, e che la gestione automatica della visibilità cambia non appena prendi il controllo manuale. È una delle ragioni per cui gli esempi basati sulla ritardata età male. Nascondono la sequenza di avvio reale anziché allinearsi con essa.
A launch screen shouldn’t be used to fake speed. It should be used to prevent users from seeing unfinished UI.
Se stai aggiungendo movimento in una pila ibrida o valutando prestazioni di rendering più ampie, questa guida alla prestazione dell'animazione nei Capacitor app è un contesto utile perché la stessa disciplina si applica. Mantenere il lavoro di avvio sottile, evitare bloccaggi non necessari e lasciare che l'animazione supporti la risposta invece di competere con essa.
Un nota pratica per i team che stanno inviando correzioni visive fuori rilasci binari completi: le piattaforme come Capgo gestiscono aggiornamenti JavaScript, CSS, copia, configurazione e asset per Capacitor e app Electron, ma le modifiche alla schermata di lancio native in React Native ancora appartengono al flusso di pipeline di costruzione nativa perché la schermata di lancio vera appare prima che l'app JavaScript sia in esecuzione.
Risolvere Problemi Comuni della Schermata di Lancio
Most splash problems fall into a small set of repeat offenders. The fix gets easier once you separate problemi di asset, problemi di timing, e problemi di integrazione nativa.
Community patterns across recent React Native guides have converged on the stessa sequenza di base: aggiungi la libreria, configura gli asset di lancio nativi, chiama show Durante l'avvio, e nascondi una volta che l'app è pronta. Le impostazioni Android sono comuni e MainActivity e risorse XML o drawable, mentre iOS si concentra su LaunchScreen.storyboard e AppDelegateLa stessa nota di riepilogo segnala che Expo raccomanda un rettangolo 1024×1024 PNG per icone dell'app e che EAS Build può generare le dimensioni richieste per i progetti creati con npx create-expo-app, come riassunto in Guida alla schermata di avvio di React Native.
Immagine di schermata allungata o sfocata
Sintomo: La logo sembra morbido, reciso o scalato in modo strano.
La causa: L'immagine di base non è stata esportata correttamente, o la disposizione dipende da un raster a schermo intero che non si adatta bene.
Fix: Sostituisci l'arte di poster con un logo centrato su un fondo piatto. Ri-esporta dalla fonte di design originale, rigenera gli asset specifici per la densità e verifica che i tuoi disegni Android o il catalogo di asset iOS contengano i file desiderati.
La schermata bianca dopo il splash nasconde
Simptoma: La schermata nativa scompare, poi gli utenti vedono una finestra vuota prima della prima schermata.
La causa: La tua app nasconde il splash prima che la UI radice possa renderizzare contenuto significativo.
Fix: Lega la chiusura del splash alla prontezza, non al tempo trascorso. In Expo, ciò significa solitamente tenere il splash fino a quando la tua vista radice può disporre. In progetti bare, utilizza il pattern equivalente e assicurati che la prima schermata visualizzata non blocchi immediatamente su più lavoro asincrono.
Schermo di attesa mancante su una piattaforma
Simulazione: L'Android lo mostra, l'iOS no, o viceversa.
Causa: One native side wasn’t fully configured. Often it’s a forgotten storyboard reference, theme wiring issue, or asset not added to the correct target.
Soluzione: Controlla i file specifici per piattaforma uno per uno. Sull'Android, controlla il tema di avvio e le referenze alle risorse. Sull'iOS, conferma LaunchScreen.storyboard, asset catalog membership, and app target settings in Xcode.
Build breaks after adding splash configuration
Simulazione: L'app ha smesso di compilare dopo aver introdotto una libreria o modificato i file di splash.
Causa: File e configurazioni generate possono diventare disallineati, soprattutto dopo modifiche di plugin o asset.
Risoluzione: Pulisci la build, reinstalla le dipendenze se necessario e ricostruisci il progetto nativo completamente. Se sei in Expo con layer native generate, regenera con cura e verifica la configurazione dei plugin. Se sei in un'app bare, revisiona MainActivity, AppDelegatenomi di risorse e qualsiasi modifica di plist o manifest per piccole incongruenze.
The fastest teams treat the splash screen as part of release engineering, not a one-time visual task. That matters even more when startup assets, UI text, or app-shell behavior need to change quickly after launch. Capgo offre a Capacitor e agli team di Electron una possibilità di inviare JavaScript, CSS, copia, configurazioni e modifiche di asset con il prossimo lancio con controlli di distribuzione e supporto di rollback, il che è utile quando il problema si trova nel layer dell'app piuttosto che nello schermo di avvio nativo stesso.
Continua da qui: Guida completa allo schermo di avvio in React Native per il 2026
Se stai utilizzando lo schermo di avvio in React Native: Guida completa per il 2026 to plan native media and interface behavior, connect it with Usando @capgo/capacitor-live-activities per la capacità nativa in Utilizzare @capgo/capacitor-attività-in-vivo @capgo/capacitor-attività-in-vivo per il dettaglio di implementazione in @capgo/capacitor-attività-in-vivo Utilizzare @capgo/capacitor-lettore-di-video per la capacità nativa in Utilizzare @capgo/capacitor-lettore-di-video @capgo/capacitor-lettore-di-video per il dettaglio di implementazione in @capgo/capacitor-lettore-di-video, e Utilizzare @capgo/capacitor-navigazione-nativa per la capacità nativa in Utilizzare @capgo/capacitor-navigazione-nativa.
