ロティ React Native
Mobile Guides

Lottie React Native

CapgoのLottie React Nativeガイド

Lottie React Native

あなたは、2つの状況のいずれかでいるかもしれません。 1 つは、デザイナーがあなたにLottie JSONを渡して、「今日中にアプリにこのLottieを入れてもらうことはできるか?」と尋ねることです。 または、既にアニメーションをセットアップして、開発環境ではアニメーションが動作するのですが、実機、起動時間、リリースビルドが含まれると、コストが高く感じることです。

Lottie React Nativeの基本的なデモは簡単です。 しかし、実用的な実装はそうではありません。 その違いは、どのようにインストールするか、どのように再生を制御するか、そしてアニメーションファイルを無害なアセットとして扱うか、またはパフォーマンスの予算の一部として扱うかということです。

目次

なぜ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とBare React NativeのプロジェクトでLottieアニメーションの設定手順のフローチャート

ワークフローを選択する前にインストールする

アプリがExpoで動作する場合、最速の設定を得るには、カスタムネイティブワークが必要な場合を除いて、Expoのパスを維持しましょう。Bareアプリの場合、または既存のネイティブモジュールに直接コントロールが必要な場合、通常のネイティブ依存関係としてインストールし、iOSとAndroidのビルドを即座に検証する

多くのチームは、設定がプロジェクトタイプと一致している場合にデバッグが簡単になることを過小評価している。同様に、カスタムネイティブ統合を構築するチームは、実際の運用が変更しにくくなる前にExpo開発クライアントワークフローに早期に移行する傾向がある 動きを追加する際にGIFやMP4を埋め込まない 基本的な画面遷移のアニメーション問題は、React Nativeのアニメーションツールが簡単に解決できることが多い。ただし、非常に大規模または高度にインタラクティブな動きのシステムでは、JSON形式がトレードオフになるのではなく勝ちとなる。ただし、トレードオフは実際の運用に到達するとより重要になる。実際の運用に到達するまでのチュートリアルは早すぎることが多い。

Expo管理セットアップ

Expo管理アプリの場合、最小限に抑えましょう。

  1. パッケージをインストール

    npx expo install lottie-react-native
  2. Metroを再起動

    npx expo start -c
  3. デバイスまたはエミュレータで確認 ローカルJSONファイルから始めて、非常に小さなアニメーションをレンダリングしてみましょう。 大きなアセットと新しいインストールを同時にデバッグしないでください。

Expoに関しては、以下の実用的な注意点が重要です。

  • ローカルファイルを優先してください: リモートアニメーションデバッグは、ライブラリが正常に動作していることを証明しようとしている場合にのみネットワークノイズを追加します。
  • リリース時の動作を早期にテストしてください: 開発モードでは、タイミングやパフォーマンスに関連する問題が隠されることがあります。
  • アセットパスを監視してください JSONファイルの配置が不正なのは、最も一般的な「何も表示されない」原因の1つです。

Expoは「何が動くか」という最速のルートですが、「何が拡大するか」という最速のルートではありません。

Bare React Nativeの設定

Bareプロジェクトでは、ネイティブ依存関係をインストールして検証することをすぐに実行してください。

  1. パッケージをインストール

    npm install lottie-react-native
  2. iOS Podsをインストール

    cd ios && pod install && cd ..
  3. アプリを再構築

    npx react-native run-ios

    または

    npx react-native run-android

Capacitorライブアップデートの代替手段

Capacitorライブアップデートの代替手段

Capawesomeライブアップデートの代替手段

Capawesomeライブアップデートの代替手段 なぜ重要か
インストール後は再構築 ネイティブモジュールは最新のコンパイルが必要
実行 pod install iOSでは必須
シンプルなローカルJSONを使用 アセット問題とインストール問題を分離
両方のプラットフォームで早期テスト AndroidとiOSは異なる理由で失敗する可能性があります

パッケージがきちんとインストールされた場合でも最初のアニメーションが表示されない場合は、通常はインストール問題ではありません。アセットパス、コンポーネントサイズ、再生設定が原因です。

最初の動作するアニメーションの表示

最初の動作するアニメーションは面白くない。ローカルファイル。固定サイズ。自動再生。ループは任意。条件付き再生、リモートJSON、重層的なアニメーションエクスポートから始めるのは避けるべきです。

A modern developer workspace with a laptop displaying code and a monitor showing a mobile animation app.

ローカルアニメーションファイルを追加する

アセットフォルダを作成する必要がある場合、以下の手順に従ってください。

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の多くのバグは、アニメーションが状態に反応する必要があるときに発生します。再生は簡単です。"ユーザーがアイテムを好きになったときにこのセグメントを再生し、ユーザーがアイテムを好きにならなかったときに逆再生し、コンポーネントが再レンダリングされてもストッタリングしない" というのは、混乱するところです。

Lottieにおけるデclarativeとイマペラティブなアニメーション制御方法の比較表、特定の用途を強調する。

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 不要な再レンダリングを避ける
  • コンポーネントは自動再生の競合を避ける マウントの挙動とユーザーがトリガーした挙動が戦うのを避ける

避けるべき一般的なミス:

  1. 参照が存在する前にトリガーする
    もし animationRef.current null である場合、再生は行われません。守りましょう。

  2. 使用 autoPlay 命令形式の制御とともに
    再生のデフォルトの所有者を 1 つ選択してください。

  3. すべてを動かす useEffect
    効果は便利ですが、UI アクションの場合、タイミングの問題を追加するのではなく、解決するのではなく、問題を引き起こします。

アニメーションがタップに反応する場合、タップ ハンドラー内でトリガーを実行します。真実の源がそのインタラクション外側に住んでいる場合にのみ useEffect パフォーマンスチューニング

パフォーマンスチューニング

Lottie React Native は、チームがアプリ バンドルに大きな JSON ファイルを詰め込むと、起動時間が悪化することに気づくまで、軽量なライブラリのように見えるものです。アニメーション自体が常に問題ではありません。配信戦略が問題です。

Lottie パフォーマンスチューニングの 3 つの主な利点を示すインフォグラフィック: バンドルサイズの削減、フレームレートの向上、メモリ使用量の低下。

チームがトラブルに陥る場所

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にプルリクエストを送信するのに役立つ。

リアルタイム更新のCapacitorアプリ

When a web-layer bug is live, ship the fix through Capgo instead of waiting days for app store approval. Users get the update in the background while native changes stay in the normal review path.

ウェブ層のバグが生じた場合、__CAPGO_KEEP_0__を通して修正を配信するのではなく、数日間待ってアプリストアの承認を待つのではなく、ユーザーはバックグラウンドで更新を受け取り、ネイティブの変更は通常のレビュー経路に残す。

ページ/エリア: ホームページ マーケティング コピー。役割: ウェブサイト コピー文。見つける場所: コンポーネント HumanSupport.astro、コンポーネント pricing/Plans.astro。メッセージキー `home_hero_human_support` (Home Hero Human Support)。

今すぐ始めよう

Capgo gives you the best insights you need to create a truly professional mobile app.