Google は Android 初級者と中級者向けに、コミュニティと一緒に学ぶ無料のオンライン プログラム「Compose Camp」を 2022 年 10 月 4 日（火）から 12 月 30 日（金）の期間中に開催します。
本プログラムではオンライン学習ツール Pathways を用いて、コミュニティで一緒に学ぶ、無料のオンライン プログラムです。今回は初級者向けと中級者向けの 2 トラックよりお選びいただけます。
① 初級者向け : Compose を用いた Android アプリ開発
Android アプリ作成の新しい UI ツールキットである Jetpack Compose を使用して Android アプリを作成するための基礎を学びます。コースを通してさまざまなアプリを開発し、Android デベロッパーになるための一歩を踏み出しましょう。
② 中級者向け : Android デベロッパー向けの Jetpack Compose
Jetpack Compose を使用して Android のネイティブ UI を作成する方法を学習します。Compose が、少ないコード、パワフルなツール、直感的な Kotlin API を使用して、Android での UI 開発を簡素化し、加速する方法を確認します。
プログラム期間 : 10 月 4 日（火） ～ 12 月 30 日 （金）
対象 :
費用 : 無料
実施方法 : オンライン
参加特典 : 本プログラムに登録しプログラムを修了した参加者には、Android 限定グッズをプレゼントいたします。
1 人ではなかなか思うように勉強が進まない方を支援することを目的とした、勉強会を開催するコミュニティを募集します。コミュニティが主催する勉強会に参加することで、1 人では解決しなかった課題などを解決しましょう。
コミュニティ主催の勉強会の情報は随時こちらのブログで更新していきます。また主催者となって勉強会を開催してくださるコミュにティのオーガナイザーの方には Google からの支援をおこないますので、こちらのフォームから申し込んでください。
皆様の参加をお待ちしております。
Google は Android 初級者向けに、コミュニティと一緒に学ぶ無料のオンライン プログラム「Android Study Jam」を 2022 年 7 月 19 日（火）から 8 月 19 日（金）の期間中に開催します。
本プログラムではオンライン学習ツール Pathways 上にあるネイティブ Android UI を開発するための最新のツールキット「Compose」について学習します。
お申し込みはこちら
プログラム期間 : 2022 年 7 月 19 日（火） ~ 8 月 19 日（金）
キックオフ セッション : 2022 年 7 月 19 日（火）16:00 ~ 18:00
Compose を初めてご利用いただく方にもご安心いただけるように、キックオフ セッションで使い方を説明し、いくつかのラボを解説つきで実施します。（本セッションは、アーカイブでもご覧いただけます。セッションに参加できなくても、プログラムに参加して学習することは可能です）
対象 : Android, Compose を学びたい大学生以上の方
本プログラムに登録しプログラムを修了した参加者には、下記のノベルティをプレゼントいたします。
コミュニティ主催の勉強会の情報は随時こちらのブログで更新していきます。また主催者となって勉強会を開催してくださるコミュニティのオーガナイザーの方には Google からの支援をおこないますので、こちらのフォームから申し込んでください。
皆様のご参加をお待ちしております。
dev-event@google.com
このたび、オープンソース ライブラリ Maps Compose の提供を開始することになりました。Maps Compose を使用すると、Maps SDK for Android を Jetpack Compose と一緒に使用できます。Compose を使ってアプリに地図を追加する場合、これまでは Compose とビューベースの MapView の間を橋渡しするために多くのビュー相互運用性コードを記述する必要がありましたが、今後はそういった手間を省くことができます。
Compose は、Android の最新の宣言型ネイティブ UI ツールキットです。UI の記述についての考え方を変えることで、前述の Compose は UI 開発を簡素化と高速化します。つまり、ユーザーはアプリの外観を指定するだけで済み、それ以外は Compose によって処理されます。これは Maps Compose についても同様です。従来よりはるかに少ないコードで Android アプリに地図を追加できるようになりました。
このブログでは、Maps Compose ライブラリをインストールする方法と、その機能の一部について説明します。
さっそく始めましょう。
Maps Compose ライブラリをインストールするには、アプリレベルの build.gradle ファイルに次の依存関係を追加します。
dependencies {
implementation "com.google.maps.android:maps-compose:1.0.0"
implementation "com.google.android.gms:play-services-maps:18.0.2"
}
上記の新しい依存関係をアプリに追加したら、Android Studio でプロジェクトを再構築して、変更を同期します。また、Cloud のコンソール経由で、API キーを作成してアプリに追加する必要があります。詳しくは、「API キーを使用する」をご覧ください。
Maps Compose を依存関係としてアプリに追加し、API キーを追加したら、アプリでコンポーズ可能な関数 GoogleMap を使用できるようになります。Compose を初めて使用する場合、コンポーズ可能な関数は基本的に、Compose で構築されたアプリケーションの UI ビルディング ブロックとなります。
アプリに地図を追加する最も簡単な例を次に示します。
val singapore = LatLng(1.35, 103.87)
val cameraPositionState = rememberCameraPositionState {
position = CameraPosition.fromLatLngZoom(singapore, 10f)
GoogleMap(
modifier = Modifier.fillMaxSize(),
cameraPositionState = cameraPositionState
) {
Marker(
position = singapore,
title = "Singapore",
snippet = "Marker in Singapore"
)
上記のスニペットでは、地図が画面内で最大化され、ビューは camera パラーメータでシンガポールの中心に配置されます。googleMapOptionsFactory で提供されるラムダ式は、地図の初期化に使用される GoogleMapOptions オブジェクトを構築します。最後に、地図のコンテンツでコンポーズ可能な関数 Marker を呼び出すと、地図にマーカーが追加されます。
この例を、ビューを使って地図を追加する例と比較するには、Maps SDK for Android のドキュメント ページにある既存のクイックスタートをご覧ください。Compose の場合は必要なコードがはるかに少なく、地図のライフサイクルを考慮する必要がないことがわかります。
地図上でプロパティを設定するには、MapProperties オブジェクト、または UI 関連のプロパティ用の MapUiSettings オブジェクトを使用します。これらの状態を管理することで、地図上で再構成をトリガーする際にに利用できます。
次のスニペットでは、地図上のズーム コントロールを切り替えるために、Compose の Material コンポーネントであるスイッチがビューに追加されています。
var uiSettings by remember { mutableStateOf(MapUiSettings()) }
var properties by remember {
mutableStateOf(MapProperties(mapType = MapType.SATELLITE))
Box(Modifier.fillMaxSize()) {
modifier = Modifier.matchParentSize(),
properties = properties,
uiSettings = uiSettings
Switch(
checked = uiSettings.zoomControlsEnabled,
onCheckedChange = {
uiSettings = uiSettings.copy(zoomControlsEnabled = it)
マーカーやポリゴンなどのオブジェクトを地図上に描画するには、コンテンツ ラムダをコンポーズ可能な関数 GoogleMap に提供します。
たとえば次のスニペットでは、コンポーズ可能な Marker を使用して、シンガポールを中心とする地図にマーカーを追加しています。
modifier = Modifier.fillMaxSize()
地図のビュー内での位置を制御するには、CameraPositionState を使用します。このオブジェクトは、地図のカメラ位置の変更を管理するために使用できます。また、カメラ更新コマンドを地図に送信するために使用することもできます。
たとえば次のスニペットでは、ボタンがクリックされると、地図のカメラをシドニーに移動する方法を表しています。
val sydney = LatLng(-33.852, 151.211)
Button(
onClick = {
cameraPositionState.move(CameraUpdateFactory.newLatLng(sydney))
Text(text = "Animate camera to Sydney")
Google マップにおける Jetpack Compose のサポートを改善することで、より迅速かつ簡単にアプリに地図を追加できるようになりました。すぐに使用したい場合は、GitHub リポジトリにある付属のサンプルアプリを利用してご確認ください。Jetpack Compose をこれまで利用したことがない場合は、Jetpack Compose の公式ドキュメントに詳細の記載がありますのでご覧ください。
今後ともどうぞよろしくお願いいたします。
Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。
この記事は Chris Banes による Android Developers - Medium の記事 "Jetpack Compose — Before and after" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今年になってから、サンプル アプリTivi の UI を Jetpack Compose に徐々に移行していました。そして 2020 年 12 月第 2 週、移行作業の第一段階がほぼ完了しました。
今回のブログ投稿では、重要な指標の数値を振り返って比較し、Compose によって何が変わるのかを確認してみましょう。比較するのは、APK サイズ、ビルド速度、コードの行数です。
Compose の話題を進める前に、まずは簡単にアプリについて説明します。
Tivi はかなり細かくモジュール化されており、それぞれの UI の「画面」ごとに Gradle モジュール（ui-$NAME）があります。それぞれの画面は Fragment で実装され、メインアプリ モジュールでは AndroidX Navigation を使ってそれらを組み合わせています。
ナビゲーション グラフはディープリンク URI を使って実装されているので、ほとんどの Fragment はお互いのことを知りません。そのため、疎結合が保証されます。しかし、それよりも重要なことは、独立してコンパイルできるため、ビルドの並列化がしやすくなることでしょう。
Compose に移行する前の Tivi は、Android デベロッパーが利用できるありとあらゆるクールな UI を利用していました。一例をあげれば、データ バインディング、Epoxy、マテリアル デザイン コンポーネント、Insetter DBX、MotionLayout などです。しかし残念ながら、これらの大半ではアノテーション処理が使われているため、ビルドのコストがかかります。
先ほど、移行の「第一段階」を終えたばかりだと書きました。これはどういう意味でしょうか。2020 年 1 月にこの作業を始めたときから、アプリの見た目はほとんど変わっていません。
アプリがモジュール化されているということは、移行自体も部品単位になり、一度に 1 つの Fragment だけ移行できるということです。この 11 か月間はまさにそれを実践し、46 個のプル リクエストに対応しています。
最初に簡単な画面 Episode details を移行し、次に Show details、そして ‘Discover’、‘Search’、‘Followed shows’ と移行を進めました。最近追加された Compose の Paging3 サポートと合わせて、最後の画面となった ‘list’ グリッドを移行できました。
2020 年 12 月 10 日（日本時間 12 月 11 日）、アプリから AppCompat、マテリアル デザイン コンポーネント、その他の AndroidX ウィジェット ライブラリを削除する処理を始めました。これは、Tivi の UI が Compose ベースになったことを意味します。
Remove AppCompat + MDC by chrisbanes · Pull Request #737 · chrisbanes/tivi
アプリで Fragment と Navigation を使っている点は変わりませんが、論理的な次のステップは、Fragment から移行して直接新しい Navigation Compose コンポーネントを使うようになります。
この移行の過程は近日中に別のブログ記事で書きたいと思いますが、本投稿の最後の「まとめ」から、私自身の言葉を引用しておきます。
いろいろ考えなくても、Compose が Android の UI 開発の未来であることはわかります。
では、いくつかの指標を確認してみましょう。
以下のそれぞれの指標では、3 つのバージョンのアプリを比較します。
ユーザーが最も気にする指標は、APK サイズです。
以下の結果は、リソース圧縮を有効にし、R8 を使って最小化した release APK を APK Analyzer で測定したものです。
‘adjusted’（調整済み）の値と ‘Pre-Compose’ を比較すると、Compose を使った場合は APK サイズが 41%、メソッド数は 17% 削減されていることがわかります。
Compose を使った場合は、APK サイズが 41%、メソッド数は 17% 削減されていることがわかる
この数から、AppCompat や MDC などがアプリ内でどれほどの容量を占めているかがわかります。それだけではなく、レイアウト ファイルで使われる場合に備えてすべての View クラスを保持しなければならない場合には、最小化ツールはほとんど役に立たないこともわかります。
ソフトウェア プロジェクトを比較する場合、ソースの行数を数えても特に役立つ統計情報にはならないことは承知していますが、この比較によって、どのような変化が起きているのかは確実に把握できます。
このテストでは、cloc ツールで以下のコマンドを使い、すべてのビルドと生成されたファイル、設定ファイルを除外しました。
cloc . --exclude-dir=build,.idea,schemas
cloc ツールにはコメントを無視する機能が組み込まれているので（ただし、検証はしていません）、上記は実際の「コード」の結果です。当然ながら、XML の行数は大幅に少なくなり、76% 削減されています。レイアウト ファイル、スタイル、テーマなど、たくさんの XML ファイルとお別れできます。
同じように興味深いのは、Kotlin の合計行数も減っていることです。仮説としては、アプリ内のボイラープレートが減り、たくさんのビューヘルパーやユーティリティ コードを削除できたためだと考えられます。3,000 行近くを削除できたこちらの PR をご覧ください。
Remove a load of old code 🗑️ by chrisbanes · Pull Request #713 · chrisbanes/tivi
ビルド速度はデベロッパーの関心が非常に高い指標です。このプロセスを開始する前は、多くのアノテーション プロセッサを削除できることでビルド速度が向上するものと考えていましたが、どの程度かはよくわかりませんでした。
テストの設定
説明を続ける前に、以下の数値をどのようにして測定したのかを知っておくことが重要になります。ここでは、Chris Horner が異なる CPU でビルド速度を測定したときと同じ設定を使いました。
テストに使ったマシンは、192 GB の RAM と超高速な Xeon® Gold 6154 CPU を搭載した Lenovo P920 です。言うまでもなく、このマシンは一般的なデベロッパーの設定ではありません。そこで、現実に近いテストを行うため、CPU を最低クロック周波数に固定しました。
# Use performance governor to allow tweaking of max freq
sudo cpupower frequency-set -g performance
# Set max frequency to CPU minimum: 1.2GHz
sudo cpupower frequency-set -u 1.2GHz
その後、すべてのリモート アーティファクト キャッシュを準備するため、./gradlew assembleDebug を実行しました。
そして、テストを実行するため、次のコマンドをループで 5 回実行します。
./gradlew --profile \
--offline \
--rerun-tasks \
--max-workers=4 \
assembleDebug
厳密には --max-workers は必要ありませんが、この CPU では、デフォルトで Gradle が利用できる 64 個の「コア」のすべてが使われます。これを 4 に制限することで、通常のラップトップ CPU と比較しやすくします。
テスト結果は以下のとおりです。それぞれの結果プロファイル レポートの ‘Total Build Time’（合計ビルド時間）の値をご覧ください。
この結果にはかなり驚かされました。ほとんど数値が変わらなかったからです。予想では、多くのアノテーション プロセッサが削除されることで、‘Without view libs’（ビュー ライブラリなし）が大幅に速くなると思っていました。
結果の明細を見てみると、kapt の実行時間はすべて同じくらいでした。おそらくこれは、View Binding、Dagger/Hilt、Room の使用を継続しているためではないかと思います。
しかし、Kotlin コンパイラや Compose コンパイラ プラグインが行ってくれることを考えれば、ビルド時間が 5% 削減されたことに何も不満はありません。
これまでに説明してきた全ての結果に当てはまる注意点があります。
この 11 か月間、Tivi には何の機能も追加しませんでしたが、この点を厳密に制限したわけではありません。移行とはあまり関係のない部分で多くの変更を行っており、それが結果に影響した可能性もあります。
移行を行った 11 か月間で、多くの依存性が更新されました。ほとんどの依存性の更新はランタイム ライブラリの依存性だったので、APK サイズ指標に影響する可能性は低いはずです。
Gradle のアップデート（6.0.1 から 6.7.0）、Android Gradle Plugin のアップデート（3.6.0 から 4.2.0）、そして Kotlin のアップデート（1.3.61 から 1.4.20）などは、すべてビルド速度に大きな影響があります。
Compose は現在アルファ版なので、すべての成果物は開発中のスナップショットになります。来年 1.0 の安定版になったとき、これらのテストを再実行して違いが出るかを見るのが楽しみです。
結果と注意点を見る限り、リンゴ 🍎 とリンゴ 🍏 を比較しているわけではない（同じ条件で比較しているわけではない）ので、あまり多くの結論を出すべきではありません。これは、リンゴ 🍎 とそれよりも少し甘いナシ 🍐 を比べているようなものです。
果物の例はさておき、最大のポイントは Compose がほとんどのデベロッパー指標で良好な（または中立的な）影響を示していることです。この点と Compose でデベロッパーの生産性が大幅に向上することを踏まえれば、いろいろ考えなくても、Compose が Android の UI 開発の未来であることはわかります。
