この記事は Android Team による Android Developers Blog の記事 " Helping Users Discover Quality Apps on Large Screens " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
大画面デバイスの普及が進んでおり、現在アクティブな Android タブレット、折りたたみ式デバイス、ChromeOS デバイスの数は、2 億 5,000 万台を超えています。需要が加速し続ける中で、ユーザーはソーシャルやゲーム、マルチタスクや仕事に至るまで、さまざまなことを大画面で行うようになっています。そこで私たちは、大画面デバイスを最大限に活用してもらうため、Google Play を大きく変更して、ユーザーが高品質なアプリやゲームを探して活用できるようにしたいと考えています。
Google Play ストアは、主に 3 つのアップデートをします。その 3 つとは、ランキングとプロモーションの変更、低品質のアプリへのアラート、デバイス固有の評価とレビューです。
先日、大画面で優れたユーザー エクスペリエンスを作成するためのガイドとして、アプリの中核品質ガイドラインに加えて、大画面アプリ品質ガイドライン (英語) を公開しました。このガイドでは、縦向きと横向きのサポートといった基本的な互換性要件から、キーボードやタッチペンの機能といった細かな差別化要件まで、幅広い機能を網羅しています。今後数か月の間に、大画面デバイスにおける Google Play ストアのおすすめやランキングのロジックを更新し、アプリの品質ガイドラインに基づいて、高品質なアプリやゲームを優先するようにします。具体的には、ユーザーが自分のデバイス向けに最適化されたアプリを見つけやすくなるように、検索結果でのアプリの表示順やホームページでのおすすめを変更します。また、Google Play ストア内の記事コンテンツについても、大画面に最適化されたアプリを紹介できるように、力を入れていく予定です。
基本的な互換性要件 (英語) を満たさないアプリに対しては、インストール後のアプリがどのような画面や機能か想定できるように、現在大画面ユーザーに表示されているアラートを更新します。これによってアプリが大画面デバイスではうまく動作しない可能性があることをユーザーに通知できます。この変更に関しては、改めて追加情報をお伝えしようと考えておりますので、今年の最新情報にご注目ください。
最後は以前お知らせした通り、ユーザーがデバイスタイプ（タブレット、折りたたみ式、Chrome OS、Wear、Auto など）ごとの評価とレビューを確認できるようになります。これにより、自分に合ったアプリはどれかを判断しやすくなります。ユーザーが使用するデバイスでのアプリのエクスペリエンスを把握しやすくなるように、可能な場合は、デフォルトでその種類のデバイスにおける評価が Google Play ストアに表示されます。Google Play Console でデバイスタイプごとの内訳を確認すると、デバイスごとの評価とレビューをプレビューできます。
デバイスタイプごとの内訳で評価とレビューを分析し、大画面向けの最適化を計画する
大画面向けの最適化をしているデベロッパーは、ユーザーのエンゲージメントや維持率が向上するというプラスな効果を感じています。ここでは、アプリを大画面向けに最適化するにあたってのヒントやリソースを紹介します。
[リーチとデバイス] のデバイスタイプのフィルタで、1 つまたは複数のデバイスタイプを選択して分析する
デバイスタイプの内訳で、ユーザーと問題の分布を確認し、現在のタイトルの最適化や次のタイトルの計画に役立てる
Google Play ストアの機能は、今後数か月間で徐々にロールアウトされます。変更が行われる前に大画面アプリの品質改善計画を立て、一歩先にスタートすることをおすすめします。今後も、大画面の最適化を最大限にサポートしてユーザー エクスペリエンスを改善できるように、フィードバックを集めて、優れたアプリを開発するデベロッパーの皆さんをサポートし続けたいと考えています。
この記事は Lidia Gaymond、Vicki Amin による Android Developers Blog の記事 " Freeing up 60% of storage for apps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
ユーザーがアプリをアンインストールする主な理由の 1 つが、容量を空けるためです。そこで、不要なアンインストールを防ぎ、ユーザーがデバイスでできることを増やすために、アプリをアーカイブできるようにする新機能の開発を始めています。
アーカイブとは、アプリを完全にアンインストールするのではなく、その一部を削除することで、ユーザーがアプリのストレージの最大 60% を一時的に取り戻せるようにする新機能です。アーカイブしたアプリはデバイスに残り、互換性のある最新バージョンを簡単に復元できます。ユーザーのデータは保持されます。
まもなく迎える Bundletool バージョン 1.10 のリリースは、すべてのデベロッパーが App Bundle を使ってアーカイブを利用できるようにするための第一歩になります。私たちは、Android Gradle プラグイン 7.3 でビルドしたアプリ用に、新しいタイプの APK である「アーカイブ APK」の生成を開始します。アーカイブ APK は、アプリが復元されるまでユーザーのデータを保持しておくための非常に小さな APK です。なお、今回私たちはアーカイブ APK の作成を開始しますが、今年後半にアーカイブ機能が一般向けにリリースされるまでは動作しません。
アーカイブ機能がリリースされると、ユーザーとデベロッパーの双方にとって、大きなメリットをもたらします。ユーザーは、アプリをアンインストールするのではなく、「アーカイブ」できるようになります。すると、一時的に容量を空けつつ、すばやく簡単にアプリを復元できます。デベロッパーには、アンインストール数が減り、お気に入りのアプリを取り戻してもらう際の手間が大幅に減るというメリットがあります。
これまでと同様に、生成されたすべての APK は、生成済み APK API や Google Play Console の App Bundle エクスプローラからダウンロードや調査できます。この機能はオープンソースなので、デベロッパーはコードを調べることができます。また、他のアプリストアもこの機能を利用できます。
アーカイブ APK の生成をオプトアウトしたい場合は、プロジェクトの build.gradle ファイルを次のように変更します。
android { bundle { storeArchive { enable = false } }}
android {
bundle {
storeArchive {
enable = false
}
または Gradle を使わずにアプリをビルドしている場合は、BundleConfig の新オプションを使ってオプトアウトできます。
{ "optimizations": { "storeArchive": { "enabled": false } }}
{
"optimizations": {
"storeArchive": {
"enabled": false
アプリのアーカイブに関する情報は今後も Android Developers Blog でお伝えしますので、ご注目ください。
2022 年 3 月 9 日にマンガアプリ カテゴリに特化した Google Play のカテゴリ イベント、マンガアプリ DAY を開催いたしました。近年マンガアプリを取り巻く環境は変化を続け、マンガアプリ自体も大きな進化を遂げています。 その中で、業界の活性化に貢献できるイベントをご提供できないかと考え、「コンテンツ戦略」をテーマの軸としイベントを実施しました。
この記事では、Google Play 担当者がイベント内で解説した「ゲーム手法から考えるコンテンツ戦略」というセッションの内容を一部ご紹介いたします。
一見マンガアプリとはあまり関係のなさそうなゲームですが、実はコンテンツ流通の最大化を目指す点などマンガアプリでも参考にできるような共通点があります。イベントでは、ゲームアプリで使われるコンテンツ戦略の考え方や手法を Google Play 担当者よりご紹介いたしました。
こういった形で、ゲームアプリは、コンテンツの需要を高めたり、それにまつわる通貨資産の管理を行っています。ゲームアプリとマンガアプリには類似点があることから、マンガアプリにも活用できるようなポイントがあるのではないでしょうか。
“ゲームの成功体験やメカニズムから、隣接であるマンガアプリの発展に結びつけようという企画が良かった”
“他のサービスにも展開しやすい形に噛み砕いていただいたので、各アプリでどう組み込んでいくかが考えやすいものになっていたと思いました”
このように、デベロッパーの皆さまが持続可能なビジネスを構築できるよう支援することは Google Play のミッションです。業界に特化したイベントを開催することで、業界の活性化や、デベロッパーの皆さまのビジネスをサポートすることを引き続き目指してまいります。
この記事は Rachel Cheung による Android Developers - Medium の記事 " Part 1: Learnings from game publishers in APAC " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
ゲームの公開モデルは、ゲーム業界の人々にとって新しい概念ではありません。しかし、絶えず変化する複雑な政府の規制、ローカライズされたコンテンツに対するユーザーの期待の高まり、外部環境の複雑さ（パンデミックによる旅行の自粛など）を踏まえて言うなら、モバイルゲーム パブリッシャーの重要性はますます高まっています。
外国のデベロッパーがパブリッシャーを通さなければ参入できない市場がある場合もあります。そのため、モバイル エコシステムでは、地域の市場でデベロッパーを十全にサポートできるパブリッシャーが不可欠です。私たちは、成功につながるパートナーシップを築くトップトレンドやベスト プラクティスについて深く理解するため、アジア太平洋地域に拠点を置くパブリッシャーと、サードパーティ パブリッシャーと連携しているデベロッパーに対してアンケートとインタビュー調査を実施しました。
なお、定義を明確にしておきます。
この記事では、パブリッシャーから学んだことについて注目します。パート 2 の記事では、デベロッパーの視点によるサードパーティ パブリッシングに関する知見についてお伝えします。
まずは、ゲームのパブリッシャーがどのように作業を進めているかについて、基本的なところから見ていきましょう。
アンケートに応じたアジア太平洋地域の 28 のパブリッシャーにとっての最大の優先事項と課題は、ライセンスと配信ができる高品質なタイトルを見つけることです。
通常、パブリッシャーがゲームを探すときは、既存の人脈やさまざまなゲームイベントを通じて、直接デベロッパーにアプローチします。そのうえで、市場への適性やプレイ内容、指標に基づいてゲームを選択します。パンデミック以降、このプロセスのスピードは低下しています。興味のあるゲームを見つけた場合、ライセンス期間は通常 2 年から 3 年です。多くの場合、収益の分配、最低保証額（パブリッシャーは、実際の収入とは別に、一定の額をデベロッパーに支払う必要がある）、前払いの年間ライセンス料を組み合わせた契約になります。
パートナーシップ面について言えば、技術的な最適化やトラブルシューティングはデベロッパーに任せるパブリッシャーがほとんどです。中には、ゲームデザインについてのガイドラインを提供したり、将来のプロジェクトに向けた合弁企業を設立したりして、デベロッパーと戦略的パートナーシップを結ぶ選択肢を提供するパブリッシャーもあります。
今後の業界を展望すると、パブリッシング ビジネスは、完全なサードパーティ パブリッシング サービスではなく、コミュニティ管理、カスタマー サービス、マーケティングといったモジュール型サービスを提供するようになるかもしれません。
パンデミックの影響で、地域にオフィスを持たないデベロッパーにとっては、リモート パブリッシングが唯一のソリューションになる可能性もあります。ただし、それはますます難しくなるでしょう。ゲーマーの目は肥え、地域の規制も変化し続けているからです。また、デベロッパーがすべての主要な市場でエキスパートとなるのは、すでにある規模に到達していない限り、ほぼ不可能だと言えます。そのため、デベロッパーがグローバル リリースの初期段階であったり、特定の市場を綿密に監視して最適化する余力がなかったりする場合、地域のパブリッシャーは考慮すべき重要なパートナーとなります。
パート 2 では、同僚の Gaby Hien が、アンケートとインタビュー調査の結果をデベロッパーの視点で振り返りますので、お楽しみに。今回学んだことに基づいたベスト プラクティスのチェックリストも掲載する予定です。このチェックリストを使って、高品質なタイトルやパートナーを見つけ、スムーズなゲームのリリースを実現して、問題が起きる可能性を減らしましょう。
この記事の一部は、ココネ株式会社に寄稿いただいたゲスト記事です。
ココネ株式会社より「長年ユーザーに愛されるコンテンツやプロダクトに必要なサービス設計とは」をテーマに、お客様が愛着を持てる「世界設定」などサービス戦略についてお話しいただきました。この記事では、ココネ株式会社 冨田様・井出様より寄稿いただいたプレゼンテーションサマリーをご紹介します。
※ココネ株式会社
複数のアバターサービスを運営。アバターを武器に日本発のメタバースへ挑戦中の企業。『ポケコロ』は2021年で10周年、『リヴリーアイランド』はブラウザ版も含めると2022年で20周年など、長期間お客様に愛されるサービス運営に強みがあります。
はじめにココネが考えるサービス設計（思想）について。
次にサービス作りで大切にしている、世界設定・体験・つながりの 3要素について、『リヴリーアイランド』の事例を元に、お話しました。
アプリ内表現の例
実際のお買い物体験を目指したガチャ画面
“体験を変えていくことを考えるきっかけになりました”
“マンガアプリ以外での視点だったことが特に良かった。広い視野で改めてマンガアプリについて考えることができました”
この記事は Andrew Flynn & Jon Boekenoogen による Android Developers Blog の記事 " Play Time with Jetpack Compose " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2020 年、Google Play ストアのエンジニアリング チームのリーダー陣は、ストアのショーウィンドウにあたる部分全体の技術スタックを再構築するという大きな決断を下しました。既存のコードは 10 年以上前のもので、無数の Android プラットフォーム リリースや機能アップデートを経て、大きな技術的負債を抱えていました。デベロッパーの生産性やストア自体のユーザー エクスペリエンスとパフォーマンスに悪影響を与えることなく、数百名のエンジニアが開発できるようにスケールアップできる新しいフレームワークが必要でした。
ネットワーク レイヤからピクセルのレンダリングに至るまで、ストアのあらゆるものを更新するため、複数年にわたるロードマップを作成しました。その一環として、インタラクティブ性とユーザーの快適さを目標とした最新の宣言型 UI フレームワークも採用したいと考えました。さまざまな選択肢を分析した結果、まだアルファ版にもなっていなかった Jetpack Compose を使うという、（当時としては）大胆な決断をすることになりました。
それ以来、Google の Google Play ストアチームと Jetpack Compose チームは、ストアの具体的なニーズを満たせるバージョンの Jetpack Compose を実現するため、非常に密接な連携のもと、リリースや改善を重ねてきました。この記事では、移行のアプローチやその過程で明らかになった課題や利点について説明し、多くのエンジニアが関わるアプリで Compose を採用するとはどういうことかについて共有したいと思います。
新しい UI レンダリング レイヤとして Jetpack Compose を検討するときの最優先事項は次の 2 つでした。
Google Play ストアはすでに 1 年以上 Jetpack Compose で UI のコードを記述しており、Jetpack Compose によって UI 開発がこれまで以上にシンプルになっていることを実感しています。
特にうれしいのは、UI の記述に必要なコードがかなり減ったことで、場合によってはコードが最大 50% 少なくなったことです。これが実現できたのは、Compose が宣言型 UI フレームワークであることに加え、簡潔な Kotlin を活用できるからです。カスタムの描画やレイアウトを作成する際も、ビューをサブクラス化してたくさんのメソッドをオーバーライドする必要はなく、シンプルな関数呼び出しで実現できます。
評価テーブルを例に説明しましょう。
ビューを使う場合、このテーブルは以下の要素で構成されます。
Compose を使う場合、このテーブルは以下の要素で構成されます。
@Composable
「そうは言っても、ライブラリの依存関係でビューが提供される場合どうすればいいのか」と疑問に思う方もいらっしゃるかもしれません。たしかに、すべてのライブラリ所有者が Compose ベースの API を実装しているとは限りません。私たちが最初に移行をしたときは特にそうでした。しかし、Compose では ComposeView と AndroidView API によって、ビューを簡単に利用できる相互運用性が実現されています。ExoPlayer (英語) や YouTube の Player などの人気ライブラリは、この方法によって問題なく統合できました。
Google Play ストアチームと Jetpack Compose チームは、Compose がビュー フレームワークと同じくらい速くジャンクなしで動作できるようにするため、密接に連携しました。Compose は Android フレームワークの一部というよりはアプリにバンドルされるものなので、これは難しい要件でした。画面上の個々の UI コンポーネントのレンダリングは高速でしたが、アプリが Compose フレームワーク全体をメモリに読み込むために必要な時間をすべて合わせれば、かなりの時間になりました。
Google Play ストアで Compose を採用するうえで、特に大きなパフォーマンス改善に貢献したのはベースライン プロファイルの開発でした。以前から利用できたクラウド プロファイルもアプリの起動時間の短縮に役立ちますが、これが利用できるのは API 28 以降に限られ、頻繁な周期で（毎週）リリースされるアプリにとっては効果的ではありません。この問題に対応するため、Google Play ストアチームと Android チームが連携して、ベースライン プロファイルの開発にあたりました。ベースライン プロファイルは、デベロッパーが定義し、アプリの所有者が指定してバンドルできるプロファイルです。アプリに同梱され、クラウド プロファイルとは完全な互換性があり、アプリレベルに限定して定義することも、ライブラリレベルで定義することもできます（Compose を採用すると、このプロファイルもついてきます！）。ベースライン プロファイルをロールアウトすることで、Google Play ストアの検索結果ページの最初のレンダリング時間は 40% 短縮されました。これは大きな成果です。
Compose は、特にスクロールの際に効率的なレンダリングをします。その中核をなす仕組みとなっているのが、UI コンポーネントの再利用です。Compose は、スキップできることがわかっている Composable の再コンポーズをできる限りスキップしようとします（不変である場合など）。しかし、すべてのパラメータが @Stable (英語) アノテーション要件を満たしている場合は、デベロッパーが強制的に Composable をスキップ可能にすることもできます。Compose のコンパイラでも、特定の関数をスキップできない理由を説明した便利なガイドが提供されています。Google Play ストアでは、スクロールが発生する状況で頻繁に再利用される UI コンポーネントを作りましたが、不要な再コンポーズが積み重なってフレーム時間が足りなくなり、ジャンクにつながるという状況が発生しました。そこで、デバッグ設定でもそのような再コンポーズを簡単に見つけることができるように、Modifier を作成しました。この手法を UI コンポーネントに適用することで、ジャンクを 10-15% 減らすことができました。
@Stable
Modifier
Modifier による再コンポーズの視覚化の例。青（再コンポーズなし）、緑（1 回の再コンポーズ）
Google Play ストア アプリの Compose を最適化するうえで、もう 1 つの重要な要素となったのが、アプリ全体の一連の移行戦略を詳細に作成したことです。最初に組み込みの実験をしたとき、「二重スタック問題」に直面しました。これは、1 つのユーザー セッション内で Compose とビューの両方のレンダリングを実行すると、特にローエンドのデバイスにおいて、メモリに大きな負荷がかかるという問題です。これはコードを同じページに展開した場合だけでなく、異なるスタックのそれぞれに 2 つのページ（Google Play ストアのホームページと検索結果ページなど）が存在する場合にも発生しました。これに起因する起動の遅さを解消するには、ページを Compose に移行する順番やスケジュールについて、具体的な計画を立てることが重要でした。さらに、アプリが完全に移行されるまでの穴埋めとして、よく使うクラスの短期的なプリウォーミングを追加することも有用であることがわかりました。
Compose は Android フレームワークにバンドルされていないので、Google Play ストアチームが Jetpack Compose に直接的に関与する手間も少なくすみました。その結果、短い時間でデベロッパーに役立つ改善をすることができました。Jetpack Compose チームとの共同作業で、LazyList のアイテムタイプのキャッシュのような機能追加をしたり、無駄なオブジェクトの割り当てなどに関する簡単な修正をすばやくしたりすることもできました。
Google Play ストアで Compose を採用したことで、チームのデベロッパー満足度は大幅に上昇し、コードの品質と健全性も大きく向上しました。Google Play ストアの新機能は、すべてこのフレームワーク上に構築されています。Compose はアプリの速度向上や利便性に貢献しています。Compose への移行戦略の性質上、APK サイズの変化やビルド速度は細かく測定できませんでしたが、可視化できたものについてはすべて順調に進んでいます。
Compose は Android UI 開発の未来です。Google Play ストアの事例から言うと、これ以上すばらしいものはありません！
この記事は Dave Burke による Android Developers Blog の記事 " Android 13 Developer Preview 2 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2022 年 3 月、2 億 5,000 万台以上の大画面 Android デバイスをさらに活用してもらうための 12L フィーチャー ドロップが、Android オープンソース プロジェクト（AOSP）にアップされました。そしてその直後、今回のリリースを迎えました。Android 13 やタブレット、Jetpack Compose でのデベロッパーの生産性向上の詳細については、#TheAndroidShow の最新エピソードをご覧ください。
デベロッパー プレビュー 2 の説明に入る前に、先ほどの話をしましょう。12L フィーチャー ドロップが正式に AOSP にリリースされ、今後数週間のうちにサポート対象のすべての Pixel デバイスにロールアウトされます。12L には、アプリをドラッグ＆ドロップしてすばやく分割画面モードに切り替えることができる新しいタスクバー、通知シェードとロック画面の新しい大画面レイアウト、アプリの互換性モードの改善などのアップデートが含まれ、タブレットでの Android 12 がさらに改善されています。詳細についてはこちら (英語) を参照してください。
12L は、年内行われるアップデートによって、Samsung、Lenovo、Microsoft のタブレットや折りたたみ式デバイスで利用できるようになる予定です。そのため、今のうちにアプリの準備も整えておくようにしましょう。さまざまなウィンドウ サイズの分割画面モードや異なる画面の向きでアプリをテストし、該当する場合は新しい互換性モードの変更点を確認することを強くおすすめします。デベロッパー向けの 12L の説明はこちら (英語) をご覧ください。
最も良いのは、12L の大画面機能が Android 13 の土台となっていることです。そのため、Android 12L を搭載したタブレットのベースもカバーできることを認識したうえで、Android 13 の開発やテストをすることができます。私たちは、大画面機能を Android の将来にとって重要な機能と位置付けています。そのため、皆さんがタブレットや Chromebook、折りたたみ式デバイスで優れたエクスペリエンスを構築するために必要になるツールを提供できるように、今後も注力を続けます。詳細については大画面向けの最適化を始める方法や大画面デベロッパー リソースをご覧ください。
それでは、今回の Android 13 デベロッパー プレビュー 2 の新機能の紹介に入りましょう。
ユーザーは、重要な個人情報や機密情報、リソースを安心してデバイスに預けることができる OS やアプリを求めています。プライバシーとユーザーの信頼は Android の製品理念の中核です。Android 13 では、すべての人に対して高品質で責任あるプラットフォームを構築することに引き続き重点を置いています。それを実現するため、デバイスでより安全な環境を実現し、ユーザーがより多くのことを制御できるようにします。デベロッパー プレビュー 2 の新機能は以下のとおりです。
通知権限 - ユーザーが最も重要な通知に集中できるようにするため、Android 13 にはアプリから通知を送信する新しい実行時の権限として、POST_NOTIFICATIONS (英語) が導入されます。Android 13 を対象とするアプリは、通知を送信する前に、ユーザーに対してこの通知権限をリクエストする必要があります。Android 12 以前を対象にするアプリでは、システムがアップグレード フローを処理します。このフローは、今後も微調整が続けられる予定です。ユーザーが自身でコントロールできる範囲を増やすため、できる限り早くアプリの対象を Android 13 に変更し、通知権限をリクエストすることをおすすめします。詳しくはこちら (英語)をご覧ください 。
Android 13 の通知権限 ダイアログ
デベロッパーがダウングレードできる権限 - アプリによっては、以前にユーザーが許可した特定の機能を有効にするための権限や、古い Android バージョンで取得した機密性の高い権限が不要になることがあるかもしれません。Android 13 では、以前に許可された実行時の権限をダウングレードしてユーザーのプライバシーを保護できるよう、新しい API (英語) を提供します。
コンテキスト登録されたレシーバの安全なエクスポート - Android 12 では、デベロッパーがマニフェストで宣言されたインテント レシーバをエクスポートするかどうか、明記することを義務付けました。Android 13 では、コンテキスト登録されたレシーバについても同様に求められます。つまり、システム以外のソースのレシーバを登録する際に、RECEIVER_EXPORTED (英語) フラグか RECEIVER_NOT_EXPORTED (英語) フラグを追加します。これにより、明示的に指定しない限り、他のアプリがレシーバを使ってブロードキャストを送信することはできなくなります。Android 13 では必須ではありませんが、アプリのセキュリティ強化の一環として、エクスポートするかどうかを宣言することをおすすめします。
Android 13 では、洗練されたエクスペリエンスと高いパフォーマンスをユーザーに提供していただけるよう、さらにツールを充実させる作業を続けています。ここでは、今回のリリースに含まれるアップデートの一部を紹介します。
日本語テキストの折り返しの改善 - TextView でテキストを文字ではなく、文節（自然に感じられる言葉の最小単位）やフレーズで折り返すことができるようになり、日本語のアプリで洗練性と読みやすさが向上します。TextView で android:lineBreakWordStyle="phrase" (英語) を指定すると、この折り返し設定を利用できます。
android:lineBreakWordStyle="phrase"
phrase スタイルを有効にして折り返した日本語テキスト（下）と、有効にしていない日本語テキスト（上）
非ラテン文字の行の高さの改善 - Android 13 では、非ラテン文字（タミル文字、ビルマ文字、テルグ文字、チベット文字など）の表示が改善され、各言語に応じた行の高さが利用されます。新しい行の高さになることで、文字が欠けることがなくなり、文字の位置も改善されます。この改善は、アプリの対象を Android 13 にするだけで反映されます。この変更は非ラテン言語の UI に影響する可能性があるため、新しい行間を使う場合は、必ずアプリのテストをするようにしてください。
Android 13 をターゲットにしたアプリでの非ラテン文字の行の高さの改善（下）
テキスト変換 API - 日本語や中国語などを話す人は、ふりがなで入力します。そのため、検索やオートコンプリートなどの機能をすばやく使用できないことがあります。Android 13 では、新しいテキスト変換 API (英語) を呼び出すことで、ユーザーが探しているものをすばやく簡単に見つけられるようになります。たとえば、日本語ユーザーが検索をする場合、これまでは（1）検索語句（場所やアプリ名など）の発音をひらがなで入力する（2）キーボードを使ってひらがなを漢字に変換する（3）漢字を使って再検索する（4）検索結果を取得する という手順を踏む必要がありました。新しいテキスト変換 API を使うと、日本語ユーザーがひらがなを直接入力するだけで、漢字の検索結果が直接表示され、手順 2 と 3 を省くことができます。
カラー ベクター フォント - Android 13 では、COLR バージョン 1（仕様 (英語) 、紹介動画 (英語) ）フォントのレンダリングがサポートされ、システムの絵文字が COLRv1 形式にアップデートされます。COLRv1 は、非常にコンパクトな新しいフォント形式で、サイズを問わず高速にくっきりと表示できます。システムがすべての処理をしてくれるので、ほとんどのアプリでは何もしなくても動作します。デベロッパー プレビュー 2 より、アプリで COLRv1 をオプトインできるようになります。アプリでシステム フォントを使って独自にテキストをレンダリングしている場合は、オプトインして絵文字のレンダリングをテストすることをおすすめします。COLRv1 の詳細は、Chrome でのお知らせ (英語) をご覧ください。
COLRv1 ベクター絵文字（左）とビットマップの絵文字
Bluetooth LE Audio - LE（低電力）Audio は、従来の Bluetooth に代わる次世代ワイヤレス オーディオで、新しい使用例や接続トポロジーを実現します。これにより、オーディオを共有して友だちや家族にブロードキャストしたり、情報や娯楽、ユーザー補助を目的として一般公開されているブロードキャストを登録したりできるようになります。また、電池寿命を犠牲にすることなく、非常に再現性の高いオーディオを受信し、従来の Bluetooth では不可能だったユースケース間でシームレスな切り替えができるように設計されています。Android 13 は LE Audio をビルトインでサポートするので、デベロッパーは互換デバイスで新機能を無料で利用できます。
MIDI 2.0 - Android 13 は、新しい MIDI 2.0 標準をサポートします。これには、USB 経由で MIDI 2.0 ハードウェアに接続する機能も含まれます。この最新の標準では、コントローラの分解能の増加、西洋以外のイントネーションのサポート強化、音符単位のコントローラによる演奏の表現力向上などの機能が提供されます。
新しいバージョンのプラットフォームをリリースするたびに、アプリの互換性を優先し、迅速かつスムーズにアップデートできるように作業をしています。皆さんが時間に余裕を持てるよう、Android 13 ではアプリに関連する変更がオプトイン方式になっています。また、短時間で対応できるように、ツールやプロセスをアップデートしています。
リリースに一歩近づいたデベロッパー プレビュー 2 では、全般的な安定性を改善する作業を続けています。そのため、新機能や変更点を試してフィードバックを送るには、今が絶好のタイミングです。特に、API に関するご意見や、プラットフォームの変更点がアプリに与える影響に関して詳しい情報をお待ちしています。フィードバック ページ (英語) にアクセスし、感想の共有または問題の報告をお願いします。
また、今は互換性テストをして必要な作業を洗い出し始めるべきタイミングでもあります。Android 13 ベータ版 1 までに互換性のあるアップデートをリリースできるように、早めにこの作業をすることをおすすめします。現時点では、アプリの targetSdkVersion を変更する必要はありませんが、開発者向けオプションの動作変更切り替えを使うことをおすすめします。Android 13 の変更点をオプトインすることで、アプリがどのような影響を受ける可能性があるかについての予備知識を得ることができます。
2022 年 7 月に プラットフォームの安定版に到達すると、アプリに関連するすべてのシステム動作、SDK/NDK API、非 SDK リストが確定します。このタイミングで最終的な互換性テストを終え、完全に互換性があるバージョンのアプリ、SDK、ライブラリをリリースできます。デベロッパー向けのタイムラインの詳細はこちらをご覧ください。
開発者向けオプションでのアプリの互換性切り替え
デベロッパー プレビューには、Android 13 の機能を試し、アプリをテストしてフィードバック (英語) を提供するために必要なすべてのものが含まれています。Pixel 6 Pro、Pixel 6、Pixel 5a 5G、Pixel 5、Pixel 4a（5G）、Pixel 4a、Pixel 4 XL、Pixel 4 のいずれかにデバイス システム イメージを書き込むと、すぐに始めることができます。Pixel デバイスをお持ちでない方は、Android Studio Dolphin で 64 ビット システム イメージと Android Emulator を使うことができます。さらに幅広くテストできるように、GSI イメージも公開しています。すでにプレビュー ビルドを Pixel デバイスにインストールしている方は、今回のアップデートや、今後のプレビューやベータ版をすべて無線（OTA）で自動的に受け取ります。Android 13 を入手する方法はこちらをご覧ください。
その他、詳しい情報はAndroid 13 デベロッパー サイト (英語) でご覧いただけます。
この記事は Krish Vitaldevara による Android Developers Blog の記事 " Keeping Google Play safe with our key 2022 initiatives " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
ユーザーとデベロッパーの皆さんのために、 Google Play の安全性を維持することは、私たちにとって、最優先事項です。ここ数年、デベロッパーの皆さんと連携して、アプリの安全性の確保に務めてきました。私たちは、デベロッパーの皆さんがアプリを保護(英語)し、データ セーフティ関連の情報をユーザーと共有する準備を整え、プライバシー保護をより優先する新しい広告ソリューションの提供などを実現させるサポートをしました。また、不正なコンテンツや悪意のあるコンテンツを含むアプリをインストール前に遮断 (英語) できるように、機械学習による検知や、アプリの審査の強化の取り組みも続けています。
また、私たちは、デベロッパーの皆さんが、この進化するプライバシーとセキュリティの状況の変化のペースについて行くことが大変だということも理解しています。Google Play Console の 受信トレイ メッセージやウェビナー、教育リソースの追加などの施策を通じて、より分かりやすいアップデート、変更に対応するための時間、そして有益な情報を提供できるよう努めております。このブログ記事で、2022 年に予定されていることを共有することで、皆さんが準備をするための充分な時間を用意できればと考えています。
デベロッパーの皆さんから、ご自身のアプリのデータの安全性について、わかりやすくシンプルな形でユーザーに説明したいと伺いました。そこで、アプリの Google Play ストア上の掲載情報には、データ セーフティ セクション が表示される予定です。このセクションでは、、デベロッパーの皆さんが、アプリがユーザーのデータをどのように収集、共有、保護するかを説明することができます。すでにユーザーからは、この情報に基づいて、アプリが自分に適したものであるかどうかを判断できるようになるというお声をいただいています。2022 年 4 月後半には、Google Play ストアにデータ セーフティ セクションの表示が開始される予定なので、お早めにデータ セーフティ フォームを送信してください。2022 年 7 月 20 日より、すべてのアプリで、アップデートの際にデータ セーフティ フォームの入力が必須になります。
先日、プライバシー サンドボックス (英語) の取り組みを Android に展開することをお知らせしました。私たちは、ユーザーのプライバシーを向上させる革新的なソリューションに取り組む一方で、デベロッパーの皆さんにとって、ビジネスを構築し、誰もが無料でアプリにアクセスできるようにするための重要なメカニズムをサポートするため、デベロッパーの皆さんと緊密に連携し、この取り組みを進めていきます。最新情報を受け取りたい方は、ニュースレター (英語) にご登録ください。
デベロッパーの皆さんがゲームやアプリを保護することをサポートするとともに、デベロッパーの皆さんが設計した通りの体験をユーザーが確実に得られるようにするために、新しい Play Integrity API (英語) の展開を開始しました。現在、デベロッパーの皆さん全員が、この新しい API にアクセスできるようになっており、疑わしいトラフィックを簡単に検知し、チートや不正行為などの問題にすばやく応答可能となりました。アップグレードに必要なビルド時間をほとんどかけずに、簡単に新機能を手に入れられるよう、将来を見据えた方法で構築しています。皆さんのアプリにこの機能を設定する方法は、こちらをご覧ください。
デベロッパーの皆さんより、SDK プロバイダからの重要なアップデート情報をより迅速に受け取りたいという声が寄せられています。そこで 2021 年、SDK プロバイダが Google Play Console で緊急の問題について通知 できる仕組みを導入しました。また、ビルド時間を無駄にしたり、ユーザーの安全性が損なわれたりすることがないように、SDK の安全性や信頼性について詳しく知りたいという声もありました。今後数か月のうちに、SDK の採用レベル、維持率、使われたランタイム権限の数などの情報を共有し、貴社ビジネスやユーザーに適した SDK を選択できるようにサポートする予定です。
2021 年は、広告と子供向けアプリに関する大人の事前承認の要件を見直す作業を続け、子どものプライバシーや安全性をさらに強化しました。対象となるデベロッパーは、近日中に追加されるデータ セーフティ セクションにバッジを追加して、ファミリー ポリシーへの準拠を宣言していることを明示できます。2022 年も引き続き、子どもの安全やプライバシー保護のためのポリシーを更新していく予定です。最新情報は、ポリシー関連のウェビナーや PolicyBytes でご確認ください。
デベロッパーの皆さんは、アプリの機能や改善に必要なデータのみを収集、利用する必要があります。この点に関する実践的なヒントは、ベスト プラクティス (英語) ガイドに掲載されています。2022 年も、権限を調整して適切なユースケースに近づける作業を継続しています。さらに、古いバージョンの Android OS の API を利用するアプリから生じるリスクを軽減する方法について、デベロッパーの皆さんと積極的に話し合っています。近日中に詳細をお知らせしますので、ポリシー更新関連のメールをお待ちください。
Google Play が誰にとっても信頼できるアプリとゲームの提供元であり続けるためご協力いただきますよう、お願いいたします。
Reviewed by Konosuke Ogura - Trust & Safety - Play & Android, Global Content Operations Lead, Tamao Imura - Developer Marketing Manager, Google Play
この記事は Phalene Gowling による Android Developers Blog の記事 " Grow your game’s revenue with Google Play Console’s new strategic guidance " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年のモバイルゲームへの消費者支出は7.3% 増の 932 億ドル (英語) に達し、勢いが衰える気配はありません。競争が激しいこの成長市場で、効率的に収益を上げることはこれまでになく重要になってきています。しかし、戦略コンサルタントを利用しない限り、どのように自社の収益化戦略を強化すべきか判断することが難しいのではないでしょうか。
このような課題を支援するため、Google Play は Play Console の一連のツールを拡張し続けています。2021 年には、皆さんのビジネス拡大に役立てていただくため、統計情報のページに新しいエンゲージメントと収益化の指標をリリースしました。そして今回、収益化の成功に役立つ新たな戦略的ガイダンス ツールを発表しました。
ゲームの収益化の向上を支援するため、指標に基づいたガイダンスが表示されたことで以下が可能になります。
戦略的ガイダンス指標の階層（詳細は Google Play アカデミーの KPI のモニタリング もしくはこちらのブログ (英語) をご確認下さい）
Google はこの数年間、一部のパートナーとともにダッシュボードをテストし、このガイダンスを完成に近づける作業をしてきました。この戦略的ガイダンスに対するフィードバックは好意的なものでした。皆さんも、ぜひご活用ください。
「この機能は本当に便利です！このような種類のインサイトは、まさに私たちが Google に期待していたものです。なぜなら、これらは私たちのビジネスを拡大するために非常に役立つものだからです。」
- Gameloft のプロダクト マネージャー
戦略的ガイダンスは、Google Play Console の売上レポートから確認できます。モバイルゲームの成長に関するエキスパートの協力のもと、簡単に類似アプリとパフォーマンス比較ができるよう、主要な収益化指標（新しい指標を含む）とその相関関係を追加しました。すべての指標は ヘルプセンターの記事 で確認できます。
この指標階層は、ゲームのどの下位指標（購入者のコンバージョンなど）を改善すると全体の収益増加に最も効果的かを理解するうえで役立つツールです。 類似アプリグループのベンチマークや国別の内訳を利用すると、どの市場では不調で、どの市場ではマーケット リーダーであるかなどの成長機会をすばやく特定することができます。
指標を選択して詳細を確認し、時系列でパフォーマンスを追跡してみましょう。戦略的ガイダンスでは、選択した指標の地域別の内訳が表示されるので、ゲームをグローバルに展開する機会を見出すのに役立ちます。また、詳細な指標分析を活用することにより、小さな投資で大きな効果を得られるところを特定できます。
一日あたりの購入者比率を改善するための戦略的ガイダンスの指標提案例
カジュアル ゲームから RPG まで、各指標個別の推奨事項は、さまざまなゲーム デベロッパーの皆さんに役立つ多くのインサイトを得られるように設計されています。プロモーション コンテンツの多様化、ゲームの仕組みの改善、購買力平価を実現するための新しい価格帯のテストなどにご活用ください。
広告のみのマネタイズからアプリ内購入 (IAP)へとビジネスモデルをシフトするデベロッパーが増える中、Google は、 IAP による収益化を全体の戦略の中に組み込んでいるデベロッパーの皆さんのために戦略的ガイダンスを開発しました 。今回のローンチにより、このようなゲーム デベロッパーの皆さんに、グロース コンサルティングの機会を幅広く提供できることを嬉しく思います。2022 年も皆さんの収益拡大を支援するために、さまざまなローンチを予定しておりますので、ご期待ください。
この記事は Smule Engineering team (David Gayle, Chris Manchester, Mark Gills, Trayko Traykov, Randal Leistikow, Mariya Ivanova) による Android Developers Blog の記事 " Smule Adopts Google’s Oboe to Improve Recording Quality & Completion Rates " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
これまでで最も多くダウンロードされたカラオケアプリをリリースしている Smule Inc. は、Android で全般的な音質を向上させる取り組みを進めています。具体的にはレイテンシ (遅延) の改善、例えば歌いながらヘッドセットで自分の声を聴けるようにすることです。1,000 万人以上の Android ユーザーに使われている Smule アプリを OpenSL オーディオ API から Oboe オーディオ ライブラリに移行するため、オーディオと動画の専門チームは 2021 年に必要な変更をしました。これにより、録音完了率が 10% 以上向上しています。
Smule Inc. は、たくさんの人々がお気に入りの歌を歌い、日々それを共有できるカラオケアプリのリーディング企業の 1 社です。Smule アプリは、共同制作に特化することで従来のカラオケの枠を超え、友人やプラットフォーム上の他のシンガー、さらにはお気に入りの音楽アーティストと音楽を共有し共同作業ができるという、他にはない機会をユーザーに提供します。特に重要なのは音質で、Smule チームは 2020 年に Android でのエクスペリエンスを改善する可能性を見いだしました。
世界市場の多様なデバイスをサポートしつつ、最新デバイスの超高速ハードウェアを活用するには、Smule が使っていた以前の OpenSL 実装は適切なものではありませんでした。Smule の開発チームは、オーディオ システムのアップグレードが不可欠で、それは合理的な改善であると判断しました。
この改善には 2 つのアプローチがあります。1 つは、Android O で導入され、低レイテンシが求められるアプリ向けに設計された高パフォーマンス Android C オーディオ API である AAudio を直接ターゲットにする方法。もう 1 つは、内部に AAudio と OpenSL の両方を包含した Oboe (英語) を使う方法です。Smule の開発チームは、慎重に評価を行い、使いやすいコードベース、幅広い互換デバイス、手厚いコミュニティ サポートを特徴とする Oboe を採用することにしました。その結果、レイテンシを最低限にとどめ、利用できるネイティブ オーディオを最大限活用することができました。
Oboe への移行は、アーキテクチャとテクノロジーの大きな進化を意味します。そのため、ロールアウト プロセスは慎重に臨みました。段階的にリリースする計画を立て、少数のデバイスモデルから始めて品質を評価しつつ、週を追うごとに有効化するデバイスを増やしました（Oboe で問題が発生したごく一部のデバイスは、OpenSL に戻しました）。この入念な段階的アプローチにより、リスクを最小化でき、エンジニアリング チームも発生したデバイス固有問題に対応できました。
Smule が Oboe に切り替えたのは、アプリのエクスペリエンス向上のためです。期待した成果は、オーディオ再生時のクラッシュを大幅に減らし、録音時のエコーや雑音などの問題をなくし、オーディオ レイテンシを減らすことでした。Android デベロッパー ブログの昨年の記事には、人気のデバイス上位 20 種類での平均レイテンシが、2017 年の 109 ミリ秒から、Oboe を使う現在では 39 ミリ秒に減少したことが記載されています。109 ミリ秒の遅延があると、明らかなエコーとして聞こえるため、ライブで歌う際に邪魔になります。しかし、39 ミリ秒であれば、リアルタイム アプリに許容されるしきい値内に収まります。現在のトップデバイス間のレイテンシの差は、すべて 22 ミリ秒以内に収まっています。この一貫性も大きなプラスです。
Smule が Oboe を使うようになってから録音完了率が上昇したことも、このレイテンシの改善が関連しているでしょう。レイテンシが低下すると、Smule のワールドクラスのオーディオ効果を適用しながら、エコーなしに自分の歌声をヘッドセットで聴くことができます。
Smule が Oboe を組み込む際、Google のチームも深く関与しました。具体的には Oboe 用の GitHub ポータルによる効率的な共同作業を通した、重要な知見やサポートの提供です。2 つのチームの共同作業により、何百万ものアクティブ ユーザーという、これまでで最大の Oboe 展開をリリースすることができました。Smule チームはいくつかの Oboe コードの問題に対処し、Google のチームは一部のモバイル デバイス メーカーとの調整をし、Oboe の互換性をさらに向上させました。
音質は、シンガーのコミュニティにとって最も重要なもの。共同作業によって、できる限り最高のエクスペリエンスを提供し、Smule での音楽制作をサポートできたことに感謝しています。- Smule CTO 、Eric Dumas 氏
大規模に利用されることを考えれば、デバイス固有の問題に直面するのは当然のことです。その顕著な例が、未処理のオーディオ ストリームにエコー効果を挿入する OS ビルトイン機能でした。このような機能が存在すると、Smule 独自の DSP アルゴリズムやオーディオ フィルタを正しく適用できなくなります。その際、Google チームは迅速にライブラリのアップデートやパッチを提供するよう試みました。Oboe の問題を報告するプロセスをシンプルで明確に定義することで、タイムリーに対応したのです。
Smule は特定のチップセットで発生するエラーなど、その他のデバイス固有の問題も協力して克服しました。例えば、Oboe がモノラルのマイク入力を要求したとき、一部のデバイスではステレオ入力を 1 つにミックスし、疑似的にモノラルのマイク入力を提供したのです。Smule は Oboe の GitHub でチケットを作成し、例を提示して、Oboe テスターアプリで問題を再現しました。
Google が開発した Oboe テスターアプリは、実装の問題を特定して解決するうえで便利なツールでした。特に役に立ったのは Oboe、AAudio、OpenSL ES のさまざまな機能のテスト、Android デバイスのテスト、レイテンシや不具合の測定などです。このアプリには非常に豊富な機能があり、ほぼすべてのオーディオ設定をシミュレーションできます。また、Android Intent を使ってシェル スクリプトから Oboe テスターアプリを起動すれば、自動テストにも利用できます。Smule は、大量のデバイスが対象になることを考慮し、この自動テストを有効活用しました。
Smule は、デバイス固有の問題が解消され、Oboe オーディオが十分安定したと確信できた段階で、大規模なスプリット テスト ロールアウトによるアプローチに切り替えました。わずか数週間のうちに、問題のないデバイスで Oboe の利用比率を 10% から 100% に増やしました。これが実現できたのは、リリースが始まってから Oboe に対して継続的に寄せられていた肯定的なフィードバックと、順調な KPI 指標があったからに他なりません。
良い結果も出ています。Oboe 対応の Smule ユーザーは、より多く歌っているのです。重複を省いたカラオケ録音数や歌唱への参加数（デュエット）は、なんと 8.07% も増加しました。また、重複を省いたアップロード数は 3.84%、最後まで歌われた曲の数は 4.10% 増加しました。2021 年の第 3 四半期と第 4 四半期には、録音完了率 が 10% 以上増加しました。
Smule は Google の Firebase Crashlytics ツールを使い、Oboe を完全リリースして以降、オーディオ関連のクラッシュが減少してアプリの安定性が向上したことを把握しています。これはローエンド デバイスでも同様です。Smule の専属カスタマー サポートチームは、意図しない自動音声やエコーなどといったオーディオ関連の苦情が 33% 減少したことに、喜びの声をあげています。
Oboe に切り替えるという決断は、確かに成果をもたらしました。アプリの動作はこれまで以上に良好になり、オーディオのさらなる進化や最新テクノロジーを搭載したハードウェアに対応する準備も整っています。何より、Smule ユーザーは楽しく音楽制作にあたることが出来ています。
この記事は Dan Galpin による Android Developers Blog の記事 " Android Basics and Training Update " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 10 月、Android Basics in Kotlin (Kotlin による Android の基礎) (英語) の最後のユニットを公開しました。この無料の自習型プログラミング コースで学べば、誰でも Android 開発ができるようになります。このコースでは、プログラミングの経験がない方向けに、Android アプリを開発する方法を説明します。学習を通して、プログラミングの基本や Kotlin プログラミング言語の基礎を習得できます。
私たちは、教育者や学習者からのフィードバックをもとに、コースの教材を見直す作業を続けており、学んだことを応用できるプロジェクトや、さらに高度な教材の足がかりとなる新たなトピックを追加しています。
今回のアップデートにより、現在の Android Basics in Kotlin (Kotlin による Android の基礎) は、Android Kotlin Fundamentals の核となる教材を網羅するようになっています。そのため、後者のコースの提供は終了する予定です。さらに上級の学習者の方にも、本教材に取り組むことをおすすめします。よく知っている内容のセクションはスキップし、直接理解度チェックに挑戦しましょう。重要なコンセプトを見逃す可能性のある中級者や上級者も、成功のために必要なことを本教材から学べます。私たちのチームも、最新のガイダンスをコースに確実に反映する作業に注力できます。あらゆるレベルの学習者に応えるため、コースに加えて、Codelabやコードサンプル、ドキュメントや動画コンテンツの提供も続けます。
私たちは、次のコースとして、Jetpack Compose による Android アプリのプログラミングを説明するコースの準備を進めています。 Android のネイティブ UI 開発用最新ツールキットについて説明できるようになる日が待ち遠しいです。このコースによって、Android の UI 開発のあらゆる側面がシンプルになり、高速になるからです。
現在のコースを受講すると、アプリ開発の基本を学ぶことができます。その経験は、既存の Jetpack Compose の学習パス (英語) を受講する際にも、近日公開の Android Basics with Compose コースを受講するうえでも、絶好のスタート地点となります。Android 開発の世界を探索し続けるうえで、土台となる部分をしっかりと身につけることができます。Android Basics は両方のバージョンが共存する予定で、どちらの UI ツールキットでも Android を学べるようになります。
まだアプリを作ったことはないけれども、その方法を学びたいと思っている皆さん。そして、最新のベスト プラクティスを通じて技術に磨きをかけたい皆さん。ぜひ Android Basics in Kotlin コース (英語) をチェックしてみてください。
この記事は Chet Haase による Android Developers - Medium の記事 " JankStats Goes Alpha " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
イラスト : Virginia Poltrack
ジャンク（名詞）: アプリケーションのパフォーマンスが悪いこと。フレーム落ちが発生したり、UI の動作が断続的になったりして、悪いユーザー エクスペリエンスにつながる。「不幸なユーザー」も参照。
パフォーマンスの問題をデバッグするのは、難しいことです。多くの場合、どこから始めればよいか、どのツールを使うか、ユーザーにどんな問題が起きているのか、その問題が実際のデバイスにどう出現しているのかは、明確ではありません。
Android チームは、ここ数年をかけて、問題のさまざまな部分をデバッグするツールを増やしてきました。たとえば、起動パフォーマンス (英語) の分析、特定のコードパスのテスト、特定のユースケースのテストや最適化、IDE のビジュアル プロファイラなどです。これらはすべて開発時のテスト用で、ローカルで確認できる問題をデバッグして修正する際に役立ちます。
一方、Google Play の Android Vitals、そして Firebase は、どちらもダッシュボードを提供しており、そこで実際のユーザーのデバイスでアプリがどのように動作しているかを確認できます。
しかしそれでも、実環境のアプリで発生する問題の見つけ方を知るのは難しいことです。とりわけ、ユーザーのデバイスで発生し、自分の席で快適に利用できる便利な開発マシンだけでは見ることができない問題はそう言えます。パフォーマンス ダッシュボードは役立ちますが、ユーザーに問題が発生しているときに、そこで何が起こっているかがわかるほどの詳しい情報が提供されるとは限りません。
そこで登場するのが、JankStats です。これは、ユーザーのデバイスで発生しているアプリのパフォーマンスの問題を計測して報告することに特化した AndroidX 初めてのライブラリです。
JankStats はかなり小さな API で、根本的な目的が 3 つあります。それは、フレームごとのパフォーマンス情報をキャプチャすること、アプリを（開発環境だけでなく）ユーザーのデバイスで実行すること、そしてパフォーマンスの問題が起きたときにアプリで発生していることを計測したり報告したりできるようにすることです。
Android プラットフォームでは、フレームのパフォーマンス データを取得する方法がすでに提供されています。たとえば、API 24 以降では FrameMetrics を使えます。また、最近のリリースでは、さらに詳しい情報を提供できる機能が追加されています。それ以前のリリースで実行している場合も、精度は落ちますが、さまざまな手法で有用なタイミング情報を取得できます。
そのため、すべてのリリースで動作する独自のフレーム時間ロジックが必要なら、さまざまな API バージョンでさまざまなメカニズムを実装しなければなりません。しかし、そうする代わりに 1 つの JankStats API を使うだけで、それが皆さんの代わりにすべてをしてくれます。さらに、その他の機能も提供されます。
JankStats では、1 つの API でフレームごとの時間を報告できるので、簡単に計測できます。内部的には、適切なメカニズム（API 24 以降の FrameMetrics (英語) など）に委譲しています。データがどこから来るかを気にする必要はなく、単に JankStats にどのくらい時間がかかったかを聞けばいいだけです。すると、コールバックでその情報が返されます。
実際に JankStats のデータを生成したりリスニングしたりするのも、それと同じくらい簡単です。生成して、あとはリスニングして待てばいいだけです（厳密に言えば、待つのはコードですが）。JankStats のサンプル JankLoggingActivity から、この手順の例を紹介しましょう。
val jankFrameListener = JankStats.OnFrameListener { frameData -> // real app would do something more interesting than log this... Log.v("JankStatsSample", frameData.toString())}jankStats = JankStats.createAndTrack( window, Dispatchers.Default.asExecutor(), jankFrameListener,)
val jankFrameListener = JankStats.OnFrameListener { frameData ->
// real app would do something more interesting than log this...
Log.v("JankStatsSample", frameData.toString())
jankStats = JankStats.createAndTrack(
window,
Dispatchers.Default.asExecutor(),
jankFrameListener,
)
Log.v()
JankStats.OnFrameListener: FrameData(frameStartNanos=827233150542009, frameDurationUiNanos=27779985, frameDurationCpuNanos=31296985, isJank=false, states=[Activity: JankLoggingActivity])JankStats.OnFrameListener: FrameData(frameStartNanos=827314067288736, frameDurationUiNanos=89903592, frameDurationCpuNanos=94582592, isJank=true, states=[RecyclerView: Dragging, Activity: JankLoggingActivity])JankStats.OnFrameListener: FrameData(frameStartNanos=827314167288732, frameDurationUiNanos=88641926, frameDurationCpuNanos=91526926, isJank=true, states=[RecyclerView: Settling, RecyclerView: Dragging, Activity: JankLoggingActivity])JankStats.OnFrameListener: FrameData(frameStartNanos=827314183945923, frameDurationUiNanos=4731405, frameDurationCpuNanos=8283405, isJank=false, states=[RecyclerView: Settling, Activity: JankLoggingActivity])
JankStats.OnFrameListener: FrameData(frameStartNanos=827233150542009, frameDurationUiNanos=27779985, frameDurationCpuNanos=31296985, isJank=false, states=[Activity: JankLoggingActivity])
JankStats.OnFrameListener: FrameData(frameStartNanos=827314067288736, frameDurationUiNanos=89903592, frameDurationCpuNanos=94582592, isJank=true, states=[RecyclerView: Dragging, Activity: JankLoggingActivity])
JankStats.OnFrameListener: FrameData(frameStartNanos=827314167288732, frameDurationUiNanos=88641926, frameDurationCpuNanos=91526926, isJank=true, states=[RecyclerView: Settling, RecyclerView: Dragging, Activity: JankLoggingActivity])
JankStats.OnFrameListener: FrameData(frameStartNanos=827314183945923, frameDurationUiNanos=4731405, frameDurationCpuNanos=8283405, isJank=false, states=[RecyclerView: Settling, Activity: JankLoggingActivity])
ログに出力された frameData には、いくつかの興味深い点があります。
frameData
isJank=true
JankLoggingActivity
Thread.sleep()
FrameMetrics
Activity
JankStats は、最近のベンチマーク用ライブラリとは異なり、ユーザーのデバイスから結果を取得できるように作られています。開発マシンで問題をデバッグできるのはすばらしいことですが、実世界の実ユーザーが、制約の異なるさまざまなデバイスでアプリを使っている状況では、開発マシンでのデバッグは役に立ちません。
JankStats では、アプリを計測して必要なパフォーマンス データを提供する API や、そのデータをアップロードしてオフラインで分析できるようにするための報告メカニズムが準備されています。
最後に（このライブラリの本当に新しい注目点はここです）、JankStats では、パフォーマンスの問題が起きたときに、アプリで実際に何が起きていたのかを把握できる仕組みが提供されています。私たちがよく耳にする不満は、既存のツールやダッシュボード、アプローチでは、ユーザーが経験しているパフォーマンスの問題に関する十分な コンテキスト が得られないというものです。
たとえば、FrameMetrics API（API 24 で導入され、JankStats で内部的に使用されています）は、フレームの描画にどのくらい時間がかかったかを教えてくれるので、そこからジャンク情報を導き出すことができます。しかし、そのときにアプリで何が起こっていたかはわかりません。FrameMetrics などのパフォーマンス測定ツールを組み込み、コードを計測しようとしているのは皆さんなので、問題を見つけるのは皆さんの仕事です。しかし、皆さんは忙しくて、このような内部インフラストラクチャを構築することはできません。そのため、ジャンクの計測は行われず、パフォーマンスの問題が残り続けるのが一般的です。
同じように、Android Vitals ダッシュボードは、アプリでパフォーマンスの問題が発生していることは教えてくれますが、その問題が発生しているときにアプリが何をしていたかは教えてくれません。そのため、その情報を使って何をすればよいのかを知るのは困難です。
JankStats では、PerformanceMetricsState API が導入されます。これはシンプルなメソッドの集まりで、任意のタイミングでアプリの中で起きていることを教えてもらうように、システムに依頼します。結果は String のペアで表され、特定の Activity や Fragment がアクティブなタイミングや、RecyclerView がスクロールされるタイミングなどを知ることができます。
PerformanceMetricsState API
String
Fragment
RecyclerView
次の例は、JankStats サンプルのコードです。RecyclerView を計測し、その情報を JankStats に渡す方法を示しています。
val scrollListener = object : RecyclerView.OnScrollListener() { override fun onScrollStateChanged(recyclerView: RecyclerView, newState: Int) { val metricsState = metricsStateHolder?.state ?: return when (newState) { RecyclerView.SCROLL_STATE_DRAGGING -> { metricsState.addState("RecyclerView", "Dragging") } RecyclerView.SCROLL_STATE_SETTLING -> { metricsState.addState("RecyclerView", "Settling") } else -> { metricsState.removeState("RecyclerView") } } }}
val scrollListener = object : RecyclerView.OnScrollListener() {
override fun onScrollStateChanged(recyclerView: RecyclerView,
newState: Int)
val metricsState = metricsStateHolder?.state ?: return
when (newState) {
RecyclerView.SCROLL_STATE_DRAGGING -> {
metricsState.addState("RecyclerView", "Dragging")
RecyclerView.SCROLL_STATE_SETTLING -> {
metricsState.addState("RecyclerView", "Settling")
else -> {
metricsState.removeState("RecyclerView")
この状態は、アプリのどこからでも（あるいは、別のライブラリからでも）挿入できます。JankStats は、結果を報告するときにこの状態を取得します。そのため、JankStats からレポートを取得すると、各フレームでかかった時間だけでなく、そのフレームでユーザーが何をしていたのかまでわかります。その操作がジャンクの原因になっているかもしれません。
JankStats をさらに詳しく知るためのリソースをいくつか紹介します。
AndroidX プロジェクト : JankStats は、AndroidX の androidx.metrics ライブラリにあります。
ドキュメント : デベロッパー サイトに新しいデベロッパー ガイドがあり、そこで JankStats の使い方が説明されています。
サンプルコード : このプロジェクトにサンプルがあります。JankStats オブジェクトをインスタンス化してリスニングする方法や、重要な UI 状態情報を使ってアプリを計測する方法が示されています。
performance-samples/JankStatsSample at main · android/performance-samples
バグ : ライブラリの問題を見つけた方や、API のリクエストがある方は、バグを送信してください。
JankStats は、最初のアルファ版がリリースされたばかりです。つまり、「私たちはこの API と機能を 1.0 リリースに妥当なものだと考えていますが、ぜひ試してみて感想をお知らせください」という意味です。
今後、JankStats で行いたいと考えていることは他にもあります。たとえば、集計メカニズムのようなものの追加や、既存のアップロード サービスとの同期などです。しかし、基本機能を搭載した最初のバージョンを公開し、皆さんの使い方や要望を確認したいと思いました。現在の基本的な状態でも、十分役に立つことを期待しています。簡単に計測して UI 状態情報を記録できるだけでも、何の機能もないよりはよいはずです。
ぜひこれを入手してお試しください。そして、問題があればお知らせください。いち早くパフォーマンスの問題を見つけて修正しましょう！ユーザーは皆さんを待っています。
.png)
.png)
.png.jpeg)
.png)
.png)
