開発者コンソール
ログイン
ログイン
開発者コンソール

ウェブアプリ開発に関するベストプラクティス

ウェブアプリ開発に関するベストプラクティス

既存のウェブアプリを移植する場合でも、FireタブレットまたはAndroidデバイス用の新しいウェブアプリを作成する場合でも、デバイスのさまざまな機能がアプリの動作や外観にどのような影響を与えるかを考慮することが重要です。次のベストプラクティスとガイドラインを参考にして、ウェブアプリを最適化してください。

ウェブアプリを保護

インターネット上の通信は、傍受や悪意のある改ざんの対象になる可能性があります。Amazonアプリストアでは、申請するウェブアプリを保護するための対策を講じることをお勧めします。ウェブアプリの安全を確保するには、TLS 1.2の使用が最適です。以前のバージョン（TLS 1.0、TLS 1.1など）はセキュリティが劣るため、使用しないでください。

ウェブアプリを保護する方法については、こちらを参照してください。

デバイスの向きの設定の変化に対応

アプリはデバイスを縦向きまたは横向きにして使用される可能性があります。次のヒントを参考にして、さまざまな向きでのアプリの動作を管理してください。

レスポンシブデザイン手法を使用する

画面サイズや解像度の選択の幅は広がり続けています。このため、個々のデバイスをターゲットとしたさまざまなバージョンのウェブアプリを作成することは、現実的ではありません。代わりに、レスポンシブウェブデザイン手法を使用して、幅広いデバイス間でリサイズ、パン、スクロールを最小限に抑え、最適化された視聴体験を提供します。

縦向きまたは横向きモードで表示の向きをロックする

ゲームなどのネイティブアプリの多くは、1つの向きで適切に動作するように設計されています。デバイスを回転しても、アプリの表示は元の向きのまま変わりません。デバイスの向きを固定する方法を参照してください。

ユーザーにデバイスを回転するように案内する 

アプリの動作に適した向きがある場合は、デバイスをその向きに回転するように文字や絵で伝えてください。

タッチフィードバックをオフ

デフォルトでは、ほとんどのAndroidデバイスは、ウェブリンクをタップすると視覚的なフィードバックを表示します。このフィードバックは通常、リンクのターゲットの上に重なった半透明のカラーブロックとして表示されます。この動作を無効にするには、次のコードをCSSマークアップに追加します。

          body {
          -webkit-tap-highlight-color: rbga(255, 255, 255, 0);
          -webkit-user-select: none;
          }

ウェブアプリを全画面表示

デバイスごとに画面サイズや縦横比が異なることを考慮して、アプリが全画面表示されるように設計します。場合によっては、アプリを全画面表示できないことがあります。たとえば、アプリをレターボックス化する必要がある場合や、ネイティブな縦横比が対象デバイスと一致しない場合が挙げられます。これらのシナリオでは、アプリが画面の80%を占める必要があります。ウェブアプリのリソースには、すべてのデバイスで適切な縦横比を維持しながらアプリを動的にサイズ変更するサンプルコードが含まれています。このコードは次のフォルダ内にあります。<インストール場所>/Web/samples/webapp-cookbook/FillScreen/

タグを使用してビューポートのカスタム設定を指定すると、FireタブレットとAmazon以外のAndroidデバイスでウェブアプリのレンダリングに差異が生じることがあります。

画面よりも幅が広いコンテンツがある場合、ビューポートはそのコンテンツに合わせてズームアウトすることがあります。これを回避するには、ヘッダーセクションに次を追加します。

<meta name="viewport" content="user-scalable=no">

ユーザーエージェント文字列

Fireタブレットのユーザーエージェント文字列を参照してください。

ゲームアプリに関するベストプラクティス

  • requestAnimationFrameを使用してフレームレートに上限を設定する。必要以上のレートでレンダリングしないでください。
  • データ構造を使用してゲームの状態をトラッキングする。
  • 効率的な競合検出アルゴリズムとデータ構造（k-d木、四分木、R木、外接矩形など）を使用するか、効率的な既存のライブラリを使用する。効率的な競合検出手法の例については、こちらを参照してください。
  • ゲームの状態を絶えず動的に計算することはしない。
  • 視認できないものを描画しない。
  • CSSのbox-shadowsはペイントのコストが高く、パフォーマンスが大幅に低下する可能性があるため、使用しない。

canvas要素の使用に関するベストプラクティス

  • テクスチャの形式で事前に生成されたコンテンツを持つスプライトを使用する。
  • 整数座標を使用してサブピクセルの演算を回避する。
  • ドローコール（直線、斜線、パスなど）にオフスクリーンcanvasを使用し、結果のバッファーをメインのレンダリングcanvasにコピーする。
  • Web Workersを使用して別のワーカースレッドでオフスクリーンcanvasに描画する。
  • canvasのドローコールを使用するときに、一括処理してパフォーマンスを改善する。
  • さまざまなレンダリングレイヤーで背景とアニメーションオブジェクトを変えずに保持する。静的なコンテンツになるため、レンダリングのオーバーヘッドが減ります。
  • 幅や高さの属性を再設定したりする代わりに、clearRectを使用してcanvasを消去する。
  • canvasの状態の変更を最小限にする。
  • エンジンが非保持モードの検出や最適化を行わない場合に、再レンダリングを必要とするアニメーションcanvasの一部を追跡して減らす。
  • ぼかしを使用しない。コストが高くなる可能性があります。
  • ピクセルの再読み込みと操作を避ける。これらがあるために、本来レンダリングエンジンで実行できる可能性のある並列化やパイプライン化が無効になるからです。

ウェブアプリの合成レイヤーの最適化に関するベストプラクティス

Amazon WebViewは選択したレイヤーを合成のためにGPUに送信することでレンダリングを改善します。CSSの変形がルートレイヤーの一部であるdivで実行されると、レイヤーがその場で作成され、合成のためにGPUに送信されます。サイズの大きい、より複雑なdivではコストが高くなります。パフォーマンスの改善のため、頻繁に変形／リペイントされるdivは、独自の合成レイヤーとして事前に作成することをお勧めします。

次のいずれかに当てはまる場合、RenderLayerは独自の合成レイヤーを取得します。

  • レイヤーにCSSの3D transformプロパティまたはperspective transformプロパティがある。
  • レイヤーが<video>要素によって高速化された動画デコードで使用されている。
  • レイヤーが<canvas>要素によって3Dコンテキストまたは高速化された2Dコンテキストで使用されている。
  • レイヤーが合成されたプラグインで使用されている。
  • レイヤーがopacityにCSSアニメーションを使用するか、アニメーションのwebkit-transformを使用している。
  • レイヤーが高速化されたCSSフィルターを使用する。
  • 合成された子孫があるレイヤーに、合成されたレイヤーツリーに必要な情報（クリップやリフレクションなど）がある。
  • レイヤーに、合成レイヤーを持つ、より低いz-indexの兄弟がある。

JavaScriptに関するベストプラクティス

  • 可能であれば、JS配列の代わりに型付き配列を使用する。
  • 「for-in」ループの代わりに「for」ループを使用する。「for」ループの方がより効率的です。
  • 可能な限りローカル変数を使用する。ただし、変数が割り当てのサポートが必要な複合オブジェクトの場合は、シングルトンとして作成することをお勧めします（データ型が変更されず、オブジェクトがポリモーフィックにならない場合）。
  • 「大きな」メソッドは作成しない。メソッドはモジュール化して、より小さなアルゴリズムのチャンクに分割してください。有益であると判断した場合は、より大きなメソッドを仮想マシンでインライン化して再作成できます。逆は正しくありません。
  • データ型が（int、float、doubleなどと）変わる可能性がある場合は変数を使用しない。

アプリ内の移動に限定

ユーザーがアプリを使用する上での最高のエクスペリエンスは、移動フローがアプリ内でとどまり、デバイスのブラウザに移動する必要がないことです。アプリの主要な機能をテストし、ユーザーがブラウザに移動することがないようにしてください。