あなたは、2つの状況のいずれかでいるかもしれません。 1 つは、デザイナーがあなたにLottie JSONを渡して、「今日中にアプリにこのLottieを入れてもらうことはできるか?」と尋ねることです。 または、既にアニメーションをセットアップして、開発環境ではアニメーションが動作するのですが、実機、起動時間、リリースビルドが含まれると、コストが高く感じることです。
Lottie React Nativeの基本的なデモは簡単です。 しかし、実用的な実装はそうではありません。 その違いは、どのようにインストールするか、どのように再生を制御するか、そしてアニメーションファイルを無害なアセットとして扱うか、またはパフォーマンスの予算の一部として扱うかということです。
目次
- LottieはReact Nativeアプリにとって不可欠なものです。
- Lottie開発環境を設定する
- 最初のLottieアニメーションを表示する
- Lottie アニメーション制御のマスター
- 生産アプリのパフォーマンスチューニング
- Lottie の一般的な問題のトラブルシューティング
なぜLottieはReact Nativeアプリに不可欠か
React Nativeで手作業でポリッシュした製品アニメーションを再現したことがある場合、すでにその痛みを知っているだろう。小さな動きの詳細はタイミングロジック、補間、プラットフォームの特性に変化し、動画は近いように見えるが、「近い」はデザイナーが送信したものとは違う。
Lottieはそのワークフローを変えた。Airbnbは2016年にLottieをオープンソース化し、それによりモバイルアニメーションを変え、デザイナーは直接アニメーションを送信できるようになった。エンジニアはフレームごとにアニメーションを再構築する必要がなくなった。企業のいくつかの環境では、そのシフトによりモバイルアプリ開発コストが40%削減された 40%AirbnbのLottieの概要 デザインとエンジニアリングは同じ戦いをしない.
Lottie React Nativeの主な利点は単に「JSONでアニメーションが見えること」だけではない。デザイナーはAfter Effectsで作業し、Bodymovinでエクスポートする。開発者はネイティブバックアッププレイバックで出力をレンダリングするのではなく、カスタム__CAPGO_KEEP_0__に動きを翻訳するのではなく。
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を使用するのは、アニメーションが製品エクスペリエンスの一部である場合、または単に簡単な不透明度または変換トランジションが必要な場合のみである。 ]}] }
Lottie React Nativeは、以下のケースで最も適しています。 ユーザー体験の視点もあります。動きはフィードバックを与え、行動を確認し、ロード中の状態を死んでいるように感じさせません。チームが、インターフェイスにおけるポリッシュ、再利用、信頼について真剣に考えている場合、動きはその議論の重要な部分です。より広い アプリのユーザー体験の議論は、通常、次の場所に終わります: 静的な画面よりも早いフィードバックが勝つ。
Lottieの適切な場所
Lottie React Nativeは、以下のケースで最も適しています。
- ブランドのマイクロインタラクション 例えば、いいね、保存、チェックマーク、購入成功の状態
- オンボーディングのイラスト カスタムの感覚を与える必要があるが、ビデオを配信する必要がない
- ロード中の状態 静的なUIが未完成のように感じる
- 機能の教育 動きを追加する際にGIFやMP4を埋め込まない
基本的な画面遷移のアニメーション問題は、React Nativeのアニメーションツールが簡単に解決できることが多い。ただし、非常に大規模または高度にインタラクティブな動きのシステムでは、JSON形式がトレードオフになるのではなく勝ちとなる。ただし、トレードオフは実際の運用に到達するとより重要になる。実際の運用に到達するまでのチュートリアルは早すぎることが多い。
Lottie開発環境の設定
Lottieの設定には1つの決定が必要です。 Expo管理ワークフローまたはBare React NativeMentalモデルを混ぜないようにしましょう。多くの設定問題は、開発者がExpoのBareワークフローを使用したり、Expoがすべてのネイティブ詳細を抽象化していると誤解したりすることによって発生する。

ワークフローを選択する前にインストールする
アプリがExpoで動作する場合、最速の設定を得るには、カスタムネイティブワークが必要な場合を除いて、Expoのパスを維持しましょう。Bareアプリの場合、または既存のネイティブモジュールに直接コントロールが必要な場合、通常のネイティブ依存関係としてインストールし、iOSとAndroidのビルドを即座に検証する
多くのチームは、設定がプロジェクトタイプと一致している場合にデバッグが簡単になることを過小評価している。同様に、カスタムネイティブ統合を構築するチームは、実際の運用が変更しにくくなる前にExpo開発クライアントワークフローに早期に移行する傾向がある 動きを追加する際にGIFやMP4を埋め込まない 基本的な画面遷移のアニメーション問題は、React Nativeのアニメーションツールが簡単に解決できることが多い。ただし、非常に大規模または高度にインタラクティブな動きのシステムでは、JSON形式がトレードオフになるのではなく勝ちとなる。ただし、トレードオフは実際の運用に到達するとより重要になる。実際の運用に到達するまでのチュートリアルは早すぎることが多い。
Expo管理セットアップ
Expo管理アプリの場合、最小限に抑えましょう。
-
パッケージをインストール
npx expo install lottie-react-native -
Metroを再起動
npx expo start -c -
デバイスまたはエミュレータで確認 ローカルJSONファイルから始めて、非常に小さなアニメーションをレンダリングしてみましょう。 大きなアセットと新しいインストールを同時にデバッグしないでください。
Expoに関しては、以下の実用的な注意点が重要です。
- ローカルファイルを優先してください: リモートアニメーションデバッグは、ライブラリが正常に動作していることを証明しようとしている場合にのみネットワークノイズを追加します。
- リリース時の動作を早期にテストしてください: 開発モードでは、タイミングやパフォーマンスに関連する問題が隠されることがあります。
- アセットパスを監視してください JSONファイルの配置が不正なのは、最も一般的な「何も表示されない」原因の1つです。
Expoは「何が動くか」という最速のルートですが、「何が拡大するか」という最速のルートではありません。
Bare React Nativeの設定
Bareプロジェクトでは、ネイティブ依存関係をインストールして検証することをすぐに実行してください。
-
パッケージをインストール
npm install lottie-react-native -
iOS Podsをインストール
cd ios && pod install && cd .. -
アプリを再構築
npx react-native run-iosまたは
npx react-native run-android
Capacitorライブアップデートの代替手段
Capacitorライブアップデートの代替手段
Capawesomeライブアップデートの代替手段
| Capawesomeライブアップデートの代替手段 | なぜ重要か |
|---|---|
| インストール後は再構築 | ネイティブモジュールは最新のコンパイルが必要 |
実行 pod install |
iOSでは必須 |
| シンプルなローカルJSONを使用 | アセット問題とインストール問題を分離 |
| 両方のプラットフォームで早期テスト | AndroidとiOSは異なる理由で失敗する可能性があります |
パッケージがきちんとインストールされた場合でも最初のアニメーションが表示されない場合は、通常はインストール問題ではありません。アセットパス、コンポーネントサイズ、再生設定が原因です。
最初の動作するアニメーションの表示
最初の動作するアニメーションは面白くない。ローカルファイル。固定サイズ。自動再生。ループは任意。条件付き再生、リモートJSON、重層的なアニメーションエクスポートから始めるのは避けるべきです。

ローカルアニメーションファイルを追加する
アセットフォルダを作成する必要がある場合、以下の手順に従ってください。
assets/
animations/
success.json
名前は単純にし、スペース、奇妙な記号、多くの階層を持つフォルダを避けましょう。パスは明確でなければなりません。 require() ローディング画面や起動後のハンドオフにLottieを使用する場合は、起動パスに大きなアニメーションを配置する前に、慎重に検討してください。特に、React Nativeのスプラッシュスクリーン動作を調整している場合に限ります。
LottieViewを使用してレンダリングする 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,
},
});
アセットパスが正しく解決されることを確認します。
- アセットパスが正しく解決されることを確認します。
- ライブラリが正しくレンダリングされることを確認します。
- 動画再生とサイズを後で調整するための、1つの隔離された場所を提供します。
基本を省略するとすぐにいくつかの注意点が現れます。
- 幅または高さが指定されていない: 動画は存在するが、見ることができない。
- 悪い
require()パス: メトロはファイルを見つけることができません。 - 無効なエクスポート: いくつかの JSON ファイルは技術的には有効ですが、モバイル上で期待どおりに動作しない機能を含んでいます。
最初のレンダリングをローカルで決定論的におこなってください。統合テストを実行しているので、構造をテストする必要はありません。
より良い最初の画面テスト
コンポーネントをシンプルな画面に配置し、背景が中立的な色の場合
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のシミュレータで両方とも機能するようになったら、最初の実際のハードルをクリアしたことになります。そこから、次のステップはアニメーションを追加することではありません。デclarative propsを使用するタイミングと、refsを使用して直接制御するタイミングを学ぶことです。
Lottieアニメーションコントロールのマスター
Lottie React Nativeの多くのバグは、アニメーションが状態に反応する必要があるときに発生します。再生は簡単です。"ユーザーがアイテムを好きになったときにこのセグメントを再生し、ユーザーがアイテムを好きにならなかったときに逆再生し、コンポーネントが再レンダリングされてもストッタリングしない" というのは、混乱するところです。

propsを使用する
非インタラクティブな再生の場合、propsは十分です。
<LottieView
source={require('../assets/animations/loading.json')}
autoPlay
loop
speed={1}
/>
このスタイルは次の場合に適しています:
- ローディングインジケータ
- パッシブなオンボーディングイラスト
- 装飾的な空の状態
デclarativeであり、読みやすいです。コンポーネントがマウントされ、再生が始まり、Reactが制御を握ります。アニメーションロジックがpropsによって完全に説明できる場合は、それをそのままにしておきましょう。
より高度なデclarativeケースは progressアニメーションのフレームを別の値にバインドする、というのは動作が外部の進行源によって反映される場合にはうまく機能しますが、一時的なトリガーイベントの場合には便利ではありません。
ここでは、動作の比較を簡単に視覚化します。リファレンスを取り入れる前に進みます。
状態がアニメーションを制御する場合に、リファレンスを使用します。
ユーザーがタップした、スイッチを切り替えた、またはアクションを完了したとき、リファレンスは通常より安全なツールです。実世界のデータは ハイブリッドフレームワークを使用する開発者が68%、 useEffect hooksで不適切なリファレンスの扱いによるアニメーションのトリガーが失敗したことを報告しています。これは、 animation.current.play() __CAPGO_KEEP_0__に焦点を当てた失敗したトリガーの議論の Capacitor-focused discussion of failed triggers.
信頼できるいいね・いいねしないパターン
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__は置き換えられます。 play() 内部 useEffect 状態の変化ごとに
なぜ機能するか:
- イベントはアニメーションのトリガーを所有する クリックイベントは再生の安定した時点である
- 参照はローカルで永続的である
useRef不要な再レンダリングを避ける - コンポーネントは自動再生の競合を避ける マウントの挙動とユーザーがトリガーした挙動が戦うのを避ける
避けるべき一般的なミス:
-
参照が存在する前にトリガーする
もしanimationRef.currentnull である場合、再生は行われません。守りましょう。 -
使用
autoPlay命令形式の制御とともに
再生のデフォルトの所有者を 1 つ選択してください。 -
すべてを動かす
useEffect
効果は便利ですが、UI アクションの場合、タイミングの問題を追加するのではなく、解決するのではなく、問題を引き起こします。
アニメーションがタップに反応する場合、タップ ハンドラー内でトリガーを実行します。真実の源がそのインタラクション外側に住んでいる場合にのみ
useEffectパフォーマンスチューニング
パフォーマンスチューニング
Lottie React Native は、チームがアプリ バンドルに大きな JSON ファイルを詰め込むと、起動時間が悪化することに気づくまで、軽量なライブラリのように見えるものです。アニメーション自体が常に問題ではありません。配信戦略が問題です。

チームがトラブルに陥る場所
JavaScriptに直接アニメーションをバンドルし、すべてのものを早すぎるように読み込むのは、最も簡単な間違いです。 このガイドに従ってLottie JSONを正しく配送するLottie JSONなどのアセットをJSバンドルにオーバーロードすることは、 中級機器ではアプリ起動時間を40%以上増やす中級機器ではアプリ起動時間を40%以上増やす
Lottie JSONなどのアセットをJSバンドルにオーバーロードすることは、
- 中級機器ではアプリ起動時間を40%以上増やす
- 中級機器ではアプリ起動時間を40%以上増やす
- 中級機器ではアプリ起動時間を40%以上増やす
- 中級機器ではアプリ起動時間を40%以上増やす
- 中級機器ではアプリ起動時間を40%以上増やす
中級機器ではアプリ起動時間を40%以上増やす
優化の第一歩は何を優先するか
エクスポート自体から始めましょう。アニメーションエクスポートが粗悪な場合、後でパース、メモリ、レンダリングの安定性でコストがかかります。デザイナーのエクスポートをすべて受け入れるのではなくて。
このプロダクションチェックリストを使用してください:
- 配信前にJSONを圧縮してください: 小さいファイルはロードしやすく、起動時に膨らみが少ないです。
- 非批判的なアニメーションをJSバンドルから移動してください: Keep launch code focused on what the app needs immediately.
- アニメーションをオンデマンドでロードしてください: 画面やアクションが必要なときにレンダリングしてください。
- 古いデバイスの挙動を検証してください: モダンシミュレータは高価な再生を隠すことができます。
- 起動時装飾として大きなLottieファイルを使用しないでください: 初期インタラクションが重要でない場合、初期起動と競合するべきではない。
モバイルパフォーマンスの取り組みをしているチーム向け モバイルパフォーマンスのガイド __CAPGO_KEEP_0__ アプリのアニメーション性能ガイド
真実の一つ 遅延した初期インタラクションの美しいアニメーションは、通常、デザインの勝利ではなく、製品のバグである。
React Nativeを孤立して考えるのではなく、チームはハイブリッドスタックで動作する問題に遭遇し、より広範な animation performance guidance for Capacitor apps ローカルファイルとリモート配信
ローカルファイルは予測可能です。オフラインでも動作し、ネットワークの変動を排除し、テストも容易です。ただし、過度にバンドルする可能性があります。
リモート配信はバイナリを軽量に保つことができますが、現在のアニメーションは利用可能性、キャッシュ、フォールバックの問題を引き起こします。非批判的な動作の場合、このトレードオフは受け入れ可能です。主なUX状態である購入確認や認証成功の場合、リスクが高まります。
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 practical split works well:
| アセットタイプ | ベター・デフォルト |
|---|---|
| コアインタラクションアニメーション | ローカル、最適化された、オーバーサイズではない |
| まれに使用されるプロモーションアニメーション | リモートにフォールバック |
| スタートアップパスアニメーション | ローカルにのみ必要な場合 |
| まれに使用される機能イラスト | オンデマンドロード |
このセクションから適用するルールの1つだけを使用する場合は、この1つを使用してください: パフォーマンスに敏感な Lottie JSON を装飾として無害なものとみなさない.
よくある Lottie のトラブルシューティング
Lottie が壊れた場合、原因は普通のことだ。間違ったパス。欠けているサイズ。タイミングの悪い参照。重すぎる JSON。デバッグの最速の方法は変数を減らすことだ。
アニメーションは Android でレンダリングされない
最初に、JSON ファイルが解決されることを確認し、コンポーネントに明示的な寸法を与える
<LottieView
source={require('../assets/animations/success.json')}
autoPlay
style={{ width: 200, height: 200 }}
/>
それでも失敗した場合、別の知られている良い動画に置き換える。問題はファイルかセットアップかを判断する
古いデバイスでは再生が乱れる
This usually points to the asset, not the component API.
試してみる修正策:
- アニメーションの複雑さを減らす: ソースファイルが重い場合は、軽いエクスポートを要求する
- 後で読み込む: 競合する初期画面作業に挑戦しないようにしましょう。
- 圧縮されたバージョンをテストしてみましょう。 圧縮ファイルが良好に動作する場合、ボトルネックを見つけたことになります。
- 複数の同時表示のLottieビューを削除してみましょう。 1つの画面に複数のアニメーションを表示すると、過剰な負荷になる可能性があります。
リファレンスがnullの場合、またはプレイが何もしない場合
リファレンスがnullの場合、通常はトリガーがマウントする前に発火したり、コンポーネントが条件付きで削除されたりします。
if (animationRef.current) {
animationRef.current.play();
}
リファレンスを安定させて useRefアニメーションコンポーネントを不要に再作成しないようにしましょう。ローカルビルドで繰り返し不思議な挙動をデバッグしている場合、古いキャッシュをクリアすることで役に立つかもしれません。簡単な Yarnキャッシュクリーンアップルーチン 開発中の不正なアセットの挙動を排除するために、時々十分です。
アニメーションは画面サイズに関係なく正しく表示されません
アニメーションがレイアウトを定義するのではなく、意図的にサイズを設定したコンテナ内に配置する。
- アイコンやリアクションの固定サイズを使用する。
- 大きいイラストのアスペクト認識対応のラッパーを使用する。
- フル幅に伸ばすことなく、エクスポートされた組み合わせの意図を確認せずに伸ばすのを避ける。
ほとんどの「Lottieは壊れた」報告はレイアウト問題、資産問題、タイミング問題であることが多い。ライブラリはよくあなたが要求したことを実行していることが多い。
最終的なデバッグのショートカットが必要な場合は、すべての高度なプロパティを削除し、1つのローカルアニメーションを中央のビューでレンダリングし、そこから再構築する。そのアプローチは、忙しいプロダクション画面を凝視するよりも問題をより速く分離する。
Capgoは、CapacitorアプリにJavaScript、資産、設定の修正を送信するのを待つことなくチームをCapgoに送信するのに役立つ。ハイブリッドアプリを管理している場合に安全な方法で更新を送信し、ステージドロールアウトを取り扱い、フロントエンドの問題から迅速に回復する必要がある場合、Capgoは見る価値がある。 Capgo __CAPGO_KEEP_0__はCapgoにプルリクエストを送信するのに役立つ。