一.困境
アニメーションを作成する際、避けられない経験があります:
Digging through frameworks for reference, guessing durations, manually creating Bézier curves, and re-making animations with nothing more than a GIF for reference
GIF 画像/効果動画を参考に模倣し、アニメーションの持続時間を推測し、ベジェ曲線を手動で作成……パラメータを繰り返し調整し、何度も目視で効果を確認し、最後に発見:
-
多くの詳細な差異が存在
-
効果が十分に繊細ではない
-
互換性などの制約により、一部の効果は実現できない
好不容易実現したが、再現度が要求に達しない。通常はデザイナーが妥協するか、一緒に半日かけて調整し、相手が満足するまで修正する。結果、詳細を調整するのに費やす時間が予想の何倍にもなり、効果はまだ物足りない
経験豊富なデザイナーは AE(Adobe After Effects)から有用な情報をコピーできる。例えばベジェ曲線パラメータ、アニメーション持続時間……さらに実装思路を提供できることもあるが、いずれにせよ、動画を参考にしてアニメーションを実装するのは模写のようなもので、効果の差異は避けられない。よく考えてみると、このプロセスにおいて、アニメーションはデザイナーにとってかなりの作業量だが、エンジニア側にはさらに大きな作業量がある。各ターゲットプラットフォームに 1 つずつ作業量があり、これらの作業は一度きりで、ほとんど再利用できず、維持も困難(数百行の並行、直列アニメーションシーケンスから特定のパラメータを見つけ出し、0.1 を追加する)
では、なぜ 1 枚の絵が完成した後、何度も模写する必要があるのか?1 + N の作業量を 1 + 0.n に削減し、同時に効果の高度な再現を保証できるのか?
二.探索
この絵がすでに完成しているなら、ゼロから手動で模写する必要はない。ツールを使用して絵から必要な情報を抽出し、ターゲットプラットフォームでこの情報を使用してアニメーションを再構築できる:
Now engineers can use exactly what the designer intended, exactly how it was made.
これにより:
-
高い再現度を保証(デザイン原稿から直接取得したアニメーションパラメータは、確実に信頼できる)
-
複数エンドの
N份の作業量を削減(基礎アニメーションコードを高度に再利用可能にし、具体的な効果を構成可能にする)
以前経験豊富なデザイナーがアニメーションパラメータをコピーしていたのと同じように、デザイン稿から十分な必要な情報をエクスポートすれば、再現度を確保できる(exactly how it was made)
完全なアニメーションパラメータがあれば、さらに構成化を進められる。ターゲットプラットフォームでこの構成データを解析し、軌跡の再生(アニメーションの再構築)を完了する。各プラットフォームで業務無関係のアニメーション基礎ライブラリを実装し、業務層は構成データを基礎ライブラリに入力するだけでよい。その後、構成データがアニメーション効果、タイミング及其び組合せを制御する。これで N の業務層作業量を 0.n に削減できる
三.目標定位
Lottie はまさにそのような方案で、複数エンドでのアニメーション実装の業務作業量を削減(easily)し、同時にアニメーション効果の高度な再現を保証(high-quality)したい:
Easily add high-quality animation to any native app.
具体的には:
Lottie is an iOS, Android, and React Native library that renders After Effects animations in real time, allowing apps to use animations as easily as they use static images.
複数エンド(iOS, Android, React Native および Web)に適し、AE アニメーション効果を轻松愉快に実現できる
Lottie allows engineers to build richer animations without the painstaking overhead of re-writing them.
クロスプラットフォームの優勢は複数エンドの重複作業を削減することにある。毕竟アニメーション効果の定義と実装は複雑で時間のかかることだから:
How difficult and time consuming it can be to re-create animations from scratch.
実際、類似の他の方案もある。例えば facebookincubator/Keyframes:
A library for converting Adobe AE shape based animations to a data format and playing it back on Android and iOS devices.
Keyframes の局限性は一部(交互応答方面の)AE 特性のみをサポートすることにある。一方、Lottie の目標は大多数の AE 特性をサポートすること:
Our goal is to support as many After Effects features as we possibly can, to allow for a lot more than simple icon animations.
サポートする AE 特性が多ければ多いほど、デザイナーへの制約が少なくなる。这也是 Lottie 方案がより人気がある理由の 1 つ
四.実装思路
JSON
Bodymovin ----------> Lottie Player
画像資源
デザイナーが AE でアニメーションを作成した後、Bodymovin(AE プラグイン)を通じて JSON 形式の Lottie アニメーション定義及相关び画像資源をエクスポートし、Android、iOS、ReactNative、Web フロントエンドエンジニアに出力する。エンジニアは対応プラットフォームの Lottie Player を呼び出してアニメーション資源をロードし、アニメーションの再生/一時停止などを制御する
AE プラグイン部分は AE のアニメーション定義を Lottie アニメーション定義に変換し、JSON ファイルを出力する。難点はより多くの AE 特性の変換をサポートし、デザイナーが使いにくくならないようにすること
プレイヤー部分は Lottie アニメーション定義を解析し、相关び資源をロードし、プラットフォームがサポートする技術を使用してアニメーション効果を実現する。例えば Web 環境ではデフォルトで SVG アニメーションを通じて実現し、Canvas 描画と CSS アニメーション実装を選択可能
鍵 は:
-
共通のアニメーション定義
-
各プラットフォーム下で該アニメーション定義をサポートするプレイヤー
Java のクロスプラットフォーム思路に類似:プラットフォーム無関係の class ファイル + プラットフォーム相关びの JVM 実装
五.lottie-web
airbnb/lottie-web は Web 環境の Lottie Player で、簡単な数行のコードで複雑なアニメーション効果を実現できる。例えば:
<div id="bm"> </div>
var animation = bodymovin.loadAnimation({
container: document.getElementById('bm'),
renderer: 'svg',
loop: true,
autoplay: true,
path: 'data.json'
})
P.S. 具体的な効果は Simple Bodymovin Demo を参照
デフォルトで SVG を通じて実現(renderer: 'svg')。さらに canvas と html もサポート。違いは:
-
svg:アニメーション要素(形状など)を SVG で実現し、アニメーション効果を SVG アニメーションで行う -
canvas:要素を Canvas で描画し、アニメーション効果をrAFで定時刷新再描画を通じて実現 -
html:アニメーション要素を SVG で実���し、アニメーション効果を CSS アニメーションで行う
実際の使用中发现、SVG モードの互換性が最も良い。HTML モードではマスクアニメーションに丸角が拡大して四角くなる問題が存在
P.S.SVG 及其びアニメーションについては、[SVG 基礎知識](/articles/svg 基礎知識/) を参照
P.S. より詳細な API は Usage を参照
lottie-web を導入する方法は 2 通り。CDN 資源 を参照するか、最新 release をダウンロード:
$ ls lottie-web-5.3.0/build/player/
lottie.js lottie.min.js lottie_light.js lottie_light.min.js
その中で、lottie_light.js(軽量版)は SVG モードのみをサポートし、expressions をサポートしない
六.まとめ
Rax のクロスコンテナ実行、Lottie のクロスエンドアニメーション……フロントエンド技術方案はすでにフロントエンド領域に限定されず、上流下流に拡張し、デザイナー、クライアント兄弟、サービス哥哥を一緒に遊ばせている。例えば:
-
Ant Design:フロントエンド + デザイナー
-
React Native:フロントエンド + クライアント兄弟
-
Backends For Frontends:フロントエンド + サービス哥哥
上流下流の横向き衝突を通じて、全体の効率を向上できる方案を沉淀産出することは、必然的な趨勢になったようだ
コメントはまだありません