Remote Compose を使用したインタラクティブなサーフェスの強化

こんにちは。

私は Nicolas Roard です。Remote Compose プロジェクトのテックリードを務めています。

John Hoford です。

私は Remote Compose のデベロッパーです。

John Zoeller です。Wear OS のデベロッパー リレーションズを担当しています。

では始めましょう

まず、Remote Compose で解決しようとしている問題の種類について、簡単に説明します。

通常、Android の UI について話したり考えたりするときは、UI をアプリケーションとアプリケーション プロセスの一部として考えます。

UI をパッケージ化して、リモート サーフェスなどの別の場所に送信したい場合があります。

リモート サーフェスとは、ウォッチフェイスやウィジェットなどの例のように、独自のアプリや別のアプリでも構いません。

これらはすべて、本質的にリモート サーフェスの例です。

つまり、アプリやサーバーなど、どこか別の場所で、そのリモート サーフェスに何を送信すべきかを把握している必要があります。

さらに…

スピーカーはどうですか？

この 2 つの間には、本質的に距離があります。

この距離は、文字どおり実際の距離の場合もあれば、ネットワーク接続の場合もあります。

プロセス境界のみの場合もあります。

同じデバイスを使用している。

しかし、それが何であれ、費用がかかります。

UI を取得して送信する最も簡単な方法は、画面のコピーを取得して送信することです。

問題は、それほど高速ではないということです。

Remote Compose では、代わりにその UI を表すドキュメントを送信します。

小規模であることには多くの利点があることを覚えておいてください。

これは重要です。

これは、最初に送信したピクセルでも確認できましたが、実際には、そのサーフェスで行うあらゆる種類の更新に当てはまります。

往復チケットを手に入れた。

そのため、リモート サーフェスでイベント、クリック、タップなどの操作が行われます。

新しいバージョンを入手するには、作成者に問い合わせる必要があります。

これは好ましくありません。

多くの点で、Remote Compose はこの問題を解決しようとしています。

ドキュメントが送信されたことがわかります。

ドキュメントのほかに、非常に重要な領域が 2 つあります。

1 つは、そのドキュメントの作成方法です。

2 つ目は、プレイ方法です。

ドキュメントを作成していると述べました。

画面のコピーも、アプリケーションも送信しません。

このドキュメントを作成する方法は 3 つあります。

1 つ目は Compose API、2 つ目は手続き型 Kotlin API（KMP）、3 つ目は JSON 形式です。

これらはすべて同じバイトを出力します。

そこで、そうしたドキュメントを作成するための一連のツールを提供しています。Compose API を使用すると、Android Studio の既存のツールを活用できます。

たとえば、プレビューを使用して、開発中の内容を IDE で直接確認できます。

また、ドキュメント インスペクタなどの強力な新しいツールにも取り組んでいます。

ドキュメントが実際にどのようなものか、簡単に見てみましょう。

これは基本的に、コンパクトなバイナリ表現でエンコードされたオペレーションのリストであり、これらのオペレーションは、リモート サーフェスに送信できるスタンドアロンのユーザー インターフェースを記述します。

これらのドキュメントの非常に重要な特徴の 1 つは、サイズが小さいことです。

そして、小さいことは良いことだと考えました。

通常は数キロバイト程度です。

しかし、非常にアダプティブなレイアウトを持つ、より複雑な UI でも、数キロバイトから数十キロバイト程度です。

そして、すべてのアセットをそのドキュメントにパッケージ化します。

つまり、ドキュメントの容量を実際に消費する可能性があるのは、ビットマップをパッケージ化する場合のみです。

注意事項として覚えておいてください。

これは、画面のコピーではなくドキュメントを送信する理由でもあります。

小規模であること、そしてそれが重要であることについて話すとき、それはコミュニケーションだけではありません。

これは、Remote Compose の背後にある哲学の中心的なコーナーケースのようなものです。

ご覧のとおり、最初のピクセルが画面に表示されるまでの時間に影響することは明らかです。

また、同じ能力、同じ容量のサーフェスで、効率を維持しながら、より多くのドキュメントを使用できるということでもあります。

これは、ウィジェットをサポートする際に活用するものです。

プレーヤー自体もかなり小さく、依存関係もほとんどありません。

また、サイズが小さく、依存関係が少ないため、Remote Compose ドキュメントを実際に再生できる場所までリーチを拡大できます。

これは、後述するように、制約のあるプラットフォームでは特に重要です。

転送と距離について詳しく説明しましたが、Remote Compose 自体は転送を処理しません。

それはあなた次第です。

これらすべてをバイトバッファにパッケージ化し、適切なメソッドを使用してリモート サーフェスに送信します。

ウィジェットについては、Google がコネクタを提供します。

しかし、一般的には、トランスポートを担当していることを念頭に置いておくと便利です。

プレーヤーがそのドキュメントを受け取ると、送信方法に関係なく、オペレーションのリストを抽出して、描画コマンド、レイアウト ツリー、式に変換できます。これらすべてを組み合わせることで、非常にリッチなユーザー エクスペリエンスを実現できます。

ここで留意すべき点は、ドキュメントの転送方法を決定する権限をユーザーに委ねることで、Remote Compose をさまざまなシナリオでツールとして再利用できるということです。中には、私たちが想定していないシナリオもあるかもしれません。

ドキュメントがプレーヤーによって読み込まれると、自動的に実行されます。

これが全体的な考え方です。

ドキュメントには、ある程度自律的な UI を作成してほしいと考えています。作成者に頼る必要がない UI です。

これらすべてを組み合わせることで、サイズ変更、スクロール、タッチイベント、コンポーネントの表示 / 非表示の決定、アニメーション、一部のタッチイベント、一部のタッチ処理を、プレーヤーに戻ることなくドキュメント内ですべて行うことができます。

また、作成に戻る必要がある場合は、実際には「新しいドキュメントをください」というアクションをリクエストできます。

Remote Compose では、主に AndroidX ライブラリを介して 3 つの公式プレーヤーを提供しています。

1 つは Compose プレーヤーであるため、Compose アプリケーションで使用できます。

View をまだ使用している場合は、View プレーヤーも用意されています。

また、API 36 以降の Android プラットフォームに搭載されている RemoteViews 実装を使用すると、Remote Compose を使用してランチャーで実行される Android ウィジェットを作成できます。

また、ご興味があれば、Skia、TypeScript、Compose Multiplatform で動作する C++ など、試験運用版のプレーヤーもいくつかあります。

つまり、使用しているのと同じテクノロジーを、さまざまなサーフェスやプラットフォームでのレンダリングに基本的に使用できるということです。

まとめると、これまでお話ししてきた距離は依然として存在しますが、実際に重要となる場合にのみ重要となるようにしようとしています。

うん

では、Remote Compose ドキュメント内で利用できる機能について少し説明しましょう。

ベースには Canvas があり、Android Canvas のすべての機能が備わっています。

ただし、いくつかの追加の API が含まれています。

ただし、特別な点として、Android Canvas にあるすべての float を式に置き換えることができます。

これにより、アニメーション、動的なスケーリング、柔軟なレイアウトが可能になります。

さまざまなことが可能です。

式についてもう少し詳しく説明します。

通常の数学、三角関数、配列アクセス、スプライン補間など、豊富な演算子が用意されています。

また、変化する値はすべてアニメーション化できるため、あらゆる値の状態の変化をアニメーション化できます。

この図では、各振り子が異なる種類のアニメーションを選択しています。これらはすべて Remote Compose で利用できます。

さらに、基本的なコンポーネント、Compose 関連の要素、よく知られている要素があります。

Box、Row、Column など、非常に馴染みのある API が生成されます。

さらに、アダプティブ コンポーネントもあります。

この方法の利点の一つは、その時点でドキュメントを制御していないため、オブジェクトの消失、出現、消失、サイズ変更による再表示などを、ドキュメントのソースに戻ることなく処理できることです。

さらに、コンポーネント アニメーションもあります。

すべての変更をアニメーション化できるため、何かが消える場合はアニメーション化できます。

独自のカスタム アニメーションを作成することもできます。

この例では、シェーダーなど、さまざまなものが使用されています。

また、単にきれいな画像を表示するだけでなく、その場で操作することもできます。

クリック、タッチイベント、スクロールなどの操作が可能です。

また、アクセシビリティも重要であるため、すべての Accessibility API が用意されています。

ここでご覧いただいているのは、興味深い UI を備えた完全なストップウォッチを構築しているところです。これらはすべてプレーヤー側で行われています。

すべてドキュメント内で完結します。

表示されているものはすべて、サーバーに戻る必要はありません。

アプリケーション内で構築した場合、この例では、青い部分がアプリケーションで、黒い部分が Remote Compose ドキュメントです。

実際に 2 つのモデル間でやり取りできます。

ここで値を増やすと、アプリケーション（ホスト）がそれを受け取っているのがわかります。また、スライダーを動かすと、ドキュメント内の値が変化します。

そのため、どちらの方向にも進むことができます。

それでは、これらのドキュメントの作成方法について詳しく見ていきましょう。

実際には、Compose、Kotlin、JSON の 3 つの API があります。

Compose API がどのようなものか、なんとなくわかっていると思います。

いくつかひねりがあります。これについては詳しく説明します。

Kotlin API は非常に手続き型です。

ドキュメント内の 1 つのコマンドに相当するため、1 対 1 の関係になります。

JSON は、Remote Compose に変換できるコンバータを備えた JSON 構文です。

また、LLM を使用している場合にも、LLM がドキュメントを読み書きできるため、この形式は便利です。

では、実際に Compose を使って何かを作成してみましょう。

この場合、コンポーズ可能とリモート コンポーズ可能が表示されます。

キャンバスではなく、リモート キャンバスとリモート修飾子がありますが、修飾子自体は、皆さんがよく知っているものと同じです。

内部のすべてのコマンドは、実際にはリモート コマンドのリモート Compose ドキュメント コマンドを生成しています。

この場合は、円を描画してから、いくつかの浮動小数点数と、式の中で時間を使用する式を追加します。

アニメーションをオンにすると、Android Studio からのライブ プレビューが表示され、実際にライブで実行されます。

これらの表現が使われています。

その概要と仕組みについて少し説明しましょう。

左側には、スプレッドシートのようなものが表示されています。

これは、浮動小数点値のテーブルです。

また、依存関係ツリーもあるため、どこがどこに接続されているかがわかります。

何かが変更されると、その依存関係はダーティとしてマークされ、クリーンアップされて調整されます。

実行時に、すべての依存関係をクリーンアップし、変更された依存関係のみを評価します。

そのため、非常に効率的です。たとえば、オブジェクトのサイズが変更された場合、その依存関係が変更され、それを反映する必要があります。

これは非常に効率的なコンピューティング方法です。上から下まで非常に効率的に処理されます。

そこで、この時計を少し拡張して、実用的なもの、実用的なものに近いものを作れることを示しましょう。

この例では、エッジに目盛りを追加しています。いくつかの for ループが表示されています。このように、ローカルで右側に for ループを記述できます。

次に、時針と分針を追加し、秒針を追加します。最後に、いくつかのボタンを追加して仕上げると、ライブ時計が完成します。

実際に時間が表示されています。

もう 1 つ興味深いのは、同じものを JSON で記述できることです。JSON で記述すれば、LLM と簡単にやり取りできます。たとえば、「分針を緑色に変更して」と言えば、LLM はその意味を理解します。

この点は非常に便利です。

違いますね。

これで、Remote Compose の機能についてご理解いただけたかと思います。

デベロッパー向けのサポートについて少し説明します。

これらは主に AndroidX ライブラリであると述べました。DAC にあるものはすべて、どこにあるかわかります。

最新のリリースやドキュメントなど、すべてを入手できます。

いつものように、Android Studio でできることを John がデモで紹介しました。

私にとって最も素晴らしいのは、開発時間を大幅に短縮できるライブ プレビューです。

Google が取り組んでいることの一つに、この形式のオープン仕様の公開があります。

完全に隠されたものを作ろうとしているわけではありません。

その仕組み、実際にどのように構築され、エンコードされているかを確認できます。

アプリでよく使用されるものの一つに、アニメーション ベクター型ドローアブルがあります。これは非常に便利です。

ビットマップについて説明したことを思い出してください。

ビットマップではなくベクターを送信することに、私たちはとても興味を持っています。

そこで、Lottie などの形式を RemoteCompose コンポーネントに変換して RemoteCompose ファイルで使用できるようにするツールをいくつか開発しています。

先ほど、追加のツールにも取り組んでいると申し上げましたが、具体的には、ドキュメントのライブ インスペクタのようなものです。作成するためのデベロッパー エクスペリエンスがあることと、その作成結果を検査できることは別だからです。

この例では、ドキュメントです。

そこで、現在開発中のツールを簡単にご紹介します。

これは RemoteCompose ドキュメント インスペクタです。名前のとおり、ドキュメントを検査し、いくつかの便利なツールと可視化を適用できます。

たとえば、ドキュメントを開いて、ドキュメントに記載されているさまざまなオペレーションをステップごとに実行し、すべてがどのように連携しているかをより深く理解できます。

しかし、他にもツールがあります。

たとえば、この機能はとても気に入っています。ドキュメントをさまざまな密度やサイズで即座に可視化できるため、作成中のものがサイズの変化にうまく適応するかどうかをすぐに確認できます。

私たちが取り組んでいる最新の機能の一つに、本格的な Layout Inspector があります。これは、Android Studio で使い慣れているレイアウト検査機能を、オペレーションやドキュメントに適用できるようにしたものです。

3D に関しては、さらに進んだ機能もあります。

先ほど、小さいことは特徴であると説明しました。

これは重要です。

ドキュメントは小さい方が望ましいです。

これは、すべての人に役立ちます。

お願いします。

では、どうすればよいでしょうか。

UI の一般的な例を見てみましょう。

多数の行があるもの。

行自体には、名前、小さなグラフ、ボタンなどがあります。

よくあることだ。

その UI のサイズはすでにかなり小さくなっています。

25 KB 程度ですが、RemoteCompose には、さらに小さくするためのさまざまな機能が用意されています。

それでは、順番に見ていきましょう。

まず、同じ文字列が送信された場合、Google がそれを検知します。これは無料で行われます。

同じ文字列を指すことで、数バイトを削減できます。

しかし、ループなどの機能も提供されています。

このループ オペレーションを使用して、小さなグラフを描画しました。

これにより、さらに数バイトを節約できます。

関数もあります。

そこで、関数を作成します。ここでは、そのグラフに対して再度関数を作成し、そのグラフを複数回呼び出すことができます。

これにより、バイト数を節約できます。

コンポーネントにはテンプレートがあります。

関数と同様の考え方ですが、コンポーネント向けですね。

そのため、適切なパラメータを使用してそのテンプレートを呼び出すだけで、さまざまなコンポーネントや行をすべて置き換えることができ、ドキュメントのサイズを大幅に削減できます。

また、ドキュメントの圧縮も標準でサポートされています。

一般的に、この方法でドキュメントのサイズを約半分に削減できます。

興味深いのは、ドキュメントのヘッダーが少し特殊なことです。

圧縮は行いません。

これは、大量のドキュメントを解凍せずにすばやく選別する場合に非常に便利です。

つまり、ドキュメントはデフォルトでも小さいですが、さらに小さくすることもできます。

この小さな例からわかるように、文字通り 1 桁削減するのは簡単です。

Android プラットフォームのウィジェット、特にランチャー ウィジェットについて説明しました。

そこで、Google が行っていることと、すでに提供されている機能について少し説明します。

まず、時計などの既存のウィジェットを RemoteCompose で複製します。これは、RemoteCompose で同じように動作します。

でも、もっとできることはありますよね？

よりアダプティブな UI、つまりサイズ変更やアニメーションが適切に行われるウィジェットを作成したい場合は、今すぐ作成できます。

これは、RemoteViews でできることとは対照的に、これを実現するための適切なプリミティブがあるためです。

基本的には、より高い柔軟性とパワーを提供します。

パワーについて言えば、これは、できることのクレイジーな例です。

ウィジェットにゲーム全体が表示されます。

そして、そのウィジェットの実際のサイズを指します。

4 KB です。

Remote Compose では、トランスポートを直接扱うことはないと述べました。

ただし、ウィジェット専用として、ドキュメントを簡単に取得してランチャーに送信できる RemoteCompose Widget コネクタクラスが用意されています。

ただし、すでにウィジェットを使用している場合は、引き続き Glance を使用することをおすすめします。Glance の最新バージョンでは、プラットフォームで Remote Compose を出力するバックエンドが自動的に提供されるためです。

次は Wear OS についてです。

ありがとう。

皆さん、こんにちは。

ジョン・ゾラーです

本日は Wear OS についてお話しします。

このプレゼンテーションのために 30 個ほどのジョークを考えましたが、すべて母に話したところ、どれを話してもクビになると言われました。

そのため、この部分はスキップして、プレゼンテーションのみを行います。

そこで、リモート Compose と、Wear OS でのリモート Compose の優れたメリットについて説明します。

まず、新しい Wear OS ワークアウト トラッカーについて説明します。

このアプリは Remote Compose を使用して構築されています。多機能で高品質なワークアウト トラッカーを Wear 向けに構築するのは非常に困難です。

これには少し時間がかかります。

そこで、Google がその作業を代行し、リアルタイム指標やメディアの操作など、最新のワークアウト機能をいくつか追加しました。

また、Remote Compose のおかげで、UI をすべての実行から切り離すことができたため、非常に効率的に実行でき、ユーザーのバッテリーを消耗させないようにすることができます。

Remote Compose を使用せず、通常の Compose のみでこれを行うと、画面上のリアルタイム指標を 1 秒ごとに更新することはできません。

指標を表示するためだけに常に画面表示モードのスマートウォッチを復帰させる必要があるため、実際には 1 分かかります。

これは大きな利点です。

信じられないかもしれませんが、これは GIF です。

これは写真ではありません。

まだ移動していないことはわかっています。次の指標の更新時に、約 45 秒で移動します。

しかし、それが Remote Compose の利点です。

覚えておいていただきたいのは、

Wear ワークアウト トラッカーは実際に利用可能です。

ASICS Runkeeper アプリは、この機能を使用して新しいアプリケーションを構築しました。こちらのリンクからオープンベータ版テストに参加して、今すぐお試しいただけます。

次は、Wear OS ウィジェットです。

これは、リモート作成が実際に活用されている優れた例です。

これらは以前の ProtoLayout Tiles ライブラリに代わるもので、デバイスごとに異なる 2 種類の UI フレームワークをサポートする必要がなくなります。

Remote Compose を使用すれば、これらすべてを実現できます。

また、Jetpack Glance の一部であるため、Wear OS のウィジェットは、ウィジェットの統合された Android エコシステムの一部となります。

このエコシステムの一部として、RemoteCompose ウィジェットの UI は特定のアプリプロセスから完全に切り離されているため、Android スタックの他の部分と同じテクノロジーを使用して、Wear OS デバイスで安全にシリアル化してレンダリングできます。

また、Remote Compose は、ウィジェットに最新のグラフィックとレスポンシブ レイアウトをもたらします。しかも、非常に効率的で、バッテリーにも優しいです。

Wear OS 7 では、ハードウェア メーカーがすでに縦スクロール トレイを採用しています。

これは Samsung Galaxy Watch です。ウィジェットがトレイを縦方向にスクロールしているのがわかります。

タイルをウィジェットに移行する方法について詳しくは、こちらのリンクをご覧ください。

タイルの横向きカルーセルを使用する古いデバイスでは、ウィジェットは自動的に全画面タイルとして表示されます。

また、Wear OS 4 との完全な下位互換性も備えています。

また、こちらのリンクでは、下位互換性について詳しく説明しています。

他にも、すでにウィジェットを導入しているパートナーがいくつかあります。

このとおりです

私からは以上です。

はい、ニコさんにお返しします。

ありがとうございました

それでは

以上で、このセッションは終了です。

リモート作成の機能の一部を確認しました。

他にもいくつかあります。

非常に豊富なフレームワークです。

利用可能なドキュメントと今後公開されるドキュメントを確認することをおすすめします。

私たちの目標は、Remote Compose を使用して、さまざまなリモート サーフェスに対応できる未来を築くことです。

Wear やウィジェットなど、いくつかご覧いただきました。

しかし、今後さらに多くの機能が追加される予定です。

また、これは継続的なプロジェクトであるとも言えます。

現在も開発が続けられています。

Google は、これらすべてをオープンに開発しています。

何をしているか確認できます。

でも、デベロッパーの皆様からのご意見をお待ちしています。

私たちはそのシステムを、お客様が使用できるようにしています。

他にもアイデアやご要望がございましたら、ぜひお聞かせください。

ご意見をお聞かせいただければ幸いです。

最後に、先ほどご覧いただいたプレゼンテーション全体は、アニメーションも含めて、すべて Remote Compose で作成されたものです。