パフォーマンスは重要です

パフォーマンスは、視聴者が何も測定しなくても気づく品質の側面です [1] [3]。視聴者がリモコンを押すと、スプラッシュ画面が望ましい時間より少し長く表示され、アプリが遅くて使いにくいと判断し始めます。起動が遅い、メニューが途切れる、スクロールが停止する——これらは視聴者がアンインストールして二度と戻らない原因となります。

優秀なチームは、パフォーマンスと効率を定期的なスプリントではなく継続的な取り組みとして扱い、すべての変更がリリースされる前にレビューされるプロセスに組み込んでいます。

パフォーマンスはアプリケーションのすべての製品機能に影響を与えます。優れたコンテンツ、洗練されたデザイン、パーソナライズされたレコメンデーションも、起動画面が空白だったり、ナビゲーション中にフレームがドロップするUIがあれば成り立ちません。ホーム画面の表示に4秒待たされる視聴者は、コンテンツを一切見る前にカタログについて判断を下しています。起動が速く、ナビゲーションが安定していれば、コンテンツチームやパーソナライゼーションチームの努力が実際に視聴者に届きます。そうでなければ、その努力は費用がかかっているのに届かないままです。

リソース効率は重要です

Fire TVストリーミングデバイスでは、ハードウェアの制約が大きいため、リソースを効率的に管理することはモバイルより困難です。典型的なローエンドのスマートフォンは8〜12GBのRAMと3GHzを超えるCPUを搭載していますが、ローエンドのFire TV Stickは約1GBのRAMと約1.7GHzで動作するCPUです。スマートフォンとは異なり、Fire TV StickデバイスはTVパネルの裏側に密閉されたHDMI筐体に収められており、アクティブな冷却機能はありません。アプリはFire TV Stickで動作する際、これらすべてのリソース制約に対応する必要があります。オペレーティングシステムはメモリ圧力がかかるとメモリを回収し、リソースを解放するためにアプリを終了させます。許容範囲と問題のある範囲の差はわずかであり、アプリはアクティブに使用されている古いモデルを含む、サポートされているすべてのデバイスファミリで動作する必要があります。Fire TVデバイスの使用セッションはモバイルより長く、ストリーミングアプリは数分ではなく数時間動作する可能性があります。ゆっくりと蓄積する問題は、数週間の使用ではなく、1回の視聴で視聴者に感じられます。

パフォーマンスの問題を認識する

機能的な問題やクラッシュは、調査と責任の所在を明確に追跡できます。パフォーマンス閾値でのリグレッションは、複数のリグレッションの累積効果が視聴者シグナルに現れるまで、アラート/クラッシュ/調査のための追跡情報が生成されません。

→ クラッシュとANRのシグナルは、安定性とレジリエンスの柱で説明しています。

ビジネス上の理由は明確です。起動が速いセッションは、より長いエンゲージメントにつながります。リソース圧力に徐々に陥るアプリは、チームを動員するような明らかな障害シグナルなしに、徐々に視聴者を失います。チームは3回のリリースを連続して配信でき、それぞれが個別のダッシュボードでは問題ないように見えます。累積的なリテンションの低下は四半期レビューで明らかになりますが、原因となる単一の変更は存在しません。チームに明確なパフォーマンス基準を課す品質オーナーは、製品への他のすべての投資のリターンを守っているのです。

開発プロセスにおけるパフォーマンス習慣

パフォーマンスの明確な閾値と目標

チームは、コールドスタートから最初のフレームまでの時間（TTFF）、ウォームスタートとレジューム、ナビゲーション中の持続的なフレームレート、1080pおよび4K再生中のメモリフットプリント、アイドル時のCPU使用率について、明示的な目標を定義します。目標はFire TVデバイスの認定閾値 [3] [7] の「内側」に設定され、アプリが新しい機能やCXアップデートを吸収してもコンプライアンスを維持できるようにします。作業上のベースラインとして、60fpsのUIはフレームあたり16.67msの予算を提供します。Fire TV Stick Liteでは、健全なフォアグラウンドフットプリントはデバイスのRAM上限を大幅に下回る必要があります。これらの目標は文書化され、所有され、品質オーナーに対して可視化されており、少数のエンジニアの頭の中だけに留められていません。

良い状態とは: アプリのパフォーマンスKPI [7] が、アプリ提出前のすべてのリリースでプラットフォームに設定された目標閾値を下回っていることです。

アプリ起動の閾値をgo/no goとして扱う

アプリケーションの起動は、ユーザー体験の観点からTTFF（アプリケーション起動から画面上に最初のフレームがレンダリングされるまでの時間）とTTFD（アプリケーションのレンダリングが完了し、ユーザー入力を受け付けられる状態になるまでの時間）に分割できます。これら2つは、ユーザーがアプリを開くことを決めてから黒い画面を見る時間と、起動後にアプリケーションを使用開始できるまで待つ必要がある時間を示します。

起動サービスを速度の観点から必須と延期可能に分類します。起動時のネットワークコールを、必要なもののみに制限してレビューします。ネットワークトラフィックは起動パフォーマンスに直接影響するためです。残りのネットワークリクエストには、キャッシュまたは並列化されたメカニズムを使用します。アプリをバックグラウンドから再開する際は、可能であればスタックを再初期化せずに状態を復元します。各起動サービスの影響を積極的に追跡するチームは、コールドスタート（アプリケーションコードがバックグラウンドで実行されていない状態での新規起動）を長くせずにCX改善を配信できる可能性が高くなります。

良い状態とは: すべてのアプリ起動条件について、文書化された起動閾値を遵守していること [7]. すべてのKPI閾値が満たされるまでアプリリリースを保留すること。

実世界のセットアップでパフォーマンス指標を測定する

サポート範囲内のMVD（minimum viable device）ファミリと実機上でアプリをプロファイリングします。問題が最初に表面化するのはそこだからです。MVDはパフォーマンスの問題が最初に現れやすい最低仕様のデバイスです。拡張使用後や制約のあるネットワーク上で、パフォーマンス指標を監視し、開発テストや理想的な環境でのテストだけに頼るのではなく、デバイス側のプロファイリングとメモリツール [3] を使用します。主要な指標は社内テストランだけでなく、実稼働データからサンプリングされます。標準的なテスト計画の一環として、視聴者がアプリ内で費やす最大時間に沿った、連続使用の長時間テストを含めます。

良い状態とは: すべてのパフォーマンス指標データポイントが、ターゲットデバイスプラットフォームとともにMVDデバイス上で収集されていることを確認すること。このデータはアプリリリースのサインオフポイントとなります。

リソース消費の閾値

アプリのリソース監視はアプリケーションバンドルのサイズから始まり、ユーザーがアプリケーションを操作している間のメモリ/CPU消費に続きます。メモリ予算はリリーステストで強制され、リグレッションは後で対処する軽微なフォローアップではなく、品質欠陥として扱われます。早期に対処しなければ、リソース使用量は複数のリリースを通じて蓄積し、視聴者が感じるようなメニューのもっさり感や起動時間の延長につながる可能性があります。サードパーティサービス（アナリティクス、広告、クラッシュレポート、A/Bテストなど）は統合前にプロファイリングする必要があります。これらをファーストパーティコードと同じリソース基準に適合させます。

良い状態とは: アプリケーションおよび統合サービスのすべてのリソース利用測定が、デバイスに定義された品質閾値内にあること。 [7]

デバイスの熱的フットプリント

Fire TVデバイスは電源に接続され、テレビの裏側に密閉されているため、関連する枠組みはモバイルのバッテリー寿命ではなく、熱と電力効率です。持続的なCPUおよびGPUの使用は最小限に抑える必要があり、ハードウェアデコードが利用可能な場合は優先する必要があります。アプリは現実的な視聴シナリオでテストし、長時間のアプリ使用がデバイスの熱的測定値を上昇させていないことをプロファイリングして確認する必要があります。スロットリングは単一の目に見えるイベントとして到達することはほとんどなく、長時間の視聴セッションの後半で徐々にフレームドロップやオーディオ/ビデオのずれとして現れます。

良い状態とは: アプリリリースについて、長時間のソークテストで熱的影響を確認する熱的測定を実施していることを確認すること。

パフォーマンスは品質オーナーの指標 [3]

パフォーマンスデータはリリースレビューのクラッシュデータの隣に位置します。すべての新機能のオンボーディングは、1つの質問に答える必要があります: これは起動時間とリソースにどのようなコストをもたらすか？ SDKの採用決定は、機能だけでなくフットプリントを考慮します。リリース決定がパフォーマンスの議論なしに行われると、ギャップは後で、単一のチケットではなく視聴者行動に現れます。この所有権が重要なのは、200msのコールドスタートリグレッションはアラートもエスカレーションも生成しないため、探し出さなければならないからです。品質オーナーの注意は、ゆっくりと動くシグナルを大きなものとして可視化します。品質オーナーは、開発プロセスの一環として、パフォーマンスの品質指標とテストへの準拠を所有する必要があります [6]

良い状態とは: すべてのリリース準備レビューの際に、パフォーマンスデータがクラッシュデータと並んで提示され、機能リリースの決定はパフォーマンス影響のレビュー後にのみサインオフされること。 [7]

品質オーナーの質問

これらの質問は、品質レビュー、リリースのgo/no go議論、およびリリース後の振り返りで品質オーナーが使用するために設計されています。強い回答はデータと指名された所有者によって裏付けられています。

起動とレジューム

チームのTTFFとインタラクティブまでの時間は、デバイスファミリごとにどのように分類されていますか？その測定はサポート範囲内のMVD上で、現実的な条件下で実施されていますか？

開発チームは、起動パフォーマンスを改善するためのパフォーマンスガイダンス [5] を実装していますか。

視聴者が30秒後、5分後、1時間後にアプリに戻ったとき、状態は保持されているか完全なリロードか、その動作は意図的なものですか？

フレームレートと流動性

チームは実際の視聴者からのフレームレートデータを持っていますか？チームはUIナビゲーションで最ももっさり感を生む画面、インタラクション、デバイスモデルを特定できますか？

新しいCX機能がUIの応答性とナビゲーションの流動性に与える影響はどのようなものですか？

メモリ、CPU、リソース予算

チームのメモリフットプリントは、起動時、リソースを多く消費するアクション中、および長時間のソーク時間後にどの程度ですか？

そのフットプリントは過去数回のリリースでどのように変化しましたか？

チームはリリーステストでリソース使用量をどのようにプロファイリングし、トレンドに基づいてどのように調整していますか？

スローリークを検出するための拡張セッションでの最後のヒープ分析はいつで、その結果の所有者は誰ですか？

熱的および持続的な動作

チームはターゲットデバイス上で現実的なセットアップで1時間のソークテストを実行し、熱的スロットリングがないことを確認しましたか？本番テレメトリはスロットルイベントを表面化させますか？

コンテンツが再生されていない状態でフォアグラウンドにあるときのアプリのアイドルCPU使用率はどの程度で、最近のリリースでその数値は変化しましたか？

パフォーマンス文化

起動遅延、UI応答性、リソースフットプリントは、データが添付された状態ですべてのリリースのgo/no go基準の一部になっていますか？チームは、出荷前にパフォーマンスリグレッションが検出された最後のリリースを挙げられますか？

視聴者がバッファリングや再生劣化を報告したとき、チームはクライアント側かネットワーク側かを判断するためのデバイス側テレメトリを、ストリーミングパイプラインへのエスカレーション前に持っていますか？

次に

パフォーマンスと効率はBlueprintの2番目の柱です。次の記事では安定性とレジリエンスについて説明します。管理されていないパフォーマンス圧力はそこで最も頻繁にクラッシュ、ハング、回復不能な状態として現れ、同じ測定作業がリターンを生み始めます。後の柱はこの基盤の上に構築されます。ストリーミングエクスペリエンスは健全なデバイス側ランタイムに依存します。リリースとオペレーションの優秀性は、ここで確立されたパフォーマンスゲートが以降のすべてのリリースで強制されていることに依存します。