Saltare al contenuto principale
Mobile Guida

Lottie React Native

La nostra guida completa ti insegna a utilizzare lottie react native. Copre Expo & flussi di lavoro bare, controlli di animazione, ottimizzazione delle prestazioni, e migliori pratiche per il 2026.

Martin Donadieu

Martin Donadieu

Content Marketer

Lottie React Native

Probabilmente sei in uno dei due posti adesso. O hai un designer che ti consegna un Lottie JSON e ti chiede, “Possiamo ottenere questo nell'app di oggi?”, o hai già collegato e notato che l'animazione funziona nel development ma inizia a sentire l'effetto una volta che i dispositivi reali, il tempo di avvio e i rilasci entrano in scena.

È lì che Lottie React Native diventa interessante. La demo base è facile. L'implementazione pronta per la produzione non lo è. La differenza solitamente si riduce a come si installa, come si controlla il playback, e se si trattano i file di animazione come asset inoffensivi o come parte del tuo budget di prestazioni.

Tavola dei contenuti

Perché Lottie è essenziale per gli App React Native

Se hai mai provato a ricreare un'animazione di prodotto raffinata a mano in React Native, già sai di cosa parliamo. I dettagli di piccoli movimenti si trasformano in una pila di logica di timing, interpolazioni e bizzarrie di piattaforma. L'animazione può sembrare vicina, ma "vicino" di solito non è ciò che il designer ha spedito.

Lottie ha cambiato quel workflow. Airbnb ha reso pubblico Lottie nel 2016, e quella rilascio ha cambiato l'animazione mobile consentendo ai designer di spedire animazioni direttamente anziché costringere gli ingegneri a ricostruirle frame per frame. In alcuni ambienti aziendali, quel cambiamento ha ridotto i costi di sviluppo di app mobili di "fino al 40%", secondo Panoramica di Lottie di AirbnbDesign e ingegneria smettono di combattere la stessa battaglia Un beneficio chiave di Lottie React Native non è solo "animazioni belle in JSON". È la separazione delle preoccupazioni. I designer lavorano in After Effects e esportano con Bodymovin. I sviluppatori rendono l'output con playback supportato nativamente anziché tradurre il moto in __CAPGO_KEEP_0__ personalizzato..

Ciò conta perché il lavoro di animazione ha l'abitudine di diffondersi. Un'unica animazione di stato celebrativa può toccare la revisione di design, la revisione del prodotto, il comportamento Android, il comportamento iOS, l'accessibilità e il rendimento di avvio. Lottie riduce quella superficie di lavoro.

A key benefit of Lottie React Native isn’t just “pretty animations in JSON.” It’s the separation of concerns. Designers work in After Effects and export with Bodymovin. Developers render the output with native-backed playback instead of translating motion into custom code.

Usa Lottie quando l'animazione fa parte dell'esperienza del prodotto, non quando hai bisogno solo di una semplice opacità o di una transizione di traduzione.

Lottie React Native è essenziale per gli App React Native Lottie React Native è essenziale per gli App React Native

Ci sono anche aspetti relativi all'esperienza utente. La motion fornisce feedback, conferma le azioni e rende gli stati di caricamento meno morti. Se il tuo team sta pensando seriamente alla liscia, alla retenzione o alla fiducia nell'interfaccia, l'animazione fa parte di quella conversazione. La discussione più ampia sull'esperienza utente dell'app solitamente finisce nello stesso posto: il feedback veloce batte le schermate statiche.

Dove Lottie si inserisce meglio

Lottie React Native tende a funzionare meglio per:

  • Micro-interazioni personalizzate come likes, salvataggi, checkmark e stati di acquisto riuscito
  • Illustrazioni di onboarding che devono sembrare personalizzate senza spedire video
  • Stati di caricamento e vuoti dove l'interfaccia statica sembra incompleta
  • Educazione delle funzionalità quando il prodotto desidera la movimentazione senza incorporare GIF o MP4s

Ciò che non risolve è ogni problema di animazione. Per le transizioni di schermo base, gli strumenti di animazione di React Native sono spesso più semplici. Per sistemi di movimento molto grandi o interattivi, il formato JSON può diventare un compromesso anziché una vittoria. Questo compromesso diventa più importante non appena si raggiunge la produzione, che è dove la maggior parte dei tutorial si ferma troppo presto.

Impostazione dell'ambiente di sviluppo Lottie

Il percorso di installazione dipende da una decisione prima: Flusso gestito da Expo o React Native nudoNon mescolare i modelli mentali. La maggior parte dei problemi di configurazione si verificano quando gli sviluppatori seguono una guida di configurazione nuda all'interno di Expo, o suppongono che Expo astragga ogni dettaglio nativo.

Un diagramma a flusso che mostra i passaggi di configurazione per le animazioni Lottie nei progetti Expo e React Native nudo.

Scegliere il flusso di lavoro prima di installare

Se il tuo app vive in Expo e desideri la configurazione più veloce, rimani sulla strada di Expo a meno che tu non sappia di aver bisogno di lavoro nativo personalizzato. Se sei in un'app nuda, o già dipendi da moduli nativi che richiedono un controllo diretto, installalo come una dipendenza nativa normale e valuta entrambi i build iOS e Android immediatamente.

Molte squadre sottostimano quanto diventi più facile il debug quando si mantiene la configurazione allineata con il tipo di progetto. È anche il motivo per cui molte squadre che costruiscono integrazioni native personalizzate si spostano presto a un flusso di sviluppo client di Expo invece di aspettare fino a quando l'app diventa più difficile da modificare.

Setup gestito da Expo

Per le app gestite da Expo, mantieni le cose semplici.

  1. Installa il pacchetto

    npx expo install lottie-react-native
  2. Riavvia Metro

    npx expo start -c
  3. Verifica su dispositivo o simulatore Inizia con un file JSON locale e rendi un'animazione molto piccola per primo. Non debuggi un grande asset e un nuovo installazione allo stesso tempo.

Alcune note pratiche sono importanti in Expo:

  • Preferisci i file locali per primo: La debuggazione di animazioni remote aggiunge rumore di rete quando si vuole solo dimostrare che il librario funziona.
  • Testa il comportamento di rilascio presto: Il modo di sviluppo può nascondere problemi legati all'orologio e alla prestazione.
  • Guarda le vie degli asset: I file JSON spostati sono una delle cause più comuni di "non si visualizza nulla".

Expo è la strada più veloce per "funziona". Ciò non significa che sia la strada più veloce per "scalabile".

Impianto React Native nudo

In un progetto nudo, installa e valuta le dipendenze native fin da subito.

  1. Installa il pacchetto

    npm install lottie-react-native
  2. Installa i pods iOS

    cd ios && pod install && cd ..
  3. Riavvia l'app

    npx react-native run-ios

    o

    npx react-native run-android

Ecco la parte che molti guide di avvio rapido trascurano: dopo l'installazione, esegui una ricostruzione nativa completa prima di decidere che qualcosa non funziona. La ricarica calda non salverà una dipendenza nativa che non è stata compilata correttamente nell'app.

Verifica del workflow nudo che risparmia tempo

Utilizza questo breve elenco di controllo prima di procedere:

Verifica Perché conta
Riavvia dopo l'installazione I moduli nativi richiedono una compilazione fresca
Esegui pod install L'iOS non sarà affidabile senza di esso
Usa un semplice file JSON locale per primo Isola le problematiche di installazione dalle problematiche degli asset
Testa entrambe le piattaforme presto L'Android e l'iOS possono fallire per motivi diversi

Se il pacchetto si installa pulitamente ma la tua prima animazione non si visualizza, di solito non è un problema di installazione. È di solito la posizione del file degli asset, le dimensioni del componente o la configurazione di riproduzione.

Visualizza la tua prima animazione Lottie

La prima animazione funzionante dovrebbe essere noiosa. File locale. Dimensione fissata. Riproduzione automatica. Lo scorrimento è facoltativo. Non iniziare con la riproduzione condizionale, JSON remoto o un'animazione di esportazione a strati pesanti.

Un ambiente di lavoro moderno per sviluppatori con un laptop che mostra code e un monitor che visualizza un'app di animazione mobile.

Aggiungi un file di animazione locale

Crea una cartella di risorse se non ne hai già una:

assets/
  animations/
    success.json

Mantieni i nomi semplici. Evita spazi, punteggiatura strane e cartelle con molti livelli di nesting. Vuoi require() che le percorrenze siano ovvie.

Se stai utilizzando Lottie per uno schermo di caricamento iniziale o per un handoff dopo il lancio, pensa attentamente prima di inserire un'animazione grande nella path di avvio. È specialmente vero quando stai anche regolando il comportamento dello schermo di splash di React Native Rendilo con LottieView.

Crea un componente dedicato invece di inserirlo direttamente in un grande file di schermo:

Fa tre cose utili:

import React from 'react';
import { View, StyleSheet } from 'react-native';
import LottieView from 'lottie-react-native';

export function SuccessAnimation() {
  return (
    <View style={styles.container}>
      <LottieView
        source={require('../assets/animations/success.json')}
        autoPlay
        loop={false}
        style={styles.animation}
      />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    alignItems: 'center',
    justifyContent: 'center',
  },
  animation: {
    width: 220,
    height: 220,
  },
});

prova che la libreria si rende correttamente

  • prova che la percorrenza della risorsa si risolve correttamente
  • Eseguilo con __CAPGO_KEEP_0__
  • ti dà un posto isolato dove regolare la riproduzione e le dimensioni in seguito

Se salti i fondamenti, alcuni trappole si presentano immediatamente:

  • Nessuna larghezza o altezza: L'animazione può esistere ma essere invisibile.
  • Pessimo require() path: Metro non troverà il file.
  • Esportazione non valida: Alcuni file JSON sono tecnicamente validi ma includono funzionalità che non si comportano come previsto su dispositivi mobili.

Mantieni la prima renderizzazione locale e deterministica. Stai testando l'integrazione, non l'architettura.

Un test di schermo iniziale migliore

Colloca il componente su uno schermo semplice con un background neutro:

import React from 'react';
import { SafeAreaView, StyleSheet } from 'react-native';
import { SuccessAnimation } from './src/SuccessAnimation';

export default function App() {
  return (
    <SafeAreaView style={styles.screen}>
      <SuccessAnimation />
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  screen: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#fff',
  },
});

If questo funziona in entrambi i simulatori iOS e Android, hai superato la prima vera difficoltà. Da lì, il prossimo passo non è aggiungere più animazioni. È imparare quando utilizzare proprietà dichiarative e quando prendere il controllo diretto con riferimenti.

Mastering Lottie Animation Controls

La maggior parte dei bug di Lottie React Native si manifesta quando l'animazione deve reagire allo stato. L'autoriproduzione è facile. 'Gioca questo segmento quando l'utente apprezza un oggetto, annulla quando non lo apprezza e non stutter quando il componente si ri-riga' è dove le cose si fanno complicate.

Un confronto tra i metodi di controllo dell'animazione dichiarativa e imperativa di Lottie, evidenziando i loro casi d'uso specifici.

Utilizza proprietà quando la riproduzione è semplice

Per la riproduzione non interattiva, le proprietà sono sufficienti.

<LottieView
  source={require('../assets/animations/loading.json')}
  autoPlay
  loop
  speed={1}
/>

Questo stile è buono per:

  • indicatori di caricamento
  • illustrazioni di onboarding passivo
  • stati vuoti decorativi

È dichiarativo e leggibile. Il componente si carica, la riproduzione inizia e React mantiene il controllo. Se la logica dell'animazione può essere descritta interamente da proprietà, tienila lì.

Un caso dichiarativo più avanzato è progress Dove si lega il frame di animazione ad un altro valore. Funziona bene quando il movimento deve riflettere una fonte di progresso esterna, ma è meno comodo per eventi di trigger unico.

Ecco una rapida comparazione visiva prima di passare ai riferimenti:

Usa i riferimenti quando lo stato guida l'animazione

Quando l'utente clicca, attiva o completa un'azione, un riferimento è spesso lo strumento più sicuro. I dati reali mostrano che 68% degli sviluppatori che utilizzano framework ibridi riportano trigger di animazione falliti a causa di un trattamento dei riferimenti improprio in useEffect hookche è il motivo per cui i modelli affidabili costruiti intorno animation.current.play() importano, come notato in questo Capacitor-focalizzato dibattito sui trigger falliti.

Problema non limitato agli app ibride. Si presenta anche in React Native puro, soprattutto quando gli sviluppatori ricreano i riferimenti, eseguono la riproduzione prima del montaggio o legano le chiamate di animazione agli effetti instabili.

import React, { useRef, useState } from 'react';
import { Pressable } from 'react-native';
import LottieView from 'lottie-react-native';

export function LikeButton() {
  const animationRef = useRef<LottieView>(null);
  const [liked, setLiked] = useState(false);

  const onPress = () => {
    if (!animationRef.current) return;

    if (liked) {
      animationRef.current.play(60, 0);
    } else {
      animationRef.current.play(0, 60);
    }

    setLiked(!liked);
  };

  return (
    <Pressable onPress={onPress}>
      <LottieView
        ref={animationRef}
        source={require('../assets/animations/like.json')}
        loop={false}
        autoPlay={false}
        style={{ width: 96, height: 96 }}
      />
    </Pressable>
  );
}

Un modello affidabile di like e unlike

Questo modello si mantiene meglio in produzione rispetto alla chiamata di play() all'interno useEffect ogni volta che cambia lo stato.

Perché funziona:

  • L'evento possiede l'attivatore dell'animazione: Un evento di pressione è un momento stabile per avviare la riproduzione.
  • La referenza rimane locale e persistente: useRef evita le rirerender non necessarie.
  • Il componente evita i conflitti di autoplay: Non vuoi che il comportamento di montaggio combatta il comportamento scatenato dall'utente.

Mistake comuni da evitare:

  1. L'attivazione prima dell'esistenza della referenza
    Se animationRef.current è nullo, non accadrà il playback. Proteggilo.

  2. Utilizzare autoPlay con controlli imperativi
    Scegli un proprietario predefinito per il playback.

  3. Tutto viene guidato da useEffect
    Gli effetti sono utili, ma per le azioni di interfaccia utente spesso aggiungono problemi di timing al posto di eliminarli.

Se un'animazione risponde a un tocco, attivalo all'interno del gestore del tocco per primo. Raggiungi useEffect solo quando la fonte di verità vive al di fuori di quella interazione.

Tuning delle prestazioni per Applicazioni di Produzione

Lottie React Native è una di quelle librerie che sembra leggera fino a quando gli squadre iniziano a caricare grandi file JSON nell'applicazione e si chiedono perché il caricamento iniziale si è regressato. Lo stesso problema non è sempre l'animazione. La strategia di consegna è.

Un infographic che dettaglia tre benefici chiave del tuning delle prestazioni di Lottie: riduzione del peso del pacchetto, miglioramento dei tassi di frame e minor utilizzo della memoria.

Dove le squadre si trovano in difficoltà

Il più semplice errore è quello di caricare ogni animazione direttamente nel JavaScript e caricarlo tutto troppo presto. Secondo questa guida sul caricamento di Lottie JSON in modo errato, sovraccaricare i bundle JS con asset come Lottie JSONs può aumentare i tempi di avvio dell'applicazione di 40% o più su dispositivi di fascia media, e spostarli negli asset nativi per il caricamento a richiesta è un'ottimizzazione critica.

Questo si allinea con ciò che molte squadre vedono nella pratica. Il problema non è un singolo animazione di successo minimo. È la pila:

  • moti di onboarding
  • stati di caricamento
  • reazioni di e-commerce
  • schermate vuote di marchio
  • file di localizzazione e altri asset pesanti di bundle che li accompagnano

Se la tua app già ha un problema di budget di avvio, i file Lottie possono peggiorare la situazione velocemente.

What da cosa ottimizzare per primo

Inizia con l'esportazione stessa. Un'animazione di esportazione disordinata porta complessità che pagherai in seguito in parsing, memoria e stabilità di rendering. Non accetta ogni esportazione del designer come tale.

Utilizza questo elenco di controllo di produzione:

  • Comprimi il JSON prima di spedirlo: Il file più piccoli sono più facili da caricare e meno probabili di gonfiare l'avvio.
  • Sposta le animazioni non critiche fuori dal pacchetto JS: Tieni l'avvio di lancio code concentrato su ciò che l'app necessita immediatamente.
  • Carica le animazioni a richiesta: Rende quando la schermata o l'azione ne ha bisogno.
  • Audita il comportamento degli antichi dispositivi: Un simulatore moderno può nascondere il pagamento costoso di playback.
  • Evita l'utilizzo di grandi file Lottie come decorazione di avvio: Se non è critico per la prima interazione, non dovrebbe competere con l'avvio dell'app.

Per le squadre che lavorano sulle prestazioni mobili serie, La guida di AppLighter alle prestazioni mobili è un utile lettura di accompagnamento perché mette le decisioni di animazione nel contesto più ampio dell'avvio dell'app, della rendering e delle scelte relative alle librerie.

Una dura verità: Una bella animazione che ritarda la prima interazione è di solito un bug del prodotto, non un successo di design.

Dovresti anche pensare oltre React Native in isolamento. Le squadre che lavorano in stack ibridi incontrano problemi simili di caricamento di asset, e la guida più ampia alle prestazioni dell'animazione per gli app __CAPGO_KEEP_0__ si adatta bene anche alle decisioni relative a Lottie. animation performance guidance for Capacitor apps I file locali sono prevedibili. Funzionano in modalità offline, eliminano la variabilità di rete e sono più facili da testare. Sono anche facili da sovraccaricare.

La consegna remota mantiene il binario più leggero, ma ora il tuo animazione ha preoccupazioni di disponibilità, caching e fallback. Quel trade-off è accettabile per la non critica del moto. È rischioso per gli stati UX primari come la conferma dell'acquisto o il successo dell'autenticazione.

For teams doing serious mobile performance work,

AppLighter’s guide to mobile performance is a useful companion read because it puts animation decisions in the larger context of app startup, rendering, and framework trade-offs. One hard truth: A beautiful animation that delays first interaction is usually a product bug, not a design win. You should also think beyond React Native in isolation. Teams working in hybrid stacks run into similar asset-loading problems, and the broader animation performance guidance for __CAPGO_KEEP_0__ apps maps well to Lottie decisions too. Local files versus remote delivery Local files are predictable. They work offline, remove network variability, and are easier to test. They’re also easy to over-bundle. Remote delivery keeps the binary leaner, but now your animation has availability, caching, and fallback concerns. That trade-off is acceptable for non-critical motion. It’s risky for primary UX states like purchase confirmation or authentication success.

A una suddivisione pratica funziona bene:

Tipo di risorsa Predefinito migliore
Animazione di interazione di base Locale, ottimizzato, non eccessivo
Animazione di promozione occasionale A distanza con fallback
Animazione del percorso di avvio Locale solo se assolutamente necessario
Illustrazione di una funzione raramente utilizzata Caricamento su richiesta

Se applichi solo una regola da questa sezione, utilizza questa: Tratta i file JSON di Lottie come asset performanti, non come decorazione innocua.

Risoluzione dei Problemi Comuni di Lottie

Quando Lottie non funziona, la causa è spesso ordinaria. Percorso sbagliato. Dimensione mancante. Tempo di riferimento sbagliato. JSON troppo pesante. La via più veloce per debuggarlo è ridurre le variabili.

L'animazione non si visualizza su Android

In primo luogo, conferma che il file JSON risolve. Poi dà alle dimensioni esplicite al componente.

<LottieView
  source={require('../assets/animations/success.json')}
  autoPlay
  style={{ width: 200, height: 200 }}
/>

Se anche questo fallisce, sostituisci con un diverso animazione conosciuta buona. Questo ti dice se il problema è il file o la configurazione.

La riproduzione è frammentata su dispositivi più vecchi

Questo solitamente indica l'asset, non il componente API.

Prova questi rimedi:

  • Riduci la complessità dell'animazione: Chiedi un esportazione più leggera se il file di origine è pesante.
  • Carica in seguito: Non competere con il lavoro dello schermo iniziale.
  • Testa una versione compressa: Se il file compresso si comporta meglio, hai trovato il punto di bottiglia.
  • Elimina più viste Lottie contemporanee: Più animazioni su uno schermo possono essere troppo.

Il riferimento è nullo o non fa nulla

I riferimenti nulli indicano spesso che il trigger si attiva prima della montatura, o che il componente è stato eliminato condizionalmente.

if (animationRef.current) {
  animationRef.current.play();
}

Mantieni stabile il riferimento con useRefe non ricrea il componente animato inutilmente. Se stai debuggando ripetute stranezze nei costrutti locali, pulire i cache invecchiati può aiutare. Un semplice routine di pulizia del cache di Yarn è a volte sufficiente per eliminare il comportamento degli asset ingannevoli durante lo sviluppo.

L'animazione si presenta male su diverse dimensioni dello schermo

Don’t lasciare che l’animazione definisca la disposizione. Mettila all’interno di un contenitore e dimensionala intenzionalmente.

  • Usa vincoli fissi per icone e reazioni
  • Usa wrapper consapevoli dell’aspetto per illustrazioni più grandi
  • Evita di allungarti fino a tutto lo spazio senza verificare la composizione esportata

La maggior parte dei rapporti ‘Lottie è rotto’ si risolve in problemi di layout, problemi di asset o problemi di timing. La libreria sta spesso facendo esattamente ciò che hai chiesto.

Se hai bisogno di un atout di debug finale, elimina ogni proprietà avanzata, rendi una animazione locale in una vista centrata e costruisci di nuovo da lì. Quell’approccio isolizza i problemi più velocemente di quanto non faccia lo sguardo a uno schermo di produzione affollato.


Capgo aiuta le squadre a distribuire modifiche JavaScript, asset e configurazione ai Capacitor senza dover aspettare la revisione della store. Se mantieni un’app ibrida e hai bisogno di un modo più sicuro per distribuire aggiornamenti, gestire i roll-out in fase di staging e riprendere velocemente da problemi di front-end, Capgo è da valutare.

Aggiornamenti in tempo reale per le app Capacitor

Quando un bug del layer web è attivo, invia la correzione attraverso Capgo invece di attendere giorni per l'approvazione della store. Gli utenti ricevono l'aggiornamento in background mentre le modifiche native rimangono nel normale percorso di revisione.

Inizia subito

Ultimi articoli dal nostro Blog

Capgo ti offre le migliori informazioni che ti servono per creare una vera app mobile professionale.