Google Developers Japan: 11月 2018

新たな Android 体験の幕開け

Android 1.6 の頃から、Android と私たちのパートナーは、さまざまな画面サイズや画面密度を考慮し、Android TV、Android Auto、Wear OS、Chromebooks の Android アプリに至るまで、プラットフォームで多彩なフォームファクタや新たな体験を利用できるようにしてきました。スマートフォンの画面は、Android パートナーが牽引てきた分野です。画面が小さいという声が上がったときには、「ファブレット」を導入しました。そして現在に至り、ファブレットは標準サイズのユーザーに好まれる普通のスマートフォンになっています。
今、Android 端末メーカーは、新しいカテゴリの製品、Foldables（折りたたみ式スマートフォン）を作っています。フレキシブルディスプレイという新技術を活用すれば、文字どおり、折り曲げ可能なスクリーンを実現できます。

大まかに、これには 2 画面端末と 1 画面端末という 2 つの種類があります。Foldables は、折りたためばポケットやハンドバッグに収まるスマートフォンのようになります。しかし広げれば、私たちが「画面の継続性」と呼んでいる決定的な特徴を持つことになります。たとえば、折りたたんだ小さな画面で動画を視聴し始めても、途中でどこかに座って端末を広げれば、タブレットサイズの大きな画面で美しく迫力のある動画を楽しむことができます。画面を広げても、アプリは一瞬たりとも止まることなく、シームレスに大きな画面に移行します。私たちは、この新しいフォームファクタに対応できるように、Android を最適化しています。さらに、世界中のデベロッパーがこのすばらしい体験を活用し、新たな方法でユーザーを引きつけて喜ばせることができるような変更も加えています。詳細については、今週の Dev Summit の Foldables に関するセッションにご注目ください。Foldables は、本日プレビュー版を紹介した Samsung をはじめとして、いくつかの Android メーカーから来年に販売される予定です。

Kotlin: 最速で拡大中の言語がアップデート

2017 年、私たちは Android のファーストクラス言語として Kotlin を作成しました。今月時点で、指標を共有することに同意したユーザーだけでも 11 万 8,000 件以上の新規プロジェクトで、Android Studio と Kotlin が使われています。昨年に比べると、実に 10 倍の増加です。GitHub で増加した貢献者数を基準にすれば、最速で拡大中の言語でもあり、Stack Overflow の投票では、2 番目に好まれている言語に選ばれました。アンケートでは、Kotlin を使うデベロッパーが増えるほど、満足度も向上するという結果が出ています。
先週、JetBrains は Kotlin の最新バージョンとなる 1.3 をリリースしました。このバージョンでは、以下のような言語機能や API の追加、バグの修正、パフォーマンスの改善が行われています。

インラインクラスを使うと、ボックス化しなければ割り当てることができない型を作成できます。Android アプリを動作させるリソースが限られた端末では、型の安全性を保ちつつ割り当てを避けることが大きなメリットになります。
UInt、UByte、ULong などの符号なし数値が Kotlin 標準ライブラリの一部として含まれるようになります。これらの新しい型は、インラインクラスを使って構築されています。
Android や JVM 向けに書かれた既存のマルチプラットフォーム コードが、Javascript やネイティブをターゲットにできるようになります。この機能により、コードベースの一部をさらに多くのプラットフォームで再利用できるようになります。
コルーチンのサポートが安定版になります。言語とライブラリによるサポートを組み合わせることで、非同期オペレーションや並列処理を簡単に取り扱うことができるようになります。これらは、Android アプリには欠かせない操作です。

以上の Kotlin 1.3 の新機能は、すべて私たちが提供する Kotlin 固有の API に統合されます。その大半は、KTX 拡張機能で Jetpack の一部として提供されます。

Android Jetpack: Navigation、Work Manager、Slices

Google I/O で、Android アプリ開発を加速させる次世代のツールおよび Android API である Jetpack を発表しました。Jetpack は、Support Library と Architecture によって築かれた土台の上に構築されています。トップ 1,000 のアプリおよびゲームのうち、80% が既に何らかの新しい Jetpack ライブラリを本番環境で利用しています。
AndroidX は、元々 Android Support Library と呼ばれていたものが進化して Jetpack の一部となったものです。今年の夏、これをパブリック AOSP に移行しました。これにより、実装される機能やバグの修正をリアルタイムで確認して、どの AndroidX ライブラリにも貢献できるようになっています。貢献についての詳細は、こちらをご覧ください。
私たちは、2 つの新しい Architecture Component ライブラリである Navigation と Work Manager に、できるだけ多くのフィードバックと微修正を組み込もうと努力しています。2 つとも、今月中にベータ版に移行する予定です。Navigation Architecture Component は、アプリで単一の Activity を利用して、Android のナビゲーション原則を簡単に実装する方法を提供します。さらに、Android Studio の新しい Navigation Editor を使うと、独自のナビゲーションアーキテクチャを作成して編集できます。これにより、ナビゲーションに関するボイラープレートが無くなり、アトミックなナビゲーション操作が利用できるようになるとともに、アニメーションによる遷移などもさらに楽になります。WorkManager は、アプリの状態や端末の API レベルに基づいて最適なソリューションを選択し、バックグラウンドタスクの実行を簡単かつ効率的にします。

Navigation Editor

さらに、Android Slices が検索の試験運用版として公開されます！今年の I/O でお知らせした Slices は、ユーザーがアプリに触れる新たな方法です。Slices はアプリの小さなスニペットのようなもので、コンテンツやアクションを表示して、飛行機を予約したり、動画を再生したり、車を呼んだりすることができます。Slices はすぐにでも公開したい機能の 1 つですが、時間をかけて動作を調整したいと考えています。Doist や Kayak などと協力しつつ、今月中にパブリック EAP に移行します。また、Google 検索結果に Slices を表示する実験も行う予定です。詳細は、ベストプラクティスと合わせて、本日の Dev Summit のセッションでお話しします。

Android Studio: 生産性、ビルド速度、品質、基本機能にフォーカス

Android Studio は、Android 開発の公式 IDE です。同意済みの Android Studio ユーザーから集めたデータから、ビルド時間はリリースを重ねるたびに速くなり、20% ほど速くなることもあります。その一方で、時間が経つにつれてビルド時間が遅くなることもあります。なぜこのような矛盾した結果になるのでしょうか。この状況を理解するために、綿密な分析を行いました。
ビルドは非常に複雑なシステムです。デベロッパーの選択によって、状況は大きく変わります。デベロッパーが使用する OS、カスタムプラグイン、アノテーションプロセッサ、言語の組み合わせは膨大であり、しかも広がり続けています。これらすべてが、時間に大きく影響します。ユーザーが追加したプラグインが、密かに 45% もビルド速度を低下させていた事例もありました。この事実から、何がビルド速度を低下させているかを簡単に理解できるように、ビルドのプロファイリングや分析を行うツールが必要であると認識しました。また、コアとなるビルド機能のパフォーマンスを向上させ続けるために、パフォーマンスの向上を図る独自プラグインにも注力しています。
本日、Android Studio 3.3 ベータ版 3 をリリースします。今後のリリースは、クラッシュやハング回数の削減、メモリ使用量の最適化、ユーザーに影響するバグの修正など、品質と基本機能に強くフォーカスしたものになる予定です。また本日、来年初頭には Android Studio が Chrome OS の公式サポート IDE となる予定をお知らせしました。詳しくはこちらをご覧ください。

Android アプリバンドルとダイナミックフィーチャー

アプリのサイズは、2012 年に比べて 5 倍と、大きく増加しています。しかし大きなアプリには、インストールコンバージョン率の低下、アップデート率の低下、アンインストール率の増加といった欠点もあります。そこで、特定の端末でアプリを実行するために必要なコードやリソースのみを提供する新たな公開フォーマット、Android アプリバンドルを開発しました。これにより、アプリのサイズはユニバーサル APK に比べて平均で 35% 小さくなりました。アプリバンドルを使うと、マルチ APK のような不完全なソリューションを使う必要がなくなるので、リリースのたびに必要になる時間や労力も削減できます。Android Studio 3.2 では、アプリバンドルが IDE で完全サポートされます。アプリバンドルは、既に本番環境で頻繁に使われており、YouTube、Google Maps、Google フォト、Google ニュースなどの Google 製アプリを含め、数十億回インストールされています。
アプリバンドルは、非圧縮ネイティブライブラリをサポートするようになりました。M 以降の端末でアプリバンドルを使えば、デベロッパーが何もしなくても、ネイティブライブラリを使っているアプリのダウンロードサイズが平均 8%、ディスク上のサイズが 16% 小さくなります。
アプリバンドルに切り替えるのと合わせて、アプリのモジュール化に着手することもできます。ダイナミックフィーチャーモジュールを使うと、任意のアプリの機能をインストール時ではなくオンデマンドで読み込むことができます。一度しか使わない大きな機能をすべての端末で永久に保持する必要はありません。動的機能は、アプリのリクエストに応じて動的にインストールやアンインストールを行うことができます。

In-app Updates API

ユーザーに最新の最も優れたバージョンのアプリを実行し続けてもらうために、制御を強化したいという声が寄せられています。これに対処するために、In-app Updates API をリリースします。現在、早期アクセスパートナーとともに API のテストを行っており、近日中にすべてのデベロッパーに対してリリースを行う予定です。
この API には、2 つの使用方法があります。1 つ目は、全画面表示で重要なアップデートを行う方法で、即座にアップデートを適用してユーザーにはアップデートが終わるまで待ってもらいます。2 つ目の方法は柔軟なアップデートです。この場合、ユーザーはアップデートをダウンロードしている間、アプリを使い続けることができます。アップデートフローは完全にカスタマイズできるので、アプリの一部のような感覚になります。

すぐに試せるアプリ

Instant App の利用がさらに簡単になります。先日、ウェブ URL の利用をオプションにし、Instant App が使える場合には、既存の Play ストアのディープリンクトラフィックからユーザーを Instant App に案内できるようにしました。さらに、Instant App のサイズ制限を 10 MB に増加させ、Play ストアの「今すぐ試す」ボタンやウェブのバナーから簡単に利用できるようにしました。
Android Studio 3.3 ベータ版では、インスタント対応アプリバンドルをビルドできるようになります。つまり、1 つの Android Studio プロジェクトで Instant App とインストール可能アプリの両方をビルドしてデプロイし、それを 1 つの Android アプリバンドルに含めることができるようになります。1 つのアーティファクトをアップロードするだけで、Instant App とインストール可能アプリの両方に対応できます。

こういった注力分野を決定するためには、デベロッパーの皆さんのフィードバックが欠かせません。初期のアイデアの段階から、EAP、Canary 版、ベータ版、そしてリリース後の反復に至るまで、私たちの取り組みには常に皆さんのご協力が必要です。ライブストリームで 30 以上のセッションをご覧になる皆さんも、ソーシャルメディアで参加する皆さんも、直接マウンテンビューにお越しくださる皆さんも、ぜひこれからの 2 日間、このイベントにご参加ください。チーム一同、皆さんの思慮深いフィードバックや貢献に心より感謝申し上げます。Android Dev Summit をお楽しみいただけることを願っています。

Reviewed by Hak Matsuda - Developer Relations Team

この記事は製品管理担当ディレクター、Stephanie Cuthbertson による Android Developers Blog の記事 "Unfolding right now at #AndroidDevSummit!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。Android Dev Summit 新たな Android 体験の幕開けFoldables

Kotlin: 最速で拡大中の言語がアップデートKotlinKotlin の最新バージョンとなる 1.3 をリリース

インラインクラスを使うと、ボックス化しなければ割り当てることができない型を作成できます。Android アプリを動作させるリソースが限られた端末では、型の安全性を保ちつつ割り当てを避けることが大きなメリットになります。

UInt、UByte、ULong などの符号なし数値が Kotlin 標準ライブラリの一部として含まれるようになります。これらの新しい型は、インラインクラスを使って構築されています。

Android や JVM 向けに書かれた既存のマルチプラットフォーム コードが、Javascript やネイティブをターゲットにできるようになります。この機能により、コードベースの一部をさらに多くのプラットフォームで再利用できるようになります。

コルーチンのサポートが安定版になります。言語とライブラリによるサポートを組み合わせることで、非同期オペレーションや並列処理を簡単に取り扱うことができるようになります。これらは、Android アプリには欠かせない操作です。

Android Jetpack: Navigation、Work Manager、SlicesJetpackAndroidXこちらNavigationWork Manager

Navigation Editor Android Studio: 生産性、ビルド速度、品質、基本機能にフォーカスAndroid Studio本日、Android Studio 3.3 ベータ版 3 をリリースします。品質と基本機能こちら Android アプリバンドルとダイナミックフィーチャーAndroid アプリバンドル Android Studio 3.2非圧縮ネイティブライブラリダイナミックフィーチャーモジュール In-app Updates APIIn-app Updates API

すぐに試せるアプリInstant App

ライブストリームで 30 以上のセッションをご覧になる皆さんHak Matsuda - Developer Relations Team

Google Play Console の [Android Vitals] セクションを活用してアプリの品質の問題を修正し、成功を収めているデベロッパーがますます増えています。Google では、Android Vitals に関する最初の記事以降も改善を続け、新しい指標や機能を提供してきました。本稿ではまず新機能の概要を紹介し、続いて、停止した wake lock とクラッシュの問題を修正する方法を説明します。

Android Vitals の新機能

Google I/O 2018 で Android Vital の新機能を発表しました。今回の改善には、2 つのパフォーマンス領域の追加、既存の指標の情報に対する機能強化、Android Vitals で予期しない変化が生じた場合の通知方法が含まれています。

カテゴリのベンチマーク

アプリの指標の測定結果が「良好な」（低い）レベルとみなされるか、「不適切な」（高い）レベルとみなされるかは、Play ストアでそのアプリがどのカテゴリに含まれるかによって大きく左右されます。たとえば、「ボード」カテゴリのゲームアプリにおけるスタートアップの遅延の平均は、「レース」カテゴリのゲームアプリよりも低くなります。そのため、Android Vitals ではカテゴリのベンチマークが表示されるようになりました。これによりデベロッパーは、自分のアプリのパフォーマンスを同じカテゴリ内の他のアプリと比較できます。

異常の検出

アプリの動作の急激な変化は好ましいことではありません。そのような状況に迅速に対応できるよう、Android Vitals では、指標の急激な変化を検出すると Play Console のメッセージとメールを通じてデベロッパーに通知します。通知を受けたデベロッパーは Android Vitals にアクセスして状況を確認し、原因に対処できます。

権限の拒否

アプリによる権限リクエストを拒否したユーザーの割合が表示されます。拒否される割合が高い場合は、アプリのデザインを見直し、許可を求める理由の伝え方を改善するなどして、権限を許可してもらえるようになるかを確認することができます。

アプリのスタートアップ時間

優れた機能や素晴らしいゲームプレイ体験を提供していても、アプリの起動に時間がかかりすぎると、ユーザーはアプリを使わなくなります。新しく追加されたこのパフォーマンス領域には、アプリのスタートアップ時間に問題があるかどうかをデベロッパーが把握できるよう、対象のアプリやゲームについて、コールドスタートアップ（アプリが最近使用されておらず、メモリ内にキャッシュされていない場合）、ウォームスタートアップ（アプリはメモリ内にあるが、アクティビティの再作成が必要な場合）、ホットスタートアップ（アプリとアクティビティがメモリ内にあり、ユーザーがそのアプリに切り替えた場合）の 3 種類のスタートアップ時間が表示されます。

Android Vitals でスタートアップに関する問題が見つかったら、Android Studio 3.2 の Android プロファイラツール（アプリスタート時の CPU プロファイリング、Systrace など）を利用して、スタートアップの遅延に関する問題を調べます。

主な指標

高品質のアプリを提供するためにはすべての指標が重要ですが、特に優先すべき指標として、過度の wakeup、ANR、停止したバックグラウンドでの wake lock、クラッシュの 4 つを挙げることができます。過度の wakeup と ANR については、第 1 回の記事で取り上げました。そこで、今回は wake lock とクラッシュについて見ていきます。

Wake locks

従来、Android でのバックグラウンド作業の実行は、必要に応じたバックグラウンドサービスの作成に依存していました。こうしたバックグラウンドサービスは必要な期間実行され続けたため、フリーランニングサービスと呼ばれることもありました。こうしたバックグラウンドサービスの実行中は、端末の CPU と通信がオフにならないようにするために wake lock が使用されていました。

このような形での wake lock の使用は最適ではありません。アプリによって頻繁にサービスのスケジュールが設定され、結果的にサービスが長時間実行されてメモリなどのリソースが占有されることがあります。このようにしてリソースを使用すると、CPU と通信の使用が増えるほか、端末がスリープ状態にならなくなることから、端末のパフォーマンス低下と電池の消耗を引き起こすことがよくあります。

Android Vitals では、アプリの PowerManager クラスを通じて取得した部分的な wake lock の詳細を、[停止した wake lock] ページと [停止した wake lock（バックグラウンド）] ページで提供しています。部分的な wake lock では CPU は動作しますが、画面やキーボードのバックライトをオフにすることができます。

レポートには、停止した wake lock の影響を受けたバッテリーセッション（端末の完全充電から次の完全充電までの期間）の割合が表示されます。この情報には、過去 30 日間とその前の 30 日間に影響を受けたセッションの割合、アプリの指標を Google Play のインストール数上位 1,000 のアプリと比較したベンチマーク、影響を受けたセッションの推移を示したグラフのほか、アプリのバージョン、Android OS のバージョン、端末などの条件に基づく内訳（スクリーンショットには表示されていません）が含まれています。

このベンチマークにおいて、自分のアプリが、停止した wake lock の影響を受けたセッションの指標で下位 25% に該当する場合は、アプリの改善を検討してください。

第 1 回の記事でもお伝えしたように、Android 5.0 での JobScheduler の導入以降、アラームとフリーランニングサービスの使用を取りやめることをおすすめしています。Android Oreo 以降、アプリはバックグラウンドでサービスを開始できなくなったため（例外が発生します）、アラームとフリーランニングサービスの使用の取りやめは必須となります。同様に、アプリでの wake lock の使用についても、ほとんどの使用例で適切な代替手段があるため、取りやめることを検討してください。wake lock を使用する代わりに、アプリで以下の方法を採用することをおすすめします。

バックグラウンドでのジョブの実行が必要な場合は、JobScheduler か WorkManager API を使用する。こうした機能を使用すると、ジョブが実行されている間だけ、そのジョブの wake lock が保持されます。

決められた時間に、または定期的にバックグラウンドタスクを実行する必要があるときは、AlarmManager ブロードキャストをスケジュールする。AlarmManager は、BroadcastReceiver.onReceive() メソッドが実行されている間だけ、wake lock を保持します。

ユーザーがアプリのアクティビティを見ている間も画面をオンにしておきたいウィンドウがある場合は、該当するウィンドウに FLAG_KEEP_SCREEN_ON を追加する。たとえば、電子書籍を読んでいるときなどが該当します。これにより、アクティビティが表示されなくなったときに、システムによって wake lock が解放されます。

自分で wake lock を管理する必要がある場合（実行時間の長いフォアグラウンドサービスを使用して音声トラックを再生する場合など）は、必ず以下のルールに準拠してください。

非推奨の種類の wake lock は使用せず、PARTIAL_WAKE_LOCK を使用してください。

wake lock を取得するときはタイムアウトを指定してください。そうすることで、アプリが wake lock を解放しない場合でも、タイムアウト時間が経過するとシステムによって wake lock が解放されます。

wake lock には、com.myapp: my wake lock のように静的でわかりやすいタグを付けてください。それにより、Android Vitals の wake lock のレポートがわかりやすくなります。カウンタやその他の動的なデータをタグに追加しないでください。適切でわかりやすいタグを付けることで、類似する wake lock が Android Vitals によってまとめられ（組み合わされ）て、個別の wake lock の動作を正確に把握できるようになります。

wake lock は不要になったら解放してください。wake lock は、エラーの発生によっても不要となることがあります。エラー処理にあたっては、安全性を重視してコードを記述し、呼び出しを try { … } finally { wakeLock.release(); } のブロックでラップすることをおすすめします。

クラッシュ

Android Vitals ではクラッシュの概要と詳細の両方を確認できます。[クラッシュ発生率] ページと [マルチクラッシュ率] ページでは、クラッシュデータと使用状況データを組み合わせて正規化された指標が表示されます。

この概要情報に加えて、[ANR とクラッシュ] ページにリアルタイムのクラッシュの詳細が表示されます。

停止したバックグラウンドでの wake lock と同様に、クラッシュ率を比較するための主な指標として「不正な動作のしきい値」があります。アプリのクラッシュ率が不正な動作のしきい値を超えている場合、クラッシュへの対処を優先することをおすすめします。

コードが例外を引き起こしてアプリをクラッシュさせる理由は数多くあります。そのため、本稿でそのすべてを説明して解決策を提示することは困難ですが、クラッシュを防止するのに役立つ一般的なアドバイスをいくつかご紹介します。

Android Vitals を利用して、頻発しているクラッシュに関する情報と、そのクラッシュの影響を受けているユーザー数を確認できます。Android Vitals の大きな利点は、発生したクラッシュを、第三者のクラッシュレポート SDK が初期化されるよりも前に捕捉できることです。

クラッシュの再現、デバッグ、修正のために詳細な情報が必要な場合は、Firebase Crashlytics の利用をご検討ください。このツールを使うと、クラッシュ時にアプリ内で何が起きているかを詳しく把握できます。Firebase Crashlytics では Firebase Analytics との統合によってこの機能を実現しており、デベロッパーはカスタムのログ記録を追加してクラッシュレポートに含めることができます。

クラッシュを引き起こす一般的な原因の多くは、以下の方法で回避できます。

一般的な処理を自力でゼロから記述しない
Kotlin に移行する
公開 API を使用する

一般的なコードパターンを自力でゼロから記述しない

クラッシュを引き起こす可能性がまずない高品質のライブラリが提供されていて、簡単に再利用できる場合、一般的なタスクを自力でコーディングしてミスを犯すリスクを取る必要はありません。

Android Jetpack には、ほとんどの Android アプリの基盤として利用できるライブラリが数多く用意されています。Android Jetpack は、アクティビティのライフサイクルの管理、ナビゲーション、バックグラウンドジョブの実行、データベースの操作、外部ソースからのデータの読み込みなど、数多くの一般的なタスクに利用できます。Google の開発したライブラリ以外にも、デベロッパーがアプリの開発に利用できる、実績ある優れたオープンソースライブラリが数多く公開されています。

Java から Kotlin への移行を検討する

Google は昨年の I/O において、Android での Kotlin のサポートを発表しました。現在も引き続き、Kotlin のサポートの改善に取り組んでいます。クラッシュにつながるおそれのある一般的なコーディングのミスを少しでも防ぐことで、デベロッパーの生産性を高めることが最終目標です。

Kotlin の大きな利点の 1 つは、null 許容性についての情報が言語の型システムに組み込まれていることです。null セーフの呼び出しとコンパイル時の null チェックにより、コードが実行時に NullPointerException を引き起こすことを防止できます。まだお試しでなければ、Kotlin を使ってみることをおすすめします。アプリには Kotlin を徐々に追加していくことができます。Kotlin は Java との高い相互運用性を備えているため、Java のコードを全面的に置き換える必要はありません。

公開されている Android API を使用する

公開されている Android API とは、Android デベロッパーサイトにドキュメントが掲載されているクラスと public メソッドを指します。こうした API は、認定済みのあらゆる Android 搭載端末での利用と動作が保証されています。リフレクションを使ってアクセス可能な private メソッドや hidden メソッドは、クラッシュを引き起こす大きな原因となるおそれがあります。こうしたメソッドには、端末で利用できるかどうかの保証がなく、また、Android のアップデートのたびに変更や中断が生じることが多いという問題があります。そのため、テスト用としてはともかく、Play ストアで公開するアプリへの使用は避けることをおすすめします。

private メソッドや hidden メソッドには上記のような問題があるため、Android P デベロッパープレビューおよび今後の Android のすべてのエディションでは、このようなドキュメント化されていない非公開 API へのアクセスが制限されます。アプリでのこうした API の利用を直ちに停止することで、互換性を維持できます。詳しくは、プレビューサイトで非 SDK インターフェースの制限についての記事をご覧ください。

おわりに

Android Vitals を活用して高品質のアプリを開発し、より多くのユーザーを引き付けて定着させることで、活気のあるビジネスを構築できます。全 2 回にわたる記事で、過度の wakeup、ANR、停止したバックグラウンドでの wake lock、クラッシュという 4 つの主な指標についての重要な情報をお伝えしました。また、最近 Android Vitals に追加された機能もご紹介しました。

この記事で紹介したおすすめの方法や詳細情報を活用することで、デベロッパーの皆様が Android Vitals に表示されるアプリの指標を的確に理解して、アプリの品質向上に役立てられるよう願っています。

詳細については、Google I/O 2018 でジョエルニューマン、ファーガスハーレイ、筆者の 3 名が共同で実施したセッション「Android Vitals: パフォーマンスの問題を解決してアプリの評価を高める」の動画をご覧ください。また、Medium に掲載されている、Google Play の Android アプリおよびゲームに関するおすすめの方法についてもご参照ください。

ご意見をお聞かせください

Android Vitals や新機能についてご意見がございましたら、#AskPlayDev を付けてツイートしていただければ、@GooglePlayDev から返信いたします。このアカウントでは定期的にニュースや Google Play で成功するためのヒントを紹介しています。

Reviewed by Iku Igarashi - Google Play Business Development Manager

この記事はによる How to Fix App Quality Issues with Android Vitals (Part 2)を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。第 2 回: クラッシュや不要な wake lock の問題を修正して Play ストアでのパフォーマンスを改善する

Android Vitals に関する最初の記事