Vous appuyez sur l'icône de votre application sur un appareil réel, et pendant une fraction de seconde, l'utilisateur obtient une flèche blanche, un logo étiré ou un écran de démarrage figé qui disparaît avant que quelque chose d'utile 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 marque. Il couvre la lacune entre le démarrage natif et le premier cadre React rendu. 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 magasin réelle. Si vous vous trompez dans le timing, les utilisateurs voient les fissures immédiatement.
Table des matières
- Pourquoi une SplashScreen Professionnelle est-elle importante ?
- Préparer des Assets de SplashScreen Parfaits
- Mise en œuvre avec le workflow du client de développement et d'Expo Go
- Configurer 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 clique sur 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.
Dans 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 React affiché. 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 : le chargement des polices, la restauration de la session persistante, la lecture des drapeaux de fonctionnalité et l'état de navigation initial se disputent tous la première frame.
- Prévenir les bugs visuels : il évite les éclairs de blanc du système, les textes non stylisés ou la vue racine partiellement montée.
- Maintenir 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 intention.
- 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 Expo 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 la mise en route comme faisant partie de la qualité du produit la 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 axé sur la production. Préparer les Attributs d'écran de démarrage parfaits
La plupart des bugs d'écran de démarrage commencent dans les fichiers de conception, et non dans __CAPGO_KEEP_0__. Si l'atelier de base est incorrect, aucun montage d'Android XML ou d'iOS storyboard ne pourra le sauver.
code’s guide to app user experience
La méthode la plus sûre consiste à considérer l'écran de chargement comme un un système de disposition, et non une image d'écran unique. Utilisez une couleur de fond ainsi qu'un logo ou une illustration centrés. 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 la transmission, 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'aspects inhabituels.
- Variantes de plateforme : Exporter les tailles d'image dont votre flux de travail a besoin, plutôt que de les étirer partout.
- Évaluation 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 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 | Artwork 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 cohérente | La différence de fond se produit entre l'écran initial et l'écran de démarrage. | Alignez les couleurs de lancement et de l'interface utilisateur. |
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, ce qui explique pourquoi des guides comme l'optimisation des images pour les mises à jour sont dignes d'être consultés lorsque vous standardisez les exportations d'actifs.
Un workflow d'exportation pratique
Un ensemble de paramètres qui fonctionne bien dans des projets réels ressemble à ceci:
- Concevez une composition centrée. Exportez un logo PNG transparent si votre flux de travail prend en charge une couleur de fond séparée.
- Exportez une image d'écran sans texte dense, de détails minuscules ou de publicité. Concevez une composition centrée sur un fond uni.
- 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 point est plus important que ce que les gens attendent. 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 se trouve généralement dans app.json ou app.config.js.
context : 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 marketing ou juridique long. Vu dans : page alternatives.astro. Préservez les termes de produit et de marque Capgo et 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 : page de comparaison/migration de Appflow. Rôle : Paragraphe marketing ou juridique long. Vu dans : page ionic-appflow.astro. Préservez les termes de produit et de marque Capgo et 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 marketing ou juridique long. Vu dans : page capwesome.astro. Préservez les termes de produit et de marque Capgo et les termes de développeur exactement. Clé de message `capwesome_cta_questions` (Questions de CTA de Capwesome). | Fragment de texte HTML d'une chaîne de dialogue Capgo plus longue (clé parente `consulting_faq_subtitle`). Page/zone : page de services de conseil. Rôle : Sous-titre ou slogan de section. Vu dans : page consulting.astro. Préservez les termes de produit et de marque Capgo et les termes de développeur exactement. Clé de message `consulting_faq_subtitle` (Sous-titre FAQ des services de conseil). | Page/zone : page 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 Ou). 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éfinissez l'apparence de lancement native dans la config, puis contrôlez la visibilité à partir de JavaScript.
Quelques choix pratiques comptent ici :
- Utilisez une couleur de fond proche de votre écran initial afin que la transition se sente continue.
- Gardez l'image simple puisque les surfaces de lancement ne sont pas le lieu pour des œuvres d'art denses.
- Évitez les « retards de marquage » fictifs qui maintiennent les utilisateurs sur un logo lorsque l'application est déjà prête.
Cachez le splash en fonction de la disponibilité, et non en fonction du temps
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 la chance 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 connecté, l'écran de splash devrait couvrir cette lacune.
Un guide utile de l'écosystème React Native plus large et du 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. parce qu'elles incluent votre projet natif généré.
- Les builds autonomes sont la dernière vérification. pour le timing de lancement, le comportement du thème et la correction des actifs.
Si votre écran d'accueil continue de clignoter ou de s'éteindre, le bug est généralement l'un des trois choses : cacher trop tôt, afficher null pour trop longtemps après la cacher, 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 d'accueil doit correspondre au travail de démarrage réel au lieu de montrer un logo pour un délai fixe. Ce contrôl’implique une responsabilité native. Vous devez connecter correctement Android et iOS, reconstruire souvent, et tester la transmission entre l'interface de lancement native et la première écran React sur des appareils réels.
In CLI projets, je recommande généralement react-native-bootsplash pour le nouveau travail. Il convient mieux aux projets React Native actuels que les anciens bibliothèques d'écran d'accueil, 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 simple :
- Générez les atouts de l'écran d'accueil pour les dossiers de ressources Android que vous supportez.
- Définez un thème de lancement avec la couleur de fond correcte et le drawable de l'écran d'accueil.
- 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.
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 ligne de code 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 la plus facile. Les erreurs tendent à provenir des ressources et des transitions de thème.
Voici les problèmes Android qui se produisent en production :
- Mauvaise correspondance 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.
- Bacs d'actifs incorrects : Android étirera ou flouera les actifs manquants dans les dossiers de densité attendus.
- Test avec Metro uniquement : Les modifications des ressources natives nécessitent généralement une reconstruction complète. La reprise chaude ne valide pas le comportement de lancement.
- Règles de lancement Android 12 : Les versions Android plus récentes appliquent leur propre comportement de splash en premier, donc les configurations personnalisées doivent respecter ces contraintes de plateforme.
- JS lent après la mise à l'écart : Si React cache le splash avant que la vue racine puisse peindre, les utilisateurs obtiennent un cadre vide au lieu d'une transition lisse.
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.
Paramètres 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 l'architecture visuelle de la première écran, pas comme un mini flux de démarrage.
La mise en place fiable ressemble à ceci :
- Ajoutez des assets au catalogue d'assets Xcode.
- Configurez
LaunchScreen.storyboardavec des contraintes simples. - Maintenez la disposition statique. Couleur de fond, logo et espacement sûr sont généralement suffisants.
- Insérez 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 mise en place plus difficile à maintenir et plus facile à briser sur les tailles de dispositif.
A un écran de démarrage simple est le choix plus sûr.
Un CLI nu vous 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 par défaut correct. CLI nu vous donne la pleine responsabilité de la pipeline de démarrage 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 native personnalisée de SDK 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 démarrage, maintenez 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 comptent 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 d'une autre pile, et la leçon se transmet clairement à React Native.
Expo-géré versus CLI nu
La comparaison pratique est moins axée sur la mise en page des images et plus sur où la complexité du démarrage vit.
| Point de décision | 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 |
| Efficacité optimale | É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à permet généralement de gagner du temps. Si le chemin d'initialisation 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 solution à long terme la plus propre.
Les deux workflows peuvent déployer une écran d'accueil raffiné. La différence réside dans qui contrôle la chaîne de lancement, votre framework ou votre équipe.
Techniques avancées pour des écrans d'accueil animés et performants
Les écrans d'accueil animés ressemblent à des écrans d'accueil raffinés lorsqu'ils respectent la chaîne de lancement. Ils semblent bon marché lorsqu'ils distraient de celle-ci.
C'est pourquoi je traite l'animation comme une couche d'amélioration, et non comme la base. La première tâche est toujours la synchronisation. Si l'application n'est pas prête, l'écran d'accueil reste visible. Si l'application est prête, la transition doit se produire rapidement vers la première écran utilisable.
L'animation doit suivre la réalité de l'initialisation
Un modèle courant consiste à conserver l'écran d'accueil natif simple, puis à exécuter 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 vraie elle-même.
Lottie est une solution pratique pour ce type de transfert de main car elle peut livrer de la motion sans créer un empilement d'animation personnalisée lourd dans le premier écran. La partie importante est la séquence :
- L'écran d'accueil natif reste visible pendant le travail critique d'initialisation.
- 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èl’ancien. setTimeout(2000) Sur un appareil rapide, cela fait attendre l'application sans 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. La page de chargement doit couvrir les tâches exactes qui doivent être terminées 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 :
- Lecture de stockage essentielle : Thème, localisation, état de démarrage et préférences critiques connues.
- 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 distante 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 de démarrage change en fonction de l'environnement. La discussion du traitement de l'écran de démarrage par 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 delay vieillissent mal. Ils cachent 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 vitesse. Il doit être utilisé pour empêcher les utilisateurs de voir une interface utilisateur inachevée.
Si vous ajoutez de la motion dans un stack hybride ou évaluez la performance de rendu plus large, cette guide à la performance d'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_KEEP_0__ 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 en cours d'exécution.
Résoudre les 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 timing, et 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 souvent MainActivity et les ressources XML ou drawable, tandis que les iOS se concentrent sur LaunchScreen.storyboard et AppDelegateUn même aperçu indique que Expo recommande une image carrée 1024 × 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 d'accueil React Native.
L'image d'écran étirée ou floue
Symptôme : Le logo semble flou, coupé ou mal é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. Réexportez à partir de la source de conception originale, régénérez les assets spécifiques à la densité et vérifiez que vos fichiers Android drawables ou votre catalogue d'assets iOS contiennent les fichiers attendus.
Écran blanc après que le splash se cache
Symptôme : Le splash natif disparaît, puis les utilisateurs voient une fenêtre vide avant la première écran.
Cause : Votre application cache le splash avant que l'UI racine puisse afficher du contenu significatif.
Solution : Attachez la disparition 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. Dans les projets bare, utilisez le modèl’équivalent et assurez-vous que la première écran affiché ne bloque pas immédiatement sur plus de travail asynchrone.
É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 lancement 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 construction se brise après avoir ajouté 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 manifest pour des petites incohérences.
Les équipes les plus rapides considèrent l'écran de démarrage comme une 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 JavaScript, Electron et Capacitor un moyen de livrer des correctifs de JavaScript, CSS, copie, configuration et actifs sur le prochain lancement avec des contrôles de déploiement et un support de retrait, ce qui est utile lorsque le problème se situe dans la couche d'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 pour planifier les médias natifs et le comportement de l'interface utilisateur, connectez-l’à Utilisation de @capgo/capacitor-activités-en-vivo pour la capacité native dans Utilisation de @capgo/capacitor-activités-en-vivo @capgo/capacitor-activités-en-vivo pour le détail d'implémentation dans @capgo/capacitor-activités-en-vivo Utilisation de @capgo/capacitor-lecteur-de-videos 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 En utilisant @capgo/capacitor-native-navigation pour la capacité native dans l'utilisation de @capgo/capacitor-native-navigation.
