さらに、Google のブログ記事 Traceview War Story（Traceview 戦記）で指摘しているように、Traceview と DDMS といったツールはそれぞれ、メソッドのコールのプロファイリング、VM メモリ割り当てのモニタリングをしてくれるので、アプリの品質アップの頼もしい右腕となってくれるでしょう。

操作性を高める


操作性について、またアプリのデザインについてもそうですが、ユーザーの声にはよく耳を傾ける必要があります。身近な Android 端末ユーザー（友人や家族など）数人に頼んでアプリを試してもらい、彼らがどのように使うかを観察します。彼らが戸惑っているときや、進め方が分からないとき、何らかの動作に驚いているときがないかを確認してみてください。アプリ内のインタラクションの一部を見直し、こういったケースができるだけ少なくなるようにします。Google I/O で Android の UI チームが議論した Android UI patterns（Android UI のパターン）（動画）の一部が参考になるかもしれません。

これに関連して、Android ユーザー インターフェースで発生しがちな問題は、タップ ターゲットが小さい、フォントサイズが必要以上に小さい、という 2 つの問題です。これらの問題は多くの場合容易に解決でき、操作性やユーザー満足度に大きく影響することがあります。一般的に、使いやすさと読みやすさを考えて最適化する一方で、情報密度は最小限にする（少なくとも、慎重にバランスを取る）ようにします。
アプリの UI をデザイン・評価する際には、Android Design（Android デザイン）ガイドラインを読み、熟知するようにしてください。UI パターンやスタイル、構成要素の例を数多く取り上げているほか、デザイン プロセス用のツールも紹介しています。

このほか、現実世界のデータに基づいて操作性を徐々に向上させる方法として、アプリ全体にアナリティクスを実装して特定のセクションの利用状況を記録する方法があります。使用頻度が低いセクションは格下げしてアクション バーのオーバーフロー メニューに配置するか、すべて削除することを検討します。使用頻度が高いセクションや UI 要素は、アプリ UI 上でひと目見て分かるようにし、ユーザーが素早く使えるようにします。

最後になりましたが、操作性はトピックとして幅広く、扱っているドキュメントも数多く存在します。インターフェースのデザインや、認知科学、その他の分野とも密接に関連して語られるトピックですので、色々調べてみるのがよいでしょう。

プロフェッショナルな見た目と美しさ


プロのユーザー インターフェース デザイナー、つまり「モバイルと Android に精通し、さらに欲を言えばインタラクションとビジュアル デザインの両方をこなせる」人物はかけがえのない存在です。デザイナーを探す場所として有名なものには jobs.smashingmagazine.com があります。また、ソーシャル ネットワークの活用で優秀な人材が見つかることもあります。

UI デザイナーに仕事を頼む余裕がない場合は、自分でアプリの見た目をよくする方法がいくつかあります。まず、Adobe Photoshop や Adobe Fireworks などのラスター画像編集ツールの操作に慣れておきましょう。これらのアプリケーションを習得するには時間がかかりますが、インターフェースのデザイン全般を洗練させる上で非常に有益なスキルです。また、フレームワーク UI アセットやレイアウトを学び、こちらの関連資料を熟読して各種リソースのフレームワークをマスターしてください。9 パッチやリソース ディレクトリ修飾子などの手法は、いわば Android 独特の手法で、フレキシブルながらも美しい UI を構築する上で非常に重要です。

アプリのデザインやコードの作成作業を先へ進めてしまう前に、Android デザインのサイトにアクセスして、方針や構成要素、美しく魅力的なユーザー インターフェースをデザインするツールについて学んでください。

適切な機能群を提供する


アプリには適切な機能群を入れることが大事です。できるだけ多くの機能をアプリに盛り込もうとしてしまう、「フィーチャー クリープ」という落とし穴にはまってしまわないよう気をつけてください。モバイル端末では、その場で最も重要な情報、あるいは最も関連性の高い情報を即座に示すことが極めて重要です。ユーザーにとって情報過多は、情報不足と同じくらい、あるいはそれ以上にいらだたしいものです。

前述の通り、機能に対する要望を集めてそれに応えることで、ユーザーの声に耳を傾けるようにしてください。ただし、機能に対する要望を鵜呑みしないよう気を付けてください。集まった要望は、どのような機能を導入すべきかを考える上で参考になりますが、すべての要望を実現する必要はありません。

システムとサード パーティのアプリと統合する


快適なユーザー エクスペリエンスを提供する良い方法は、オペレーティング システムと密接に連携させることです。そういった点では、ホーム画面のウィジェットや高度な通知、グローバル検索の統合、クイック コンタクトなどの機能は、手軽に実現できる機能です。

アプリのカテゴリによっては、ホーム画面ウィジェットなどの基本機能はあって当然という認識を持たれており、その機能が含まれていないと、それ以外の点で良いユーザー エクスペリエンスを提供していても、評価を落とすのは確実です。アプリの中には、Android の連絡先やアカウント、同期 API を利用してより密接な OS との連携を実現できるものもあります。

サード パーティとの統合によって、ユーザーにはさらなる快適さを提供できるうえ、端末としてのまとまり感を与えることもできます。また、他のアプリの機能を活用することで、コードを新たに書かなくてもアプリに機能を追加できる非常に優れた方法でもあります。例えば、カメラ アプリの場合、ユーザーが該当するサード パーティの編集アプリをインストールしていれば、写真をそのアプリで編集してから保管場所に保存するといったことも可能になります。このトピックに関する詳しい情報は、Android トレーニング クラスInteracting with Other Apps（他のアプリと連携する）を参照してください。

細部にも注意を払う


中でも注意すべきなのは、アプリのアイコンの品質と一貫性です。アプリのアイコン （特にランチャー アイコン） がどの解像度でも鮮明に表示されること、また、できる限りアイコンのガイドラインに従っていることを確認してください。アイコン作成で何かお困りの場合や自分でアイコンをデザインしようにもリソースがない場合は、アイコン一式を作成できる Android Asset Studio ツールの使用をご検討ください。


2. 大画面に合わせてレイアウトを最適化する


Android では、さまざまな種類の端末の画面サイズやフォーム ファクター上で動作するアプリの開発を容易に行うことができます。その幅広い適合性は、すべての対象端末に配布できる単一アプリの設計ができるという点で、開発者にとって有利に働きます。しかし、（特にタブレット ユーザーに対して）それぞれの画面構成に最適なユーザー エクスペリエンスを提供するには、対象の端末の画面構成ごとに、レイアウトや各種 UI コンポーネントを最適化する必要があります。タブレットでは、UI の最適化によって広い画面を活用できるというメリットを生かして、例えば新機能の提供や、新しいコンテンツの表示、その他のさまざまな方法によるエクスペリエンスの強化ができ、ユーザーのエンゲージメントを高めます。

携帯端末向けのアプリをすでに開発していて、それを新たにタブレットにも提供したいときは、まず、レイアウトやフォント、スペーシングを微調整することから始めます。場合によっては（7 インチのタブレットや、広々としたレイアウトのゲーム アプリなど）、これらを微調整するだけで見た目が整います。それ以外、例えばもっと大きなサイズのタブレットなどの場合は、UI の一部を設計し直すことで、「拡大されただけの UI」を効率の良いマルチペイン UI にしたり、ナビゲーションを行いやすくしたり、追加コンテンツへと変えたりすることができます。

「拡大されただけの UI」を解消する: タブレットの場合、単一ペイン レイアウトにすると不自然な余白が生じたり、一行が長くなりすぎたりします。パディングを使用して UI 要素の幅を狭くすると共に、マルチペイン レイアウトの使用も検討しましょう。

推奨事項は下記の通りです。

  • 必要に応じて large（大）および xlarge（特大）画面用のカスタムレイアウトを用意します。また、画面の最小寸法あるいは幅・高さの最小値に基づいてロードされるようなレイアウトを提供してもよいでしょう。
  • 大きめの画面については最低でもフォントサイズやマージン、間隔などの寸法をカスタマイズし、画面の使い方とコンテンツの読みやすさを改善します。
  • UI コントロールの位置を調整し、ユーザーがタブレットを手に持っているときに操作しやすい位置に配置します（横置きのときはサイドに配置するなど）。
  • UI 要素のパディングは通常、タブレットでは携帯端末の場合よりも大きくします。48dp 単位（グリッドは 16dp）にすることをお勧めします。
  • テキスト形式のコンテンツは、画面の端にぴったり沿った状態にならないよう適切にパディングを使用します。画面の端近辺では最低でも 16dp のパディングを使用してください。
特に、レイアウトが画面全体に「広がって」表示されないように注意します:
  • テキストの行は長くなりすぎないようにし、1 行あたり半角文字で最大 100 文字とし、1 行あたり50～75 文字に収めるのがベストです。
  • ListViews やメニューには画面の幅全体を使用しないでください。
  • パディングを使用してオンスクリーン要素の幅を管理したり、タブレット向けにマルチペイン UI に切り替えたり（次の項目を参照）します。
参考資料:

3. タブレット上の余っている画面領域を活用する


タブレット画面では、マルチペイン レイアウトにすることで見た目のバランスがよくなると同時に、実用性も読みさすさも向上します。

タブレット端末は携帯端末にくらべ、特に横向きにした場合、アプリで使える画面領域が大幅に増えます。中でも 10 インチのタブレットは特に画面領域が大きくなりますが、7 インチのタブレットでもコンテンツの表示やユーザーのために使えるスペースが増えます。

タブレット上で動作するときのアプリの UI を検討するときは、タブレット上の余っている画面領域を十分に活用しましょう。推奨事項は下記の通りです。
  • 追加のコンテンツを盛り込んだり、既存のコンテンツを別な形で扱ったりする方法を探ります。
  • タブレット画面では マルチペイン レイアウト（Multi-pane Layout）を使い、複数の単一ビューを 1 つの複合ビューにまとめます。こうすることで、増えた画面領域をより効率よく使用でき、ユーザーもアプリを操作しやすくなります。
  • 画面の向きが変わったときに複合ビューのパネルをどのように再配置するのかを考慮します。
複合ビューは、携帯端末用 UI（上）の複数の単一ビューを 1 つにまとめ、より充実した効率の良いタブレット用 UI にします（下）。

  • 1 つの画面は Activity サブクラスとして実装されますが、個々のコンテンツ パネルを Fragment サブクラスとして実装することを検討します。こうすることで、さまざまなフォーム ファクター全体で、またコンテンツを共有するすべての画面にわたって最大限にコードを再利用できます。
  • どの画面サイズでマルチペインUIを使用するかを決め、それぞれのレイアウトを適切な画面サイズ バケット（large/xlarge など）、あるいは最小画面幅（sw600dp/sw720 など）で提供します。
参考資料:

4. タブレット画面用に設計されているアイコンなどのアセットを使用する


アプリの見た目をよくするには、タブレット画面で使用されるピクセル密度用に作られているアイコンなどのビットマップ アセットを使用するようにします。具体的には、タブレットが通常サポートしている範囲のすべてのピクセル密度それぞれに対し、代替ビットマップ ドローワブルのセットを作成する必要があります。

表1. アイコンタイプ別の未加工のアセット サイズ
密度 ランチャー アクションバー 小型/コンテキストタイプ 通知
mdpi 48x48px 32x32px 16x16px 24x24px
hdpi 72x72px 48x48px 24x24px 36x36px
tvdpi (hdpi を使用) (hdpi を使用) (hdpi を使用) (hdpi を使用)
xhdpi 96x96px 64x64px 32x32px 48x48px

その他の検討事項:
  • アクションバーや通知、ランチャーのアイコンは、アイコンのデザイン ガイドラインに従ってデザインし、タブレット上でも携帯端末と同じ物理サイズにします。
  • ピクセル密度固有の リソース修飾子（resource qualifiers）を使用して、適切な代替リソース セットがロードされるようにします。
参考資料:

5. タブレット画面用にフォント サイズとタッチ ターゲットを調整する


タブレット上で使いやすいアプリにするには、アプリの対象としているすべての画面構成に合わせて、タブレット UI のフォント サイズとタッチ ターゲットを調整するための時間はしっかり取りましょう。フォントサイズの調整は、スタイル設定可能な属性（styleable attributes）または寸法のリソース（dimension resources）で行うことができます。また、タッチ ターゲットは前述したようにレイアウトとビットマップ ドローワブルで調整可能です。

推奨事項は下記の通りです。
  • テキストは、タブレットの画面サイズやピクセル密度で表示したときに大きすぎたり、小さすぎたりしないようにしましょう。ラベルは、該当する UI 要素に合わせて適正なサイズにし、またラベルやタイトルなどの各種要素が不適切な位置で改行されないようにします。
  • オンスクリーン要素については、タッチ ターゲットの推奨サイズは 48dp（最低でも 32dp）ですので、タブレット UI 用にいくつかの調整が必要かもしれません。ほとんどのユーザーを対象とした実装方法については、尺度とグリッド（Metrics and Grids）をお読みください。一部のユーザーのニーズに対応するには、大きめのタッチ ターゲットを使用するのが適切な場合があります。
  • 比較的小さなアイコンについては、TouchDelegate を使用するか、または透明ボタン内でアイコンをセンタリングすることで、タッチ可能な領域をできるだけ 48dp よりも大きくします。
参考資料:

6. タブレット画面用にホーム画面ウィジェットのサイズを調整する


アプリにホーム画面ウィジェットがある場合、タブレット画面での優れたユーザー エクスペリエンスを提供するため、下記に示す事項を検討してみてください。
  • ウィジェットのデフォルトの高さ・幅は、タブレット画面と最小/最大リサイズ高さ・幅に合わせて適切に設定します。
  • ウィジェットは 420dp 以上のサイズに変更できるようにし、垂直または正方形ウィジェットの場合はホーム画面の 5 行以上、水平または正方形ウィジェットの場合は 5 列以上にまたがるようにします。
  • 9 パッチ画像が正しくレンダリングされるようにします。
  • デフォルトのシステム マージンを使用します。
  • アプリの targetSdkVersion を 14 以上に設定します（可能な場合）。
参考資料:

7. アプリの全機能セットをタブレット ユーザーに提供する


タブレット ユーザーが、あなたのアプリの売りとなる機能をきちんと体験できるようにします。推奨事項は下記の通りです。
  • アプリは少なくとも携帯端末と同じ機能セットをタブレットにも提供するようにします。
  • 例外的なケースとして、ほとんどのタブレットにおいてハードウェア的に対応していない、あるいはユース ケース上対応していない一部の機能については、省くか他のものに置き換えても構いません。下記に例を示します。
    • 携帯端末では電話機能を使用しているが現在のタブレットでは電話機能を使用できない場合は、この機能を省くか、関連する機能に置き換えても構いません。
    • 多くのタブレットには GPS センサーが搭載されていますが、一般的なユーザーは、タブレットを持ってランニングをすることはまずありません。携帯端末向けアプリで、端末を身につけてランニングしたときに GPS で追跡し距離などを記録する機能を提供しているとしましょう。タブレットではそういったユース ケースの需要がないと思われるため、この機能をタブレット向けに提供する必要はないと考えられます。
  • タブレット UI から機能や性能を省くことになる場合は、ユーザーがそれらにアクセスできないようにするか、いわゆる「グレースフル デグラデーション」として代替機能を提供するようにします（ハードウェア機能については次のセクションも参照してください）。

8. タブレットに搭載されていない可能性があるハードウェア機能を要求しない


携帯端末とタブレットとでは一般的にセンサーやカメラ、電話機能など、各種機能のハードウェア サポートが異なっています。例えば、多くのタブレットは Wi-Fi 構成で利用できますが、電話機能には対応していません。

顧客ベース全体に対応する 1 つの APK を配布するためにも、タブレットでは一般的ではないハードウェア機能を要求するようなものがアプリに組み込まれていないことを確かめてください。
  • アプリのマニフェストには、android:required=”false” 属性で宣言されている場合を除き、タブレットで使用できない可能性のあるハードウェア機能や能力に対しては <uses-feature> 要素を含めないでください。例えば、アプリが次のような機能を要求しないようにします。
    • android.hardware.telephony
    • android.hardware.camera （バックカメラを参照）または
    • android.hardware.camera.front
  • 同様に、アプリのマニフェストには、タブレットでは適切でない可能性がある機能要件を暗示（imply feature requirements）する <permission> 要素は一切含めないでください。ただし、android:required=”false” 属性で宣言されている当該 <uses-feature> 要素を伴っている場合はこの限りではありません。
いずれの場合でも、アプリが使用するハードウェア機能が利用できないときもアプリは正常に動作し、必要に応じてグレースフル デグラデーションや代替機能を提供できなければなりません。例えば端末が GPS 未対応の場合は、アプリがユーザーに現在位置を手動で設定できるようにします。アプリは、必要なハードウェア性能についてランタイム チェックを実施し、適宜、処理を実施するようにします。
参考資料:

9. 対応しているタブレット画面構成を宣言する


幅広い種類のタブレットにアプリを配布できるようにするには、アプリが対応しているすべての画面サイズをマニフェストにて宣言します。
  • 必要に応じて、適切な属性を使い <supports-screens> 要素を宣言します。
  • マニフェスト内でアプリが <compatible-screens> 要素を宣言している場合は、その要素には、必ずアプリが対応しているタブレット画面のサイズ/ピクセル密度のすべての組み合わせを指定する属性が含まれていなければなりません。できれば、アプリでこの要素を使用するのは避けるようにしてください。
参考資料:

10. Google Play への公開に関するベスト プラクティスに従う


  • アプリは、すべての画面サイズ（携帯端末とタブレット）に対して 1 つの APK として公開し、Google Play への掲載は 1 つにします。その理由は、次の通りです。
    • ユーザーが検索やブラウズ操作、プロモーションからアプリを見つけやすい
    • ユーザーが新しい端末を入手したとき、アプリを復元しやすい
    • レーティングやダウンロード統計がすべての端末での合計になる
    • タブレット用アプリを別物として公開すると、ブランドとしてのレーティングが弱まる
  • 必要であれば複数の APK サポート（Multiple APK Support）を使いアプリを配布する選択肢もありますが、ほとんどの場合は 1 つの APK ですべての端末に対応することを強くお勧めします。
  • • 製品詳細のページにて、次のような方法でアプリのタブレット向け機能を目立たせます。
    • アプリがタブレット上で動作しているときのスクリーンショットを最低 1 枚は載せましょう。できれば横向きと縦向きそれぞれのスクリーンショットを 1 枚ずつ載せてください。こういったスクリーンショットを載せることで、アプリがタブレット向けにデザインされていることをユーザーに明確に示せると同時に、あなたがタブレット アプリをデザインする上で力を入れた点をアピールできます。
    • アプリの説明にタブレット対応であることを明記します。
    • アプリのリリース ノートや更新情報に、タブレット対応であることを盛り込みます。
    • アプリのプロモーション動画に、アプリがタブレット上で動作している様子を加えます。
  • アプリがきちんとタブレット端末へ配布されていることを確認します。Developer Console にて、アプリの対応端末リストをチェックし、対象のタブレット端末からアプリがフィルタリングされていないことを確かめます。
  • タブレット ユーザーにアプリの存在をアピールしましょう。タブレットでのアプリ使用を紹介するマーケティングや広告キャンペーンを企画します。
参考資料:

タブレット用テスト環境を整える


タブレット上でのアプリ品質（コア アプリ、タブレット アプリ両方の品質）を評価するには、適切なハードウェアまたはエミュレーターによるテスト環境を用意する必要があります。

テスト環境には、現在ユーザーに普及している主要なフォーム ファクター、ハードウェア/ソフトウェアの組み合わせのハードウェア実機をいくつか用意するのが理想的です。市場に出ているすべての端末をテストする必要はなく、1 つのフォーム ファクターにつき 1～2 台程度で、いくつかの代表的な端末を集中的にテストします。下の表に、テストに使う端末の概要を示しています。

テスト用に実機を入手できない場合は、代表的なフォーム ファクターとハードウェア/ソフトウェアの組み合わせのエミュレートした端末（emulated devices (AVDs)）を準備します。使用するエミュレーターの推奨構成については、下表を参照してください。

基本的なテスト以上のテストを実施する場合は、テスト環境の端末やフォーム ファクターの数を増やす、他のハードウェア/ソフトウェアの組み合わせを使う、などが考えられます。例えば、中型サイズのタブレットや、ハードウェア/ソフトウェアの機能が多い（または少ない）タブレットなどを使用するのもよいでしょう。また、テストの項目数を増やしたり、複雑化したり、品質条件を増やしたりしても構いません。

表 1. 代表的なタブレット テスト環境には、下表の各行の端末（代表的なチップセット、プラットフォーム バージョン、ハードウェア機能構成を備えたもの）を 1～2 台準備するのがよいでしょう。
タイプ サイズ 密度 バージョン AVD スキン
7 インチ タブレット large または -sw600 hdpi,
tvdpi		 Android 4.0+ WXGA800-7in
10 インチ タブレット xlarge または -sw800 mdpi,
hdpi		 Android 3.2+ WXGA800


このチェックリストは Creative Commons Attributes 2.5（クリエイティブ・コモンズ 表示 2.5）ライセンスで公開しています。詳しい内容と制限事項については、コンテンツのライセンス（Content License）をご参照ください。


機能


アプリが適正な権限を持ち、期待される機能動作を提供しているかを確認する基準です。

分野 ID 説明 テスト
権限 FN-P1 基本機能をサポートするのに必要な最低限の権限しか要求しないこと。 CR-11
FN-P2 アプリの基本機能にかかわる場合を除き、機密性の高いデータ（連絡先やシステム ログなど）や、ユーザー側に支払いが発生するようなサービス（ダイヤラーや SMS など）にアクセスする権限を要求しないこと。
インストール場所 FN-L1 アプリは、SD カードにインストールされている場合でも正常に動作すること（アプリが対応している場合）。

サイズの大きいアプリ（10 MB 超）については、SD カードへのインストールをサポートすることが望ましい。どういったタイプのアプリのときに SD カードへのインストールをサポートすべきかについては、アプリのインストール場所に関するデベロッパー向けガイドを参照すること。 		SD-1
オーディオ FN-A1 画面が消えているときは、オーディオは再生しないこと。ただし、それが基本機能の場合は除く（音楽プレーヤー アプリの場合など）。 CR-7
FN-A2 オーディオは、画面ロック中に再生しないこと。ただし、それが基本機能である場合は除く。 CR-8
FN-A3 オーディオは、ホーム画面または別のアプリ上では再生しないこと。ただし、それが基本機能の場合は除く。 CR-1,
CR-2
FN-A4 アプリがフォアグラウンドに復帰したときに、オーディオが再開する。もしくは、再生が一時停止の状態であることをユーザーに示すこと。 CR-1,
CR-8
UIとグラフィックス FN-U1 縦向き画面と横向き画面の両方をサポートすること（可能な場合）。

どちらの向きでもほぼ同じ特性と動作を備え、機能的同等性を維持すること。コンテンツや表示の軽微な変更は容認する。 		CR-5
FN-U2 画面がどちらの向きでも画面全体を使用し、向きの変更に対応するのにレターボックスを用いないこと。

画面配置上のわずかな差分を相殺するために使用する若干のレターボックスは容認する。 		CR-5
FN-U3 レンダリング上の問題を生じることなく、ディスプレイの向きの素早い遷移を正しく処理すること。 CR-5
ユーザー/アプリの状態 FN-S1 アプリは、バックグラウンドにあるときは、サービスを実行したままにしてはならない。ただし、アプリの基本機能にかかわる場合は除く。

例えば、通知のためのネットワーク接続の維持や、Bluetooth 接続の維持、GPS のパワー オン状態の維持といった目的のために、サービスを実行したままにしてはならない。 		CR-6
FN-S2 ユーザーやアプリの状態を正しく保存し復旧すること。

アプリがフォアグラウンドから離れるときは、ユーザー/アプリの状態を保存し、バック ナビゲーションやその他の状態変化による偶発的なデータ損失を防止すること。アプリがフォアグラウンドに戻ったとき、保存した状態と、重要なステートフル トランザクション（編集可能フィールドへの変更やゲームの進捗、メニュー、動画、アプリやゲームのその他セクションなど）で保留中だったものがあればそれを復旧させること。
  1. 「最近使用したアプリ」スイッチャーからアプリを再開するときは、アプリは、最後に使用されたときの状態にユーザーを戻すこと。
  2. スリープ（ロック）状態から端末を復帰させたのちにアプリを再開するときは、最後に使用されたときの状態にユーザーを戻すこと。
  3. アプリをホームまたは「すべてのアプリ」から再度起動するときは、直前の状態にできるだけ近い状態で復旧させること。
  4. 「Back」キー押下時に、バック ナビゲーションで状態が失われる内容がある場合は、アプリ/ユーザーの状態を保存する選択肢を用意すること。
 CR-1,
CR-3,
CR-5
関連資料:


パフォーマンスと安定性


ユーザーからより高い評価を得るには、対象とするすべての端末、フォーム ファクター、画面上で正常に機能し、応答性を維持することが求められます。ここでは、ユーザーが期待する基本的なパフォーマンスや安定性、レスポンスをアプリが提供していることを確認するための基準を挙げます。

分野 ID 説明 テスト
安定性 PS-S1 対象とする端末すべてにおいて、クラッシュ、強制終了、フリーズなどの異常な動作が起きないこと。 CR-all,
SD-1,
HA-1
パフォーマンス PS-P1 アプリは素早くロードされること。ロードに 2 秒以上かかるときは画面上にユーザーへのフィードバックを表示すること（進捗のインジケーターなど、手がかりになるものを表示）。 CR-all,
SD-1
PS-P2 StrictMode が有効なとき（後述する StrictMode でのテストを参照）、アプリの実行中（ゲームプレイやアニメーション、UI 遷移、その他アプリのあらゆる部分の実行中も含む）は、赤の点滅（StrictMode からのパフォーマンス警告）が表示されないこと。 PM-1
メディア PS-M1 音楽と動画の再生がスムーズで、通常のアプリ使用状況下および通常の負荷の状態では、途切れたり止まったりするなどのノイズが生じないこと。 CR-all,
SD-1, HA-1
視覚的品質 PS-V1 目立った変形やぼやけ、ピクセレーションを生じることなく、グラフィックやテキスト、画像、その他 UI 要素を表示すること。
  1. アプリは、対象とする画面サイズ、フォーム ファクター（タブレットなどの大画面の端末も含む）のすべてにおいて高品質のグラフィックスを表示すること。
  2. メニューやボタン、その他 UI 要素の端の部分にエイリアシングが生じないこと。
 CR-all
PS-V2 テキストとテキスト ブロックを適切に表示すること。
  1. タブレットなどの画面が大きい端末も含め、対応する全てのフォーム ファクターにて構図が適正である。
  2. 切れている文字や単語がない。
  3. ボタンやアイコン内のテキストが不適切な位置で改行されていない。
  4. テキストとその周辺にある要素の間には十分なスペースがある。
関連資料:


Google Play


アプリを Google Play で公開し、評価を上げ、ストアのプロモーション活動の対象になるようにするには、下記の基準を満たしてください。

分野 ID 説明 テスト
ポリシー GP-P1 Google Play デベロッパー プログラム ポリシーの条項を厳守し、不適切なコンテンツを提供したり、他人の知的財産権や商標などを使用したりしないこと。 GP-all
GP-P2 アプリの成熟度がコンテンツのレーティングに関するガイドラインに基づいて適切に設定されていること。

特に、端末の位置情報の使用許可を求めるアプリの場合は、成熟度レベルの「全ユーザー対象」は設定できないことに注意する。		 GP-1
アプリ詳細ページ GP-D1 アプリの宣伝用画像については、こちらのブログ記事に説明されているガイドラインに従う。以下の点を守ること。
  1. アプリの掲載情報には、高品質な宣伝用画像が含まれていること。
  2. 宣伝用画像には、最も小さい対象端末上で縮小表示されたときに読めないようなテキスト、端末の画像、スクリーンショットがでていないこと。
  3. 宣伝用画像は、広告のように見えないようにすること。
 GP-1,
GP-2
GP-D2 アプリのスクリーンショットや動画では、Android 以外の端末を見せたり言及したりしないこと。 GP-1
GP-D3 アプリのスクリーンショットや動画では、アプリの内容やアプリで体験できることを、誤解を招く形で表現しない。
ユーザー サポート GP-X1 Google Play ページの「レビュー」タブで、ユーザーから報告された共通のバグについては、そのバグが再現可能で、多数の異なる端末で発生している場合は対処すること。少数の端末でしか発生していないバグの場合でも、それらの端末が特に普及している端末、あるいは新しい端末の場合にはそのバグに対処する必要がある。 GP-1
関連資料:


テスト環境を整える


アプリの品質を評価するには、テスト用に適切なハードウェアあるいはエミュレーター環境を用意する必要があります。

テスト環境には、現在ユーザーに普及している主要なフォーム ファクター、ハードウェア/ソフトウェアの組み合わせのハードウェア実機をいくつか用意するのが理想的です。市場に出ているすべての端末をテストする必要はなく、1 つのフォーム ファクターにつき 1、2 台程度で、いくつかの代表的な端末を集中的にテストします。

テスト用に実機を入手できない場合は、代表的なフォーム ファクターとハードウェア/ソフトウェアの組み合わせのエミュレーション用端末（AVD）を準備します。

基本的なテスト以上のテストを実施する場合は、テスト環境の端末やフォーム ファクターの数を増やす、他のハードウェア/ソフトウェアの組み合わせを使用する、などが考えられます。また、テストの項目数を増やしたり、複雑化したり、品質基準を増やしたりしても構いません。


テスト方法


アプリのさまざまな品質に関する問題の発見につながるテストの方法を以下に示します。皆さんのテストプランの中では、これらのテスト同士を組み合わせたり、複数のテストグループを 1 つにまとめたりしても構いません。一部のテストで、一定の基準があるものについては、これまでのセクションを参考にしてください。

タイプ テスト 説明
基本機能全般 CR-0 アプリのあらゆる部分（すべての画面やダイアログ、設定、すべてのユーザーフロー）のナビゲーションを確認する。
  1. 編集やコンテンツの作成、ゲームプレイ、メディア再生ができるアプリの場合は、コンテンツを作成・変更するフロー内も確認すること。
  2. アプリの実行中に、ネットワーク接続状態やバッテリー機能、GPS や位置取得状況、システム負荷などを一時的に変化させること。
CR-1 アプリの各画面から、端末の「Home」キーを押したのち、「すべてのアプリ」画面からアプリを再度起動する。
CR-2 アプリの各画面から、実行中の別のアプリに切り替え、「最近使ったアプリ」スイッチャーを使ってテスト中のアプリに戻る。
CR-3 アプリの各画面（とダイアログ）から、「Back」キーを押す。
CR-5 アプリの各画面から、画面を回転させて縦向きと横向きを切り替える。最低 3 回は実施すること。
CR-6 別のアプリに切り替えて、テスト中のアプリをバックグラウンドへ移動させる。「設定」へ行き、テスト中のアプリがバックグラウンドで何らかのサービスを実行していないかをチェックする。Android 4.0 以降では、「アプリ」画面へ行くと、「実行中」タブにアプリが表示される。それ以前のバージョンの場合は、「アプリケーションの管理」で実行中のサービスがないかを確認する。
CR-7 電源ボタンを押して端末をスリープ モードにしたのち、電源ボタンを再度押して画面を復帰させる。
CR-8 電源ボタンを押したときにロックするよう端末を設定する。電源ボタンを押して端末をスリープ モードにしたのち、電源ボタンを再度押して画面を復帰させ、端末のロックを解除する。
CR-9 スライド式キーボードを搭載している端末では、キーボードの出し入れを最低 1 回は実施する。キーボード ドック付きの端末では、端末をドックに装着してみる。
CR-10 外部ディスプレイ ポート付きの端末では、外部ディスプレイを接続してみる。
CR-11 通知ドロワーに、アプリが表示できる全種類の通知を表示させて確認する。展開できる通知は展開し（Android 4.1以降）、提供されているアクションをすべてタップする。
CR-12 「設定」>「アプリ情報」で、アプリが要求する権限を確かめる。
SD カードへのインストール SD-1 端末 SD カード（アプリが対応している場合）にインストールしたアプリで、「基本機能全般」の項目を繰り返す。

アプリを SD カードに移動するには、「設定」>「アプリ情報」>「SD カードに移動」を選ぶ。
ハードウェア アクセラレーション HA-1 ハードウェア アクセラレーションを有効にした状態で、「基本機能全般」の項目を繰り返す。

ハードウェア アクセラレーションを強制的に有効にするには（端末が対応している場合）、アプリのマニフェストの <application> に hardware-accelerated="true" を追加し、リコンパイルする。
パフォーマンス モニタリング PM-1 後述する StrictMode によるプロファイリングを有効にした状態で、「基本機能全般」の項目を繰り返す。

ガベージ コレクションや、それによるユーザー エクスペリエンスへの影響を注視する。
Google Play GP-1 Developer Console にサインインし、デベロッパーのプロフィールやアプリの説明、スクリーンショット、宣伝用画像、成熟度設定、ユーザーのフィードバックを確認する。
GP-2 宣伝用画像とスクリーンショットをダウンロードし、アプリの対象端末やフォーム ファクター上のディスプレイ サイズに合うようサイズを縮小する。
GP-3 すべての画像アセットや、メディア、テキスト、コード ライブラリーなど、アプリまたは拡張ファイル ダウンロードにパッケージとして含まれているコンテンツを確認する。
支払い GP-4 アプリのすべての画面のナビゲーションを確認し、また、アプリ内の購入フローの中も確認する。


StrictMode でのテスト


パフォーマンスのテストでは、アプリで StrictMode を有効にし、パフォーマンスやネットワーク アクセス、ファイルの読み書きなどに影響しそうなメイン スレッドとその他スレッド上の動作を捕捉することをおすすめします。

StrictMode.ThreadPolicy.Builder にてスレッドごとにモニタリング ポリシーを設定でき、detectAll() を使用すれば、ThreadPolicy にてサポートされているモニタリングをすべて有効にできます。

penaltyFlashScreen() を使い、ThreadPolicy に対するポリシー違反の視覚通知を有効にしてください。


第 1 部：Making the Web Fast with PageSpeed

PageSpeed ​​は、サイト所有者が自身のサイトを最適化し、そのプロセスを自動化をする Google によるプロジェクト スイートです：Insights はお勧めを提案します。mod_pagespeed と ngx_pagespeed はサイトの最適化プロセスを自動化するオープンソースプロジェクトです。PageSpeed​ Service は、2013 年に提供開始を予定している Google の新しい最適化サービスです。本講演では、PageSpeed がどのように動き、どこに向かい、皆さんのサイトでどのように役立つかについて、詳しく見ていきます。

PageSpeed is a family of Google projects to help site owners optimize their sites, and to automate the optimization process: insights product delivers recommendations, mod_pagespeed and ngx_pagespeed are open-source projects which automate the site optimization process, and PageSpeed Service is a new Google hosted optimization service to be launched in 2013. In this talk we'll look under the hood of PageSpeed to see how it works, where it's heading, and how you can take advantage of it on your own site!

第 2 部：Wait, Chrome DevTools can do THAT?

皆さんが使われているブラウザは、（あなたがまだ気付かれていないだけで）最高の計測用の開発プラットフォームの 1 つです。もちろん、ソースコードを調べ、DOM を解析し、CSS をいじって、さらにいくつかの JavaScript の式を評価することができますが、できることはまだまだあります！本講演では、ウェブアプリケーションのパフォーマンスに関する問題を発見し、デバッグするのを手助けするヒントやトリック、隠れた機能をご紹介します。

Your browser is one of the most and best instrumented development platforms – you may just not realize it yet. Of course, you can inspect the source, walk the DOM, fiddle with the CSS, and even evaluate some Javascript expressions, but there is so much more! We'll take a look at a collection of tips, tricks, and hidden features in Chrome to help you find performance problems and debug your web applications!

＜イベント内容＞

名称：Chrome Tech Talk Night #5
日時：2013 年 1 月 31 日（木） 19:30 - 21:00 （受付 19:00 〜 19:30）
　　　※ 終了後、懇親会（軽食付き）を行う予定です。
場所：Google 東京オフィス 六本木ヒルズ森タワー 30 階
会費：無料
主催：Google
内容：PageSpeed を利用したウェブアプリケーションのパフォーマンス向上の手法、Chrome Dev Tools を利用したパフォーマンス測定方法をご紹介します。

※ 英日逐次通訳あり
※ 当日はライブ配信を行う予定です （ただし、諸事情により実施しない場合があります）。

＜申し込み方法＞

申し込みフォーム よりお申し込みください。
定員に達しましたので、締め切りました。多数のご応募ありがとうございます。

先着順による受付です。定員は 80 名です。定員になり次第、受付を締め切ります。
なお、参加証は 1 月 28 日（月）までに順次ご登録いただいたメールアドレス宛にお送りする予定です。

多くの皆様のご参加をお待ちしております。


さて、Google 日本語入力安定版 （Win, Mac） をアップデートしたことをお知らせします。既に Google 日本語入力安定版をお使いの場合は自動的に更新されますので、そのままお待ちください。

主な変更点は以下のようになります。

共通の変更点
既知の不具合
ところで、Google 日本語入力では「ことし」から「2013 年」や「平成25年」に変換したり、「きょう」から今日の日付を変換することができます。この時期は、ついつい間違えそうになりますが、これでバッチリですね。


これからも、Google 日本語入力をよりよくしようと、チーム一同で開発を進めていきます。お気づきの点がありましたら、ぜひプロダクト フォーラムからお知らせください。みなさんのフィードバックがなによりの励みになります。

【2013年1月28日追記】 

細かいバグを修正したバージョン (安定版: 1.8.1310.x, 開発版: 1.8.1314.10x) をリリースしました。以前のバージョンでは、二番目以降の候補を取得するロジックに不具合があり、期待する候補が表示されない問題がありました。

Share on Twitter Share on Facebook

Share on Twitter Share on Facebook