Posted by Khanh LeViet - Developer Relations Team


Posted by Eiji Kitamura - Developer Relations Team

先日開催された Google I/O 2017 に合わせて Canary リリース チャンネルでダウンロード可能になっている Android Studio 3.0 について、ご紹介します。Android 開発に特化した Android Studio は Google の公式 IDE で、積極的に開発が続けられています。Android Studio の一連の機能は、アプリ開発フローの高速化と Android プラットフォーム用の最新ツールの提供を主な目的としたものです。

Android Studio 3.0 には、開発フローの高速化を実現するための 3 つの主な機能が追加されています。パフォーマンスの問題をすばやく診断する新たなアプリのパフォーマンス プロファイリング ツール一式、Kotlin プログラミング言語のサポート、サイズの大きいアプリのプロジェクトでの Gradle ビルドの高速化です。さらに、Instant App 開発のサポート、Android O エミュレータ システム イメージへの Google Play ストアの追加、Android O の開発に利用できる新しいウィザードといった機能によって、Android Studio 3.0 は Android プラットフォーム開発と密接に統合されています。すべてを合わせれば、今回の最初の Canary リリース版 Android Studio 3.0 には、20 以上の新機能が追加されています。

これらの機能の多くは、Android Studio 2.4 の Canary リリースの一部として、密かに作業が進められていたものです。今回は、多くの重要な機能を追加し、Android Gradle プラグインにも拡張性とビルド時間を改善する画期的な変更を行っていますので、バージョン番号を改めて Android Studio 3.0 としてリリースいたします。Android O をターゲットにしたい方、Instant App を作成したい方、Kotlin 言語で開発を始めたい方、または最新の Android アプリ用のパフォーマンス ツールを使用してアプリの品質を改善したい方は、今すぐ Android Studio 3.0 Canary 1 をダウンロードしてください。
Android DevByte - Android Studio 3.0 Canary 1 の新機能


今回の最初の Canary リリース版 Android Studio 3.0 の新機能の詳細については、重要なデベロッパー フローごとに分類された以下のリストをご覧ください。

開発


  • Kotlin プログラミング言語 - 多くのリクエストをいただいた結果、Android Studio 3.0 に Kotlin のサポートが追加されました。この新しい言語のサポートによって、既存の Android アプリのコードに Kotlin コードをシームレスに追加できるようになります。さらに、Android Studio のすばらしい開発ツールのすべてにアクセスすることもできます。Kotlin をプロジェクトに追加するには、[Code] → [Convert Java File to Kotlin File] からビルトインの変換ツールを使うか、新規プロジェクト ウィザードから Kotlin を有効にしてプロジェクトを作成します。詳細については、AndroidAndroid Studio での Kotlin 言語のサポートをご覧ください。

Android Studio での Kotlin 言語への変換


  • Java 8 言語機能 - Java 8 言語機能と API のサポートの強化は続いています。先日の Jack ツールチェーンのサポートの終了と javac ベースのツールチェーンへの移行によって、Java 8 言語機能を使うプロジェクトで Android Studio から Instant Run などの機能にアクセスできるようになりました。プロジェクトをアップデートして新しい Java 8 言語ツールチェーンをサポートするのは簡単です。[Project Structure] ダイアログで ソースターゲット の互換性レベルを 1.8 にアップデートします。詳細をご覧ください
[Project Structure] ダイアログで Java 8 言語にアップデート




  • Layout Editor - 今回の Android Studio リリースでは、Layout Editor もさらに強化されています。コンポーネント ツリーがアップデートされてドラッグ アンド ドロップによるビューの挿入の操作性が向上しているほか、エラーパネルも新しくなっています。また、ConstraintLayout のアップデートと合わせて、ビューバリアの作成、Google グループの作成、チェーン作成の拡張もサポートされています。詳細をご覧ください
Layout Editor のコンポーネント ツリーと警告パネル



  • アダプティブ アイコン ウィザード - Android O では、アダプティブ ランチャー アイコンが導入されています。この機能を利用すると、Android 端末ごとに異なる図形を表示できます。新しく追加されたアダプティブ アイコン ウィザードを使うと、新規または以前のランチャー アイコン アセットを作成し、さまざまなランチャー画面のアイコンマスクでアダプティブ アイコンがどのように表示されるかをプレビューで確認できます。プロジェクトの /res フォルダを右クリックし、[New] → [Image Asset] → [Launcher Icons (Adaptive and Legacy)] を選択すると、新しいアセットを作成できます。詳細をご覧ください
アダプティブ アイコン ウィザード



  • XML フォントとダウンロード可能フォント - Android Studio の XML フォント プレビューおよびフォント選択ツールによって、アプリへのカスタム フォントの追加(Android O がターゲットの場合に利用可能)がさらに簡単になりました。また、アプリにダウンロード可能フォント リソースを作成できるようになっています。ダウンロード可能フォントを使うと、フォント リソースを APK にバンドルせずにアプリでカスタム フォントを使うことができます。ダウンロード可能フォントを使うには、端末やエミュレータで Google Play Services v11.2.63 以降が実行されている必要があります。詳細をご覧ください
ダウンロード可能フォント リソース ピッカー

XML フォント プレビュー




  • Android Things のサポート - Android Studio 3.0 では、新規プロジェクト ウィザードと新規モジュール ウィザードに追加された新しいテンプレート集を使って Android Things の開発を始めることができます。Android Things を使うと、Android 開発の知識を Internet of Things(IoT)に分類される端末にも広げることができます。詳細をご覧ください

Android Things の新規モジュール ウィザード 




  • IntelliJ プラットフォーム アップデート - Android Studio 3.0 Canary 1 には、IntelliJ 2017.1 リリースが含まれています。これには、Java 8 言語のリファクタリング、パラメータ ヒント、セマンティック ハイライト表示、ブレークポイントのドラッグ、強化されたコントロール検索などの機能が追加されています。詳細をご覧ください

ビルド

  • Instant App のサポート - Android Studio 3.0 では、プロジェクトで Instant Apps を作成できます。Instant Apps は、ユーザーがインストールなしに即座に実行できる軽量 Android アプリです。これをサポートするため、Android Studio に Instant App と Feature という 2 つのタイプの新しいモジュールが導入されています。Android Studio は、新しく追加された「Modularize」(モジュール化)というリファクタリング操作と App Links Assistant を組み合わせて、アプリを Instant App に簡単に拡張できるようします。この機能を使うには、新規モジュール ウィザードを実行するか、クラスを右クリックして [Refactor] → [Modularize] を選択します。詳細をご覧ください

Instant App モジュール ウィザード



  • ビルドの高速化 - ビルドを高速化するための改善は続いています。今回のリリースでは、多くのモジュールがあるプロジェクトの高速化に重点が置かれています。高速化と今後の拡張をサポートするために、Android Studio が使用する Android Gradle プラグインの API を根本から見直し ています。以前のプラグインの API を利用している場合は、新しいプラグインとの互換性を確認し、適切な API に移行する必要があります。テストするには、 build.gradle ファイルでプラグインのバージョンをアップデートしてください。詳細をご覧ください



build.gradle

dependencies {
   classpath 'com.android.tools.build:gradle:3.0.0-alpha1'
}
  • Google の Maven レポジトリ - こちらも多くのリクエストが寄せられたため、Android SDK Manager の外部のまったく新しい Maven レポジトリで Android サポート ライブラリの Maven 依存関係を配布いたします。継続的インテグレーション(CI)システムで開発を行っている方は、これによって Maven 依存関係の管理が容易になるはずです。最新のコマンドライン SDK Manager ツールGradle を併用する場合は、Google の Maven レポジトリを使うと CI ビルドを簡単に管理できます。新しい Maven ロケーションを使うには、アプリのモジュールの build.gradle ファイルに次の URL を追加します。詳細をご覧ください
build.gradle
repositories {
   maven {
       url "https://maven.google.com"
   }
}



    テストとデバッグ

    • Google Play システム イメージ - Android O ベータ版リリースへのアップデートと合わせて、Android Emulator O システム イメージをアップデートし、Google Play ストアを追加しています。Google Play ストアがバンドルされることによって、Google Play を用いた包括的なアプリのテストが可能になり、Android Virtual Device(AVD)の Google Play サービスを最新に保つ便利な方法が提供されます。AVD でも、物理端末と同様に Google Play サービスのアップデートを行うことができます。
    Android Emulator の Google Play ストア



    Android Emulator での Google Play サービスのアップデート




    アプリのセキュリティを確保し、物理端末と同様の体験を提供できるようにするため、Google Play ストアがバンドルされたエミュレータ システム イメージは、リリースキーで署名されています。これにより、権限の昇格はできなくなります。アプリのトラブルシューティングに権限の昇格(root)が必要な場合は、Google のアプリやサービスが含まれていない Android オープンソース プロジェクト(AOSP)のエミュレータ システム イメージを使うことができます。 この機能を使うには、Android Emulator v26.1 以上と API 24 以上の最新システム イメージを利用し、端末定義の隣に Google Play アイコンが表示されている AVD を新しく作成する必要があります。詳細をご覧ください


    Google Play ストアがサポートされた Android Virtual Device Manager 





    • Android Emulator での OpenGL ES 3.0 のサポート - 開発を高速化するために継続されている投資の一環として、最新版の Android O システム イメージの Android Emulator では OpenGL ES 3.0 がサポートされています。さらに、古いエミュレータ システム イメージでの OpenGL ES 2.0 のグラフィック パフォーマンスが大きく改善されています。ほとんどの最新グラフィック カードは、すべてのオペレーティング システムで OpenGL ES 2.0 アクセラレーションをサポートしています。Android Emulator で OpenGL ES 3.0 を使うには、OpenGL 3.2 以降をサポートするホスト GPU グラフィック カードを搭載した Microsoft® Windows® または Linux の開発マシンが必要です(Apple MacOS® も今後サポートされる予定です)。詳細をご覧ください


    Android Emulator での OpenGL ES 3.0




    • Android Emulator の App Bug Reporter - アプリのバグの記録をサポートするために、再現手順の記録に必要となるすべての設定と領域を含むバグレポートを簡単に生成する方法が追加されています。さらに、特定のエミュレータのバグを Android チームと共有したい場合のために、Android Issue Tracker でバグを簡単に作成できるリンクも追加しています。この機能を使うには、[Emulator Tool Bar] → [Extended Controls] → [Help] → [Emulator Help] → [File a Bug] を選択します。詳細をご覧ください

    Android Emulator のアプリ バグレポート


    • Android でのプロキシのサポート - インターネットにアクセスするために HTTP プロキシを使う必要がある方のために、エミュレータが使用するプロキシ設定を管理するユーザー インターフェースを追加しています。Android Emulator はデフォルトで Android Studio の設定を使いますが、ネットワーク設定を優先させることができます。設定を行うには、[Extended Controls] → [Settings] → [Proxy] を選択します。
    Android Emulator のプロキシ設定


    • Android Emulator の Android Wear ロータリー コントロール - Android Wear 2.0 エミュレータ システム イメージの Android Emulator で、ロータリー コントロールがサポートされました。これによって、スクロールにロータリー入力を使用する Android Wear 端末をターゲットにしたアプリのテストが簡単になります。Android Wear をターゲットにしたエミュレータ AVD を作成すると、[Extended controls] に [Rotary Input] パネルが表示されます。詳細をご覧ください

    Android Emulator のロータリー入力



    • APK デバッグ - Android Studio でプロジェクトをビルドせずに APK をデバッグしたい方のために、Android Studio 3.0 リリースでは任意の APK のデバッグを行えるようになっています。この機能は、別の開発環境で Android C++ コードを開発し、Android Studio で APK のデバッグや分析を行いたい方にはとりわけ便利です。デバッグ可能なバージョンの APK を持っている限り、新しく追加された APK デバッグ機能を使って、APK の分析、プロファイリング、デバッグを行うことができます。さらに、APK のソースにアクセスできる場合は、ソースを APK デバッグフローにリンクして高度なデバッグを行うことができます。Android Studio のようこそ画面で [Profile or debug APK] を選択するか、メニューから [File] → [Profile or debug APK] を選択すると、この機能を利用できます。 詳細をご覧ください

    APK のプロファイリングまたはデバッグ


    APK デバッグ


    • Layout Inspector - Android Studio 3.0 では、Layout Inspector のいくつかの機能が拡張されており、アプリのレイアウトの問題を簡単にデバッグできるようになっています。具体的な拡張機能は、一般的なカテゴリに基づくプロパティのグループ化の改善、ビューツリーとプロパティ パネルの検索機能などです。アプリの実行中に Layout Inspector にアクセスするには、[Tools] → [Android] → [Layout Inspector] を選択します。詳細をご覧ください
    Layout Inspector


    • Device File Explorer - これは、多くのリクエストがあったため、DDMS から Android Studio に移行された機能です。新しい Device File Explorer を使うと、Android 端末やエミュレータのファイルとディレクトリの構造を表示できます。これによって、アプリをテストする際に、Android Studio から簡単にアプリのデータファイルを直接プレビューしたり変更したりできるようになります。

    Device File Explorer



    最適化

    • Android Profiler - Android Studio 3.0 には、アプリのパフォーマンスの問題をデバッグするためのまったく新しいツールセットが含まれています。以前の Android Monitor ツールセットは完全に書き直され、Android Profiler に置き換わっています。アプリをデプロイして端末やエミュレータで実行し、[Android Profiler] タブをクリックすると、一元的かつリアルタイムにアプリの CPU、メモリ、ネットワーク アクティビティを表示するビューにアクセスできます。各パフォーマンス イベントは UI イベント タイムラインにマッピングされます。タイムラインでは、タップイベント、キープレス、アクティビティの変更がハイライト表示されるので、イベントの発生場所や発生理由がわかりやすくなります。 各タイムラインをクリックすると、アプリの各パフォーマンス要素を詳細に分析できます。詳細をご覧ください。 

    Android Profiler と結合されたタイムライン ビュー

    • CPU Profiler - 質の悪いアプリでよく起きるのが、不必要な CPU の処理や急激な負荷の増加です。CPU Profiler を使うと、サンプルまたは計測した CPU をトレースしてアプリの CPU スレッドの使用率を分析できます。ここでは、CPU Profiler に組み込まれたさまざまなデータビューやフィルタを使って CPU のパフォーマンスの問題をトラブルシューティングできます。詳細をご覧ください

    CPU Profiler


    • Memory Profiler - メモリの使用が非効率だと、ぎこちない UI から空きメモリ不足のイベントまで、端末のさまざまな問題につながることがあります。Memory Profiler は、以前の Heap Viewer と Allocation Tracker の機能を高度なインターフェースへと統合したものであり、アプリのメモリ使用量の問題をデバッグすることができます。メモリの割り当てやヒープダンプなどを分析することによって、さまざまなメモリの問題の診断が可能です。詳細をご覧ください

    Memory Profiler



    • Network Profiler - アプリのフォアグラウンドとバックグラウンドのネットワーク使用量を最適化すれば、データ使用量を抑えたパフォーマンスのよいアプリになります。Network Profiler を使うと、アプリのネットワーク アクティビティの監視、ネットワーク リクエストのペイロードの調査、ネットワーク リクエストを生成したソースコードの行の特定が可能です。現在のところ、Network Profiler は HttpURLConnectionOkHttpVolley の各ネットワーク ライブラリで動作します。Network Profiler は、Android O 以前の端末やエミュレータでも利用できる高度な分析機能です。[Run Configuration] ボックスの [Profiling] タブで [Enable Advanced Profiling] を選択すると有効にできます。このチェックボックスは、ネットワーク リクエストとペイロードの分析だけでなく、トップレベルのイベントの収集、メモリ オブジェクトのカウント、メモリのガベージ コレクションも有効にします。Android O ベースの端末やエミュレータには、アプリをデプロイするだけで利用できます。詳細をご覧ください
    Network Profiler




    Android O 以前の端末での Network Profiler の設定


    • APK Analyzer の改善 - Android Studio 3.0 の APK Analyzer がさらに拡張されており、APK のサイズを詳細に分析できるようになっています。この機能のアップデートと合わせて、Instant App の zip ファイルや AAR の分析、クラスやメソッドの dex バイトコードの参照も可能になります。さらに、Proguard 設定ルールの生成や、dex ビューアでの Proguard マッピング ファイルの読み込みも可能です。詳細をご覧ください

    APK Analyzer
    詳細は、リリースノートをご覧ください。

    スタートガイド 

    ダウンロード

    以前のバージョンの Android Studio を使っている方は、安定版とは別に Android Studio 3.0 Canary 1 をインストールできます。今回のアップデートは、公式の Android Studio プレビューのダウンロード ページからダウンロードできます。本ブログで説明したように、Gradle プラグイン API は IDE の新機能をサポートするために大幅に変更されています。そのため、アプリのプロジェクト設定のテストや検証を行うには、現在のプロジェクトの Android Gradle プラグインのバージョンも 3.0.0-alpha1 にアップデートする必要があります。


    気に入った機能や問題点、新機能の提案などのフィードバックは大歓迎です。バグや問題を見つけた方は、ご遠慮なく問題を送信してください。Google+ のページや Twitter で Android Studio 開発チームからの情報を常にチェックしてください。




    Posted by Yuichi Araki - Developer Relations Team


     
    Reviewed by Hak Matsuda - Developer Relations Team

    Posted by Takeshi Hagikura - Developer Relations Team
    Share on Twitter Share on Facebook

    TensorFlow Research Cloud を通じて、研究者は次のようなリソースを利用できます。
    TensorFlow Research Cloud のへの参加申請のリクエストは、こちらからお申し込みできます。このフォームからは、研究者の皆さまの計算ニーズに関する情報も寄せていただけます。もっともクリエイティブで有望な提案を採用すべく、いただいた申込みは順次審査します。

    TensorFlow Research Cloud プログラムの対象は、学術分野に限定されているわけではありません。機械学習の研究には、さまざまな所属、役割、専門性の方々が主要な貢献を行っています。所属する分野を問わず、ぜひ積極的に申請してください。選出された方々には、計算時間で制限されたアクセス権を付与します。複数のプロジェクトで複数回応募しても構いません。


    TensorFlow Research Cloud の主な目的は、オープンな機械学習研究コミュニティ全体を進化です。選出された応募者には以下のような成果が期待されます。
    また、研究開発用にクラウド TPU の利用を検討している企業ユーザーに向けて、クラウド TPU Alpha プログラムも合わせて提供します。このプログラムについて詳しく知りたい方は、こちらからお申し込みください。以下のいずれかに興味がある方は、クラウド TPU Alpha プログラムへの参加をおすすめします。
    できる限り多くの研究者に TensorFlow Research Cloud を提供し、機械学習研究の最前線の探求によって新たな発見が生まれることを期待します。最新情報をいち早くご確認いただくため、ぜひ今すぐお申し込みください。


    Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud
    Share on Twitter Share on Facebook


    NXP i.MX7D System on Module

     
    製品版ハードウェア サンプル  
     
    Android Things は、デベロッパーが市場にリリース可能な端末を開発できるようサポートに特に力を入れています。それには、Android Things SoM(System on Module)上で実行するソフトウェアだけでなく、カスタム ハードウェアの構築も含まれます。この取り組みの一環として、ハードウェアとソフトウェアの連動の実例となる製品サンプル シリーズの第 1 弾となる Edison Candle をリリースしました。コードは GitHub に、ハードウェアの設計ファイルは CircuitHub にありますので、第三者企業もそれらを利用し簡単に製造することができます。  
     
    Edison Candle サンプルのソース概略図

     
    以前の Developer Preview にフィードバックを送ってくださったデベロッパーの皆さま、ありがとうございました。バグレポート機能リクエストによって今後も引き続きフィードバックをお願いします。質問はどんなものでもかまいませんので、stackoverflow にお寄せください。Developer Preview 4 のイメージは、Android Things ダウンロード ページに、変更点はリリースノートからご覧いただけます。最新情報やアイデアを話し合うことができ、4,900 名以上のメンバーが参加している Google+ の Google IoT デベロッパー コミュニティにも参加できます。Google I/O でも、Android Things と IoT に関する多数のセッションを行いました。YouTube にある Google I/O 2017 のプレイリストから動画をご覧ください。  
     
    Posted by Takeshi Hagikura - Developer Relations Team
    Share on Twitter Share on Facebook




    テストできる変動要素の例は次のとおりです。

    2. 真の A/B テストを行うために、一度に 1 つのバリエーションのみをテストしてください。テスト段階では、現在のバージョンとデザインを変更したバージョンの 2 つのバリエーションのアプリ画面が必要です。これらのバリエーションを作成するときに A/B テスト プラットフォームを使うと、テストのデザイン、実行、監視が容易になります。

    3. テストを行います。ここでは、テストの結果を確認します。アプリを設定して、半分のユーザーには元々の設定(「コントロール グループ」)を、残りの半分のユーザーには 2 つ目のバージョン(「テストグループ」)を無作為に表示するようにします。コントロール グループから、結果を比較する際に基準となるデータを収集します。このデータがなければ、新しいデザインや季節的な条件など、その他の変動要因への反応を区別できません。

    4. 決断します。テストを行ったら、データを分析します。まず最初の目標と仮説を再確認し、新しいバリエーションに変更する価値があるかどうかというきわめて重要な最終的な判断を下します。ただし、新しい視点だけに目を奪われてはいけません。重要な変更の場合は、複数の期間にわたって実験を行い、結果が季節的な要因やその他の変動要因によるものではないことを確認するとよいでしょう。

    テストを継続的に繰り返すうちに、便利な補助ツールがあったとしても、テストには多くの時間やリソースが必要になることがわかるはずです。目標に大きく影響しない要素をテストして時間を無駄にしないよう注意してください。アプリの Analytics データを利用して、改善のチャンスや可能性が大きい場所(トラフィックが多い画面、エンゲージメントが高い画面、ユーザーの離脱率が高い画面など)を見つけます。専門チームを設け、その 25% の時間を Analytics データの監視に使い、広告最適化のアイデアを検討したりテストを行うのが理想的です。





    次の投稿までの間、AdMob が TwitterLinkedInGoogle+ でお届けする情報をご覧ください。


    Posted by Rikako Katayama - AdMob Team
    Share on Twitter Share on Facebook


    次に、合成データと実際のデータのトレーニング結果の比較を示します。ベンチマーク結果では、GPU 上に静的に置かれた合成データのトレーニングと、ImageNet のデータを使った入力パイプラインのフル実行では、わずかの差しか見られません。TensorFlow の強みの 1 つは、最新の計算ユニットに大量の入力を限界まで送り込む入力パイプラインの能力です。  
     

     

    NVIDIA® Tesla® K80(単一サーバー、8 個のGPU)


    単体サーバー構成の 8 個の NVIDIA® Tesla® K80 を使用した場合、単一の GPU を使用した場合と比較して TensorFlow は Inception v3 で 7.4 倍の高速化(93% 効率)、ResNet-50 で 7.4 倍の高速化が見られました。このベンチマークでは、Google Compute Engine インスタンスを使用しています。  
     

    NVIDIA® Tesla® K80(最大 64 個の GPU)を使用した
    分散型トレーニング


    分散構成の複数の Amazon EC2 インスタンス上で実行する 64 個の Tesla K80 を使用した場合、合成データを使用して InceptionV3 で 59 倍の高速化(92% 効率)、ResNet-50 で 52 倍の高速化(82% 効率)が見られました。  
     

     

    考察


    DGX-1 やその他のプラットフォームのテストでは、NVIDIA ディープ ラーニング SDK の一部である NCCL(Collective Communications Library)を使用したさまざまな構成を使用しました。テストを開始する前の私たちの仮説は、GPU 間の変数の複製と NCCL を使用したこれらの同期が最適なアプローチだろう、というものでした。結果は必ずしも予想通りではありませんでした。最適な構成は GPU により異なりましたが、それだけではなくプラットフォームやテスト対象のモデルによっても異なります。たとえば DGX-1 では、各 GPU で変数を複製し、NCLL を使用してそれらを更新した場合は VGG16 と AlexNet が最高のパフォーマンスを記録しました。一方、共有変数を CPU 上に配置した場合は、InceptionV3 と ResNet が最高のパフォーマンスを記録しています。このような複雑なふるまいは、包括的なベンチマークの重要さを示しています。各モデルはプラットフォームごとにチューニングする必要があり、「同じ手法をすべてに適用する」アプローチは多くの場合最高のパフォーマンスを得られないと考えられます。  
     
    最高のパフォーマンスを得るには、複数の設定を組み合わせて、プラットフォームごとに最高のパフォーマンスを得られる設定を判断する必要があります。高パフォーマンス モデルの作成の記事に含まれているスクリプトは、最高のパフォーマンスを得る方法を示すためだけではなく、さまざまな設定でプラットフォームのベンチマークを実行するためのツールとしても作成されています。ベンチマーク ページには、テスト対象の各プラットフォームで最高のパフォーマンスを得られた構成のリストが掲載されています。  
    その他のプラットフォームで実行されたさまざまなベンチマークに対して多くの人が指摘するように、1 秒あたりのサンプル数の増加は、必ずしも学習の速やかな収束とは関連しません。また、バッチ サイズの増加に伴い、高精度な学習結果への収束が難しくなる可能性があります。  
     
    今後も私たちのチームは、高精度な学習結果への収束に要する時間に注目したテストを実施したいと考えています。より高い性能を得るための TensorFlow チューニングにこれらのベンチマーク結果を役立てていただければ幸いです。  
     
    NVIDIA には、ベンチマーク テストに際し DGX-1 をご提供いただき、技術的に支援していただいたことを感謝します。私たちは、NVIDIA の次期アーキテクチャである Volta に期待しています。また、同社と緊密に連携して、このアーキテクチャで TensorFlow のパフォーマンスを最適化し、FP16 のサポートを拡張できることを楽しみにしています。  
     
    お読みいただきありがとうございます。GitHub の問題ページStack Overflow[email protected] リスト、@TensorFlow などのフォーラムで皆さんと協力できることを楽しみにしています。  
     
     
    Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud
    Share on Twitter Share on Facebook


    プロセス外 iframe の導入にあたっては、描画、入力イベント、およびナビゲーションなどのシステムに影響する Chrome アーキテクチャ に大規模な変更を加える必要がありましたが、これにより Chrome のセキュリティ モデルは一層強化されます。今回の変更はサイト分離プロジェクトの第一段階に過ぎません。プロセス外 iframe によるさらなるセキュリティ改善に今後もご期待ください。

    Posted by Eiji Kitamura - Developer Relations Team
    Share on Twitter Share on Facebook


    Google では先週、カリフォルニア州マウンテンビューにおいて Google I/O 2017 を開催し、約 7,000 名のデベロッパーの皆様にご参加いただきました。  
     
    日本では今年も、Google Developer Groups(GDG)やその他の IT コミュニティの皆さんによって、Google I/O 報告会が開催される予定です。Google Developers Expert、GDG オーガナイザーその他のデベロッパーの方々が、Google I/O で発表のあったセッションの解説やイベントの様子、そこで得られたさまざまな情報をお伝えします。  
     
    イベントの概要は下記のとおりです。会場ごとにお申し込み方法が異なりますので、参加をご希望の方は、各会場のリンクから詳細をご覧ください。リンクがない箇所は、情報が入り次第更新していきます。


    イベント概要  
    GDG 主催
    その他



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


    Posted by Takuo Suzuki - Developer Relations Team
    Share on Twitter Share on Facebook


    1. JOYCITY: Game of Dice

    JOYCITY は、モバイルファーストの主導デベロッパーで、iOS および Android 両方でゲームおよびエンターテイメントアプリの開発を行っています。JOYCITY がリリースした Game of Dice は、一風変わったテンポの速いゲームで、世界中で多くのファンを集めています。  
    動画リワード広告の活用方法  
    JOYCITY は、アプリ内課金(IAP)を多用するこのゲームで IAP による収入を維持しつつ、課金しないユーザーの収益化を行いたいと考えました。そこで、AdMob の動画リワード広告を実装し、AdMob のメディエーション機能を使って複数のサードパーティによるデマンドソースの広告を追加しました。その結果、動画リワード広告をゲームアプリに組み込むことによって収益を増加させることができました。  
    結果  
    Game of Dice 全体の収益が増加しました。中でも、IAP の収益は 10% 増加し、デイリーアクティブ ユーザー率も維持できました。  

    JOYCITY の広告収益化マネージャーである Somin Oh 氏は、次のように話しています。  
    「AdMob の動画リワード広告を実装することによって、非課金層のユーザーを収益化できただけでなく、IAP の収益を含めたゲーム全体の収益を増加させることができました。さらに、AdMob のメディエーションを使うと、広告ネットワーク間のパフォーマンスを簡単に比較できます」

    2. Cheetah Mobile: BADLAND 2

    BADLAND 2 は、世界屈指のデベロッパーである Cheetah Mobile の作品です。このアプリは、イギリス、オーストラリア、インドの Google Play「Best of 2016」で「Most Beautiful」(最優秀美術賞) を受賞しました。  
     
    動画リワード広告の活用方法  
    Cheetah Mobile は、ゲームのユーザー エクスペリエンスを損なわずに BADLAND 2 を収益化したいと考えました。そこで、ゲームの自然な切れ目に AdMob の動画リワード広告を実装し、プレイヤーが動画を見ることと引き替えに貴重な報酬を提供しました。これによって、Cheetah Mobile は優れたユーザー エクスペリエンスを維持しつつ、効率的にアプリを収益化できました。  
    結果  
    AdMob の動画リワード広告やその他のローカル ネットワークの動画リワード広告を使ったところ、1 週間以内に eCPM が 40% 増加し、アメリカでのフィルレートは 93% 以上になりました。また、動画リワード広告によって、月間のユーザー継続率も上昇しました。  

    Cheetah Mobile の SVP である Chen Yong 氏は、次のように話しています。  
    「私たちの主要マーケット プレイスでのフィルレートと eCPM という面で、AdMob の動画リワードはあらゆるネットワークの中でも優れたパフォーマンスを見せてくれました。ゲームアプリの適切なシナリオの中で動画リワード広告を実装したことによって、ユーザー エンゲージメントも向上しました」

    次の投稿までの間、AdMob が TwitterLinkedInGoogle+ でお届けする情報をご覧ください。  
     
    Posted by Rikako Katayama - AdMob Team
    Share on Twitter Share on Facebook