Lorsque vous appuyez sur l'icône de votre application sur un appareil réel, l'utilisateur voit pendant une fraction de seconde une flèche blanche, un logo étiré ou un écran de démarrage figé qui disparaît avant que quoi que ce soit d'utile ne soit prêt. C'est généralement le moment où une application React Native cesse de ressembler à une application de production.
Un bon écran d'accueil dans React Native répare plus que la branding. Il couvre la lacune entre le démarrage natif et le premier cadre React rendu significatif. Il oblige également à réfléchir clairement à l'ordre de démarrage, à la préparation des ressources et à la différence entre ce qui se passe dans Expo Go, un client de développement, et une mise en vente réelle. Si vous vous trompez dans le timing, les utilisateurs voient les fissures immédiatement.
Table des matières
- Pourquoi une SplashScreen professionnelle compte
- Préparer des Assets de SplashScreen parfaits
- Mise en œuvre avec le workflow de l'application Expo Go et du client de développement
- Configuration pour les projets React Native Bare CLI
- Techniques avancées pour des écrans de démarrage animés et performants
- Résolution des problèmes courants liés à l'écran de démarrage
Pourquoi un écran de démarrage professionnel compte
A l'ouverture de votre application, un utilisateur appuie sur l'icône depuis l'écran d'accueil, et la séquence de démarrage affiche une fenêtre blanche vide avant que le premier élément d'interface utilisateur ne soit visible. En production, cela donne l'impression d'instabilité. Il n'a pas d'importance que React Native charge toujours le bundle JavaScript ou restaure l'état en arrière-plan. L'impression première est déjà fausse.
En React Native, l'écran de démarrage est la première surface native que votre application contrôle. Il recouvre la transition entre le démarrage du processus et le premier cadre affiché par React. Cela le rend un outil de démarrage, et non seulement un atout de branding. Si vous le synchronisez bien, les utilisateurs voient un démarrage stable qui ressemble à une intention. Si vous le masquez trop tôt, ils voient des déplacements de mise en page, des polices manquantes ou une écran mort pendant que l'authentification, la navigation ou la configuration distante rattrape le coup.
Ce que fait vraiment l'écran de démarrage
Un écran de démarrage en production doit généralement gérer quatre préoccupations de démarrage :
- Couvrir le travail de démarrage native vers le JavaScript : chargement de polices, restauration de session persistante, lecture de drapeaux de fonctionnalité et état de navigation initial, tous concurrents pour le premier cadre.
- Prévenir les glitches visuels : il évite les éclairs de blanc système, du texte non stylisé ou d'une vue racine partiellement montée.
- Conserver la cohérence visuelle du démarrage : la couleur de fond et le logo peuvent correspondre à la coque de l'application pour que la transition ressemble à une action contrôlée.
- Forcer les décisions de démarrage : Les équipes doivent définir ce que signifie « prêt » avant de supprimer l'écran de démarrage.
Règle pratique : Cacher l'écran de démarrage lorsque la première écran réel peut s'afficher clairement, et non après un délai arbitraire.
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.
Cette trade-off compte dans les projets réels. Expo est plus rapide à configurer et plus facile à maintenir cohérent à travers les environnements. Les projets sans gestion sont souvent la bonne choix lorsque l'application dépend déjà de modules natifs personnalisés, d'un comportement de démarrage personnalisé ou d'un contrôle plus strict sur le chemin d'initialisation.
Les équipes qui traitent le démarrage comme faisant partie de la qualité du produit le reviennent généralement en même temps que le travail de UX plus large, et non comme une tâche native isolée. C'est le même esprit que celui couvert dans le guide de __CAPGO_KEEP_0__ à l'expérience utilisateur de l'application. Capgo’s guide to app user experienceNerdify solutions pour les applications React Native donne un aperçu utile centré sur la production. Préparer les Attributs de l'écran de démarrage parfait
La plupart des bugs de l'écran de démarrage commencent dans les fichiers de conception, et non dans __CAPGO_KEEP_0__. Si l'attribut de base est incorrect, aucun nettoyage d'Android XML ou d'iOS storyboard ne pourra le sauver.
Most splash screen bugs start in design files, not code. If the base asset is wrong, no amount of Android XML or iOS storyboard cleanup will save it.
La méthode la plus sûre consiste à traiter l'écran de chargement comme un un système de disposition, et non comme une image d'écran unique. Utilisez une couleur de fond ainsi qu'un logo ou une illustration centrée. Cela s'adapte plus prédicablement sur les appareils Android hauts, les iPhones, les tablettes et les orientations d'appareil plus larges que d'essayer de faire tenir une image d'affiche détaillée en tout lieu.
Ce à quoi il faut se préparer avant de coder
Commencez avec un fichier source vierge depuis le design. Le vecteur est idéal pour le transfert, même si l'atout de lancement exporté est un PNG.
Utilisez ce tableau de bord :
- Artwork source : Conservez un logo ou une marque maître en SVG, AI ou un autre format source éditable afin que les exports restent cohérents.
- Couleur de fond : Définez la couleur de fond exacte de l'écran de chargement dès le début et assurez-vous qu'elle correspond à la première page ou à la coque d'application.
- Marges sûres : Laissé suffisamment d'espace vide autour du logo pour éviter que la mise en page ne soit coupée par des ratios d'aspect inhabituels.
- Variantes de plateforme : Exportez les tailles d'image dont votre flux de travail a besoin, plutôt que de les étirer partout.
- Examen de la mode sombre : Si votre application prend en charge les surfaces sombres, confirmez que le logo est encore lisible contre le fond choisi.
La documentation d'Expo est utile ici car elle renforce l'idée que les actifs de lancement font désormais partie de la chaîne de construction, et non une pensée après coup. Un carré de 1024 x 1024 px en PNG pour les icônes d'applications, et notez que EAS Build peut générer les tailles requises pour les projets créés avec npx create-expo-appqui montre comment la génération d'actifs a évolué vers des outils modernes plutôt que des répétitions manuelles.
Erreurs courantes d'actifs
Les plus grandes erreurs visuelles sont prévisibles :
| Problème | Cause probable | Approche meilleure |
|---|---|---|
| Logo flou | Exporté d'une image raster à faible résolution | Re-export à partir d'une source vectorielle |
| Bords coupés | L'artwork est placé trop près des limites | Augmenter la marge de sécurité |
| Étirement | Image plein écran forçée dans de nombreuses ratios d'aspect | Utiliser une couleur de fond plus une image centrée |
| Transition non conforme | La différence de fond se produit entre l'écran de démarrage et l'écran principal | Alignez les couleurs de lancement et de la coquille de l'application |
Une image d'écran ne doit pas comporter de texte dense, de détails minuscules ou de publicité. Les écrans de démarrage sont affichés brièvement et rendus sous des contraintes natives serrées.
Pour les équipes qui livrent des mises à jour visuelles fréquentes, la discipline de l'image compte au-delà du lancement. Les mêmes habitudes s'appliquent aux lots de livraison et à la taille des fichiers binaires, c'est pourquoi des guides comme l'optimisation des images pour les mises à jour sont dignes d'être examinés lors de la standardisation des exportations d'actifs.
Un workflow d'exportation pratique
Un ensemble qui fonctionne bien dans des projets réels ressemble à ceci :
- Concevez une composition centrée sur un fond uni.
- Exporter un logo PNG transparent s'il est possible de supporter une couleur de fond séparée dans votre workflow.
- Maintenez la cohérence des noms à travers les plateformes afin que les échanges d'actifs ne deviennent pas des conjectures.
- Testez sur les simulateurs petits et grands tôt avant de brancher le cycle de vie de la splash.
- Rebâtissez après les changements d'actifs car les ressources de lancement sont souvent stockées dans les caches natifs.
Cette dernière considération compte plus que les gens ne l'imaginent. Beaucoup d'issues de splash screen qui semblent être des bogues de configuration sont simplement des actifs natifs périmés.
Implémenter avec le flux de travail de l'Expo Go et du Client de Développement
Si vous utilisez Expo, commencez par expo-splash-screen. Il convient au flux de travail géré, garde la plupart de la configuration déclarative et vous donne un contrôl’explicite sur le moment où la splash doit partir.
Le comportement clé à comprendre est simple. Conservez la splash native visible jusqu'à ce que le premier cadre UI significatif soit prêt. Expo's SplashScreen API prend exactement ce modèl’avec preventAutoHideAsync() à l'initialisation et hideAsync() une fois la charge critique terminée, et Expo avertit que cacher trop tôt peut brièvement exposer une écran vide dans les builds iOS et Android, comme documenté dans le Expo splash screen API.
Configurez la splash native de manière déclarative
Dans un projet Expo, la partie visuelle vit généralement dans app.json ou app.config.js.
contexte : Fragment de texte HTML d'une chaîne de dialogue Capgo plus longue (clé parente `alternatives_cta_questions`). Page/zone : Page de comparaison des alternatives de mise à jour en direct de Capacitor. Rôle : Paragraphe de marketing ou juridique long. Vu dans : page alternatives.astro. Préservez les termes de produit et de marque Capgo ainsi que les termes de développeur exactement. Clé de message `alternatives_cta_questions` (Questions de CTA des alternatives). | Fragment de texte HTML d'une chaîne de dialogue Capgo plus longue (clé parente `appflow_cta_questions`). Page/zone : Copie de marketing de comparaison/migration d'Appflow. Rôle : Paragraphe de marketing ou juridique long. Vu dans : page ionic-appflow.astro. Préservez les termes de produit et de marque Capgo ainsi que les termes de développeur exactement. Clé de message `appflow_cta_questions` (Questions de CTA d'Appflow). | Fragment de texte HTML d'une chaîne de dialogue Capgo plus longue (clé parente `capwesome_cta_questions`). Page/zone : Page de comparaison de Capawesome. Rôle : Paragraphe de marketing ou juridique long. Vu dans : page capwesome.astro. Préservez les termes de produit et de marque Capgo ainsi que les termes de développeur exactement. Clé de message `capwesome_cta_questions` (Questions de CTA de Capawesome). | Fragment de texte HTML d'une chaîne de dialogue Capgo plus longue (clé parente `consulting_faq_subtitle`). Page/zone : Page de services de consulting. Rôle : Sous-titre ou tagline de section. Vu dans : page consulting.astro. Préservez les termes de produit et de marque Capgo ainsi que les termes de développeur exactement. Clé de message `consulting_faq_subtitle` (Sous-titre FAQ de consulting). | Page/zone : Copie de marketing de comparaison/migration d'Appflow. Rôle : Étiquette UI courte ou élément de navigation. Vu dans : page ionic-appflow.astro, page ionic-enterprise-plugins.astro, page solutions/ionic-enterprise-plugins.astro. Clé de message `appflow_plugins_or` (Appflow Plugins Or). app.json Un setup typique ressemble à ceci :
{
"expo": {
"plugins": [
[
"expo-splash-screen",
{
"backgroundColor": "#111111",
"image": "./assets/splash-icon.png",
"imageWidth": 200
}
]
]
}
}Les champs exacts peuvent varier en fonction de la configuration du projet, mais le modèle reste le même. Vous définez l'apparence de lancement native dans la config, puis contrôlez la visibilité à partir de JavaScript.
A quelques choix pratiques importent ici :
- Utilisez une couleur de fond proche de votre écran initial afin que la transition se sente continue.
- Gardez l'image simple car les surfaces de lancement n'ont pas besoin d'artwork dense.
- Évitez les « retards de branding » fictifs qui maintiennent les utilisateurs sur un logo lorsque l'application est déjà prête.
Cacherez le splash en fonction de la disponibilité, et non de la durée
Beaucoup de tutoriels se trompent souvent. Ils utilisent setTimeoutqui est facile à démontrer mais incorrect pour la production.
Utilisez l'état de démarrage au lieu de cela. Un modèle de niveau racine courant ressemble à ceci :
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>
);
}Deux détails rendent ce modèle fiable.
Premièrement, preventAutoHideAsync() est appelé avant que l'application ne commence à afficher une interface utilisateur significative. Deuxièmement, la cacher se produit uniquement après que la vue racine soit prête à organiser, ce qui réduit les chances d'un éclair entre l'écran de splash natif et l'arbre React.
Ne cachez pas l'écran de splash lorsque votre travail asynchrone commence à se terminer. Cacher-le lorsque l'interface utilisateur qui dépend de ce travail peut vraiment s'afficher.
Cette distinction compte le plus lorsque le démarrage inclut la restauration d'authentification, la configuration à distance ou le chargement de polices. Si votre écran d'accueil dépend de polices personnalisées et d'un état signé-in, l'écran de splash devrait couvrir cette lacune.
Un guide utile de la plateforme React Native et de l'écosystème de démarrage est présenté ci-dessous :
Ce que vous pouvez attendre dans Expo Go et les builds de développement
Expo ajoute une complexité supplémentaire. Le comportement de l'écran de splash que vous attendez dans une build autonome peut ne pas correspondre à ce que vous voyez dans Expo Go.
Cette incohérence confond beaucoup d'équipes. Vous modifiez l'asset ou la logique de timing, testez dans Expo Go et concluez que la configuration est brisée lorsque le problème réel est que l'environnement de développement ne se comporte pas comme un binaire de production.
Utilisez ce modèle mental :
- Expo Go est pratique pour l'itération mais ce n'est pas l'autorité finale sur le comportement de l'écran de splash natif.
- Les clients de développement sont plus proches de la réalité parce qu'elles incluent votre projet natif généré.
- Les builds autonomes constituent la dernière vérification. pour le timing de lancement, le comportement de la thématique et la correction des actifs.
Si votre écran de splash continue de clignoter ou de s'éterniser, le bug est généralement l'un des trois choses : cacher trop tôt, afficher null pour trop longtemps après la mise à l'obscurité, ou tester dans un environnement qui ne reflète pas le comportement de la mise en production.
Configuration pour les projets React Native Bare CLI
Un projet React Native Bare vous donne un contrôle direct sur le comportement de lancement, ce qui est utile une fois que l'écran de splash doit correspondre au travail de démarrage réel au lieu de montrer un logo pour un délai fixe. Ce contrôl’est accompagné de la responsabilité native. Vous devez brancher correctement Android et iOS, reconstruire souvent, et tester la transmission entre l'interface de lancement native et la première écran de React sur des appareils réels.
Dans les projets CLI, je recommande généralement react-native-bootsplash pour de nouvelles tâches. Il convient mieux aux projets React Native actuels que les anciens bibliothèques de splash, et la mise en place native est plus facile à raisonner pendant les mises à niveau. Les anciens projets continuent de livrer avec react-native-splash-screenmais pour un nouveau setup, l'objectif reste le même. Montrez une surface de lancement native immédiatement, puis cachez-l’uniquement après que l'application puisse afficher une interface utilisateur significative.
Configuration Android dans un projet Bare
La configuration de l'écran d'accueil Android se trouve dans plusieurs endroits à la fois : les ressources de thème, les drawables, AndroidManifest.xmlet MainActivity. C'est pourquoi les petites erreurs créent des éclairs visibles.
Le flux habituel est direct :
- Générez les ateliers d'écran pour les dossiers de ressources Android que vous supportez.
- Définez un thème de lancement avec la couleur de fond et le drawable d'écran corrects.
- Appliquez ce thème à l'activité de démarrage dans
AndroidManifest.xml. - Initialisez l'écran d'accueil dans
MainActivity. - Cacherez-le depuis JavaScript après les tâches de démarrage qui bloquent la première mise à jour sont terminées.
Un modèle simplifié MainActivity.kt se présente souvent ainsi :
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// initialize splash handling here depending on the library
}Cette snippet est intentionnellement générique car l'appel exact dépend de la bibliothèque. Le point d'intégration natif est généralement la partie facile. Les erreurs tendent à provenir des ressources et des transitions de thème.
Voici les problèmes Android qui se produisent en production :
- Problème de thème : Si le thème de lancement utilise une couleur de fond différente de votre première écran d'application, les utilisateurs voient un flash lors de la prise en main.
- Répertoires d'actifs incorrects : Android étirera ou flouera les actifs qui manquent dans les dossiers de densité attendus.
- Test avec Metro uniquement : Les modifications des ressources natives nécessitent généralement une rebond propre. La mise à jour en temps réel ne valide pas le comportement de lancement.
- Règles de lancement Android 12 : Les versions Android plus récentes appliquent d'abord leur propre comportement de splash, donc les paramétrages personnalisés doivent respecter ces contraintes de plateforme.
- JS lent après la mise à l'obscurité : Si React cache le splash avant que la vue racine puisse peindre, les utilisateurs obtiennent un cadre vide au lieu d'une transition fluide.
Ce dernier point compte plus que l'image elle-même. Les problèmes de timing sont généralement perçus comme des problèmes de performance.
Configuration iOS dans un projet vierge
Sur iOS, le centre de gravité est LaunchScreen.storyboard plus une petite fonction native dans AppDelegate. La plateforme attend que l'écran de démarrage soit statique et léger. Traitez-le comme une capture de la structure visuelle de la première écran, pas comme un mini flux de prise en main.
La configuration fiable ressemble à ceci :
- Ajoutez des actifs au catalogue d'actifs Xcode.
- Configurez
LaunchScreen.storyboardavec des contraintes simples. - Maintenez la disposition statique. La couleur de fond, le logo et l'espace sûr sont généralement suffisants.
- Ajoutez l'appel de démarrage natif de la bibliothèque dans
AppDelegate. - Cacherez l'écran de démarrage uniquement depuis JavaScript après que l'application soit complètement prête à afficher.
Les équipes nouvelles à iOS ont souvent surconstruit l'histoire de bord. Cela se retourne généralement contre elles. Les contraintes complexes, les vues imbriquées multiples ou les tentatives d'animation de l'écran de démarrage rendent la configuration plus difficile à maintenir et plus facile à briser sur les tailles de dispositif.
A un écran de démarrage simple, il est plus sûr de choisir cette option.
Un CLI nu donne plus de contrôle sur la transmission de données.
C'est la principale différence entre Expo-géré et CLI nu. Expo vous offre un chemin plus rapide vers un écran de démarrage correct par défaut. Le CLI nu vous donne la pleine responsabilité de la chaîne de pipeline de lancement natif.
Cet équilibre devient utile lorsque le démarrage fait plus que charger un bundle. Les applications avec la restauration d'authentification, la lecture de stockage chiffré, l'initialisation de SDK natif personnalisée ou les règles de branding blanc nécessitent souvent un contrôle supplémentaire. Les projets SDK nu vous permettent d'aligner la synchronisation de l'écran de démarrage avec ce travail au lieu de forcer tout à travers une configuration de niveau supérieur.
Si vous prévoyez d'ajouter une transition animée après le lancement, gardez l'écran de démarrage natif statique et déplacez la motion dans la première écran de React. Les compromis de performance sont similaires à ceux qui importent dans tout chemin de démarrage mobile. Le travail lourd pendant la première peinture est coûteux. Cela guide à la performance de l'animation dans les applications Capacitor couvre le même principe à partir d'une autre pile, et la leçon s'applique proprement à React Native.
CLI Expo-géré versus nu
La comparaison pratique est moins liée à la mise en page d'image et plus liée à où la complexité du démarrage vit.
| Point de décision | __CAPGO_KEEP_0__ Expo-géré | CLI nu |
|---|---|---|
| Configuration de vitesse | Initialisation plus rapide | Plus de travail natif |
| Personnalisation native | Plus de contraintes | Contrôle total |
| Flux de génération d'actifs | Plus déclaratif | Plus manuel |
| Surface de débogage | Configuration JS plus couche native générée | Fichiers Android et iOS directs |
| Meilleure correspondance | Équipes optimisant la vitesse et la cohérence | Équipes nécessitant un contrôle natif approfondi |
Si l'application est déjà en Expo et que les exigences de lancement sont standard, rester là sauve généralement du temps. Si le chemin d'initialisation du démarrage dépend de l'ordre d'initialisation natif, de thèmes personnalisés ou de logique de démarrage spécifique au plateau, le CLI bare est souvent la meilleure option à long terme.
Les deux workflows peuvent déployer une écran de démarrage poli. La différence est qui contrôle la chaîne de lancement, votre framework ou votre équipe.
Techniques avancées pour des écrans de démarrage animés et performants
Les écrans de démarrage animés ressemblent à des écrans de démarrage poli lorsqu'ils respectent la chaîne de démarrage. Ils ressemblent à des écrans de démarrage bon marché lorsqu'ils distraient de cela.
C'est pourquoi je traite l'animation comme une couche d'amélioration, et non comme la base. Le premier travail est toujours la synchronisation. Si l'application n'est pas prête, l'écran de démarrage reste visible. Si l'application est prête, la transition devrait se déplacer rapidement vers la première écran utilisable.
L'animation doit suivre la réalité de la démarrage
Un modèle courant est de garder l'écran de démarrage natif simple, puis de lancer une animation légère personnalisée dans le premier écran React après le lancement. Cela vous donne plus de flexibilité que de tenter d'animer la surface de lancement natif réelle elle-même.
Lottie est une choix pratique pour ce type de transfert de main car il peut livrer du mouvement sans construire un pilier d'animation personnalisé lourd dans le premier écran. La partie importante est la séquence:
- L'écran de démarrage natif reste visible pendant le travail critique de démarrage.
- React monte la première écran réel ou un écran de transition contrôlé.
- Une animation facultative ne joue que si elle ne bloque pas l'interaction plus longtemps que nécessaire.
Ce qui ne fonctionne pas, c'est le modèle setTimeout(2000) Sur un appareil rapide, cela fait attendre l'application pour aucune raison. Sur un appareil lent, cela remplace souvent un état de chargement par un autre.
Considérez le lancement comme une orchestration
Un meilleur modèle mental est l'orchestration de démarrage. L'écran de chargement doit couvrir les tâches exactes qui doivent se terminer avant que l'application puisse afficher du contenu significatif.
Cela inclut généralement une combinaison de :
- Authentification de démarrage : Restauration d'une session ou décision de routage vers la connexion.
- lecture de stockage essentielle : Thème, localisation, état de l'interface utilisateur et préférences critiques connues précédemment.
- Prêt de la police : En particulier si la première page repose sur une police personnalisée pour la stabilité de la disposition.
- Configuration à distance qui contrôle l'interface utilisateur : Seulement si la première page ne peut pas afficher en toute sécurité sans cela.
Existe une autre nuance que de nombreux tutoriels manquent. Le comportement de l'écran d'accueil change en fonction de l'environnement. La discussion de la gestion de l'écran d'accueil d'Expo en développement et en production met en évidence que le comportement peut ne pas apparaître de la même manière dans Expo Go que dans les builds autonomes, et que la gestion automatique de la visibilité change une fois que vous prenez le contrôle manuel. C'est une raison pour laquelle les exemples basés sur la mise en attente vieillissent mal. Ils masquent la séquence de démarrage réelle au lieu de s'aligner sur elle.
Un écran de démarrage ne doit pas être utilisé pour simuler la rapidité. Il doit être utilisé pour empêcher les utilisateurs de voir une interface utilisateur non terminée.
Si vous ajoutez de la motion dans un stack hybride ou évaluez la performance de la mise en page plus large cette guide à la performance de l'animation dans les applications Capacitor est un contexte utile car la même discipline s'applique. Gardez le travail de démarrage maigre, évitez les blocages inutiles et laissez l'animation soutenir la responsivité au lieu de la concurrencer.
Une note pratique pour les équipes qui expédient des correctifs visuels en dehors des mises à jour binaires complètes : les plateformes telles que Capgo Gérer les mises à jour de JavaScript, CSS, copie, configuration et actifs pour Capacitor et les applications Electron, mais les changements de l'écran de démarrage natif dans React Native appartiennent toujours à la chaîne de production de l'application native car l'écran de démarrage réel apparaît avant que l'application JavaScript ne soit exécutée.
Résolution de problèmes courants de l'écran de démarrage
La plupart des problèmes d'écran de démarrage se répartissent en un petit ensemble de récidivistes. La correction devient plus facile une fois que vous séparez les problèmes d'actifs, les problèmes de timinget les problèmes d'intégration native.
Les modèles de la communauté dans les guides React Native récents se sont concentrés sur le même flux de base : ajouter la bibliothèque, configurer les actifs de démarrage natifs, appeler show au démarrage, et masquer une fois que l'application est prête. Les configurations Android impliquent généralement MainActivity et les ressources XML ou drawable, tandis que les iOS se concentrent sur LaunchScreen.storyboard et AppDelegate. La même note d'aperçu indique que Expo recommande une image carrée de 1024 x 1024 pixels 1024 x 1024 PNG pour les icônes d'applications et que EAS Build peut générer les tailles requises pour les projets créés avec npx create-expo-app, comme résumé dans ce guide de l'écran de démarrage React Native.
Image d'écran étirée ou floue
Symptôme : Le logo semble flou, coupé ou étrangement échelonné.
Cause : L'image de base n'a pas été exportée correctement, ou la disposition repose sur un raster plein écran qui ne s'adapte pas bien.
Correction : Remplacez l'affiche par un logo centré sur un fond plat.
Écran blanc après le splash masqué
Symptôme : Le splash natif disparaît, puis les utilisateurs voient une fenêtre vide avant la première écran.
Cause : Votre application masque le splash avant que l'interface utilisateur racine puisse afficher du contenu significatif.
Solution : Attachez la suppression du splash à la disponibilité, et non à la durée écoulée. Dans Expo, cela signifie généralement conserver le splash jusqu'à ce que votre vue racine puisse organiser l'espace.
Écran splash manquant sur une plateforme
Symptôme : Android le montre, iOS non, ou l'inverse.
Cause : Une partie native n'était pas configurée complètement. Souvent, il s'agit d'une référence à un storyboard oubliée, d'un problème de câblage de thème ou d'un élément non ajouté à la cible correcte.
Fix : Vérifiez les fichiers spécifiques à la plateforme un par un. Sur Android, inspectez le thème de démarrage et les références aux ressources. Sur iOS, confirmez LaunchScreen.storyboardl'appartenance au catalogue d'actifs et les paramètres de cible de l'application dans Xcode.
La compilation se rompt après ajout de la configuration de splash
Symptôme : L'application s'est arrêtée de compiler après avoir introduit une bibliothèque ou changé les fichiers de splash.
Cause : Les fichiers de projet natif et la configuration générée peuvent diverger, surtout après des modifications de plugin ou d'actifs.
Fix : Nettoyez la construction, réinstallez les dépendances si nécessaire et reconstruisez le projet natif complètement. Si vous êtes dans Expo avec des couches natives générées, régénérez avec soin et vérifiez la configuration du plugin. Si vous êtes dans une application nue, passez en revue MainActivity, AppDelegateles noms de ressources et les éditions de plist ou de manifeste pour des petites incohérences.
Les équipes les plus rapides considèrent l'écran de démarrage comme faisant partie de l'ingénierie de la mise en production, et non comme une tâche visuelle unique. Cela compte encore plus lorsque les actifs de démarrage, le texte de l'interface utilisateur ou le comportement de la coquille de l'application doivent changer rapidement après le lancement. Capgo Cela donne aux équipes de Capacitor et Electron un moyen de livrer des correctifs JavaScript, CSS, copie, configuration et actifs sur le prochain lancement avec des contrôles de déploiement et un support de reversion, ce qui est utile lorsque le problème se situe dans la couche de l'application plutôt que dans l'écran de démarrage natif lui-même.
Continuez de la page d'accueil de l'écran de démarrage dans React Native : Guide complet pour 2026
Si vous utilisez L'écran de démarrage dans React Native : Guide complet pour 2026 à des fins de planification de la média et du comportement de l'interface native, connectez-l’à Utilisation de @capgo/capacitor-activités en direct pour la capacité native dans Utilisation de @capgo/capacitor-activités en direct @capgo/capacitor-activités en direct pour le détail d'implémentation dans @capgo/capacitor-activités en direct Utilisation de @capgo/capacitor-lecteur de vidéo pour la capacité native dans l'utilisation de @capgo/capacitor-video-player, @capgo/capacitor-video-player pour le détail d'implémentation dans @capgo/capacitor-video-player, et l'utilisation de @capgo/capacitor-native-navigation pour la capacité native dans l'utilisation de @capgo/capacitor-native-navigation.
