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


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

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

ウェブアプリの保護

インターネット上の通信は、傍受や悪意のある改ざんの対象になる可能性があります。Amazon Mobile App Distributionでは、申請するウェブアプリを保護するためのアクションを実行することをお勧めしています。ウェブアプリのセキュリティを強化する最適な方法は、SSL(Secure Sockets Layer、すなわちHTTPS)を使用する方法です。

詳細については、ウェブアプリの保護を参照してください。

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

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

レスポンシブデザイン手法の使用

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

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

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

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

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

タッチフィードバックの無効化

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

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

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

デバイスごとに画面サイズや縦横比が異なることを考慮して、アプリが全画面表示されるように設計します。場合によっては、アプリを全画面表示できないこともあります。たとえば、アプリをレターボックス化する必要がある場合や、ネイティブな縦横比が対象デバイスと一致しない場合が挙げられます。これらのシナリオでは、アプリが画面の80%を占める必要があります。ウェブアプリのリソースには、すべてのデバイスで適切な縦横比を維持しながらアプリを動的にサイズ変更するサンプルコードがインクルードされています。このコードは<install location>/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は、事前に独自の合成レイヤーとして作成することをお勧めします。

次のいずれかがtrueの場合、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などと)変わる可能性がある場合は変数を使用しない。

アプリ内での移動で完結

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