Martin 氏による
詳しい解説 や、このプロジェクトについての
Slashgear のコメント もご覧ください。
（
ドクター・フー のファンである）
Tom Minnich 氏は、ダーレクの声で話すアシスタントを作りました。
VIDEO
Minnich 氏は同じようなことをしたい方のために Voice Kit の改造方法をまとめた
チュートリアル も提供しています。これを使えば、ドロゴンの声のアシスタントも作れるかもしれません。
Victor Van Hee 氏は、Voice Kit を使って音声で起動できる
インターネット ストリーミング ラジオ を作りました。別のタイプのオーディオ ファイルも再生できます。
手順 が公開されているので、同じものを作ることもできます。
現在、Voice Kit は米国で入手できます。今年末までに、世界各国で販売されるようになる予定です。最新のアップデート情報をお知らせする本ブログにもご注目ください。Voice Kit に強い需要があることは、AIY Projects の大きな推進力になっています。
人間の声や視覚、動きを理解するキットで Maker を刺激する
次のキットには、視覚や動作検出が含まれる予定です。これは、既存の
Voice Kit と連携して動作できるようになるはずです。AIY Project のキットは、シンプルで強力なデバイスのインターフェースを実現する「目」、「耳」、「声」、そして「バランス」感覚をモノ作り愛好家の皆さんに提供するものになるでしょう。
皆さんからのフィードバックを次のリリースに反映したいと考えていますので、ぜひ
hackster.io にアクセスするか、コメントを記入してお知らせください。また、皆さんが作っているものを私たちやモノ作り愛好家コミュニティと共有してください。その際には、ソーシャル メディアでハッシュタグ
#AIYprojects をつけてください。
Reviewed by
Takuo Suzuki - Developer Relations Team
この記事は AIY Projects ディレクター、Billy Rutledge による Google Developers Blog の記事 "AIY Projects update: new maker projects, new partners, new kits " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Raspberry Pi と力を合わせて 5 月に リリースした Voice Kit は、わずか数時間のうちに完売しました。そのとき、私たちは明確なメッセージを受け取りました。人工知能は、人間と機械のインタラクションを自然な人間のインタラクションに近づけます。そういった人工知能を活用したモノ作りを自分たちの手で行いたいという純粋な需要があるのです。 Speech Commands Dataset についてお知らせしました。このデータセットには、30 種類の短い単語を発声した長さ 1 秒の 65,000 個のデータが含まれています。これは、AIY のウェブサイト を通して貢献してくださった数千人が発声したもので、これを使えば、アプリケーションでシンプルな音声インターフェースを実現できます。現在私たちは、このデータセットを次期バージョンの Voice Kit に組み込む作業を行っています。これによって、モノ作り愛好家の皆さんはシンプルな音声コマンドに応答するデバイスを作れるようになります。ボタン操作もインターネット接続も不要です。 Voice Kit の予約注文 を受け付けています。注文した製品は、Micro Center を通して店舗やオンラインで購入できるようになります。 Voice Kit with MagPi #57 が売り切れた際に、モノ作り愛好家の Shivasiddarth 氏が作成し、今月再び（17 分以内で） 作り上げたものをハック してみるのもよいかもしれません。
Maker による Voice Kit のクールな活用方法
Martin Mander 1986 Google Pi Intercom 詳しい解説 や、このプロジェクトについての Slashgear のコメント もご覧ください。 ドクター・フー のファンである）Tom Minnich
VIDEO
チュートリアル も提供しています。これを使えば、ドロゴンの声のアシスタントも作れるかもしれません。 Victor Van Hee インターネット ストリーミング ラジオ を作りました。別のタイプのオーディオ ファイルも再生できます。手順 が公開されているので、同じものを作ることもできます。
人間の声や視覚、動きを理解するキットで Maker を刺激する
Voice Kit と連携して動作できるようになるはずです。AIY Project のキットは、シンプルで強力なデバイスのインターフェースを実現する「目」、「耳」、「声」、そして「バランス」感覚をモノ作り愛好家の皆さんに提供するものになるでしょう。 hackster.io にアクセスするか、コメントを記入してお知らせください。また、皆さんが作っているものを私たちやモノ作り愛好家コミュニティと共有してください。その際には、ソーシャル メディアでハッシュタグ #AIYprojects をつけてください。
Takuo Suzuki - Developer Relations Team
アプリに 2 ～ 3 種類のアクションが個別に存在する場合は、複数のアプリ ランチャーを使用します。 たとえば、さまざまなオプション、アクション、ビューがあるアクティビティ トラッキングと、トラッキングしたアクティビティの履歴の分析や管理のアクション ドロワーの上部でピークを使用して、プライマリ アクションにすばやくアクセスできるようにします。 ビューに関連付けられているプライマリ アクションがない場合は、デフォルトの動作をオーバーライドしてオーバーフロー ボタンでピークするようにし、ボタンがタップされた際に、ビューの下部にすべてのアクションを表示します。
Wear 2.0 端末では、アプリでこういった新しい UI パターンを活用して、一貫性のあるユーザー エクスペリエンスを提供できます。
Wear のナビゲーションとアクション についてのトレーニング リソースや、
ナビゲーション および
アクション ドロワーのマテリアル デザインの仕様もご覧ください。
通知
Wear 2.0 では、シンプルな縦方向のナビゲーション パターンが使われており、横方向にスワイプして通知アクションを表示するジェスチャーはなくなっています。通知アクションは、単一のプライマリ アクションとして、適宜通知の下部に表示されます。プライマリ アクションがない場合は、通知が展開されて縦スクロールが可能な単一のビューにオプションが表示されます。
通知は、大きな変更を行わなくても 1.x 端末と 2.0 端末の両方で動作しますが、外見はまったく異なります。
Wear 2.0 端末向けにアプリを作成する場合は、次のベスト プラクティスを適用すれば通知のユーザー エクスペリエンスを改善できます。
展開できる通知をサポートします。 ユーザーが時計上で多くのコンテンツを見ることができるように、BigTextStyle を使います。
通知の表示に折りたたみ可能なビューを使用します（適切な場合）。 可能な場合は、setContentIntent() を利用して折りたたまれた通知ビューに通知のプライマリ アクションを追加します。
メッセージング アプリでは MessagingStyle を利用します。 展開した通知では、このスタイルを利用してチャットアプリのような高度なエクスペリエンスを提供します。
Wear 1.0 ユーザー向けの指示をアップデートします。 横方向にスワイプしてカードを操作する説明（Wear 1.x パターン）を削除します。
インライン アクションを利用して通知を拡張します。 これによって、通知をタップして展開し、詳細を表示しなくてもアクションを行えるようになります。メッセージの通知に対するアクションでは、Smart Reply プリセット、音声、キーボード入力など数種類の入力方法を利用できます。これらの機能を活用して追加機能を提供し、ユーザーの満足度を高めましょう。
詳細については、
通知にウェアラブル機能を追加する をご覧ください。
ウォッチフェイスの追加機能
ウォッチフェイス デベロッパーやサードパーティ データ プロバイダは、Wear 2.0 のウォッチフェイスの追加機能 API を使ってユーザーが求めている大事な情報を一目でわかる形で簡単に提示できます。この API をサポートしているウォッチフェイスは、外見を完全に制御しつつ、時計にインストールされている任意のデータ プロバイダを使用するように設定できます。ウォッチフェイスの追加機能 API をサポートしているアプリは、ウォッチフェイスの追加機能をサポートしている任意のウォッチフェイス上でデータを公開できます。こういったウォッチフェイスの追加機能は、データ プロバイダの設定とウォッチフェイスに割り当てられているスペースに応じて、さまざまな形態（短いテキスト、アイコン、範囲値、長いテキスト、小さなイメージ、大きなイメージ）で表示できます。
ウォッチフェイスの追加機能をサポートする場合は、この機能がウォッチフェイス全体のデザインと一致し、さらにデータ型を適切に扱えるように、以下の点に注意してウォッチフェイスを作成することをおすすめします。
Wear 2.0 SDK の TextRenderer これによって、ウォッチフェイスの追加機能内のテキストが縮小されて境界内に収まるようになります。テキストベースのウォッチフェイスの追加機能の境界を越えた場合は、動的に改行や文字列の省略が行われます。
ComplicationDrawable ユーザーが設定メニューからウォッチフェイスの追加機能を設定または調整できるように、ウォッチフェイスをデザインします。 このような設定を追加する方法については、GitHub の ウォッチフェイス サンプル をご覧ください。
データ プロバイダ テスト スイート アプリを使ってダミーデータをウォッチフェイスの追加機能にフィードします。 これによって、ウォッチフェイスの追加機能ですべてのレンダリングが適切に行われ、フォントが境界内でフォーマットされることを確認できます。
ウォッチフェイスの追加機能のデータを提供するには、ComplicationProviderService ここでは、アプリがウォッチフェイスの追加機能に提供する ComplicationData
Wear 端末のスタンドアロン機能
コンパニオン アプリがインストールされておらず、android.hardware.type.watch ハードウェア機能フラグを使用している場合に、アプリが単独で動作するようにします。 この機能を使うと、スマートフォンのコンパニオン アプリをインストールしていなくても Wear 端末から直接アプリを検索してインストールできるようになります。ユーザー エクスペリエンスが損なわれないように、単独でもアプリが適切に動作するようにします。
ウェアラブル アプリでログイン認証や主な機能を使う際に、スマートフォン アプリに依存しないようにします。 複雑な入力や認証（パスワードの入力など）が必要な場合は、ウェアラブル アプリからコンパニオンのスマートフォンに向かわせることはできますが、アカウントやパスワードの入力には、アプリよりもウェブ UI を利用するようにします。
別の目的でアプリをサポートするためにスマートフォンにコンパニオン アプリを表示する必要がある場合、CapabilityApi を使います。 この方法は、ユーザーのコンパニオン端末で Play Store の適切な掲載情報を開き、不足しているアプリをインストールするために使用します。それ以外の場合は、Wear のビルトイン Wi-Fi や GPS などの接続機能を使って、アプリが単独で動作できるようにします。
Play Store 掲載情報に、コンパニオン アプリの要件や Wear アプリの機能について説明を加えます。 この説明によって、ユーザーが機能を予測したり正しいアプリをインストールできるようになり、最高のエクスペリエンスを提供できます。
ウェアラブル アプリがスマートフォンのコンパニオンと連携せずに動作できる場合は、マニフェストに com.google.android.wearable.standalone フラグを設定します。 このフラグは、Android または iOS のコンパニオン スマートフォンとペア設定していなくても、ウェアラブル アプリをインストールするだけで完全に動作することを示します。
本投稿では多くのことを取り上げましたが、アプリやゲームを最適化し、Wear の最新パターンや機能を活用するためのリソースは他にもあります。質の高い Wear アプリを作るために、
品質ガイドラインをレビュー し、デベロッパー トレーニング ドキュメントに目を通して
ウェアラブル アプリ開発 や
ウェアラブル アプリ デザイン のベスト プラクティスを学習してください。
Reviewed by
Yoshifumi Yamaguchi - Developer Relations Team
この記事は Google Play アプリ品質コンサルタント、Steven Tepper による Android Developers Blog の記事 "How to improve app design for Wear 2.0 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Wear 2.0 には、新しいハードウェア機能の追加サポート、新しいマテリアル デザイン テーマ の採用、ガイドライン ウォッチフェイスの追加機能 API も導入され、容易にアプリからウォッチフェイスにデータを提供したり、ウォッチフェイスに外部データを組み込めるようになりました。もう 1 つの大きなアップデートは、Wear 2.0 をターゲットにしたアプリがスタンドアロン モード で動作できるようになり、スマートフォンのコンパニオン アプリとの接続が不要になったことです。
ナビゲーション
シンプルで頻繁に使用しないナビゲーションには WearableDrawerLayout ナビゲーションドロワーを使います。 シンプルなナビゲーションとは、アプリの設定へのアクセス、ユーザーの切り替え、ログアウトなどのタスクです。 Wear 2.0 でこれを実装するには、画面上部から下方向にスワイプしてアプリの別のビューやセクションに切り替えたり、画面下部から上方向にスワイプして状況依存アクション用のアクション ドロワーを設定します。
ナビゲーションドロワーをシングルページ ドロワーとして表示し、ユーザーがすばやくビューのナビゲーションを行えるようにします。 ナビゲーションドロワーは、マルチページまたはシングルページ ドロワーとして表示できます。シングルページ レイアウトは、ユーザーがアプリで 7 個以下のビューをすばやく移動する際に便利です。アプリでシングルページ ドロワーを使う場合、このレイアウトにはラベルとなるテキストは表示されないため、アイコンのデザインを明確でわかりやすいものにすることが重要です。移動先が 7 個以上のビューである場合は、アイコンで簡単に表示することはできません。マルチページ ドロワー レイアウトを利用してください。
アプリに 2 ～ 3 種類のアクションが個別に存在する場合は、複数のアプリ ランチャーを使用します。 たとえば、さまざまなオプション、アクション、ビューがあるアクティビティ トラッキングと、トラッキングしたアクティビティの履歴の分析や管理のアクション ドロワーの上部でピークを使用して、プライマリ アクションにすばやくアクセスできるようにします。 ビューに関連付けられているプライマリ アクションがない場合は、デフォルトの動作をオーバーライドしてオーバーフロー ボタンでピークするようにし、ボタンがタップされた際に、ビューの下部にすべてのアクションを表示します。
Wear のナビゲーションとアクション についてのトレーニング リソースや、ナビゲーション およびアクション ドロワーのマテリアル デザインの仕様もご覧ください。
通知
展開できる通知をサポートします。 ユーザーが時計上で多くのコンテンツを見ることができるように、BigTextStyle を使います。
通知の表示に折りたたみ可能なビューを使用します（適切な場合）。 可能な場合は、setContentIntent() を利用して折りたたまれた通知ビューに通知のプライマリ アクションを追加します。
メッセージング アプリでは MessagingStyle を利用します。 展開した通知では、このスタイルを利用してチャットアプリのような高度なエクスペリエンスを提供します。
Wear 1.0 ユーザー向けの指示をアップデートします。 横方向にスワイプしてカードを操作する説明（Wear 1.x パターン）を削除します。
インライン アクションを利用して通知を拡張します。 これによって、通知をタップして展開し、詳細を表示しなくてもアクションを行えるようになります。メッセージの通知に対するアクションでは、Smart Reply プリセット、音声、キーボード入力など数種類の入力方法を利用できます。これらの機能を活用して追加機能を提供し、ユーザーの満足度を高めましょう。
通知にウェアラブル機能を追加する をご覧ください。
ウォッチフェイスの追加機能
ウォッチフェイス デベロッパーやサードパーティ データ プロバイダは、Wear 2.0 のウォッチフェイスの追加機能 API を使ってユーザーが求めている大事な情報を一目でわかる形で簡単に提示できます。この API をサポートしているウォッチフェイスは、外見を完全に制御しつつ、時計にインストールされている任意のデータ プロバイダを使用するように設定できます。ウォッチフェイスの追加機能 API をサポートしているアプリは、ウォッチフェイスの追加機能をサポートしている任意のウォッチフェイス上でデータを公開できます。こういったウォッチフェイスの追加機能は、データ プロバイダの設定とウォッチフェイスに割り当てられているスペースに応じて、さまざまな形態（短いテキスト、アイコン、範囲値、長いテキスト、小さなイメージ、大きなイメージ）で表示できます。
Wear 2.0 SDK の TextRenderer これによって、ウォッチフェイスの追加機能内のテキストが縮小されて境界内に収まるようになります。テキストベースのウォッチフェイスの追加機能の境界を越えた場合は、動的に改行や文字列の省略が行われます。
ComplicationDrawable ユーザーが設定メニューからウォッチフェイスの追加機能を設定または調整できるように、ウォッチフェイスをデザインします。 このような設定を追加する方法については、GitHub の ウォッチフェイス サンプル をご覧ください。
データ プロバイダ テスト スイート アプリを使ってダミーデータをウォッチフェイスの追加機能にフィードします。 これによって、ウォッチフェイスの追加機能ですべてのレンダリングが適切に行われ、フォントが境界内でフォーマットされることを確認できます。
ウォッチフェイスの追加機能のデータを提供するには、ComplicationProviderService ここでは、アプリがウォッチフェイスの追加機能に提供する ComplicationData
Wear 端末のスタンドアロン機能
コンパニオン アプリがインストールされておらず、android.hardware.type.watch ハードウェア機能フラグを使用している場合に、アプリが単独で動作するようにします。 この機能を使うと、スマートフォンのコンパニオン アプリをインストールしていなくても Wear 端末から直接アプリを検索してインストールできるようになります。ユーザー エクスペリエンスが損なわれないように、単独でもアプリが適切に動作するようにします。
ウェアラブル アプリでログイン認証や主な機能を使う際に、スマートフォン アプリに依存しないようにします。 複雑な入力や認証（パスワードの入力など）が必要な場合は、ウェアラブル アプリからコンパニオンのスマートフォンに向かわせることはできますが、アカウントやパスワードの入力には、アプリよりもウェブ UI を利用するようにします。
別の目的でアプリをサポートするためにスマートフォンにコンパニオン アプリを表示する必要がある場合、CapabilityApi を使います。 この方法は、ユーザーのコンパニオン端末で Play Store の適切な掲載情報を開き、不足しているアプリをインストールするために使用します。それ以外の場合は、Wear のビルトイン Wi-Fi や GPS などの接続機能を使って、アプリが単独で動作できるようにします。
Play Store 掲載情報に、コンパニオン アプリの要件や Wear アプリの機能について説明を加えます。 この説明によって、ユーザーが機能を予測したり正しいアプリをインストールできるようになり、最高のエクスペリエンスを提供できます。
ウェアラブル アプリがスマートフォンのコンパニオンと連携せずに動作できる場合は、マニフェストに com.google.android.wearable.standalone フラグを設定します。 このフラグは、Android または iOS のコンパニオン スマートフォンとペア設定していなくても、ウェアラブル アプリをインストールするだけで完全に動作することを示します。
品質ガイドラインをレビュー し、デベロッパー トレーニング ドキュメントに目を通してウェアラブル アプリ開発 やウェアラブル アプリ デザイン のベスト プラクティスを学習してください。
Yoshifumi Yamaguchi - Developer Relations Team
図 1. Measure
描画プロセス内の各フェーズでは、上から順にビューツリーをたどる処理が必要です。そのため、ビュー階層に別のビューが埋め込まれている（ネストしている）ビューが多いほど、端末がビューを描画する際に必要となる時間と計算能力が増加します。つまり、Android アプリのレイアウトでフラットな階層を維持すれば、高速で反応の早いユーザー インターフェースを実現できます。
従来型のレイアウト階層にかかるコスト
以上の説明に留意した上で、
LinearLayout オブジェクトと
RelativeLayout オブジェクトを使って従来型のレイアウト階層を作成してみましょう。
ここでは、上のイメージのようなレイアウトを作成することを考えてみます。従来型のレイアウトを使って作成する場合、要素の階層を含む XML ファイルは次のようになります（この例では、属性は省いています）。
<RelativeLayout>
<ImageView />
<ImageView />
<RelativeLayout>
<TextView />
<LinearLayout>
<TextView />
<RelativeLayout>
<EditText />
</RelativeLayout>
</LinearLayout>
<LinearLayout>
<TextView />
<RelativeLayout>
<EditText />
</RelativeLayout>
</LinearLayout>
<TextView />
</RelativeLayout>
<LinearLayout >
<Button />
<Button />
</LinearLayout>
</RelativeLayout>
通常、このような種類のビュー階層には改善の余地がありますが、どのような形であっても、いくつかのネストしたビューを作成する必要があります。
先ほど説明したように、ネストした階層はパフォーマンス悪化の原因となる場合があります。では、ネストしたビューが実際にどのように UI のパフォーマンスに影響するかについて、Android Studio の
Systrace ツールを使って見てみましょう。各
ViewGroup（
ConstraintLayout と
RelativeLayout）についてプログラムから Measure フェーズと Layout フェーズを呼び出し、それぞれが実行されている間に Systrace が呼び出されるようにします。次のコマンドを実行すると、時間がかかっているイベントが記録された、HTML ファイルが生成されます。これには、20 秒間に発生した標準より大幅に時間がかかっている Measure や Layout のパスなどが含まれます。
python $ANDROID_HOME/platform-tools/systrace/systrace.py --time=20 -o ~/trace.html gfx view res
Systrace の使用方法の詳細は、
Systrace で UI のパフォーマンスを分析する ためのガイドをご覧ください。
Systrace は、このレイアウトに関する（たくさんの）パフォーマンスの問題を自動的に報告するだけでなく、それを修正する方法も提案してくれます。[Alerts] タブをクリックすると、このビュー階層の描画には、 Measure フェーズと Layout フェーズで 80 回ものパスで標準より大幅に時間がかかっていることがわかります。
Measure フェーズと Layout フェーズでコストがかかる多くの処理が呼び出されるというのは、理想からはほど遠いものです。描画に必要な作業が多すぎると、ユーザーが気づくようなフレーム スキップが発生する可能性もあります。結論として、このレイアウトはパフォーマンスが悪いことがわかります。これは、ビュー階層がネストされていることと、各子要素について 2 回測定を行う必要があるという
RelativeLayout の特性が原因となっています。
図 3. RelativeLayout を利用したレイアウトについてのアラートを確認
この測定に使ったコードは
GitHub レポジトリ から確認できます。
ConstraintLayout オブジェクトがもたらすメリット
ConstraintLayout を使ってレイアウトを作成すると、XML ファイルには次のような要素が含まれることになります（今回も属性は省略します）。
<android.support.constraint.ConstraintLayout>
<ImageView />
<ImageView />
<TextView />
<EditText />
<TextView />
<TextView />
<EditText />
<Button />
<Button />
<TextView />
</android.support.constraint.ConstraintLayout>
この例からわかるように、レイアウトの階層は完全にフラットになります。
ConstraintLayout を使うと、
View 要素や
ViewGroup 要素をネストさせずに複雑なレイアウトを作成できます。
たとえば、レイアウトの中ほどにある
TextView と
EditText に注目してみましょう。
RelativeLayout を使う場合は、新しい ViewGroup を作成して EditText と TextView の縦方向の位置を合わせる必要があります。
<LinearLayout
android:id="@+id/camera_area"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal"
android:layout_below="@id/title" >
<TextView
android:text="@string/camera"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center_vertical"
android:id="@+id/cameraLabel"
android:labelFor="@+id/cameraType"
android:layout_marginStart="16dp" />
<RelativeLayout
android:layout_width="match_parent"
android:layout_height="wrap_content">
<EditText
android:id="@+id/cameraType"
android:ems="10"
android:inputType="textPersonName"
android:text="@string/camera_value"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_centerVertical="true"
android:layout_marginTop="8dp"
android:layout_marginStart="8dp"
android:layout_marginEnd="8dp" />
</RelativeLayout>
</LinearLayout>
しかし、
ConstraintLayout を使う場合は、
TextView のベースラインを
EditText と合わせるという制約を追加するだけで同じ効果が得られます。別の
ViewGroup を作成する必要はありません。
図 4.
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:layout_constraintLeft_creator="1"
app:layout_constraintBaseline_creator="1"
app:layout_constraintLeft_toLeftOf="@+id/activity_main_done"
app:layout_constraintBaseline_toBaselineOf="@+id/cameraType" />ConstraintLayout を使ったレイアウトに対して Systrace ツールを実行すると、同じ 20 秒間でコストがかかる Measure および Layout での標準より時間がかかっているパスがかなり少なくなっていることがわかります。このパフォーマンスの向上は当然です。ビュー階層がフラットになっているからです。
図 5. ConstraintLayout を利用したレイアウトについてのアラートを確認
なお、先ほどのレイアウトの
ConstraintLayout 版は、
レイアウト エディタ だけを使い、XML を直接編集することなく作りました。
パフォーマンスの違いを測定する
ConstraintLayout と
RelativeLayout の 2 種類のレイアウトについて、Android 7.0（API レベル 24）で導入された
OnFrameMetricsAvailableListener を使ってすべての Measure と Layout のパスにかかる時間を分析してみました。このクラスを使うと、アプリの UI レンダリングについてフレームごとのタイミング情報を収集できます。
次のコードを呼び出すと、フレームごとの UI アクションの記録を開始します。
window.addOnFrameMetricsAvailableListener(
frameMetricsAvailableListener, frameMetricsHandler);
タイミング情報が利用できるようになると、
frameMetricsAvailableListener() コールバックが呼び出されます。今回は、Measure と Layout のパフォーマンスを取得したいので、実際のフレームの所要時間を取得する際に
FrameMetrics.LAYOUT_MEASURE_DURATION を呼び出します。
Window.OnFrameMetricsAvailableListener {
_, frameMetrics, _ ->
val frameMetricsCopy = FrameMetrics(frameMetrics);
// Layout measure duration in nanoseconds
val layoutMeasureDurationNs =
frameMetricsCopy.getMetric(FrameMetrics.LAYOUT_MEASURE_DURATION);
FrameMetrics で取得できるその他のタイプの所要時間情報の詳細については、
FrameMetrics API リファレンスをご覧ください。
測定結果: 高速なのは ConstraintLayout
パフォーマンスの比較から、
ConstraintLayout は
RelativeLayout より計測フェーズと配置フェーズが約 40% 早くなっていることがわかります。
図 6.
この結果からわかるように、
ConstraintLayout の方が従来型のレイアウトよりも高速である可能性が高いと言えます。さらに、
ConstraintLayout オブジェクトがもたらすメリット のセクションで説明したように、
ConstraintLayout には複雑でパフォーマンスのよいレイアウトを作成するための他の機能も備わっています。詳しくは、
ConstraintLayout による応答性が高い UI の作成 ガイドをご覧ください。アプリのレイアウトをデザインする際には、
ConstraintLayout を使うことをお勧めします。
ConstraintLayout を使うと、以前は深くネストさせなければならなかったほとんどすべての場合で、使いやすく最適なパフォーマンスを提供できるレイアウトを実現できます。
付録: 測定環境
上記の測定は、すべて以下の環境で実施しました。
端末
Nexus 5X
Android バージョン
8.0
ConstraintLayout バージョン
1.0.2
次のステップ
デベロッパー ガイド 、
API リファレンス ドキュメント 、
Medium の記事 を確認し、
ConstraintLayout ができることを理解しましょう。また、
ConstraintLayout のアルファ リリース以降の数か月間で、フィードバックや問題をお送りくださった皆さん、どうもありがとうございました。おかげさまで今年初め、本番環境で利用できる
バージョン 1.0 の
ConstraintLayout をリリースできました。
ConstraintLayout の改善はこれからも続きますので引き続き
Android Issue Tracker からフィードバックをお送りください。
Reviewed by
Takeshi Hagikura - Developer Relations Team
この記事はデベロッパー プログラム エンジニア、Takeshi Hagikura による Android Developers Blog の記事 "Understanding the performance benefits of using ConstraintLayout " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
ConstraintLayout Chain の導入 や Ratio によるサイズ設定 など、ConstraintLayout ならではの新機能も追加され、さまざまな種類のレイアウトが作りやすくなっています。こういった機能に加え、ConstraintLayout には大きなパフォーマンス上のメリットがあります。本投稿では、このパフォーマンスの改善がもたらすメリットについて説明します。
Android がビューを描画する方法
ConstraintLayout のパフォーマンスを深く理解するため、まずは Android がどのようにビューを描画しているのかについて見てみましょう。
Measure ViewGroup とビュー要素の大きさを決定します。ViewGroup を測定する際は、その子要素も測定します。
Layout ViewGroup について測定フェーズで求めたサイズから子要素の位置を決定します。
Draw Canvas オブジェクトが作成され、GPU に描画コマンドのリストが送られます。このコマンドには、最初の 2 つのフェーズで求めた ViewGroup および View オブジェクトのサイズと位置が含まれます。
図 1. Measure
描画プロセス内の各フェーズでは、上から順にビューツリーをたどる処理が必要です。そのため、ビュー階層に別のビューが埋め込まれている（ネストしている）ビューが多いほど、端末がビューを描画する際に必要となる時間と計算能力が増加します。つまり、Android アプリのレイアウトでフラットな階層を維持すれば、高速で反応の早いユーザー インターフェースを実現できます。
従来型のレイアウト階層にかかるコスト
以上の説明に留意した上で、LinearLayout オブジェクトと RelativeLayout オブジェクトを使って従来型のレイアウト階層を作成してみましょう。 <RelativeLayout>
<ImageView />
<ImageView />
<RelativeLayout>
<TextView />
<LinearLayout>
<TextView />
<RelativeLayout>
<EditText />
</RelativeLayout>
</LinearLayout>
<LinearLayout>
<TextView />
<RelativeLayout>
<EditText />
</RelativeLayout>
</LinearLayout>
<TextView />
</RelativeLayout>
<LinearLayout >
<Button />
<Button />
</LinearLayout>
</RelativeLayout>
Systrace ツールを使って見てみましょう。各 ViewGroup（ConstraintLayout と RelativeLayout）についてプログラムから Measure フェーズと Layout フェーズを呼び出し、それぞれが実行されている間に Systrace が呼び出されるようにします。次のコマンドを実行すると、時間がかかっているイベントが記録された、HTML ファイルが生成されます。これには、20 秒間に発生した標準より大幅に時間がかかっている Measure や Layout のパスなどが含まれます。 python $ANDROID_HOME/platform-tools/systrace/systrace.py --time=20 -o ~/trace.html gfx view res
Systrace で UI のパフォーマンスを分析する ためのガイドをご覧ください。 RelativeLayout の特性が原因となっています。
図 3. RelativeLayout を利用したレイアウトについてのアラートを確認
GitHub レポジトリ から確認できます。
ConstraintLayout オブジェクトがもたらすメリット
ConstraintLayout を使ってレイアウトを作成すると、XML ファイルには次のような要素が含まれることになります（今回も属性は省略します）。 <android.support.constraint.ConstraintLayout>
<ImageView />
<ImageView />
<TextView />
<EditText />
<TextView />
<TextView />
<EditText />
<Button />
<Button />
<TextView />
</android.support.constraint.ConstraintLayout>
ConstraintLayout を使うと、View 要素や ViewGroup 要素をネストさせずに複雑なレイアウトを作成できます。 TextView と EditText に注目してみましょう。
RelativeLayout を使う場合は、新しい ViewGroup を作成して EditText と TextView の縦方向の位置を合わせる必要があります。
<LinearLayout
android:id="@+id/camera_area"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal"
android:layout_below="@id/title" >
<TextView
android:text="@string/camera"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center_vertical"
android:id="@+id/cameraLabel"
android:labelFor="@+id/cameraType"
android:layout_marginStart="16dp" />
<RelativeLayout
android:layout_width="match_parent"
android:layout_height="wrap_content">
<EditText
android:id="@+id/cameraType"
android:ems="10"
android:inputType="textPersonName"
android:text="@string/camera_value"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_centerVertical="true"
android:layout_marginTop="8dp"
android:layout_marginStart="8dp"
android:layout_marginEnd="8dp" />
</RelativeLayout>
</LinearLayout>
ConstraintLayout を使う場合は、TextView のベースラインを EditText と合わせるという制約を追加するだけで同じ効果が得られます。別の ViewGroup を作成する必要はありません。
図 4.
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:layout_constraintLeft_creator="1"
app:layout_constraintBaseline_creator="1"
app:layout_constraintLeft_toLeftOf="@+id/activity_main_done"
app:layout_constraintBaseline_toBaselineOf="@+id/cameraType" />ConstraintLayout を使ったレイアウトに対して Systrace ツールを実行すると、同じ 20 秒間でコストがかかる Measure および Layout での標準より時間がかかっているパスがかなり少なくなっていることがわかります。このパフォーマンスの向上は当然です。ビュー階層がフラットになっているからです。
図 5. ConstraintLayout を利用したレイアウトについてのアラートを確認
なお、先ほどのレイアウトの ConstraintLayout 版は、レイアウト エディタ だけを使い、XML を直接編集することなく作りました。
パフォーマンスの違いを測定する
ConstraintLayout と RelativeLayout の 2 種類のレイアウトについて、Android 7.0（API レベル 24）で導入された OnFrameMetricsAvailableListener window.addOnFrameMetricsAvailableListener(
frameMetricsAvailableListener, frameMetricsHandler);
frameMetricsAvailableListener() コールバックが呼び出されます。今回は、Measure と Layout のパフォーマンスを取得したいので、実際のフレームの所要時間を取得する際に FrameMetrics.LAYOUT_MEASURE_DURATION Window.OnFrameMetricsAvailableListener {
_, frameMetrics, _ ->
val frameMetricsCopy = FrameMetrics(frameMetrics);
// Layout measure duration in nanoseconds
val layoutMeasureDurationNs =
frameMetricsCopy.getMetric(FrameMetrics.LAYOUT_MEASURE_DURATION);
FrameMetrics で取得できるその他のタイプの所要時間情報の詳細については、FrameMetrics
測定結果: 高速なのは ConstraintLayout
パフォーマンスの比較から、ConstraintLayout は RelativeLayout より計測フェーズと配置フェーズが約 40% 早くなっていることがわかります。
図 6.
この結果からわかるように、ConstraintLayout の方が従来型のレイアウトよりも高速である可能性が高いと言えます。さらに、ConstraintLayout オブジェクトがもたらすメリット のセクションで説明したように、ConstraintLayout には複雑でパフォーマンスのよいレイアウトを作成するための他の機能も備わっています。詳しくは、ConstraintLayout による応答性が高い UI の作成 ガイドをご覧ください。アプリのレイアウトをデザインする際には、ConstraintLayout を使うことをお勧めします。ConstraintLayout を使うと、以前は深くネストさせなければならなかったほとんどすべての場合で、使いやすく最適なパフォーマンスを提供できるレイアウトを実現できます。
付録: 測定環境
端末
Nexus 5X
Android バージョン
8.0
ConstraintLayout バージョン
1.0.2
次のステップ
デベロッパー ガイド 、API リファレンス ドキュメント 、Medium の記事 を確認し、ConstraintLayout ができることを理解しましょう。また、ConstraintLayout のアルファ リリース以降の数か月間で、フィードバックや問題をお送りくださった皆さん、どうもありがとうございました。おかげさまで今年初め、本番環境で利用できる バージョン 1.0 の ConstraintLayout をリリースできました。ConstraintLayout の改善はこれからも続きますので引き続き Android Issue Tracker からフィードバックをお送りください。 Takeshi Hagikura - Developer Relations Team
左（Android O 以前）: システムアップデートに偽装した PHA のインストール画面。
Android O では、
Install unknown apps パーミッションが追加され、提供元不明のアプリのインストールが安全になっています。このパーミッションは、他のランタイム パーミッションと同じく、インストールしようとするアプリに関連付けられています。そのため、ユーザーがそのインストール提供元を利用するパーミッションを付与してから、アプリのインストールの確認画面が表示されるようになります。Android O 以降を実行している端末では、あらかじめ許可を得ていない悪意のあるダウンローダーがユーザーを欺いてアプリをインストールさせることはできません。
この新しいパーミッションによって、ユーザーにとっての透明性や制御範囲が向上し、信頼できる提供元によるアプリのインストールを有効化する処理も効率化されます。Settings アプリには、ユーザーがインストールを許可した提供元不明のアプリの一覧が表示されます。特定のアプリに付与したパーミッションは、いつでも取り消すことができます。
提供元不明のアプリのインストールを許可したアプリはいつでも確認できます。パーミッションを付与する処理を簡単にするため、セットアップのフローの中でユーザーをパーミッション画面に飛ばすこともできます。
デベロッパーにとっての変更点
Package Installer 経由で別のアプリをダウンロードおよびインストールするアプリでこの新しい動作を利用するには、いくつかの変更が必要になる場合があります。
targetSdkLevel が 26 以降のアプリで別のアプリをインストールするには、次のようにしてマニフェスト ファイルに
REQUEST_INSTALL_PACKAGES パーミッションを含める必要があります。
<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />
このパーミッションを宣言していないアプリは、別のアプリをインストールすることはできません。これは、別のアプリのインストールを想定していないアプリには便利なセキュリティ保護になります。
ACTION_MANAGE_UNKNOWN_APP_SOURCES Intent アクションを利用して、実際にインストールを行う前に
Install unknown apps パーミッション画面を表示することもできます。また、PackageManager の
canRequestPackageInstalls() API を利用して、このパーミッションの状態を問い合わせることもできます。
Google Play で配布するアプリから別のアプリのインストールやアップデートを行う場合は、
Play ポリシー が適用されることも忘れないようにしてください。大半の場合、このような動作は不適切です。Play Store のアプリの掲載情報ページへの
ディープリンク を使うようにしてください。
提供元不明のアプリのインストールについての詳しい情報は、アップデートされた
公開ガイド をご覧ください。また、Android O で強化されたセキュリティについては、他の投稿にもご注目ください。
Reviewed by
Yuichi Araki - Developer Relations Team
この記事は Android Security プロダクト マネージャー、Edward Cunningham による Android Developers Blog の記事 "Making it safer to get apps on Android O " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Install unknown apps パーミッションと、これが Android ユーザーとデベロッパーの双方にもたらすセキュリティ上のメリットについて説明します。Google Play プロテクト が導入されました。Google Play は、依然として Android ユーザーがアプリをダウンロードできる安全な場所です。有害な可能性があるアプリ（PHA）の大半は、サードパーティの提供元に由来しています。
2016 年 Android セキュリティ総括 をご覧ください）。提供元不明のアプリのインストールを有効にしたユーザーは、このような偽装した動作の被害に遭いやすくなります。
左（Android O 以前）: システムアップデートに偽装した PHA のインストール画面。
Install unknown apps パーミッションが追加され、提供元不明のアプリのインストールが安全になっています。このパーミッションは、他のランタイム パーミッションと同じく、インストールしようとするアプリに関連付けられています。そのため、ユーザーがそのインストール提供元を利用するパーミッションを付与してから、アプリのインストールの確認画面が表示されるようになります。Android O 以降を実行している端末では、あらかじめ許可を得ていない悪意のあるダウンローダーがユーザーを欺いてアプリをインストールさせることはできません。
提供元不明のアプリのインストールを許可したアプリはいつでも確認できます。パーミッションを付与する処理を簡単にするため、セットアップのフローの中でユーザーをパーミッション画面に飛ばすこともできます。
デベロッパーにとっての変更点
Package Installer 経由で別のアプリをダウンロードおよびインストールするアプリでこの新しい動作を利用するには、いくつかの変更が必要になる場合があります。targetSdkLevel が 26 以降のアプリで別のアプリをインストールするには、次のようにしてマニフェスト ファイルに REQUEST_INSTALL_PACKAGES <uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />
ACTION_MANAGE_UNKNOWN_APP_SOURCES Install unknown apps パーミッション画面を表示することもできます。また、PackageManager の canRequestPackageInstalls() Play ポリシー が適用されることも忘れないようにしてください。大半の場合、このような動作は不適切です。Play Store のアプリの掲載情報ページへのディープリンク を使うようにしてください。 公開ガイド をご覧ください。また、Android O で強化されたセキュリティについては、他の投稿にもご注目ください。 Yuichi Araki - Developer Relations Team
Fast Fetch は、Delayed Fetch と比較して 50 パーセンタイルで 850 ミリ秒、90 パーセンタイルで 2.7 秒高速です。
AMP Ads の協調レンダリング
広告レスポンスが AMP 形式である場合（AMP Ads）、AMP ランタイムは広告を即座にレンダリングします。レスポンスが通常の広告である場合、ランタイムはページの残りのコンテンツが読み込まれるのを待つ必要があります。AMP 広告ではパフォーマンスが保証されているのでそのようなことが可能ですが、非 AMP 広告にはそのような保証はありません。
DoubleClick と AdSense の実験によると、AMP Ads は 50 パーセンタイルで 1.6 秒、90 パーセンタイルで最大 5 秒早く読み込まれます。
広告が画面に早く表示されるほど、広告の視認性も向上します。ブランドが多くの人の目に触れることになるので、これは広告主にとって有益です。また、視認性の向上によってユーザーが広告を開くチャンスが増えるため、成果型の広告主にとっても有益です。
Fast Fetch の新機能のリリース
多くのサイトオーナーが、主要サイトのコンテンツを AMP 形式で提供する実験を行っています。そのようなサイトオーナーの作業をサポートするため、AMP の Fast Fetch には、さらに高度な広告機能が追加される予定となっています。たとえば、次のようなものです。
AMP ページでの競合広告の排除やブロック
設定した頻度で広告を更新する機能
リアルタイムで広告リクエストに広告サーバーのターゲット情報を含める拡張機能のサポート
サイトオーナー（または広告主）の皆さまへ
DoubleClick と AdSense のおかげで、AMP ページから広告リクエストが送られる際に、一定の条件を満たす広告は自動的に AMP に変換されます。AMP に変換可能な形式が増えるにつれて、自動変換される広告も増加することが考えられます。その結果、何も変更しなくても、皆さまのページに高い視認性とクリックスルー率を持つ広告が提供されることになります。
クリエイティブを制作している広告主（またはサイトオーナー）の皆さまへ
広告を制作している方は（サイトオーナーであるか広告主であるかにかかわらず）、AMP Ads への切り替えをご検討ください。視認性やユーザー エクスペリエンスが高い高速な広告によるメリットを受けることができます。まずは、社内のクリエイティブ制作者に、こちらの
AMP Ads デベロッパーのよくある質問 を確認してもらってください。
クリエイティブ アセットの制作を外注している場合は、AMP クリエイティブの制作に特化した
JoyStick Interactive などの代理店に依頼することができます。広告制作ツールを使ってアセットを作成している場合は、
Celtra の A d C
r e
a t
o r を使って AMP Ads を制作することをご検討ください。
Google Web Designer などの他のツールでも、近日中に AMP 広告がサポートされます。
広告技術プラットフォームの皆さまへ
DoubleClick や Adsense の広告タグは、Fast Fetch を利用して劇的にレイテンシを削減しています。私たちは、すべての広告ネットワークが Fast Fetch に移行することを望んでいます。移行をサポートする
ガイド はこちらです。AMP Ads に署名したい方は、Cloudflare の
Firebolt サービス を利用できます。自分で署名したい方は、
Github をご覧ください。
「Cloudflare Firebolt を使うと、どんな広告ネットワークでも、署名した広告を世界に提供できます。追加の作業はほとんど発生しません」と Cloudflare のプロダクト戦略責任者である Dane Knecht 氏は述べています。「私たちは、インターネットをよりよくするという使命の一環として、Firebolt のグローバルな AMP 広告エクスペリエンスをさらに高速で安全なものへと強化しています。それによって、コンバージョン率を向上させることができます」
また、AMP Ads は DoubleClick
Ad Exchange （Real Time Bidding 経由）をサポートしており、DSP は RTB 経由で AMP 広告 を提供できるようになっています。
自動変換して AMP Ads を配信できるよう広告ネットワークを強化
広告サーバーでカスタムメイド AMP Ads のアップロードと配信をサポート
クリエイティブ制作者が AMP Ads を制作する際に役立つ機能の構築
デフォルトで AMP Ads を出力するように、さらに多くの広告制作ツールと連携
いつものように、皆さまのフィードバックは大歓迎です。ウェブの進化に向けて、上記の取り組みにご協力いただける方もお待ちしています。
Yoshifumi Yamaguchi - Developer Relations Team
この記事は AMP Project プロダクト マネージャー、Vamsee Jasti による Accelerated Mobile Pages Project の記事 "Even Faster Loading Ads in AMP " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
セッションを開催し 、AMP ページで広告の基本機能をサポートするところから、ユーザーやサイトオーナー、広告主にとって本当に優れた広告エクスペリエンスを実現する AMP ページに至るために必要な道のりについてお話ししました。セッションで説明したように、これを達成するまでには次の 3 つのフェーズがあります。
Fast Fetch のリリース
フェーズ 2 で追加された一番の目玉機能が「Fast Fetch」です。Fast Fetch を使うと、広告をリクエストするタイミングと、広告のレスポンスをレンダリングするタイミングを分離できます。これによって、ページのライフサイクルのかなり早い段階ですべてのスロットの広告をリクエストでき、その広告はユーザーが見る直前までレンダリングされなくなります。
Fast Fetch では、ページのライフサイクルのかなり早い段階で広告がリクエストされるため、ページのレンダリングや、広告サーバーでのクリエイティブの選択が並列に実行されます。
Fast Fetch は、Delayed Fetch と比較して 50 パーセンタイルで 850 ミリ秒、90 パーセンタイルで 2.7 秒高速です。
AMP Ads の協調レンダリング
広告レスポンスが AMP 形式である場合（AMP Ads）、AMP ランタイムは広告を即座にレンダリングします。レスポンスが通常の広告である場合、ランタイムはページの残りのコンテンツが読み込まれるのを待つ必要があります。AMP 広告ではパフォーマンスが保証されているのでそのようなことが可能ですが、非 AMP 広告にはそのような保証はありません。
DoubleClick と AdSense の実験によると、AMP Ads は 50 パーセンタイルで 1.6 秒、90 パーセンタイルで最大 5 秒早く読み込まれます。
Fast Fetch の新機能のリリース
多くのサイトオーナーが、主要サイトのコンテンツを AMP 形式で提供する実験を行っています。そのようなサイトオーナーの作業をサポートするため、AMP の Fast Fetch には、さらに高度な広告機能が追加される予定となっています。たとえば、次のようなものです。
AMP ページでの競合広告の排除やブロック
設定した頻度で広告を更新する機能
リアルタイムで広告リクエストに広告サーバーのターゲット情報を含める拡張機能のサポート
サイトオーナー（または広告主）の皆さまへ
DoubleClick と AdSense のおかげで、AMP ページから広告リクエストが送られる際に、一定の条件を満たす広告は自動的に AMP に変換されます。AMP に変換可能な形式が増えるにつれて、自動変換される広告も増加することが考えられます。その結果、何も変更しなくても、皆さまのページに高い視認性とクリックスルー率を持つ広告が提供されることになります。
クリエイティブを制作している広告主（またはサイトオーナー）の皆さまへ
広告を制作している方は（サイトオーナーであるか広告主であるかにかかわらず）、AMP Ads への切り替えをご検討ください。視認性やユーザー エクスペリエンスが高い高速な広告によるメリットを受けることができます。まずは、社内のクリエイティブ制作者に、こちらの AMP Ads デベロッパーのよくある質問 を確認してもらってください。JoyStick Interactive などの代理店に依頼することができます。広告制作ツールを使ってアセットを作成している場合は、Celtra の A d Cr ea to r を使って AMP Ads を制作することをご検討ください。Google Web Designer などの他のツールでも、近日中に AMP 広告がサポートされます。
広告技術プラットフォームの皆さまへ
DoubleClick や Adsense の広告タグは、Fast Fetch を利用して劇的にレイテンシを削減しています。私たちは、すべての広告ネットワークが Fast Fetch に移行することを望んでいます。移行をサポートするガイド はこちらです。AMP Ads に署名したい方は、Cloudflare の Firebolt サービス を利用できます。自分で署名したい方は、Github をご覧ください。
「Cloudflare Firebolt を使うと、どんな広告ネットワークでも、署名した広告を世界に提供できます。追加の作業はほとんど発生しません」と Cloudflare のプロダクト戦略責任者である Dane Knecht 氏は述べています。「私たちは、インターネットをよりよくするという使命の一環として、Firebolt のグローバルな AMP 広告エクスペリエンスをさらに高速で安全なものへと強化しています。それによって、コンバージョン率を向上させることができます」
Ad Exchange （Real Time Bidding 経由）をサポートしており、DSP は RTB 経由で AMP 広告 を提供できるようになっています。
自動変換して AMP Ads を配信できるよう広告ネットワークを強化
広告サーバーでカスタムメイド AMP Ads のアップロードと配信をサポート
クリエイティブ制作者が AMP Ads を制作する際に役立つ機能の構築
デフォルトで AMP Ads を出力するように、さらに多くの広告制作ツールと連携
いつものように、皆さまのフィードバックは大歓迎です。ウェブの進化に向けて、上記の取り組みにご協力いただける方もお待ちしています。
Yoshifumi Yamaguchi - Developer Relations Team
今年のアプリには、I/O の進行状況を随時ユーザーに知らせる
フィード 機能もありました（アプリのユーザーのほとんどは現地にいなかったため、フィードがカンファレンスの状況を伝える窓になりました）。このフィード機能も RTDB を利用しており、単純な CMS を使ってサーバーにデータをプッシュしています。RTDB のフィードデータを Cloud Function で監視し、サーバー上でフィードデータが更新されると、Function が Cloud Messaging のダウンストリーム メッセージをクライアントに送信します。クライアントでは、新しいフィードアイテムが視覚的にユーザーに提示されます。
2015 年と 2016 年 の IOSched には、MVP アーキテクチャが採用されていましたが、今年も引き続き、このアーキテクチャを利用しています。このアーキテクチャによって、関心の分離やテストの促進が実現でき、一般的にコードも見やすくなって保守性も上がります。フィード機能では、
Android Architecture Blueprints から着想を得たさらに軽量な MVP 実装を試してみることにしました。これは、必要となるモジュール性を提供しつつ、とても簡単に概念化できるものです。ここでは、教育的な面と実用的な面の両方を目標とし、デベロッパーに別の MVP パターンを示すとともに、この機能のニーズを満たすアーキテクチャも提示したいと考えました。
また、IOSched で初めて
Firebase Remote Config が多用されました。かつては、WiFi 情報、シャトル便のスケジュール、ライドシェアリングの割引コードなど、セッション以外のデータがカンファレンスの前や最中に変更されたことをユーザーにお知らせするのは難しいことでした。単にアプリ内のデフォルト値をアップデートできるようにしたいだけなので、アプリのアップデートを強制するのは現実的ではありません。この問題は、Remote Config を使って簡単に解決できました。
最終的には、3 層のシステムでユーザーに変更を通知する形になりました。
カンファレンス データやユーザーデータの変更は、Cloud Messaging とデータ同期経由で伝達されます（ping-and-fetch モデル）。
フィードデータの変更は、RTDB で管理します。
アプリ内定数の変更は、Remote Config で管理します。
今後の計画
2017 年版のコードがリリースされましたが、今後実施する作業も残っています。まず、バックグラウンド処理の最新パターンに従うようにコードを更新する予定です（そして、アプリを「O」対応にします）。さらに、Android の
Architecture Components を採用して、アプリ全体の設計をシンプルなものにする予定です。デベロッパーの皆さんは、コードの変化を
GitHub でフォローできます。
Reviewed by
Takeshi Hagikura - Developer Relations Team
この記事は Shailen Tuli による Android Developers Blog の記事 "Google releases source for Google I/O 2017 for Android " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google I/O 2017 Android 公式アプリのソースコード を公開しました。Firebase を使うように拡張されています。本投稿では、主なアプリの変更点や設計上の検討事項について紹介します。 予約 システムです。これは、参加者個人の時間を節約し、効率的にカンファレンスに参加できるようにするものです。登録済みの参加者は、カンファレンスの前および開催中にセッションを予約したり順番待ちリストに登録することができ、予約しておけば長い列に並ばず、スムーズにセッションに入場できました。予約データは参加者のカンファレンス バッジと同期されるので、イベント スタッフは NFC 対応スマートフォンで予約を確認できます。予約機能はとても好評だったうえに、予約データに応じて I/O の前や最中にセッション会場の大きさを変更して実際の需要に合わせて座席数を調整するなど、イベント スタッフにも役立ちました。 Firebase Realtime Database （RTDB）と Cloud Functions for Firebase で実装されています。RTDB を使うと、コードにリスナーを実装してデータベースの更新を受信するだけで、簡単にユーザーの端末間で同期をとることができます。また、RTDB ではすぐに利用できるオフライン サポートも提供されています。そのため、たとえ移動中でネットワーク接続が断続的であっても、カンファレンスのデータを利用できます。Cloud Function は、ユーザーの予約リクエストをバックグラウンドで処理します。この際、トランザクションを使っているので正しい状態が保証されます（いたずら好きなユーザーがたくさんの座席を確保できないようになっています！）。また、イベントバッジ システムとも連動しています。 Cloud Endpoints の利用を継続することにしました（データ自身は Datastore に格納されます）。RTDB は元々データを同期できるようになっていますが、ユーザーの予約データが確実にすべての端末に存在するようにしたいと考えました。 アプリがフォアグラウンドにない場合にもです。 RTDB の予約データを同期フローに組み込む部分では、Cloud Function を利用しました。RTDB 内のユーザーの予約データが変更されると、Cloud Function によってエンドポイントが更新され、Firebase Cloud Messaging のダウンストリーム メッセージがトリガーされてすべてのユーザーの端末に送られます。その後、スケジュールによるデータの同期が行われます。 フィード 機能もありました（アプリのユーザーのほとんどは現地にいなかったため、フィードがカンファレンスの状況を伝える窓になりました）。このフィード機能も RTDB を利用しており、単純な CMS を使ってサーバーにデータをプッシュしています。RTDB のフィードデータを Cloud Function で監視し、サーバー上でフィードデータが更新されると、Function が Cloud Messaging のダウンストリーム メッセージをクライアントに送信します。クライアントでは、新しいフィードアイテムが視覚的にユーザーに提示されます。 Android Architecture Blueprints から着想を得たさらに軽量な MVP 実装を試してみることにしました。これは、必要となるモジュール性を提供しつつ、とても簡単に概念化できるものです。ここでは、教育的な面と実用的な面の両方を目標とし、デベロッパーに別の MVP パターンを示すとともに、この機能のニーズを満たすアーキテクチャも提示したいと考えました。 Firebase Remote Config が多用されました。かつては、WiFi 情報、シャトル便のスケジュール、ライドシェアリングの割引コードなど、セッション以外のデータがカンファレンスの前や最中に変更されたことをユーザーにお知らせするのは難しいことでした。単にアプリ内のデフォルト値をアップデートできるようにしたいだけなので、アプリのアップデートを強制するのは現実的ではありません。この問題は、Remote Config を使って簡単に解決できました。
カンファレンス データやユーザーデータの変更は、Cloud Messaging とデータ同期経由で伝達されます（ping-and-fetch モデル）。
フィードデータの変更は、RTDB で管理します。
アプリ内定数の変更は、Remote Config で管理します。
今後の計画
2017 年版のコードがリリースされましたが、今後実施する作業も残っています。まず、バックグラウンド処理の最新パターンに従うようにコードを更新する予定です（そして、アプリを「O」対応にします）。さらに、Android の Architecture Components を採用して、アプリ全体の設計をシンプルなものにする予定です。デベロッパーの皆さんは、コードの変化を GitHub でフォローできます。 Takeshi Hagikura - Developer Relations Team
DevFest は、
Google Developer Group （GDG）コミュニティによって世界各地で開かれるデベロッパー向けイベントです。参加者は
Android 、
Firebase 、
Google Cloud Platform 、
TensorFlow による機械学習、
Web などの Google のデベロッパー テクノロジーに関する技術情報、知識やアイデアを共有できます。
それぞれの DevFest は、主催するコミュニティとその地域のニーズに沿ったユニークな内容となり、日本では下記のイベント企画がされています。情報は追加、更新されていきますので、ブログ記事やツイッターをご確認ください。
■
DevFest Tokyo 2017
日時：2017 年 10 月 9 日（祝）、10:00 - 17:00（仮）
場所：国際交流館 プラザ平成（東京都江東区青海2-2-1）
参加費：無料
定員：1,000 名
対 象 者：Android, Web, GCP (ML), Firebase 技術者および学生
主 催：GDG Tokyo, Shibuya.apk, DroidKaigi, 日本Androidの会, golang.tokyo, html5j, GTUG Girls, Women Who Go, XR 女子部, Droid Girls, Geek Women Japan, GCPUG, TFUG, TangoWG
■ DevFest Kyoto 2017
日時：2017 年 11 月 4 日
場所：京都市内
参加費：無料
定員：40 名
主催：GDG 京都、KyotoGAS
■
GDG温泉︎ in 湯布院 Devfest
日時：2017 年 11 月 3 日（祝）〜 11 月 5 日（日）
Posted by
Takuo Suzuki - Developer Relations Team
Google Developer Group （GDG）コミュニティによって世界各地で開かれるデベロッパー向けイベントです。参加者は Android 、Firebase 、Google Cloud Platform 、TensorFlow による機械学習、Web などの Google のデベロッパー テクノロジーに関する技術情報、知識やアイデアを共有できます。
DevFest Tokyo 2017
GDG温泉︎ in 湯布院 Devfest
日時：2017 年 11 月 3 日（祝）〜 11 月 5 日（日）
Takuo Suzuki - Developer Relations Team
