この記事は 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 状態情報を記録できるだけでも、何の機能もないよりはよいはずです。
ぜひこれを入手してお試しください。そして、問題があればお知らせください。いち早くパフォーマンスの問題を見つけて修正しましょう！ユーザーは皆さんを待っています。
この記事は Rohan Shah による Android Developers Blog の記事 " Material You: Coming to more Android devices near you " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
まもなく、Material You、とりわけダイナミック カラーが利用できる Android 12 スマートフォンが世界中で増加します。これには、Samsung (英語) 、OnePlus、Oppo、Vivo、realme、Xiaomi、TECNO などによるデバイスが含まれます。
Android 12 のリリースと Material You の導入により、ユーザーの Android エクスペリエンスは、これまでになく軽快でパーソナルなものになっています。豪華な新デザインのおかげで、ダイナミックさが増したタッチリップル、とてもなめらかなスクロール、広々としたレイアウトなどのエクスペリエンスが、現実のものになりました。ただし、そのエクスペリエンスの中心であり、これからもそうであり続けるのは、ダイナミック カラーです。この機能では、お気に入りの壁紙を選ぶと、ホーム画面から一部のお気に入りのアプリまで、スマートフォンのエクスペリエンス全体が皆さんをよりよく表現するものに変換されます。
Material You が導入された今、パーソナライゼーションは Android の決定的な特徴となっています。このエコシステムは、これを土台に、今後何年にもわたって成長し続けることになるでしょう。デベロッパーの皆さんには、自信を持ってこの道のりに参加し、アプリでこれまで以上にパーソナルなルック アンド フィールをユーザーに提供していただきたいと思っています。
Material You をサポートする一部の Android デバイスのエクスペリエンスで、さまざまな壁紙ベースのテーマを適用した虹色の Gmail
これからの数か月で、さらに多くの Android 12 デバイスが登場します。OEM パートナーは、重要なデザイン API、特にダイナミック カラー関連が Android エコシステム全体で一貫して動作するように、私たちと連携して作業を進めています。それにより、デベロッパーには安心を、ユーザーには安定した体験によるメリットを提供できます。
マテリアル チームは、ダイナミック カラーの実装方法と、それを総合的なブランド ストーリーに組み入れる方法について理解を深めていただけるように、マテリアルのカスタマイズに関する包括的な記事 (英語) を公開しました。合わせて、ビュー (英語) や Jetpack Compose でこれを使ってみるための Codelab やガイドも提供しています。デザインや実装に必要なツールとして、 Material Theme Builder や Material Color Utilities を更新する作業も続いています。今後数か月間は、お見逃しなく。
マテリアル テーマ ビルダーを使って、アプリでダイナミック カラーを視覚的に確認
Google アプリ（Gmail、フォト、Chrome など多数）も、まさにこのツールとガイドを使って、ブランド体験でカラーによるストーリーを実現しています。皆さんにも、ぜひお試しいただきたいと思っています。どうすればユーザーが選択したカラーと調和させる (英語) ことができるかについての知識が増え、アプリでダイナミック カラーを使えるようになったら、Material Android Issue Tracker (英語) にフィードバックをお送りいただけると幸いです。ぜひ、カラーをお楽しみください！
この記事は Android Team による Android Developers Blog の記事 " Chrome’s multitasking usage increases 18x on large screens " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google Chrome は、世界で最も広く使われているブラウザです。そして Chrome チームは、そのユーザーがあらゆるデバイスで確実にすばらしい体験ができるようにしたいと願っています。多くの Chrome ユーザーは、モバイル、タブレット、折りたたみ式デバイスにも生産性機能が追加され、PC 版 Chrome の機能に匹敵するようになることを望んでいます。こういったニーズに応えるため、マルチタスク機能を推進できる仕組みを構築することにしました。この機能の開発対象にはスマートフォンも含まれていますが、最もよく使われると思われるタブレットや折りたたみ式などの大画面デバイスを特に主眼において実装することにしました。
まずは、複数の Chrome ウィンドウ（インスタンス）を並べて開く方法の開発に注力することにしました。それに当たり、タスクバーなどの 12L の機能や、Samsung のエッジパネルを活用しました。
横に並べる機能は、singleInstancePerTask (英語) 起動モードを使って構築しました。必要だったのは、ユーザーが同時にたくさんのウィンドウを使えるようにすることと、機能のユーザビリティを両立することです。そこで、ユーザビリティのベスト プラクティスを調査し、大画面デバイスでの他のマルチウィンドウ体験を観察し、デバイスで最適なメモリ使用量を保証するための制限について検討しました。そして、大画面デバイスでは最大 5 つのウィンドウを並べても快適に利用できると判断し、この機能をサポートするようにアプリを更新しました。
また、ユーザーにとって使いやすい機能にするため、メニューに新規ウィンドウのショートカットを追加しました。このショートカットは、新しいインテント フラグの組み合わせ LAUNCH_ADJACENT | NEW_TASK (英語) を使って作成しました。プロダクト内でこの機能が目立つように表示されたことで、使用頻度が大幅に向上し、 マルチウィンドウの利用が 18 倍になりました。
これは新機能ですが、Chrome アプリのマルチインスタンスの利用は、この機能をサポートしているスマートフォンと比較して、タブレットと折りたたみ式では 42% 多いことがすでにわかっています。利用状況から、この機能は大画面デバイスの Chrome ユーザーに好意的に受け止められていることが示されています。また、このような機能を構築して、大画面の Chrome ユーザーのエクスペリエンスを拡張することは、価値がある作業であることもわかります。
さらに、アプリのレビューという形でも、以下のように大画面ユーザーからたいへん好意的なフィードバックが寄せられています。「このアプリはすばらしい 👌！画面を分割したり、タブを変更したりできます。その中でたくさんのゲームをプレイすることもできます。私はこのアプリに 5 つ星をつけます」
今後も、大画面での Chrome エクスペリエンスとユーザーの生産性をさらに向上させたいと考えています。
大画面向けにアプリの最適化を始める方法は、こちらをご覧ください。
この記事は 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) に含まれる主な機能拡張と新機能をまとめます。
この記事は Kateryna Semenova, Rahul Ravikumar, Chris Craik による Android Developers Blog の記事 " Improving App Performance with Baseline Profiles " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
多くのアプリにおいて、アプリのパフォーマンスとユーザー エンゲージメントとの間に相関性があることがわかっています。ユーザーが期待するのは、応答性が高く、読み込みが速いアプリです。起動時間は、アプリのパフォーマンスと品質の重要な指標の 1 つになっています。
私たちのパートナーのいくつかは、アプリの起動を最適化するために、すでに多くの時間とリソースを費やしています。その一例として、Facebook のストーリーをご確認ください。
この記事では、ベースライン プロファイルと、それがどのようにアプリやライブラリのパフォーマンスを改善するかを紹介します。その結果、起動時間が最大 40% 短縮されることもあります。ここでは起動に注目しますが、ベースライン プロファイルはジャンクにも大変有効です。
Android 9 (API レベル 28) では、アプリの起動時間短縮を目的として、Play Cloud に ART 最適化プロファイル (英語) が導入されました。クラウド プロファイルが利用できる場合、アプリのコールド スタートは、さまざまなデバイスで少なくとも平均 15% 高速になることがわかっています。
アプリがインストール後やアップデート後に初めて起動する場合、JIT コンパイルが行われるまでの間、コードはインタープリタ モードで動作します。APK では、Java と Kotlin のコードは dex バイトコードにコンパイルされますが、完全にコンパイルしたアプリの保存や読み込みにかかるコストの関係で、完全にマシンコードにコンパイルされることはありません (Android 6 以降)。アプリのクラスやメソッドのうち、頻繁に使われるものやアプリの起動に使われるものは、プロファイルのファイルに記録されます。そしてデバイスがアイドルモードになると、ART がそのプロファイルに基づいてアプリをコンパイルします。これにより、その後のアプリ起動が高速になります。
Android 9 (API レベル 28) より、Google Play もクラウド プロファイルを提供するようになっています。デバイスでアプリを実行すると、ART が生成したプロファイルが Play Store アプリにアップロードされ、クラウドに集約されます。アプリに対して十分な数のプロファイルがアップロードされると、Play アプリは集約したプロファイルを利用して、その後のインストールを行います。
クラウド プロファイルが利用できる場合、それが大きな効果を発揮してくれますが、アプリをインストールするときに常に利用できるとは限りません。通常、プロファイルの収集と集約には数日かかるため、多くのアプリで毎週アップデートが行われると、この点が問題になります。クラウド プロファイルが利用できるようになる前に、多くのユーザーがアップデートをインストールすることになるからです。そこで、Google の Android チームは、プロファイルが用意できるまでの時間を短縮する別の方法を探し始めました。
ベースライン プロファイルは、プロファイルを提供する新たなメカニズムであり、Android 7 (API レベル 24) 以降で利用できます。ベースライン プロファイルは、Android Gradle プラグインが生成する ART プロファイルです。人間が読むことができるプロファイル形式になっており、アプリやライブラリによって提供されます。たとえば、次のようなものです。
HSPLandroidx/compose/runtime/ComposerImpl;->updateValue(Ljava/lang/Object;)VHSPLandroidx/compose/runtime/ComposerImpl;->updatedNodeCount(I)IHLandroidx/compose/runtime/ComposerImpl;->validateNodeExpected()VPLandroidx/compose/runtime/CompositionImpl;->applyChanges()VHLandroidx/compose/runtime/ComposerKt;->findLocation(Ljava/util/List;I)I
HSPLandroidx/compose/runtime/ComposerImpl;->updateValue(Ljava/lang/Object;)V
HSPLandroidx/compose/runtime/ComposerImpl;->updatedNodeCount(I)I
HLandroidx/compose/runtime/ComposerImpl;->validateNodeExpected()V
PLandroidx/compose/runtime/CompositionImpl;->applyChanges()V
HLandroidx/compose/runtime/ComposerKt;->findLocation(Ljava/util/List;I)I
Compose ライブラリの例
バイナリのプロファイルは、APK のアセット ディレクトリの特定の場所 (assets/dexopt/baseline.prof )に格納されます。
ベースライン プロファイルは、ビルド時に作成され、APK の一部として Play に提供されます。そして、ユーザーがアプリをダウンロードするときに、Play からユーザーに送信されます。クラウド プロファイルがまだ利用できない場合、ベースライン プロファイルが ART クラウド プロファイル パイプラインの足りない部分を補います。クラウド プロファイルが利用できる場合、ベースライン プロファイルは自動的にクラウド プロファイルと結合されます。
ベースライン プロファイルの作成からエンドユーザーへの配信までのワークフローを示した図
ベースライン プロファイルの特に大きなメリットは、ローカルで開発や評価が行える点です。そのため、デベロッパーは実際にエンドユーザーが体験するパフォーマンスの向上を確認できます。また、クラウド プロファイルは Android 9 以降でしか利用できませんが、ベースライン プロファイルはそれよりも古いバージョンの Android (7 以降) でもサポートされています。
2021 年の前半に、Google マップのリリース サイクルが 2 週間から 1 週間に変更されました。アップデートの頻度が高くなるということは、ローカルの作成済みプロファイルがより頻繁に破棄され、Play クラウド プロファイルが存在しないために起動が遅くなるユーザーが増えるということでもあります。しかし、ベースライン プロファイルを使うことで、Google マップの起動時間は平均 30% 短縮され、それに伴って検索が 2.4% 増加しました。このように既に定着したアプリにとっても、非常に大きな成果です。
ライブラリに含まれるコードも、アプリのコードと同じです。デフォルトでは完全にコンパイルされないので、起動時のクリティカル パスで大量の処理を行う場合、問題につながる可能性があります。
Jetpack Compose は、Android システム イメージには含まれない UI ライブラリです。そのため、多くの Android View ツールキットのコードとは異なり、インストール時に完全にコンパイルされることはありません。そのため、パフォーマンスの問題が発生することがありました。特にそれが顕著だったのが、最初の数回のコールド スタート時です。
この問題を解決するため、Compose はプロファイル インストーラを利用します。これがベースライン プロファイルのルールを提供してくれるので、Compose アプリの起動時間やジャンクが減少します。
Google Play ストアの検索結果ページは、Compose を使って書き直されています。Compose からベースライン プロファイル ルールを取り込んだ後では、イメージを含む最初の検索結果ページを表示するまでの時間が最大 40% 短縮されました。
Android チームも、関連する AndroidX ライブラリにベースライン プロファイルを追加しました。これは、対象のライブラリを使うすべての Android アプリにメリットがあります。Constraint Layout では、プロファイルのルールを提供 (英語) することで、アニメーションのフレーム時間が 1 ミリ秒以上短縮されました。
ベースライン プロファイルを含めると、アプリやライブラリのデベロッパーすべてがメリットを得られます。理想的な方法は、特に重要なユーザー操作について、デベロッパーが複数のプロファイルを作成することです。それにより、クラウド プロファイルが利用できるかどうかによらず、常にその操作のパフォーマンスが高速になります。アプリ デベロッパーとライブラリ デベロッパー向けのベースライン プロファイルの設定方法は、詳細なガイドをご覧ください。
すぐにはアプリのベースライン プロファイルを作成できないという方でも、依存関係を更新することで、ベースライン プロファイルによるメリットを享受できます。Android Gradle Plugin 7.1.0-alpha05 以降でビルドすれば、ライブラリ (Jetpack など) が提供するベースライン プロファイルを APK に含めることができます。Google Play は、インストール時にそのプロファイルを使ってアプリをコンパイルします。プロファイルの追加は、アプリのビルドの一環として行うことができます。
忘れずに改善の測定を行うようにしましょう。生成されたプロファイルを使ってローカルで起動を測定するには、こちらの手順に従います。
ぜひフィードバックを共有し、皆さんの体験をお知らせください！ (英語)
この記事は 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 をお楽しみください！
この記事は Madan Ankapura による Android Developers Blog の記事 " Building apps for Android Automotive OS " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2022 年 1 月 27 日、Car App Library のバージョン 1.2 ベータ版が公開されたことをお知らせします。これにより、アプリ デベロッパーの皆さんは、Android Automotive OS 向けにナビゲーション、駐車場、充電スポットのアプリ開発を始めることができるようになります。
現在、デベロッパーの皆さんは、これらのカテゴリのアプリについて、Automotive OS エミュレータを使って構築とテストを始めることができます。Android Automotive OS と Android Auto の両方が対象となります。V1.2 ベータ版でのすべての変更点のリストは、リリースノートをご覧ください。自動車用のアプリ開発を始めるには、最新版のデベロッパー ドキュメント、自動車向けアプリの品質ガイドライン、デザイン ガイドライン (英語) をご覧ください。
以前 (英語) お知らせしましたが、Polestar 2 や Volvo の自動車を運転している方は、Google グループに参加し、Google Play ストアでご自分の Gmail アカウントを使って各アプリのベータ版をオプトインすると、充電スポット（ChargePoint、PlugShare）、駐車場（Spothero、Parkwhiz）、ナビゲーション（Flitsmeister、Sygic）のアプリをダウンロードできます。これらのアプリは、Car App Library を使って開発されています。
Android Automotive OS 上の Car App Library アプリは、各自動車の他のエクスペリエンスと一貫性を保つように自動的にレンダリングされます。デベロッパーがなんらかの作業を追加で行う必要はありません。次に例を示します。
Polestar 2
Volvo
Polestar 2 の設定、PlugShare でラベル付きのオン / オフ スイッチを表示
Volvo の設定、PlugShare でスライディング スイッチを表示
Polestar 2 での SpotHero のログイン画面
Volvo での SpotHero のログイン画面
Android Automotive OS でのアプリのカスタマイズ例
ナビゲーション以外では、ライドシェアのドライバは車の中で長い時間を過ごすため、車の画面でライドシェア関連のアプリを安全に使えるようになれば、メリットになります。今後数か月のうちに、Lyft や Kakao Mobility のドライバ向けアプリを車内で体験できるように、両社と連携して作業を進めています。
GPS マップが表示された車の画面のイメージと Lyft のロゴ
もう 1 つ、うれしいお知らせがあります。すべての有名スポットアプリを含めるように、サポートを拡大しているところです。これにより、充電スポットや駐車場だけでなく、観光名所などをマップ上で見つけたり、探したりするほか、場合によってはその場所へナビゲーションできるアプリを実現できます。早期アクセス パートナーとして、MochiMochi、Fuelio、Prezzi Benzina、NAVITIME JAPAN と連携しています。
今後の早期アクセスプログラムに参加したい方は、こちらのフォーム (英語) から登録してください。g.co/androidforcars にアクセスして、Android for Cars App Library をさっそく使ってみてください。
この記事は Dave Burke による Android Developers Blog の記事 " The first developer preview of Android 13 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2022 年 2 月 10 日、Android 13 デベロッパー プレビュー 1 を公開しました。本日は、Android の次期リリースの概要を初めてお伝えします。Android 13 では、プライバシーとセキュリティ、デベロッパーの生産性という重要なテーマに取り組み続けます。また、12L で行った最新アップデートをベースとして、現在使われている 2 億 5000 万台以上の大画面 Android デバイスのメリットを活用していただけるようサポートします。
これは、Android 13 の始まりにすぎません。今後リリースに向けて作業を進める中で、さらに多くのことを共有する予定です。以下、新機能の概要について説明します。Pixel 向けのダウンロード (英語) やリリース スケジュール (英語) の詳細については、Android 13 デベロッパー サイト (英語) をご覧ください。いつものように、機能を最終リリースに含めるためには、早い段階でフィードバックを得ることが不可欠です。皆さんの感想を聞くのを楽しみにしています。そして、Android を誰もが使えるプラットフォームにするために、引き続き協力をお願いいたします！
ユーザーは、重要な個人情報や機密情報を安心して預けることができる OS やアプリを求めています。プライバシーは Android の製品理念の中核です。Android 13 では、デバイスで安全な環境を提供し、ユーザーが制御できることを増やす取り組みを通して、あらゆる人のために高品質で責任あるプラットフォームを構築することに主眼を置いています。2022 年 2 月 10 日 のリリースでは、ユーザーが写真や動画を安全にアプリと共有できる写真選択や、アプリが位置情報のパーミッションを取得する必要性を一層少なくするための新しい Wi-Fi パーミッションを導入します。新しい API を試し、変更によってアプリが受ける影響をテストしてみることをお勧めします。
写真選択と API - 写真や動画に関するユーザーのプライバシーを守るため、Android 13 にシステムレベルで写真選択機能を追加します。これは、ユーザーにとって、ローカルとクラウドベースの写真の両方を安全に共有する標準的で最適な方法になります。長年にわたって Android に搭載されているドキュメント選択機能を使うことで、デバイス上のすべてのメディア ファイルを参照するパーミッションを必要とせず、特定のドキュメントをアプリと共有できます。今回の写真選択では、この機能を拡張し、写真や動画を選択する便利な専用機能を追加します。アプリは、写真選択 API (英語) を使って共有された写真や動画にアクセスします。デバイス上のすべてのメディア ファイルを参照するパーミッションは必要ありません。Google Play システム アップデートを通じて、この写真選択をさらに多くの Android ユーザーに提供したいと考えています。Android 11 以降を実行するデバイス (Go デバイスは除く) を対象に、MediaProvider モジュールのアップデートとして提供する予定です。ぜひ写真選択 API を試してみて、フィードバックをお知らせください (英語) ！
写真選択を使うと、一貫性のある安全な方法で、
特定の写真や動画へのアクセス権をアプリに与えることができる
ニアバイ デバイスの Wi-Fi パーミッション - Android 13 では、近くにあるアクセス ポイントへの Wi-Fi 接続を管理するアプリに対して、NEARBY_WIFI_DEVICES (英語) ランタイム パーミッション（NEARBY_DEVICES パーミッション グループの一部）を導入します。この新しいパーミッションは、多くの一般的な Wi-Fi API (英語) を呼び出すアプリに必要です。これを持つアプリは、位置情報のパーミッションがなくても、Wi-Fi で近くのデバイスを検出したり、それと接続したりできます。これまで、近くの Wi-Fi デバイスと接続する必要があり、デバイスの位置情報は必要としないアプリにとって、位置情報のパーミッション要件は高いハードルでした。Android 13 をターゲットにするアプリでは、そうする代わりに、NEARBY_WIFI_DEVICES パーミッションと “neverForLocation” フラグ (英語) をリクエストできるようになります。これにより、デベロッパーの手間を減らしつつ、プライバシー フレンドリーなアプリ設計が推進されます。詳しくはこちら (英語) をご覧ください。
Android 13 では、デベロッパーの生産性を向上させる新機能やツールも導入されます。数十億台のデバイスで動作する美しいアプリを作る皆さんをサポートすることは、私たちの中核となるミッションの 1 つです。その点は、Android 13 の仕組みであろうと、愛されている Kotlin 言語や Jetpack のこだわりがある API をはじめとする最先端の Android 開発用のツールであろうと変わりません。皆さんの生産性を上げることで、開発コストを下げ、皆さんがこれからもすばらしいエクスペリエンスの開発に集中できるようにしたいと考えています。以下では、2022 年 2 月 10 日のリリースに含まれている新機能の一部を紹介します。
クイック設定配置 API - 通知シェードのクイック設定は、ユーザーがアプリから離れずに設定を変更したり、すぐにアクションを実行したりできる便利な方法です。カスタムタイル (英語) を提供するアプリのために、ユーザーが簡単にタイルを見つけてクイック設定に追加できるようにします。新しいタイル配置 API (英語) を使うと、カスタムタイルをアクティブなクイック設定タイルに直接追加するプロンプトをアプリから表示できます。新しいシステム ダイアログを使うと、わざわざクイック設定に移動してタイルを追加しなくても、アプリを離れずに 1 つの手順でタイルを追加できます。
テーマ対応アプリアイコン - Android 13 では、Material You のダイナミック カラーを Google アプリ以外にも拡大し、すべてのアプリアイコンで、壁紙などのテーマのプリファレンスの色合いを引き継いだアイコンをオプトインできるようにします。アプリで必要なのは、モノクロのアプリアイコン (英語) 通知ドローアブルなど) を提供し、アダプティブ アイコンの XML を微調整することだけです。オプトインしたユーザーに一貫性のあるエクスペリエンスを提供できるよう、すべてのデベロッパーの皆さんには、互換性のあるアイコンを提供することをお勧めします。テーマ対応アプリアイコンは、まず Pixel デバイスでサポートされます。現在、パートナーのデバイス メーカーと連携して、対応デバイスを増やす作業を進めています。詳しくはこちら (英語) をご覧ください。
アプリごとの言語設定 - アプリによっては、多言語ユーザーのニーズを満たすため、ユーザーがシステム言語とは異なる言語を選べるようになっています。そのようなアプリでは、新しいプラットフォーム API (英語) を呼び出して、ユーザーの優先言語の設定や取得を行えるようになります。これにより、アプリのランタイム言語を設定する際のボイラープレート コードを減らし、互換性を向上させることができます。さらに互換性を向上させるため、同様の API を Jetpack ライブラリにも追加する予定です。詳しくはこちら (英語) をご覧ください。
ハイフネーションの高速化 - ハイフネーションを行うと、折り返されたテキストが読みやすくなり、UI のアダプティブ性が増します。Android 13 では、ハイフネーションのパフォーマンスを最適化して 200% 近く向上させ、TextView で有効化してもレンダリング パフォーマンスにほとんど影響を与えなくなっています。ハイフネーションを高速化するには、setHyphenationFrequency() (英語) で、新しい頻度 fullFast (英語) または normalFast (英語) を使います。ぜひハイフネーションの高速化をお試しいただき、感想をお聞かせください！
プログラマブル シェーダー - Android 13 では、プログラム可能な RuntimeShader (英語) オブジェクトがサポートされます。このオブジェクトの動作は、Android Graphics Shading Language (AGSL) で定義できます。AGSL は、構文は GLSL とほぼ同じですが、Android レンダリング エンジンの内部で動作して、Android キャンバスの描画やビュー コンテンツのフィルタリングをカスタマイズします。Android のリップル エフェクト、ぼかし、ストレッチ オーバースクロールは、内部的にこのシェーダーを使って実装しています。Android 13 では、皆さんのアプリでも同じような高度なエフェクトを作れるようになります。
AGSL アニメーション シェーダー
元になっているのはこちらの GLSL シェーダー
OpenJDK 11 アップデート - Android 13 では、Android のコア ライブラリを刷新して OpenJDK 11 LTS リリースに合わせる作業を始めています。これには、ライブラリのアップデートと、アプリおよびプラットフォーム デベロッパー向けの Java 11 プログラミング言語のサポートの両方が含まれます。また、Google Play システム アップデートにより、さらに多くのデバイスにコア ライブラリの変更を提供することも計画しています。このアップデートは、Android 12 以降を実行するデバイスを対象に、ART モジュール アップデートの一環として行う予定です。詳しくはこちら (英語) をご覧ください。
新しいバージョンのプラットフォームをリリースするたびに、アプリの互換性を優先し、迅速かつスムーズにアップデートできるように作業を行っています。皆さんが時間に余裕を持てるよう、Android 13 ではアプリに関連する変更のほとんどがオプトイン方式になっています。また、短時間で対応できるように、ツールやプロセスをアップデートしています。
Google Play を経由した Android アップデートの促進 - Android 13 では、デバイスを問わず、一貫性のある安全な環境をアプリに提供するため、また新機能をユーザーに配信するため、Google Play システム アップデート (Project Mainline) 英語) への注力を拡大し続けます。今では、写真選択や OpenJDK 11 などの新機能を、既存モジュールのアップデートという形で古いバージョンの Android ユーザーに直接プッシュできます。Bluetooth や超広帯域無線 (UWB) などの新モジュールも追加され、Android でコア機能をアップデートできる範囲はさらに広がっています。
タブレット、折りたたみ式、Chromebook 向けの最適化 - タブレット、折りたたみ式、Chromebook などの大画面デバイスには勢いがあります。今こそ、アプリをこのようなデバイスに対応させ、どんな画面にも適応できる完全にアダプティブなアプリをデザインしましょう。タブレット向けの最適化ガイドから始めて、大画面向けの開発や折りたたみ式デバイス向けの開発の方法を学ぶことができます。
変更点のテストやデバッグの簡易化 - アプリに影響を与える可能性がある変更点を簡単にオプトインしてテストできるように、今年も多くの変更点を切り替え可能にしています。この切り替えを利用すると、それぞれの変更を開発者向けオプションや adb から強制的に有効化、無効化できます。詳しくはこちら (英語) をご覧ください。
開発者向けオプションでのアプリの互換性切り替え
Platform Stability マイルストーン - アプリの互換性作業を計画する時間を長くとれるように、昨年と同様にかなり早いタイミングで Platform Stability マイルストーンをお知らせします。このマイルストーンでは、最終版の SDK や NDK API だけでなく、内部 API やアプリに関連するシステム動作の最終版を配信します。今年は、2022 年 6 月に Platform Stability に到達することを想定しています。その後、数週間の最終テストの期間を経て、公式リリースを迎える予定です。詳しいリリース スケジュールはこちら (英語) をご覧ください。
デベロッパー プレビューには、Android 13 の機能を試し、アプリをテストしてフィードバック (英語) を提供するために必要なすべてのものが含まれています。タブレットや折りたたみ式でアプリのテストを始める一番簡単な方法は、タブレットまたは折りたたみ式設定の Android Emulator を使うことです。完全な設定手順はこちらにあります。スマートフォンの場合は、システム イメージ (英語) を Pixel 6 Pro、Pixel 6、Pixel 5a 5G、Pixel 5、Pixel 4a（5G）、Pixel 4a、Pixel 4 XL、Pixel 4 のいずれかのデバイスに書き込むと、すぐに始めることができます。Pixel デバイスをお持ちでない方は、Android Studio で 64 ビット システム イメージと Android Emulator を使うことができます。さらに幅広くテストできるように、GSI イメージも公開しています。
セットアップ (英語) の完了後にやるべきことは、以下のとおりです。
プレビュー システム イメージと SDK は、Android 13 のリリース サイクル期間中、定期的にアップデートされる予定です。このプレビューの第 1 弾リリースは、デベロッパーのみを対象としています。日常的な使用やユーザーの使用を想定したものではありません。そのため、手動のダウンロードでのみ利用できます。プレビュー ビルドを手動でインストールすると、今後のプレビューやベータ版の無線 (OTA) アップデートをすべて自動的に受け取ります。詳しくはこちら (英語) をご覧ください。
ベータ版リリースに近づいたら、ユーザーも招待して Android 13 を試していただく予定です。その際には、Android ベータ版プログラムへの登録もオープンします。現在のところ、Android 13 のベータ版はまだ利用できない点に注意してください。
完全な情報は、Android 13 デベロッパー サイト (英語) でご覧いただけます。
Java および OpenJDK は Oracle および、またはその関連会社の商標または登録商標です。
この記事は Manuel Vicente Vivo による Android Developers Blog の記事 " Rebuilding our guide to app architecture " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android アプリのサイズが増大するにつれ、アーキテクチャに従ったコードを設計することが重要になっています。そうすることで、アプリをスケーリングでき、品質や堅牢性を向上させて、テストしやすいものにできるからです。
アプリのアーキテクチャは、アプリのパーツ間の境界や、それぞれのパーツが担うべき責任を定義します。これは、前述のメリットを実現する関心の分離の原則とも一致します。
アプリのアーキテクチャに関する最新のガイダンスがほしいというコミュニティの声に応えて、刷新したアプリ アーキテクチャ ガイドを公開しました。これには、堅牢で高品質なアプリを作るためのベスト プラクティスや推奨アーキテクチャが含まれています。さらに、推奨アーキテクチャのレイヤ、すなわちUI、ドメイン、データの各レイヤについて説明するページもあります。その中で、UI イベントのハンドリング方法などのさらに複雑なトピックを掘り下げています。
Android アプリには、少なくとも次の 2 つのレイヤが必要です。
また、ドメイン レイヤと呼ばれるレイヤを追加し、UI レイヤとデータレイヤとの間のインタラクションの簡素化や再利用を行うこともできます。
典型的なアプリ アーキテクチャを汎用化した図。UI レイヤは、オプションのドメイン レイヤか、アプリケーション データを公開するデータレイヤからアプリケーション データを取得する。
このコンテンツを順番に、そしてどこまで進んだかを把握しつつ利用できるように、学習用の Pathway (英語) を作成しました。この機会を見逃すことなく、すべての内容を学んで認定バッジを取得しましょう。
初心者の方は、アプリのアーキテクチャを採用することによるメリットを理解するところから始め、次にトピックへの最初のアプローチとして、推奨事項に従いましょう。中級および上級のデベロッパーの方は、推奨事項に従い、ニーズに合わせてカスタマイズしましょう。実際に、私たちの調査から、ほとんどのプロのデベロッパーが既にこれらのベスト プラクティスを利用していることがわかっています。
既存のアーキテクチャをアップデートして推奨事項に従うべきか、疑問に思う方もいらっしゃるかもしれません。その答えは否というより、皆さん次第です。現在のアーキテクチャが問題なく機能していれば、それを使い続けてもよいでしょう。しかし、ガイドを読めば、メリットが得られたり、アプリに導入したいと思えたりするパターンが見つかるかもしれません。
今回公開するドキュメントは第一弾で、2022 年中にさらに公開を続ける予定です。ガイドの改善にご協力ください。現在の推奨事項にフィードバックがある方や、他のアーキテクチャ関連トピックを確認したい方は、ドキュメントの Issue Tracker (英語) からお知らせください。
.png)
