당신은 현재 두 가지 위치 중 하나에 있을 것입니다. 디자이너가 당신에게 Lottie JSON을 제공하고, “오늘 앱에 이걸 넣을 수 있나요?”라고 묻는 경우, 또는 이미 그것을 연결하고 애니메이션 개발 단계에서 작동하는 것을 발견했지만, 실제 장치, 시작 시간, 및 릴리즈 빌드가 들어오면 비용이 많이 들 것이라는 것을 알게 된 경우.
Lottie React Native는 흥미로운 곳에서 시작됩니다. 기본 데모는 쉽습니다. 프로덕션 준비된 implementation은 그렇지 않습니다. 차이점은 일반적으로 설치 방법, 플레이백 제어, 그리고 애니메이션 파일을 무해한 자산으로 대우하는지, 성능 예산의 일부로 대우하는지에 따라 결정됩니다.
내용목록
- Why Lottie Is Essential for React Native Apps
- 설계와 엔지니어リング이 같은 싸움에서 싸우지 않도록
- Choose the workflow before you install
- Lottie 애니메이션 제어를 마스터하세요
- 생산 앱의 성능 최적화
- Lottie 문제를 해결하는 방법
Lottie는 React Native 앱에서 필수적인 이유
React Native에서 고급 제품 애니메이션을 재현하려는 시도가 실패한 적이 있나요? 애니메이션의 작은 동작 세부 사항은 타이밍 논리, 이격, 플랫폼 특이성의 쌓인 문제로 변합니다. 애니메이션은 가깝게 보이지만 '가깝게'는 디자이너가 배송한 것과는 다릅니다.
Lottie는 이 워크플로를 바꾸었습니다. 에어비앤비는 2016년에 Lottie를 오픈 소스로 출시했으며, 이 출시로 모바일 애니메이션을 디자이너가 직접 배송할 수 있도록 해 주었습니다. 엔터프라이즈 환경에서 이 변화는 개발 비용을 40%까지 줄였습니다. 에어비앤비의 Lottie 개요디자인과 엔지니어링은 같은 싸움을 더 이상 싸우지 않습니다 Lottie React Native의 주요 이점은 'JSON에서 예쁜 애니메이션'만이 아니라 관심사 분리입니다. 디자이너는 After Effects에서 작업하고 Bodymovin으로 내보내고, 개발자는 원본을 native-backup 플레이백으로 렌더링합니다. 개발자는 motion을 커스텀 __CAPGO_KEEP_0__로 번역하지 않습니다..
이것은 중요합니다. 애니메이션 작업은 확산하는 경향이 있습니다. 단 하나의 축하 애니메이션은 디자인 리뷰, 제품 리뷰, 안드로이드 동작, iOS 동작, 접근성, 시작 시간에 영향을 미칩니다. Lottie는 이 표면 영역을 좁힙니다.
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.
Lottie를 사용할 때는 애니메이션이 제품 경험의 일부일 때, 단순한 불투명도나 translate 전환만 필요할 때만 사용하세요.
__CAPGO_KEEP_0__ __CAPGO_KEEP_0__
There’s also a user experience angle. Motion gives feedback, confirms actions, and makes loading states feel less dead. If your team is thinking seriously about polish, retention, or trust in the interface, animation is part of that conversation. The broader 애플리케이션 사용자 경험 토론 일반적으로 빠른 feedback가 정적 화면보다 더 좋다.
Lottie가 가장 잘 맞는 곳
Lottie React Native는 다음에 가장 잘 작동합니다.
- 브랜드 미니 인터랙션 좋아요, 저장, 체크마크, 구매 성공 상태와 같은 것
- 온보딩 일러스트 비디오를 배송하지 않고 커스텀으로 느끼게 해야 하는 것
- 로딩 및 빈 상태 정적 UI가 완성되지 않은 곳
- 기능 교육 when product wants motion without embedding GIFs or MP4s
What it doesn’t solve is every animation problem. For basic screen transitions, React Native’s own animation tools are often simpler. For very large or highly interactive motion systems, the JSON format can become a trade-off instead of a win. That trade-off becomes more important once you hit production, which is where most tutorials stop too early.
Lottie 개발 환경 설정
Capgo는 JSON 형식의 애니메이션을 사용하여 제품의 동작을 표현하는 데 도움이 됩니다. 그러나 모든 애니메이션 문제를 해결하지는 않습니다. 기본적인 화면 전환 애니메이션을 위해서는 React Native의 내장 애니메이션 도구가 더 간단합니다. 매우 큰 또는 상호작용이 많은 동작 시스템의 경우 JSON 형식이 이점이 아닌 단점이 될 수 있습니다. 이 단점은 프로덕션 환경에서 더 중요해집니다. 대부분의 튜토리얼은 너무 일찍 끝나기 때문에 프로덕션 환경에서 이 단점이 더 중요해집니다. 설치 경로는 첫 번째 결정에 따라 달라집니다.Expo 관리 워크플로우 또는 Bare React Native

워크플로우를 선택하기 전에 설치하세요.
앱이 Expo에 살고 있고 가장 빠른 설정을 원한다면, Expo 경로를 유지하세요. Expo가 모든 네이티브 세부 사항을 추상화하지 않는다는 것을 알고 있다면, Expo 경로를 유지하세요. Bare 앱에 있다면, 또는 이미 네이티브 모듈에 직접 제어를 필요로 하는 경우, 일반 네이티브 의존성을 설치하고 iOS 및 Android 빌드를 즉시 검증하세요.
많은 팀이 설정을 프로젝트 유형과 일치시키지 않아 디버깅이 더 어려워지는 것을 과소 평가합니다. 프로젝트 유형과 일치시키지 않으면 디버깅이 더 어려워질 수 있습니다. 따라서 많은 팀이 커스텀 네이티브 통합을 위해早い 시기에 Expo 개발 클라이언트 워크플로우 앱이 더 어려워질 때까지 기다리지 말고 사용하세요.
Expo 관리 설정
Expo 관리 앱의 경우, 최소한으로 유지하세요.
-
패키지를 설치하세요
npx expo install lottie-react-native -
메트로를 재시작하세요
npx expo start -c -
장치 또는 시뮬레이터에서 확인하세요 시작하기 전에 로컬 JSON 파일을 사용하여 매우 작은 애니메이션을 렌더링하세요. 큰 자산과 새로운 설치를 동시에 디버깅하지 마세요.
Expo에서 몇 가지 실용적인 주의 사항이 중요합니다:
- 로컬 파일을 우선으로 사용하세요: 원격 애니메이션 디버깅은 네트워크 노이즈를 추가하여 라이브러리가 작동하는지 증명하려는 경우에만 문제를 일으킵니다.
- 릴리즈 동작을 빠르게 테스트하세요: 개발 모드에서는 타이밍과 성능과 관련된 문제를 숨길 수 있습니다.
- 자산 경로를 감시하세요: __CAPGO_KEEP_0__는 가장 일반적인 'nothing이 렌더링된다' 원인 중 하나입니다.
__CAPGO_KEEP_0__는 'it works'로 가는 가장 빠른 길이지만 'it scales'로 가는 가장 빠른 길이 아닙니다.
__CAPGO_KEEP_0__ 설정
__CAPGO_KEEP_0__ 프로젝트에서 네이티브 의존성을 설치하고 유효성 검사하세요.
-
__CAPGO_KEEP_0__ 패키지를 설치하세요.
npm install lottie-react-native -
__CAPGO_KEEP_0__ iOS pods를 설치하세요.
cd ios && pod install && cd .. -
__CAPGO_KEEP_0__ 앱을 재구성하세요.
npx react-native run-ios또는
npx react-native run-android
설치 후 앱을 완전히 재구성하는 것을 잊지 마세요. 네이티브 의존성이 올바르게 컴파일되지 않은 경우 핫 리로드가 네이티브 의존성을 구동하지 못합니다.
__CAPGO_KEEP_0__ 워크플로우는 시간을 절약하는 체크리스트입니다.
이러한 짧은 체크리스트를 사용하세요.
| __CAPGO_KEEP_0__를 확인하세요. | Why it matters |
|---|---|
| 설치 후 재구축 | 네이티브 모듈은 최신 컴파일이 필요합니다. |
실행 pod install |
iOS는 그것이 없으면 신뢰할 수 없습니다. |
| 단순한 로컬 JSON을 사용하세요. | 자산 문제와 분리된 설치 문제 |
| 두 플랫폼 모두 초기에 테스트하세요. | Android와 iOS는 서로 다른 이유로 실패할 수 있습니다. |
패키지가 깨끗하게 설치되지만 첫 번째 애니메이션을 표시하지 못한다면, 일반적으로 설치 문제가 아닙니다. 그것은 일반적으로 자산 경로, 컴포넌트 크기, 또는 재생 설정과 관련이 있습니다.
첫 번째 동작하는 애니메이션은 흥미롭지 않아야 합니다. 로컬 파일. 고정 크기. 자동 재생. 반복 옵션. 조건부 재생, 원격 JSON, 또는 heavly layerd 애니메이션 export와 함께 시작하지 마세요.
Displaying Your First Lottie Animation

지역 애니메이션 파일을 추가하세요
자신이 이미 하나가 있으면 asset 폴더를 생성하세요:
assets/
animations/
success.json
이름이 간단해야 합니다. 공백, 이상한 기호, 여러 계층으로 구성된 폴더를 피하세요. 경로가 명확해야 합니다. require() Cloudflare, Capacitor, GitHub, Capgo, code, API, SDK, CLI, npm, bun
Lottie를 사용하여 초기 로딩 화면이나 런칭 후 전환 화면으로 사용할 경우, 시작 경로에 큰 애니메이션을 넣기 전에 신중히 고려하세요. 특히 React Native 스플래시 화면 동작을 튜닝하는 경우 especialmente. LottieView를 사용하여 렌더링하세요.
대형 화면 파일에 직접 넣기보다는 전용 컴포넌트를 생성하세요:
3 가지 유용한 일을 수행합니다:
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,
},
});
라이브러리가 올바르게 렌더링되는지 증명합니다.
- 자산 경로가 올바르게 해결되는지 증명합니다.
- __CAPGO_KEEP_0__
- 이것은 재생 및 크기 조정을 나중에 조정할 수 있는 단일 고립된 장소입니다.
기본 사항을 생략하면 즉시 나타나는 몇 가지 함정들이 있습니다:
- 너무나도 가로 또는 높이가 없습니다: 애니메이션은 존재할 수 있지만 보이지 않을 수 있습니다.
- 잘못된
require()경로: 메트로가 파일을 찾을 수 없습니다. - 유효하지 않은 내보내기: 일부 JSON 파일은 기술적으로 유효하지만 모바일에서 예상치 못한 동작을 하는 특성이 포함되어 있습니다.
__CAPGO_KEEP_0__
첫 번째 렌더링을 지역화하고 결정적입니다. 통합을 테스트하는 것이 아님에 유의하세요.
더 나은 첫 번째 화면 테스트
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',
},
});
iOS 및 Android 시뮬레이터에서 모두 작동하는지 확인하면 첫 번째 실제 장벽을 넘었습니다. 그 다음 단계는 더 많은 애니메이션을 추가하는 것이 아니라, refs를 사용하여 직접 제어하는 데 적절한 경우를 declarative props를 사용하는 것입니다.
Lottie 애니메이션 제어를 마스터하세요
Lottie React Native 버그의 대부분은 애니메이션에 상태에 반응할 때 나타납니다. 자동 재생은 쉽습니다. '사용자가 아이템을 좋아할 때 이 구간을 재생하고, 사용자가 아이템을 싫어할 때 역방향으로 재생하고, 컴포넌트가 다시 렌더링될 때 stutter하지 않도록' 하는 것은 복잡한 곳입니다.

props를 사용할 때는 재생이 단순할 때
비활성화된 재생이 단순할 때 props만 사용하면 됩니다.
<LottieView
source={require('../assets/animations/loading.json')}
autoPlay
loop
speed={1}
/>
이 스타일은 다음에 좋습니다.
- 로딩 인디케이터
- 비활성화된 온보딩 일러스트레이션
- 빈 상태의 데코레이션
이 스타일은 declarative이고 읽기 쉽습니다. 컴포넌트가 마운트되면 재생이 시작되고, React가 제어를 유지합니다. 애니메이션 로직이 props로 완전히 설명될 수 있다면 그곳에 남겨두세요.
더 복잡한 declarative 사례는 progressanimation frame을 다른 값과 연결하는 곳입니다. motion이 외부 진행 소스에 반영되어야 할 때는 잘 작동하지만, one-off trigger 이벤트의 경우 편리하지 않습니다.
이전으로 이동하기 전에 빠른 시각 비교를 보세요:
state가 애니메이션을 제어할 때 refs를 사용하세요.
사용자가 탭, 토글, 또는 작업을 완료할 때, refs는 일반적으로 더 안전한 도구입니다. 실제 세계 데이터는 68%의 개발자가 하이브리드 프레임워크를 사용하여 애니메이션 트리거를 실패시킨 이유는 hooks에서 refs를 적절하게 처리하지 못했기 때문입니다. useEffect __CAPGO_KEEP_0__에 집중된 실패한 트리거에 대한 이 논의에서 언급된 것처럼, 이러한 문제는 프레임워크에 국한되지 않습니다.plain React Native에서도 나타납니다. 개발자가 refs를 재생성하거나, 애니메이션 호출을 불안정한 효과에 묶거나, 애니메이션 프레임을 mount하기 전에 호출하는 경우가 많습니다. animation.current.play() 믿을 수 있는 liked와 unliked 패턴 Capacitor-focused discussion of failed triggers.
refs를 사용하는 것이 더 안전합니다.
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>
);
}
__CAPGO_KEEP_0__에 대한 논의
hooks에서 refs를 적절하게 처리하지 못한 경우 play() inside useEffect every time state changes.
왜 작동하는가:
- 이벤트는 애니메이션 트리거를 소유합니다: 클릭 이벤트는 재생을 시작하는 안정적인 순간입니다.
- 리퍼는 지역적이고 지속적입니다:
useRef필요하지 않은 리렌더링을 피합니다. - 컴포넌트는 자동 재생 충돌을 피합니다. 마운트 동작과 사용자 트리거 동작이 충돌하지 않도록 하세요.
주의할 만한 일반적인 실수:
-
리퍼가 존재하기 전에 트리거하는 경우
만약animationRef.currentnull이면 재생이 일어나지 않습니다. 보호하세요. -
Using
autoPlay명령형 제어와 함께
재생의 기본 소유자를 한 개 선택하세요. -
모든 것을 통제하는
useEffect
효과는 유용하지만 UI 액션에 사용할 때 대신 타이밍 문제를 추가하는 대신 제거하는 데 도움이 됩니다.
터치 핸들러 내부에서 애니메이션을 트리거하세요.
useEffect만약 소스 트루스는 그 상호 작용 외부에 존재한다면
생산 앱의 성능 최적화
Lottie React Native은 팀이 큰 JSON 파일을 앱 번들에 넣고 시작 시간이 후퇴하는 이유를 궁금해하는 것을 보면서 가볍게 보이는 라이브러리 중 하나입니다. 애니메이션 자체가 항상 문제가 되지 않습니다. 전달 전략이 문제입니다.

팀이 문제에 빠지는 곳
The easiest mistake is bundling every animation directly into JavaScript and loading it all too early. According to 이 문서에 설명된 Lottie JSON을 잘못 배포하는 것에 대해이 가이드에 따르면 JS 번들을 오버로드하는 Lottie JSON과 같은 자산으로 인해 중간급 장치에서 앱 시작 시간이40% 이상 증가할 수 있습니다
그것들을 네이티브 자산으로 로드하는 데 필요한 시간을 지연시키기 때문에, 자원 로딩을 지연시키는 것은 중요합니다.
- 실제로 많은 팀이 이러한 문제를 경험합니다. 문제는 단 하나의 작은 성공 애니메이션이 아니라, 쌓인 애니메이션입니다.
- 온보딩 모션
- 로더 상태
- 전자 상거래 반응
- 브랜드 비어있는 화면
지역 파일 및 다른 번들-heavy 자산이 그들 옆에 앉아있는 것
What to optimize first
export을 시작하세요. export 자체가 복잡하고, 나중에 parsing, 메모리, 렌더링 안정성에서 비용을 지불할 수 있습니다. 모든 디자이너 export을 그대로 받아들이지 마세요.
이 프로덕션 체크리스트를 사용하세요:
- JSON을 압축하세요: 작은 파일은 로드하기가 더 쉬우며, 시작 시간을 늘리지 않습니다.
- 비중요한 애니메이션을 JS 번들에서 제거하세요: Keep launch code focused on what the app needs immediately.
- 애니메이션을 필요할 때 로드하세요: 화면이나 액션에 필요한 때 렌더링하세요.
- 오래된 기기 동작을 감사하세요: 최신 시뮬레이터는 비용이 많이 드는 재생을 숨길 수 있습니다.
- 대형 Lottie 파일을 시작 화면으로 사용하지 마세요: 앱 런칭과는 관련이 없는 첫 번째 상호 작용이 중요하지 않다면, 그것은 앱 런칭과 경쟁해서는 안 됩니다.
serious mobile performance work를 하는 팀에게는 AppLighter의 모바일 성능 가이드 앱 시작, 렌더링, 프레임워크 트레이드 오프의 더 큰 맥락에서 애니메이션 결정에 도움이 됩니다.
어떤 진실: 첫 번째 상호 작용을 늦추는 아름다운 애니메이션은 일반적으로 디자인 승리보다는 제품 버그입니다.
Capacitor을 독립적으로 생각하지 말고 React Native을 넘어서 생각하십시오. Hybrid 스택에서 작업하는 팀은 유사한 자산 로딩 문제를 만나고, 더 광범위한 Capacitor 앱의 애니메이션 성능 지침 Lottie 결정에도 잘 맞습니다.
Local 파일 versus Remote 전송
Local 파일은 예측 가능합니다. 오프라인에서 작동하고 네트워크 불안정성을 제거하고 테스트하기 쉽습니다. 또한 쉽게 오버-배ंडल 될 수 있습니다.
Remote 전송은 바이너리 크기를 줄이지만 애니메이션의 가용성, 캐싱, 대체 문제가 발생합니다. 비중심적인 동작에 대한 이 트레이드 오프는 받아 들일 수 있습니다. 그러나 주요 UX 상태인 구매 확인 또는 인증 성공과 같은 경우는 위험합니다.
실용적인 분할이 잘 작동합니다.
| 자산 유형 | 기본값을 더 좋게 |
|---|---|
| 핵심 상호작용 애니메이션 | 지역 최적화, 과도한 것은 아님 |
| 일부 홍보적인 움직임 | 대체로 fallback |
| 시작 경로 애니메이션 | 절대 필요할 때만 지역 |
| 적게 사용되는 기능 설명 | 요청 시 로드 |
이 섹션의 규칙 중 하나만 적용할 경우, 이 규칙을 사용하세요. Lottie JSON을 성능에 민감한 자산으로 다루세요, 무해한 장식으로는 안됩니다..
Lottie 문제 해결
Lottie가 깨졌을 때, 일반적인 원인은 잘못된 경로, 크기 누락, 참조 타이밍 오류, overweight JSON입니다. 디버깅의 가장 빠른 방법은 변수를 줄이는 것입니다.
Android에서 애니메이션 렌더링이 안됩니다.
첫 번째로 JSON 파일이 해결되는지 확인하세요. 그리고 컴포넌트에 명시적인 크기를 주세요.
<LottieView
source={require('../assets/animations/success.json')}
autoPlay
style={{ width: 200, height: 200 }}
/>
그렇지 않으면, 다른 알려진 좋은 애니메이션으로 교체하세요. 그럼 파일이 문제인지, 설정이 문제인지 알 수 있습니다.
오래된 기기에서 플레이백이 끊기게 됩니다.
이 경우 일반적으로 자산이 문제인 것입니다, 컴포넌트가 문제인 것은 아닙니다 API.
이러한 해결책을 시도하세요:
- 애니메이션 복잡성을 줄이세요: 원본 파일이 무거운 경우 가벼운 내보내기 요청하세요.
- 나중에 로드하세요: 초기 화면 작업과 경쟁하지 마세요.
- 압축된 버전을 테스트하세요: 압축된 파일이 더 잘 동작한다면, 병목 현상을 찾았습니다.
- 여러 동시 Lottie 뷰를 제거하세요: 화면에 여러 애니메이션을 보여주면 너무 많아집니다.
ref가 null이거나 play가 아무런 효과가 없다면
null ref는 일반적으로 mount 전에 트리거가 발생하거나 컴포넌트가 조건부로 제거된 경우입니다.
if (animationRef.current) {
animationRef.current.play();
}
ref를 안정적으로 유지하고 useRef불필요한 애니메이션 컴포넌트를 다시 생성하지 마세요. 개발 중에 반복적으로 이상한 현상이 발생하는 경우, 오래된 캐시를 삭제하는 것이 도움이 될 수 있습니다. 간단한 Yarn 캐시 정리 루틴 개발 중에 애니메이션 동작에 대한 오해를 제거하기 위해 종종 충분합니다.
화면 크기에 따라 애니메이션이 잘못 보인다면
__CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
- __CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
Capgo helps teams ship JavaScript, asset, and config fixes to Capacitor apps without waiting on store review. If you maintain a hybrid app and need a safer way to push updates, handle staged rollouts, and recover quickly from front-end issues, Capgo __CAPGO_KEEP_0__