あなたは現在、2つの状況のいずれかにいるかもしれません。あるいは、デザイナーがあなたにLottie JSONを渡し、「今日中にアプリにこの動画を入れてもらうことはできるか？」と尋ねているかもしれません。あるいは、既に動画を組み込んでいて、開発環境では動画が動作するのに、実機、起動時間、リリースビルドが入ってくると、動画が高価な印象を与えるようになったかもしれません。
Lottie React Nativeが面白くなるのはその時です。基本的なデモは簡単です。実用的な実装ではありません。通常、違いはインストール方法、再生の制御方法、動画ファイルを無害なアセットとして扱うか、パフォーマンスの予算として扱うかという点にあります。
目次
- LottieはReact Nativeアプリに不可欠な理由
- Lottieの開発環境を設定する方法
- Lottieアニメーションを表示する
- Lottieアニメーション制御のマスター
- Production アプリのパフォーマンス最適化
- Lottie の一般的な問題のトラブルシューティング
React Native アプリ用の Lottie の重要性
React Native で手動でポリッシュした製品アニメーションを再現することは、すでに痛みを感じていることを知っている場合、すでに知っていることです。小さな動きの詳細は、タイミングロジック、補間、プラットフォームの特性に変わり、アニメーションは近いように見えますが、「近い」はデザイナーが送信したものではありません。
Lottie はこのワークフローを変えた。Airbnb は 2016 年に Lottie をオープンソース化し、そのリリースはモバイルアニメーションを変え、デザイナーが直接アニメーションを送信できるようにし、エンジニアがフレームごとに再構築することを強制するのをやめました。企業環境では、このシフトはモバイルアプリ開発コストを削減しました。 40%以下まで、というのは AirbnbのLottie概要.
デザインとエンジニアリングは同じ戦いをやめよう
Lottie React Nativeの主な利点は単に「JSONで作ったアニメーション」だけではない。分離された責任のある設計です。デザイナーはAfter Effectsで作業し、Bodymovinでエクスポートします。開発者は、動きをカスタムのcodeに翻訳するのではなく、ネイティブバックアッププレイバックで出力をレンダリングします。
アニメーション作業は広がりがちです。単一の祝賀的な状態アニメーションは、デザインレビュー、製品レビュー、Androidの動作、iOSの動作、アクセシビリティ、起動時のパフォーマンスなど、さまざまな面に影響を与えることがあります。Lottieはその面積を狭めます。
実践的なルール Lottieを使用するのは、製品体験の一部としてのアニメーション時のみで、単に簡単な不透明度または変換トランジションが必要な場合のみではありません。
ユーザー体験の観点からも考えてみましょう。動きはフィードバックを与え、行動を確認し、ロード中の状態を死んだように感じさせないようにします。チームが真剣にポリッシュ、ロジン、またはインターフェイスにおける信頼について考える場合、動きはその議論の重要な部分です。より広い アプリのユーザー体験の議論 通常は同じ場所に終わります: フィードバックが速いことは、静的な画面よりも優れています。
Lottieはどのくらいの場所に適しているか
Lottie React Native は、以下のシナリオで最も効果的に機能します:
- ブランドのマイクロインタラクション いいね、保存、チェックマーク、購入成功の状態など
- オンボーディングのイラスト ビデオを配信せずにカスタムフィールを実現する必要がある場合
- ロード中と空の状態 静的UIが未完成のように感じる場合
- 機能の教育 製品がモーションを必要とするが、GIFやMP4を埋め込まない場合
しかし、すべてのアニメーション問題を解決するものではありません。基本的な画面のトランジションでは、React Native の独自のアニメーションツールがしばしばシンプルです。非常に大規模または高度にインタラクティブなモーションシステムの場合、JSON形式は勝ちになるのではなく、トレードオフになります。このトレードオフは、プロダクションに到達すると、トレーニングが早すぎることが多いところで重要になります。
Lottie 開発環境の設定
インストールのパスは、最初に 1 つの決定に依存します: Expo管理ワークフローまたはバーレイアクトネイティブ. Expoのバーレイワークフロー向けの設定ガイドを読みながら開発者が混乱するのは、設定問題の多くが起きている理由です。 また、Expoがすべてのネイティブの詳細を抽象化していることを想定することもあります。
ワークフローを選択する前にインストールする
あなたのアプリがExpoで動作し、最速のセットアップが必要な場合は、Expoのパスに留まることをお勧めします。ただし、カスタムネイティブワークが必要な場合は、既存のネイティブモジュールに依存している場合、またはiOSとAndroidの両方のビルドを直ちに検証する必要がある場合は、通常のネイティブ依存関係としてインストールしてください。
多くのチームは、設定がプロジェクトのタイプと一致しているときにデバッグが容易になることを過小評価しています。 また、カスタムネイティブ統合を実装するチームも、設定がプロジェクトのタイプと一致しているときにデバッグが容易になることを認識しています。 Expo開発クライアントワークフロー Expo管理セットアップ
Expo管理アプリの場合、最小限に抑えましょう。
パッケージをインストールする
-
Metroを再起動する
npx expo install lottie-react-native -
ワークフローを選択する前にインストールする
npx expo start -c -
デバイスまたはシミュレータで確認する ローカル JSON ファイルから始めて、非常に小さなアニメーションをレンダリングしてください。 大きなアセットと新しいインストールを同時にデバッグしないでください。
Expo に関するいくつかの実用的な注意点があります:
- ローカル ファイルを優先してください: リモート アニメーション デバッグは、ライブラリが正常に動作していることを証明するために、ネットワーク ノイズを追加します。
- リリースの動作を早期にテストしてください: 開発モードでは、タイミングやパフォーマンスに関連する問題が隠されることがあります。
- アセット パスを監視してください: JSON ファイルが置かれていないのは、最も一般的な「何もレンダリングされない」原因の 1 つです。
Expo は「動作する」までの最速のルートではありませんが、「拡大する」までの最速のルートではありません。
React Native の基本的なセットアップ
バーレス プロジェクトでは、ネイティブ依存関係をインストールして検証することをすぐに実行してください。
-
パッケージをインストールする
npm install lottie-react-native -
iOS Podsをインストールする
cd ios && pod install && cd .. -
アプリを再構築する
npx react-native run-iosまたは
npx react-native run-android
インストール後、多くのクイックスタートガイドが省略する部分です: 正しく構築されたアプリに依存しているネイティブ依存関係がコンパイルされていない場合、ホットリロードはアプリを正しくコンパイルしない場合にネイティブ依存関係を救うことはできません。
時間を節約するための基本的なワークフロー
次に進む前に、短いチェックリストを使用してください:
| チェック | なぜ重要か |
|---|---|
| インストール後に再構築する | ネイティブモジュールには新しいコンパイルが必要です |
実行 pod install |
iOSはそれ безの信頼性がなくなる |
| 最初はシンプルなローカルJSONを使用してください | アセットの問題からインストールの問題を分離する |
| 両方のプラットフォームを早期にテストしてください | AndroidとiOSは異なる理由で失敗することがあります |
パッケージがきれいにインストールされていても最初のアニメーションが表示されない場合、それは通常インストールの問題ではありません。通常は、アセットパス、コンポーネントサイズ、再生設定が原因です。
最初のLottieアニメーションを表示する
最初の動くアニメーションは面白くない。ローカルファイル。固定サイズ。自動再生。ループは任意。条件付き再生、リモートJSON、重層的なアニメーションエクスポートから始めるのではなく。
ローカルアニメーションファイルを追加してください
アセットフォルダを作成する必要があります。すでにフォルダが存在する場合はスキップしてください:
assets/
animations/
success.json名前を簡単にし、スペース、奇妙な記号、多くの階層のネストを含むフォルダを避けます。多層のネストは避けましょう。 require() パスを明確に保つ。
初期のブランドローディング画面や起動後のハンドオフにLottieを使用している場合、起動パスに大きなアニメーションを配置する前に、慎重に検討する必要があります。特に、React Native スプラッシュ画面の動作を調整している場合に尤もです。 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 つの場所を提供します。
- 基本を省略するとすぐにいくつかの注意点が現れます。
幅または高さが指定されていない場合:
- アニメーションは存在するかもしれませんが、見えません。 paths to stay obvious.
- Bad
require()path: Metroはファイルを見つけることができません。 - Invalid export: JSONファイルは技術的には有効ですが、モバイルで期待どおりに動作しない機能を含むことがあります。
最初のレンダリングをローカルで決定論的におきましょう。Integrationテストではありません。アーキテクチャテストではありません。
最初の画面テストの改善
画面にシンプルな背景とコンポーネントを配置してみましょう:
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の多くのバグは、アニメーションが状態に反応する必要があるときに発生します。Autoplayは簡単です。 “ユーザーがアイテムを好きになったときにこのセグメントを再生し、ユーザーがアイテムを好きにならなかったときに逆再生し、コンポーネントが再レンダリングされたときにスムーズに再生する” というのは、実際に難しいところです。
動画再生が単純な場合には、propsを使用します。
非インタラクティブ再生の場合、propsは十分です。
<LottieView
source={require('../assets/animations/loading.json')}
autoPlay
loop
speed={1}
/>このスタイルは、以下のシナリオに適しています。
- ローディングインジケータ
- パッシブなオンボーディングイラスト
- 空の状態の装飾
宣言的であり、読みやすいです。コンポーネントがマウントされ、再生が開始され、Reactが管理を続けます。アニメーションロジックがpropsによって完全に説明できる場合、そこに留めます。
より高度な宣言的ケースは progressアニメーションフレームを他の値と紐付けする場合です。動きが外部の進行源によって反映される場合、うまく機能しますが、一時的なトリガーイベントの場合、便利ではありません。
ここでは、refsに移る前に、視覚的な比較を簡単に確認してみましょう。
状態がアニメーションを制御する場合には、refsを使用します。
ユーザーがタップ、スイッチ、またはアクションを完了した場合、refsは通常、より安全なツールです。実世界のデータはそれを示しています 68%の開発者がハイブリッドフレームワークを使用しているが、不適切な参照ハンドリングによりアニメーショントリガーが失敗することは報告されています。 useEffect hooks, which is why dependable patterns built around animation.current.play() matter, as noted in this Capacitorに焦点を当てた失敗したトリガーの議論.
その問題は、ハイブリッドアプリに限ったものではありません。React Nativeの純粋な場合でも、開発者が参照を再作成したり、モント前に再生をトリガーしたり、不安定な効果にアニメーション呼び出しを結び付けたりすると、特にそうした場合に現れます。
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>
);
}信頼できるlikedとunlikedのパターン
このパターンは、stateが変更されるたびに play() inside useEffect を呼び出すのではなく、生産性が高いです。
なぜ機能するか:
- イベントはアニメーショントリガーを所有しています: A press eventは再生を開始する安定した時点です。
- 参照はローカルで永続的です:
useRef不要な再レンダリングを避けます。 - コンポーネントは自動再生の競合を避けます: マウントの動作とユーザーがトリガーした動作が相反することはありません。
避けるべき一般的なミス:
-
参照が存在する前にトリガーすることは避けます。
参照がnullの場合、再生は行われません。ガードします。animationRef.currentイマ Percativeコントロールと組み合わせることは避けます。 -
再生のデフォルトのオーナーを1つ選択します。
autoPlayTriggering before the ref exists
If is null, playback won’t happen. Guard it. -
すべての処理を駆動する
useEffect
エフェクトは便利ですが、UIアクションの場合、タイミングの問題をなくすのではなく、加えることが多いため、有用ではありません。
タップのハンドラー内でアニメーションをトリガーするようにしましょう。タップのソースとなるものが外部にある場合にのみ、
useEffectパフォーマンスチューニング
Lottie React Nativeは、チームが大きなJSONファイルをアプリバンドルに詰め込み始めると、起動時間が悪化したりするなど、軽量に見えるライブラリですが、実際は問題が生じます。問題はアニメーション自体ではなく、配信戦略です。
パフォーマンスチューニングの3つの主な利点を示すインフォグラフィック: バンドルサイズの削減、フレームレートの向上、メモリ使用量の低下。
最も簡単なミスは、すべてのアニメーションを直接JavaScriptにバンドルし、すべてのものを早すぎるタイミングでロードすることです。この
Lottie JSONを誤って配信するためのガイド によると、JSバンドルにLottie JSONなどのアセットをオーバーロードすると、中級機器では起動時間が40%以上長くなる可能性があります __CAPGO_KEEP_0__、および、必要なときにオンデマンドでロードするために、ネイティブアセットに移動することは、重要な最適化です。
実践で多くのチームが見るように、単一の小さな成功アニメーションだけでは問題ではありません。問題は、積み重なるものです。
- オンボーディングモーション
- ローダーステート
- エコノミックリアクション
- ブランドの空の画面
- ロケールファイルやその他のバンドル重いアセットが隣り合っている
あなたのアプリがすでに起動時の予算問題がある場合、Lottieファイルはすぐに悪化させることができます。
最適化するものを優先する
エクスポート自体から始めましょう。設計者のエクスポートをそのまま受け入れることは、後でパース、メモリ、レンダリングの安定性のためにコストがかかります。
使用するプロダクションチェックリスト
- JSONを圧縮して配信する: ファイルサイズが小さいと、読み込みが容易になり、起動時に膨張する可能性が低くなります。
- 非批判的なアニメーションをJSバンドルから外す: 起動時にはアプリが必要とするものに焦点を当て、codeを軽量に保つ:
- アニメーションをオンデマンドで読み込む: 画面またはアクションが必要なときにレンダリングする:
- 古いデバイスの挙動を検証する: モダンなシミュレータでは、コストのかかる再生を隠すことができます。
- 起動時装飾として大きなLottieファイルを使用しないようにする: アプリ起動時には、最初のインタラクションに必要ではないものは、起動競争に参加しないようにする:
モバイルパフォーマンスの仕事を真剣に取り組むチームにとっては AppLighterのモバイルパフォーマンスのガイド アプリ起動、レンダリング、フレームワークのトレードオフのより広いコンテキストにアニメーションの決定を置くため、有用な相談相手です。
One hard truth: 初期インタラクションを遅らせた美しいアニメーションは、通常、製品のバグであり、デザインの勝利ではありません。
React Nativeを孤立して考えるのではなく、React Nativeを超えた考え方が必要です。ハイブリッドスタックで作業するチームは、類似のアセットロード問題に遭遇し、より広範な アニメーション性能ガイドラインは、Capacitorアプリに適合します。Lottieの決定も同様です。 ローカルファイルとリモート配信
ローカルファイルは予測可能です。オフラインで動作し、ネットワークの変動を排除し、テストが容易になります。バンドルも簡単です。
リモート配信はバイナリを軽量化しますが、アニメーションの可用性、キャッシュ、フォールバックに関する懸念が生じます。非批判的な動作の場合、このトレードオフは受け入れ可能です。主なUX状態、購入確認や認証成功の場合、リスクが高まります。
実用的分割は効果的です:
アセットタイプ
| デフォルトの改善 | コアインタラクションアニメーション |
|---|---|
| Core interaction animation | ローカル、最適化され、オーバーサイズではない |
| 時々のプロモーション動画 | リモートにフォールバック |
| 起動パスアニメーション | ローカルにのみ絶対に必要な場合 |
| まれに使用される機能のイラスト | オンデマンドロード |
このセクションのルールのうち1つだけを適用する場合は、このルールを使用してください: Lottie JSONをパフォーマンスに敏感なアセットとして、無害な装飾として扱うのではなく.
Lottieの一般的な問題のトラブルシューティング
Lottieが壊れた場合、原因は通常普通のことです。間違ったパス。サイズが欠けている。タイミングが悪い参照。重い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 を安定させて、不要なアニメーション コンポーネントの再生成を避ける。ローカル ビルドで繰り返し不思議な挙動をデバッグしている場合、古いキャッシュをクリアすることが役立つ場合がある。簡単な useRefYarn キャッシュ クリーンアップ ルーチン 開発中のアセットの誤解を招く動作を削除するために、時々これだけが必要になる アニメーションは画面サイズによって異なるように見える
アニメーションがレイアウトを定義しないようにする。意図的にサイズを指定するコンテナ内にアニメーションを配置する
アイコンや反応に固定された境界を使用する
- 大きいイラストにアスペクトを意識したラッパーを使用する
- 全幅に伸ばすことなく、エクスポートされた組み合わせの意図を確認することなく伸ばすのを避ける
- Avoid stretching to full width without checking the export’s intended composition
Most “Lottieは壊れた”と報告される報告の多くはレイアウトの問題、資産の問題、タイミングの問題に終わる。ライブラリはよくあなたが要求したことを正確に実行している。
あなたが最終的なデバッグのショートカットが必要なら、すべての高度なプロパティを削除し、1つのローカルアニメーションを中央のビューでレンダリングし、そこから再構築する。そうしたアプローチは、忙しいプロダクション画面を凝視するよりも、問題をより速く分離する。
Capgoは、CapacitorアプリにJavaScript、資産、設定の修正を送信するのを待つことなくチームを支援する。アプリをハイブリッドで管理し、安全な方法で更新をプッシュし、ステージドロールアウトを取り扱い、フロントエンドの問題から迅速に回復する必要がある場合 Capgo は見る価値がある。
