この記事は 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 ストアの事例から言うと、これ以上すばらしいものはありません！
この記事は Adarsh Fernando による Android Developers Blog の記事 " Android Studio Bumblebee (2021.1.1) Stable " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Studio チームは、Android 公式の IDE とビルドシステムの最新版である Android Studio Bumblebee (2021.1.1) 🐝 と Android Gradle プラグイン (AGP) 7.1.0 の安定版リリースに向けて取り組んできました。一般的なデベロッパー ワークフローの幅広い領域で機能強化をしました。具体的には、ビルドとデプロイ、プロファイリングと検査、そしてデザインです。
注目すべき追加機能をいくつか挙げてみましょう。Android Studio と継続的インテグレーション (CI) サーバー間での統合テストの実行 ✅、ADB over Wi-Fi をサポートするための便利なペア設定フロー 📲、アプリのジャンクを特定して分析する際に役立つプロファイラ ツールの強化 🕵️、アプリをデバイスにデプロイせずにアニメーションをプレビューしたり 🎥 UI インタラクションしたりする新たな方法などです。
今回のリリースも、プレビュー ユーザーの皆さんからの早期フィードバックがなければ実現できなかったはずです。以下では、今回の安定版の主な特長や新機能について紹介します。さっそく自分で試してみたい方は、公式ウェブサイトから Android Studio Bumblebee (2021.1.1) (英語) をダウンロードしてください。
以下では、Android Studio Bumblebee (2021.1.1) のすべての新機能を 3 つの主なテーマにまとめています。
デバイス マネージャ
ADB over Wifi によるデバイスのペア設定
異なるランナーを使うと、結果が一致しない
今回より、Android Studio は Gradle からインストルメンテーション テストを実行
CPU Profiler の詳細なフレーム ライフサイクル情報
<profileable android:shell="true"/>
Background Task Inspector でのジョブ、アラーム、ウェイクロックの検査
Compose プレビューを操作して動作を検証
アニメーション付きベクター型ドローアブルのプレビュー
以下、Android Studio Bumblebee (2021.1.1) に含まれる主な機能拡張と新機能をまとめます。
この記事は Florina Muntenescu による Android Developers Blog の記事 " Jetpack Compose 1.1 is now stable! " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは、Android の最新ネイティブ UI ツールキット、Jetpack Compose のロードマップを実現する作業を続けており、2022 年 2 月 9 日にバージョン 1.1 をリリースしました。今回のリリースには、フォーカス処理の向上、タッチ ターゲットのサイズ調整、ImageVector のキャッシュ、Android 12 のストレッチ オーバースクロールのサポートなどの新機能が含まれています。さらに、Compose 1.1 では、これまで試験運用版だったたくさんの API が安定版になっているほか、より新しいバージョンの Kotlin もサポートされています。すでにサンプル、Codelab、Accompanist ライブラリもアップデートしており、Compose 1.1 と合わせて利用できるようになっています。
Compose 1.1 に ImageVector のキャッシュ機能を導入し、パフォーマンスを大幅に向上させています。painterResource API にキャッシュ機構を追加しており、解析した ImageVector のすべてのインスタンスを、与えられたリソース ID やテーマと合わせてキャッシュできるようになっています。このキャッシュは、構成が変わると無効になります。
Compose 1.0 と比較した場合、マテリアル コンポーネントのレイアウトでは、マテリアルのアクセシビリティ ガイドライン（英語）に記載されているタッチ ターゲット サイズ（英語）を満たすようにレイアウト領域が拡大されます。たとえば、RadioButton のタッチ ターゲットは、最小サイズの 48x48 dp に拡大されます。RadioButton のサイズをそれ以下に設定した場合も同様です。これにより、Compose のマテリアルとマテリアル デザイン コンポーネントの動作が一致し、ビューと Compose が共存しても、動作の一貫性が保たれます。また、この変更により、Compose のマテリアル コンポーネントを使って UI を作成すれば、タッチ ターゲットのアクセシビリティ最低要件が確実に満たされるようになります。
この変更によって既存のレイアウト ロジックが壊れる場合は、LocalMinimumTouchTargetEnforcement (英語) を false に設定することで、この動作を無効化できます。ただし、アプリのユーザビリティが低下する可能性があることを認識したうえで、慎重に利用するようにしてください。
RadioButton のタッチ ターゲットの更新
左 : Compose 1.0、右 : Compose 1.1
いくつかの API が試験運用版から安定版になっています。主なものを紹介します。 (以下、リンク先はすべて英語)
Compose に新機能を導入する作業も続いています。いくつかの主な機能を紹介します。
@OptIn (英語) を使うと、新しい API を試すことができます。ぜひフィードバックをお願いします！
注 : Compose 1.1 を使うには、Kotlin 1.6.10 が必要です。詳しくは、Compose と Kotlin の互換性マップをご覧ください。
次に登場するのは何でしょうか。現在検討中または作業中の機能は、更新版のロードマップで確認できます。たとえば、遅延項目アニメーション、ダウンロード可能フォント、移動可能コンテンツなどです。
Jetpack Compose は安定版で、本番環境で利用できます。また、要望が寄せられた機能を追加する作業も続いています。すでに多くのアプリで Jetpack Compose が本番環境として使われ始めているのを見て、とてもうれしく思っています。皆さんが開発したアプリを見るのが、待ち遠しくてたまりません。
アルファ版やベータ版を通して Issue Tracker (英語) にバグレポートや機能リクエストをお送りいただき、大変感謝しています。Compose の改善や、皆さんに必要な API を作るうえで役立っています。Compose をよりよいものにするために、今後もフィードバックをお願いします！
Compose をお楽しみください！
この記事は Dave Burke による Android Developers Blog の記事 " 12L and new Android APIs and tools for large screens " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
タブレット、折りたたみ式デバイス、ChromeOS デバイスを合わせると、2 億 5000 万台を超える大画面デバイスが Android を実行しています。ここ 12 か月だけでも、1 億台近くの新しい Android タブレットがアクティベートされました。これは前年比 20% の増加です。現在最も成長が著しいデスクトップ プラットフォームである ChromeOS は、92% の増加率となっていますが、さらに、折りたたみ式デバイスも急増中で、前年比 265% 以上の成長を遂げています。すべて合わせれば、Android が動作しているアクティブな大画面デバイスは 2 億 5000 万台を超えます。その勢いを受けて、このようなデバイスで動作している Android を、ユーザーにとってもデベロッパーにとってもよりよい OS にするために、私たちは努力を続けています。
そこで 2021 年 10 月 27 日 (日本時間:10 月 28 日) の Android Dev Summit (英語、動画は日本語字幕あり) では、大画面に特化した Android 12 のフィーチャー ドロップについてお知らせしました。私たちはこれを 12L と呼んでいます。併せて、大画面向けの開発を容易にするための新 API や新ツール、ガイダンスも準備しています。さらに、Google Play で行っている変更についてもお話ししました。これにより、ユーザーは大画面に最適化されたアプリをこれまで以上に簡単に見つけられるようになります。ここでは、Android の大画面向け新機能について紹介しますので、ぜひお読みください。
先月、12L のデベロッパー プレビュー を提供しました。これは今後公開する予定のフィーチャー ドロップで、Android 12 を大画面でさらに快適に使えるようにするものです。このプレビューを使って、大画面関連の新機能を試したり、自分のアプリを最適化したり、フィードバックの送信が可能です。
12L では、通知、クイック設定、ロック画面、概要、ホーム画面など、大画面向けの UI 全般を改善しました。たとえば、画面領域を有効活用するため、600dp を超える画面では、通知シェードやロック画面、その他のシステム表示を新しい 2 列レイアウトで表示します。システムアプリも最適化されます。
2 列レイアウトによって表示できる内容が増加し、さらに使いやすいものに
また、マルチタスクをこれまで以上に強力で直感的なものにしました。12L では大画面で新しいタスクバーが搭載されるので、ユーザーはすぐにお気に入りのアプリに切り替えることができます。このタスクバーのおかげで、分割画面モードもこれまで以上にわかりやすくなり、タスクバーからドラッグ＆ドロップするだけで、アプリを分割画面モードで実行できるようになります。また、Android 12 以降で分割画面モードの操作性を向上させるため、アプリがサイズ変更可能かどうかにかかわらず、すべてのアプリを自動的に分割画面モードに対応させます。
アプリをドラッグ＆ドロップして分割画面モードで実行
さらに、互換性モードを改善して見た目と安定性を向上させ、レターボックス表示の快適さを向上させたほか、アプリのデフォルトでの外観も改善しました。レターボックス表示は、デバイス メーカーが簡単にカスタマイズできるようになっているので、カスタムの色や処理を設定したり、はめ込むウィンドウの位置を調整したり、カスタムの角丸を適用したりできるようになっています。
Android 12 のタブレットや折りたたみ式デバイスが次にまとまって登場するタイミングに間に合うように、12L のフィーチャー ドロップは来年の早い時期にリリースする計画です。以上のような機能を大画面デバイスに導入するため、私たちは既に OEM パートナーと協力して作業を進めています。近日中に 12L のデベロッパー プレビューが Lenovo P12 Pro (日本未発表) に搭載される予定なので、ご期待ください。数か月後には、この機能がデバイスに配信されます。今から大画面向けに最適化したアプリの準備を入念にしておきましょう。
デベロッパーの皆さんには、さまざまなサイズのウィンドウの分割画面モードでアプリがどのように動作するかを確かめておくことを強くお勧めします。まだアプリを最適化していない方は、画面の向きを変えたときにどう見えるかを確認し、新しい互換性モードの変更が適用される場合はそれを試してみましょう。12L には、大画面向け機能のほかにも、いくつかのデベロッパー向けの新 API や、新しい API レベルが含まれています。アプリに互換性を破る変更が起こらないように注意しているので、アプリのターゲットを 12L にしなくても Google Play 要件を満たすことができます。
12L を使ってみたい方は、Android Studio の最新プレビュー リリースから、12L Android Emulator のシステム イメージやツールをダウンロードしてください。機能と変更点を確認してアプリをテストする領域を判断し、プレビューの概要でスケジュールやリリースの詳細をご確認ください。問題やリクエストはこちらから報告できます。そしていつものように、フィードバックは大歓迎です。
12L はスマートフォンでも利用できますが、ほとんどの新機能は小さな画面では確認できません。現在、私たちはタブレット、折りたたみ式デバイス、ChromeOS デバイスに重点的に対応しています。今後のプレビューでは、Pixel デバイス向けに Android ベータ版への登録をオープンする予定です。詳しくは、developer.android.com/12L をご覧ください。
どんな画面にも適応する完全にアダプティブなアプリを作り始める時です。そして、それを今まで以上に簡単に実現できるようにしています。OS や Play でアプリの変更に対応できるように、デベロッパー プレビューと併せて API やツール、ガイダンスのアップデートを公開します。
アダプティブ UI をサポートするための第一歩は、小さな画面と大きな画面の両方でうまく動作するアプリを設計することです。私たちは、アプリの UI をあらゆる画面サイズに対応させる際に役立ててもらうため、新しいマテリアル デザインのガイダンス (英語) の作成を進めてきました。このガイダンスは、エコシステムでよく使われている一般的なレイアウト パターンをカバーしているので、さまざまなアイデアが得られるだけでなく、作業を加速することにもつながるはずです。
マテリアル デザインのガイドライン、アダプティブ UI パターン
最高のナビゲーション エクスペリエンスをユーザーに提供するには、ユーザーが使うデバイスのウィンドウ サイズ クラスに合わせたナビゲーション UI を提供する必要があります。私たちが推奨するナビゲーション パターンには、コンパクトな画面（compact）ではナビゲーション バー (英語) を使う、中程度（medium）以上の画面幅（600dp 以上）のデバイスクラスではナビゲーション レール (英語) を使う、などがあります。新たに公開したマテリアル デザインのガイダンス (英語) には、広い画面幅（expanded）のデバイス向けに、いくつかの大画面レイアウトのアイデアが掲載されています。たとえば、SlidingPaneLayout を使って実装できるリスト / 詳細構造などです。ガイダンスを参照して、ビューと Compose でアダプティブ UI 向けのナビゲーションを実装する方法をご確認ください。
フラグメントを使っている既存アプリに大画面に最適なレイアウトを適用する場合、ナビゲーション パターンを更新して SlidingPaneLayout を使うのはすばらしい方法です。しかし、多くの皆さんが複数のアクティビティに基づいたアプリを作っていることは承知しています。そういったアプリでは、Jetpack WindowManager 1.0 ベータ版 03 で新しくリリースしたアクティビティ埋め込み API を使うと、TwoPane ビューなどの新しい UI パラダイムに簡単に対応できます。現在、SlidingPaneLayout をアップデートしてこの API をサポートする作業を進めています。今後数か月間のアップデートに注目してください。
Jetpack Compose を使うと、大画面や多様なレイアウトを対象にした開発が楽になります。Compose の採用を始めているなら、大画面向けの最適化を行う絶好のチャンスです。
Compose は宣言型 UI ツールキットです。すべての UI をコードで記述するので、UI が利用できるサイズにどう適応すべきかを実行時に判断するのは簡単です。Compose がアダプティブ UI の開発に特に向いているのはそのためで、画面サイズやコンポーネントの違いによる UI の変更にとても簡単に対処できます。Compose でアダプティブ レイアウトを構築するためのガイドでは、知っておくべき基本的な事項について説明しています。
Jetpack WindowManager ライブラリを使うと、下位互換性のある形でアプリのウィンドウを操作し、すべてのデバイスを対象としたレスポンシブな UI を開発できます。新機能は以下のとおりです。
アクティビティを埋め込むと、たとえばリスト / 詳細パターンなど、複数のアクティビティを一度に表示することで、大画面で利用できるようになる広い表示領域を有効活用できます。その際、アプリのリファクタリングはほとんど、あるいはまったく必要ありません。並べるか重ねるかなど、アプリにどのようにアクティビティを表示するかは、皆さんが決定します。具体的には、XML 構成ファイルを作成するか、Jetpack WindowManager API を呼び出します。あとはシステムが対応して、作成した構成に基づいて表示方法を決めてくれます。
アクティビティの埋め込みは、折りたたみ式デバイスでもシームレスに動作します。デバイスを折りたたんだり広げたりすると、それに応じてアクティビティが重なったり並んだりします。アプリで複数のアクティビティを使っている方は、アクティビティの埋め込みを使って大画面デバイスでのユーザー エクスペリエンスを向上させることができます。アクティビティ埋め込み API は、Jetpack WindowManager 1.0 ベータ版 03 以降のリリースで試すことができます。詳しくはこちらをご覧ください。
Jetpack WindowManager でアクティビティを埋め込む
ウィンドウ サイズ クラスは、綿密に検討されたビューポートの一連のブレークポイントで、サイズ変更可能なアプリでのレイアウトの設計、開発、テストに利用できます。ウィンドウ サイズ クラスのブレークポイントは、compact（コンパクト）、medium（中程度）、expanded（広い）の 3 つのカテゴリに分かれています。これらは、エコシステムのデバイスの大部分を表しつつ、レイアウトのシンプルさと特異なユースケースにアプリを最適化できる柔軟性との間でバランスをとるように設計されています。WindowSizeClass API は、近日中に Jetpack WindowManager 1.1 で公開される予定です。これにより、レスポンシブ UI の構築がさらに簡単になります。詳しくはこちらをご覧ください。
Jetpack WindowManager のウィンドウ サイズ クラス
WindowManager では、折り目やヒンジなど、さまざまなウィンドウ形状に対応した一般的な API サーフェスも提供されます。折りたたみ対応のアプリでは、折り目やヒンジの部分を避けてウィンドウのコンテンツを表示したり、折り目やヒンジの部分を自然なセパレータとしてうまく活用したりできます。アプリを折りたたみ対応にする方法は、こちらのガイドをご覧ください。
Android アプリは、あらゆるデバイス、そしてあらゆるカテゴリに適応できるように構築すべきです。そこで、Android Studio 全体を対象として、UI やレイアウトの設計、開発、テストを行うたくさんのツールに、リファレンス デバイスを導入します。リファレンス デバイスは 4 つあり、それぞれスマートフォン、大型折りたたみ式デバイスの内側ディスプレイ、タブレット、デスクトップを表します。マーケットのデータを分析して設計したもので、人気のデバイスや急成長中のセグメントを表しています。また、リファレンス デバイスを規定したことで、新しい WindowSizeClass のブレークポイントを使ってアプリがさまざまなよくあるブレークポイントの組み合わせに対応して動作することを確認できるようになります。そのため、アプリができる限り多くのユースケースをカバーすることを保証できます。
リファレンス デバイスの定義
大画面向け UI の対応を始める際に、どこから手を付けてよいかわからない方もいらっしゃるかもしれません。その場合は、まず新しいツールを使って、大画面デバイスで起こりうる問題を確認しましょう。Android Studio Chipmunk では、レイアウト検証によって先回りで UI について警告や提案を行ってくれる新しいビジュアル lint チェックツールを開発しています。どのリファレンス デバイスが影響を受けるかもわかるようになっています。
リファレンス デバイスの各クラスが表示されたレイアウト検証ツール
ランタイムでアプリをテストする場合、Android Studio Chipmunk (英語) に搭載されているサイズ変更可能な新しいエミュレータ構成を使うことができます。サイズ変更可能なエミュレータを使うと、4 つのリファレンス デバイス（スマートフォン、折りたたみ式、タブレット、デスクトップ）をすばやく切り替えることができます。これにより、設計時にレイアウトを検証したり、ランタイムで動作をテストしたりする操作が簡単になります。どちらの作業にも、同じリファレンス デバイスを使うことができます。サイズ変更可能なエミュレータを新規作成するには、Android Studio の Device Manager を使って新しい仮想デバイスを作成し、Resizable デバイス定義と Android 12L（Sv2）システム イメージを選択します。
サイズ変更可能な Android Emulator
タブレット、折りたたみ式、ChromeOS の各デバイスに最適なアプリを簡単に探せるようにするため、ユーザーのデバイスに最も適したアプリを目立たせるように Play を変更します。
現在、それぞれのアプリの品質を大画面アプリ品質ガイドライン (英語) に照らして評価する新たなチェックを追加する作業を行っています。これにより、デバイスに最適なアプリが目立つようになります。Play ストアで大画面のユーザーが大画面に最適化されていないアプリを表示した場合、そのアプリのストア掲載情報ページに通知を表示する予定です。
加えて、既にお知らせしたように、アプリの評価にも大画面専用の評価を導入し、大画面デバイスでアプリがどう動作するかをユーザーが評価できるようにします。以上の変更は来年に実施する予定です。皆さんがアプリの準備を始められるように、あらかじめお知らせいたしました。
また、Google Play で Google のビジネスモデルを進化させてデベロッパーのニーズに応えるための取り組みを紹介した記事も忘れずに確認しておきましょう。
大画面や折りたたみ式デバイス向けの開発を始めるうえで役立てていただけるように、私たちはビューにも Compose にも対応します。新規アプリや既存アプリで異なる画面サイズをサポートする方法、ビューと Compose の両方でナビゲーションを実装する方法、折りたたみ式デバイスのメリットを活用する方法などを紹介したガイダンスの追加や改訂も行っています。ビューのサポートの大画面ガイドのセクション、または Compose ガイドのセクションをご覧ください。
コードほど雄弁なものはありません。以下のサンプルは、レスポンシブ UI に対応するように更新しています。
実践的な演習を行いたい方は、Codelab で、アップデートされた Jetpack WindowManager による折りたたみ式デバイスとデュアル スクリーン デバイスのサポートをご覧ください。
Reviewed by Tamao Imura - Developer Marketing Manager, Google Play
2021 年 10 月 18 日に開催された、『DroidKaigi 前夜祭』に Google 関係者がパネリストとして登壇しました。
このイベントでは、2021 年に発表した Android/Google Play 関連の製品のお話や、I/O 以降に発表された製品・技術関連の最新情報についての内容を中心に Google 関係者が解説をしました。
この記事では、イベント内で解説した内容をまとめます。
Jetpack Compose は、ネイティブ UI をビルドするための Android の最新ツールキットで、Kotlin API を使用して、少ないコードで Android の UI 開発を簡素化し、加速することができます。Google I/O では、株式会社メルカリ様のケーススタディもリリースされ、UI 開発の生産性が 56 ％ 向上したという実例もございます。今回のイベントでは、その Jetpack Compose の最新アップデートである、1.1.0 についてお話をさせていただきました。
このセッションでは、Android IDE Android Studio (英語) の Android Gradle Plugin API (AGP) (英語) や Test framework についてについてお話をさせていただきました。公式の強力な Android IDE Android Studio Arctic Fox (2020.3.1) ベータ版 を I/O で発表したあと、7 月に安定版をリリースしました。UI 設計期間の短縮、新しいデバイスへのアプリ拡張、デベロッパーの生産性向上を目的としており、Compose と合わせて使うことで、最新の UI をすばやくデザインすることができます。
このセッションでは、Google Play と Multi Form Factor についてお話をさせていただきました。
Wear OS や大画面対応から、セキュリティ ツールなどのトピックまで幅広くカバーしました。
ご参加いただきました皆さん、ありがとうございました！Android Developer Summit の動画も、ぜひご視聴ください。
この記事は Wayne Lu による Android Developers Blog の記事 " Answering your top questions on Android Game Development Kit " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 7 月に Android Game Development Kit（AGDK） (英語) をリリースしてから、デベロッパーの皆さんよりお寄せいただいた主な質問をまとめました。その内容は、AGDK のライブラリやツールから、Android のメモリ最適化、グラフィックスの実装に関することまで、さまざまです。
まず、新進気鋭のゲーム デベロッパーから寄せられた、AGDK の一連のライブラリやツールの使い方に関する質問です。セットアップに応じて、以下の事項を推奨しています。
ご自身の環境に合致したゲームエンジンとワークフローに沿って、ゲーム内で利用する CPU、メモリ、ネットワーク、バッテリーなどの状況を詳細に調査する Android Studio Profiler、グラフィックスに特化してプロファイリングを行う Android GPU Inspector(英語)、フレームレートや読み込み時間を端末毎に最適化する Android Performance Tuner (英語) などの各種ツールを確認しましょう。
続いて、Android 12 での開発に関する質問も寄せられています。Android 12 でゲームを実行するにあたって、特別なことは何も必要ありません。しかし、プレイヤーがゲーム体験をカスタマイズできるように、Game Mode API と Interventions (英語) を導入していきましょう。
2 つ目は、Android と Windows のゲーム開発におけるメモリアクセスの動作の違いについての質問です。以下に、いくつかのヒントをまとめます。
3 つ目は、Android でのグラフィックスの実装に関する質問です。選択肢には、OpenGL ES と Vulkan グラフィックス API があります。
AGDK に関する主な質問は、Q&A 動画でも確認できます。また、Android ゲーム開発の最新リソースには、g.co/android/AGDK (英語) からアクセスできます。
Reviewed by Maru Maruyama - Developer Relations Engineer
この記事は Jacob Lehrbaum による Android Developers Blog の記事 " Working Towards Android App Excellence " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
すばらしいアプリ体験は、ビジネスにもすばらしい成果をもたらします。実際、Google Play に5 つ星の評価を残した Android アプリユーザーの約 3 分の 1 が、アプリ体験の質*1つまり、スピードやデザイン、ユーザビリティに触れています。Google では、すべてのデベロッパーが優れたアプリの開発を実現し、ユーザーの獲得、維持、収益化を果たせるようなサポートを提供したいと考えています。
では、「優れたアプリ」とは何でしょうか。これは遠い目標のように聞こえるかもしれませんが、多くのアプリでも手が届くところにあります。その第一歩となるのは、ユーザーにフォーカスし続けることです。具体的には、直感的なユーザー エクスペリエンスでアプリの主要機能にできる限り早く到達できるようにすることです。しかし、これはまだ始まりに過ぎません。優れたアプリにはすべての画面や操作に一貫性があり、使うデバイスによらず快適に動作します。アプリ開発に携わっているあらゆるメンバーがアプリ体験に集中すれば、優れたアプリの開発が実現できます。
優れたアプリの開発を阻むものの 1 つが、曖昧で不明確な責任分担です。クラッシュや読み込み時間など、アプリの質を測る主な指標の中には、エンジニアリング チームなどの社内の 1 グループの責任であると見なされるものがあります。しかし、業界のトップクラスの組織の方々にどのようにして優れたアプリの開発を実現しているか聞いたところ、*2エンジニアリング、デザイン、プロダクト、ビジネスの各チームが共通の目的に向かって連携する、部門間の協力的なアプローチが重要であることが明確になりました。
では、優れたアプリ開発のための裏側にある内部的なベスト プラクティスはどのようなものでしょうか。
ビジネス側の立場に立って「競合他社のアプリは私たちのアプリよりも速いので、読み込み時間を 5 秒から 4 秒に短縮する必要がある」と私から言えるので会話がよりスムーズです。クロス プラットフォーム アプリのソフトウェア エンジニア
ビジネス側の立場に立って「競合他社のアプリは私たちのアプリよりも速いので、読み込み時間を 5 秒から 4 秒に短縮する必要がある」と私から言えるので会話がよりスムーズです。
クロス プラットフォーム アプリのソフトウェア エンジニア
優れたアプリは、ビジネスの成果につながります。新機能の追加はすばらしいことですが、それでアプリの起動時間が遅くなったり、デバイスの容量を使いすぎたりすると、アプリの使用頻度が減り、やがて削除される結果をうみます。多くの場合、エンジニアは品質問題がビジネスの成果に与える影響を定量化することで、全社的に品質を重視する体制を構築しています。具体的には、次の方法で定量化しています。
機能（ユーザー ジャーニーの各ステージ）を担当するチームを編成している企業は、サポートするそれぞれのオペレーティング システム全体で一貫した操作を提供し、新しいアプリや機能を市場に投入するまでの時間が短くなり、すべてのお客様に優れたアプリ体験を提供できる可能性が高くなります。多くの場合、このようなチームは、エンジニア、マーケティング、UX、プロダクトなどの機能を横断するグループです。そして、あらゆるデバイスやプラットフォームで、機能やユーザー ジャーニーのステージ*3を成功させる責任を担います。この構造により、優れた体験や機能レベルが実現できるだけでなく、機能領域を超えた統一目標ができます。また、縦割りを減らして、特定の目標に集中的に対処することにもつながります。
ビジネス目標を重視するチーム構成により、ユーザーに対するフォーカスが高まる
ユーザーの大半が特定の種類のデバイスを使っている場合、主なデバイスとして同じスマートフォンやタブレット、スマートウォッチを使えば、ユーザーがどのような体験をしているか理解が深まるでしょう。特にこれが当てはまるのは、多くユーザーの日々の体験に影響を与える意思決定が求められる組織の経営幹部です。たとえば、Duolingo はこれを自社の DNA に組み込んでいます。ユーザー ベースの大部分と同様の環境を作り出すために、CEO も含む、すべての Duolingo の社員は、エントリーレベルの Android デバイスのみを使っているか、あるいは使える状態にあります。
ビジネスを成長させるうえで、品質および優れたアプリの開発に対するユーザー中心のアプローチは欠かせません。優れたアプリの開発を実現する方法を詳しく学びたい方は、実用的なヒントを含むケーススタディをご覧ください。また、Android App Excellence (英語) のページにアクセスし、ぜひ App Excellence Summit に参加してください。（事前登録制です）
今後のブログ投稿では、優れたアプリの開発を実現する 2 つの要素について詳しく取り上げる予定です。具体的には、アプリ パフォーマンスとそれによるユーザー行動への影響、そして複数のデバイス間のシームレスなユーザー エクスペリエンスの開発です。こちらのページから Android デベロッパー向け ニュースレターに登録すると、次号の発行時に通知が届き、Android チームからの最新ニュースや知見を得られますので、ぜひご登録ください。
注
1. 2021 年の Google Play 内部データ
2. 2021 年の Google App Quality Research
3. アプリを使ううえで、それぞれのユーザーが体験する一連の手順を「ユーザー ジャーニー」と呼びます。ユーザー ジャーニーのステージの例として、インストール、オンボーディング、エンゲージメント、リテンションなどがあります
この記事は Amanda Alexander による Android Developers Blog の記事 " Android Studio Arctic Fox (2020.3.1) Stable " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Studio Arctic Fox が、安定版リリース チャンネルでダウンロードできるようになったことをお知らせします。この最新リリースでは、Android の新しいネイティブ UI 構築ツールキットである Jetpack Compose 1.0 を利用できます。さらに、Wear OS を含むデバイスにも注力し、新しい Background Task Manager などのデベロッパーの生産性を高める機能も搭載されています。皆さんのフィードバックをもとに開発されたこの新しい Android Studio 機能のスイートは、デベロッパー コミュニティがさまざまなデバイスで動作する質の高い最先端のアプリを迅速に作るために役立つことができれば幸いです。
注 : 昨年発表した通り、Android Studio のバージョン番号体系を Android Studio のベースになっている IntelliJ IDEA の年とバージョンに一致させ、そこに独自のパッチ番号を付加するように変更しました。今後はコードネーム（アルファベット順）を利用します。最初は Arctic Fox で、次は Bumblebee（現在カナリー版）です。Android Studio Arctic Fox（2020.3.1）では、Android Studio が IntelliJ プラットフォームのバージョン 2020.3 にアップデートされます。これには、デバッガ インタラクティブ ヒント、VCS のアップデート、いくつかの新しいコードエディタの強化など、ワークフローを高速化するたくさんの新機能が含まれています。詳細はこちらをご覧ください。（英語）
最新 UI をすばやくデザインできるように、Jetpack Compose 用の追加機能も搭載しています。Compose プレビューを使うと、Compose UI の複数のコンポーネントのプレビューを作成し、さまざまな要素（テーマ、画面、フォントサイズなど）にわたって変更の影響を即座に確認できます。デバイスへのデプロイ プレビュー機能では、Compose コードのスニペットを直接デバイスやエミュレータにデプロイし、小さなコードをすばやくテストできます。レイアウトを詳しく調べたい場合は、Layout Inspector に追加された Compose サポートを使って、レイアウトがどのようにレンダリングされるかを理解できます。さらに、リテラルのリアルタイム編集を追加しました。エミュレータや実機でアプリを動作させるときに、コンパイルを行うことなく、プレビューで Compose コードの変更を即座に確認できます。
サポート対象のデバイスを増やすため、新しい Wear OS ペア設定アシスタントを構築し、Wear OS エミュレータと物理スマートフォン、仮想スマートフォンとのペア設定を簡単に行えるようにしました。Wear OS の最新バージョンを使うには、Wear OS 3 システム イメージのデベロッパー プレビューをご利用ください。Wear OS エミュレータを実行すれば、心拍数センサー API のサポートが追加されていることにも気づくはずです。Google TV をターゲットにするアプリのために、最新の Google TV リモート コントロール機能を追加し、Google TV システム イメージをアップデートして最新の UI デザインを反映しました。さらに、Automotive OS で、運転に関するユースケースをシミュレーションするため、エミュレータで自動車センサーデータを利用できるようにして開発とテストのワークフローを完成させました。タブレットをターゲットにするアプリのために、すぐに横向きをサポートできるようにすべてのテンプレートを更新しました。開発のターゲットとなるデバイス画面の大小にかかわらず、新たな方法の導入とアプリの構築を継続するうえで役立つ新機能が含まれています。
最後に、デベロッパーの皆さんの生産性を向上させるために、作業の効率化に役立つ機能の追加についてご紹介します。たとえば、次期バージョンの Android アプリを構築する際のガイドとして、Android 12 向けの lint チェックを追加しました。コードのテストに役立ててもらうため、Layout Editor に Accessibility Scanner を追加し、レイアウトのユーザー補助に関する問題を簡単に見つけられるようにしました。また、新しいテスト マトリックスを使うと、複数のデバイスで並列実行されるテスト結果をリアルタイムに確認できます。さらに、Apple Silicon（arm64）ハードウェアのプレビュー サポートを追加し、幅広いテストをサポートできるようにエミュレータのコントロールを拡張しました。加えて、デバッグ用の新しい Background Task Inspector を使うと、アプリのバックグラウンド ワーカーを分析できます。
Android Studio Arctic Fox には、たくさんの機能強化が含まれています。すべての変更点のリストを確認したい方は、Android Studio Arctic Fox（2020.3.1）Beta リリースブログとリリースノートをご覧ください。以下では、主な変更点について紹介します。
Android Studio Arctic Fox の新機能
@Preview アノテーションを使うと、Compose コードのプレビューを生成して複数のコンポーネント（デバイス、テーマなど）をさまざまな構成で表示できます。Compose プレビューを活用すれば、コードで Composable のメンタル マッピングを簡単に作成できます。
Compose プレビュー
すべて Compose で書かれたアプリでも、Compose とビューを併用したアプリでも、Layout Inspector を使えばレイアウトの詳細を確認したり、トラブルシューティングを行ったりできます。たとえば、各 Composable に渡されたパラメータや修飾子を確認できます。アプリを開発する際に、ライブ アップデートを有効にしてデバイスからデータをストリーミングすることもできます。
Compose Layout Inspector
リテラル（文字列、数値、ブール値など）をインラインで編集すると、コンパイルしなおすことなく、変更の結果を画面（プレビュー、エミュレータ、実機）ですぐに確認できます。
リテラルのライブ編集 : 文字列を編集するとプレビューに即時反映
新しい Wear OS ペア設定アシスタントは、順を追ってペア設定プロセスを案内してくれるので、Wear OS エミュレータと仮想または物理スマートフォンのペア設定が簡単になります。なお、この機能は、Wear OS 2 コンパニオンとのペア設定をサポートします。Wear OS 3 は近日中にサポートされる予定です。詳細はこちらをご覧ください。
Wear OS エミュレータ ペア設定アシスタント ダイアログ
スマートフォン + スマートウォッチ エミュレータのペア設定が成功した状態
API レベル 26 以上を実行しているデバイスで WorkManager ライブラリ 2.5.0 以上を使っている場合、新しい Background Task Inspector を使ってアプリのバックグラウンド ワーカーを視覚化、監視、デバッグできます。メニューバーから [View] > [Tool Windows] > [App Inspection] を選択してアクセスできます。詳細はこちらをご覧ください。
Background Task Inspector
まとめると、Android Studio Arctic Fox（2020.3.1）安定版には、以下の機能強化と新機能が含まれています。
詳細は、Android Studio のリリースノート、Android Gradle プラグインのリリースノート、Android Emulator のリリースノートをご覧ください。
最新バージョンの Android Studio Arctic Fox はダウンロード ページ（英語）から、Apple Silicon プレビュー ビルドはこちら（英語）からダウンロードできます。Android Studio の以前のリリースをお使いの方は、最新バージョンの Android Studio にアップデートするだけで利用できます。Android Studio の安定バージョンを保持する必要がある場合、Android Studio Arctic Fox の安定リリース バージョンとカナリー リリース バージョンを同時に実行することができます。詳細はこちらをご覧ください。
気に入った点、問題点、新機能の提案などのフィードバックをお寄せください。バグや問題が見つかった場合は、バグを報告してください。Android Studio 開発チームの Twitter と Medium もぜひフォローしてください。
この記事は Anna-Chiara Bellini, Nick Butcher による Android Developers Blog の記事 " Jetpack Compose is now 1.0: announcing Android’s modern toolkit for building native UI " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 7 月 28 日（日本時間 7 月 29 日) Jetpack Compose のバージョン 1.0 をリリースしました。Android の最新ネイティブ UI ツールキットである Jetpack Compose を使うと、優れたアプリを短時間で構築できます。このリリースは安定版で、本番環境で利用できます。Compose は、この 2 年間、Android コミュニティのフィードバックや貢献を受けつつ、オープンに開発が行われてきました。1.0 に到達した現時点で、既に Google Play ストアの 2000 以上のアプリで Compose が使われています。実は、Play ストアアプリ自体にも Compose が使われています。それだけではありません。たくさんのトップ アプリ デベロッパーと協力し、フィードバックやサポートを受けることで、1.0 リリースはさらに強固なものになっています。たとえば、Square は Compose を使うことで「宣言型 UI フレームワークの構築に関するさまざまな問題を解決することではなく、Square 独自の部分や UI インフラストラクチャに集中できる」と教えてくれました。Monzo は、Compose を使うと「質の高い画面を短時間で構築できる」と述べています。また、Twitter は「とても気に入っています！❤️」と見事に一言で言い表しています。
Compose は、ネイティブ Android アプリを短時間で簡単に作成できるように設計されています。完全に宣言的なアプローチが採用されているので、UI を記述しさえすれば、あとは Compose が対応してくれます。アプリの状態が変わると、UI が自動的に更新されるので、UI の構築がはるかにシンプルかつ高速になります。直感的な Kotlin API を使うと、美しいアプリを はるかに 少ないコードで実現できます。また、すべての既存の Android コードにネイティブでアクセスできるので、自分のペースで導入することもできます。強力なレイアウト API とコード駆動型 UI により、タブレットや折りたたみ式デバイスなど、異なるフォーム ファクタのサポートも簡単です。Compose のサポートは、Wear OS や ホーム画面 ウィジェットなども追加される予定です。
今回の 1.0 リリースは本番環境で利用でき、以下の主要機能が提供されています。
完全な宣言型アプローチを採用している Jetpack Compose によって、UI の開発方法は大きく変わります。新しいワークフローと異なる考え方をサポートするため、Compose 向けに設計された新しいツールを提供します。また、いくつかの既存のツールに Compose のサポートを追加しています。
Android Studio Arctic Fox で利用できる新しい Compose プレビューでは、異なる状態、ライトテーマやダークテーマ、異なるフォント スケーリングのコンポーザブルをすべて同時に確認できます。アプリ全体をデバイスにデプロイする必要はないので、コンポーネントの開発が簡単になります。リテラルのライブ編集機能によって機能強化されているため、プロジェクトを再コンパイルせずにアップデートを確認できます。
作業中の画面まで移動せずにデバイスで UI のパーツをテストしたいと思っていた方なら、新しいデプロイ プレビューを気に入ってくれるはずです。Composable のプレビューを作成するだけで、デバイスにデプロイしてすばやく反復できます。
Layout Inspector に Composable サポートが追加されるため、Compose と既存のビューを確実に混在させることができます。
Android Studio Arctic Fox での Compose サポートの詳細については、こちらをご覧ください。
新しいフレームワークを採用するには、評価が必要です。新しい UI ツールキットのように広範囲にわたるものでは、特にそれが重要になります。皆さんにとって今が適切なタイミングかどうかを情報に基づいて判断できるように、パブリック ロードマップ (英語) を公開して今後の Jetpack Compose の開発計画をお知らせします。
Compose を活用していただくために、皆さんや皆さんのチームが利用できる幅広いリソースを準備しました。
学ぶべきことはたくさんあります。Jetpack Compose Pathway (英語) では、主要な コードラボ、動画、ドキュメントを順番に体験できます。
Jetpack Compose は大きな飛躍であり、すばらしい UI を短時間で簡単に作れるものだと確信しています。これを使って皆さんが作るものを見ることが楽しみでなりません。Compose が 1.0 の安定版になった今こそ、実際に使うべきときです。直接コードを触るのが最善の方法です。ぜひ Compose を使ってみてください！
