Zenn
📝

Google I/O 2022 Fireside Q&Aメモ

2022/05/16に公開
Android
tech

Google I/O 2022で開催されたFireside Q&Aが開催されて、Compose、大画面対応、Wear OSなど幅広いジャンルの質問がピックアップされていました

(Q&Aセッションは15:30あたりから)

Q: なぜダッシュボードをなくした？

（OSバージョンや画面サイズを調べるのに便利だったダッシュボードについての質問）

  • Android Studioに内包することにした
  • 新しくプロジェクトを作る際にダッシュボードと同等の内容を表示している

Q: OEMのバッテリー最適化について、なにかできることはないか？

  • まず、バックグランド処理についてのセッションがあるのでそちらを見てほしい
  • OEMとの関係について
    • 他のプラットフォームと違ってAndroidは「GoogleのOS」ではないので難しい問題
    • 逆にそのことが様々なカスタマイズや革新を可能にしている
  • バッテリー最適化
    • OEMがかなり気にしている部分で様々な工夫をこらしている
    • 開発者からするとちょっと工夫しすぎているようにも見えたりする
  • OEMとは継続的に議論していてOEM側の対応を減らしたり、問題視して入れた改善をプラットフォーム側にも取り入れている
    • JobScheduler
    • Doze mode
    • App Standby
    • バックグラウンド実行制限
    • バックグラウンドからのアクティビティの起動に関する制限
    • フォアグラウンド サービスの起動に関する制限
  • デベロッパーからはあまり歓迎されていない機能だということは認識している
  • OEMがそれぞれ対応するよりプラットフォームがまとめて対応したほうがよいというのが対応した理由の一つ
  • （Androidでは）OEMのエコシステムとアプリのエコシステムふたつがある
    • OEMは短期的にみていいデバイスを作ろうとしていて、アプリのエコシステムはあまり重視していない（悪い意味ではなく）
    • アプリのエコシステムが長期的にみて健全な状態を保てるようにするのがGoogle側の役割
    • 今はアプリのエコシステムに害を与えるような方向に行き過ぎていると思っているので、よりよい環境に戻そうとしている

Q: Jetpack ComposeでのアニメーションAPIは今後も発展する？それとももう完成？

  • 「ソフトウェアだよ？完成なんてないさ」
  • まだまだ開発中
  • Shared element transitionsはまだExperimental API
  • Viewシステムではアーキテクチャの制限があったのでやりたくてもできなかったことが多い
  • なのでComposeはよりよいアニメーションAPIを提供するチャンスだと思っていて、まだまだ開発は始まったばかり
  • どういうアニメーションが欲しいかのフィードバックがほしい

Q: ライブラリでComposeを使うとどんな問題が発生する？

Q: 大画面対応について、直近のリリースではどのようなことをしている？

  • Android12Lからはマルチタスキングがしやすいような工夫をしている
    • マルチタスクを主眼とすることで様々な変更が入った
      • 互換モード、縦向き・横向きレイアウト、アプリを回転させたり
      • ドラッグ・アンド・ドロップも重要になってきている
      • フォルダブルのposturesも
    • まだまだスタート地点で、大画面デバイスの魅力を最大限に引き出せるようなOSの大規模アップデートが入っている
  • 開発者向けにはAndroid Studioのresizable emulatorが入った
    • 画面サイズを動的に切り替えられる特別なシステムイメージ
    • いろんな画面サイズを確認するためでなく、OSの機能としてスマホからタブレットに切り替えたときの挙動が確認できる
    • Android13限定ではある
    • 折りたたみ式端末やデスクトップでアプリがどう動くかを手軽に検証できる方法
  • 大画面デバイスへの対応がしやすくなる方法も考えている
    • アクティビティの埋め込みが良い例
      • アクティビティをベースにしたアプリでも書き換えずにlist-detailレイアウトを構築することができる

Q: アプリの質を高めるために開発者ができることは？

（全員それぞれ自分の担当している領域の宣伝をしはじめる）

Q: 某プラットフォームみたいな絵文字にはいつ対応してくれるの？

「ちょっと聞いたことないプラットフォームだな…」

絵文字の今とこれからについて

Q: なぜAVDはBluetooth接続に対応しないのだろう？

  • 長らく要望として上がっていたが、ちょうどエミュレーターのBluetooth接続機能のCanary版を公開した
    • 仮想Bluetoothデバイスを作ってエミュレーターでつなぐことができる
    • 2つのデバイスをBluetoothでつなげられる

Q: Wear OSの現状と今後は？

  • Wearは"Big" Androidのフォーク
    • （Wearに対してPhoneは"Big"なので内部的にはそう呼ばれている模様）
  • 継続的にWear OSのアップデートを続けていく
  • スケジュールについてはそのうち

Q: Composeでフォームに対応してほしい

  • 機能や開発のスケジュールについては基本的に話さない
  • フォームについてはわからない…が、Composeの開発予定についてはロードマップを公開している
  • 抽象度の高いコンポーネントや基本のウィジェットについて集中している
    • canonical layoutsなど
  • 入力フォームなどその真中に位置するものもある。認識はしていて考えているが明確なスケジュールはない

Q: Live Editはよさそうだが、Instant Runとはどう違う？

  • Instant Runはすべてをいっぺんに解決しようとしていた
    • Instant Runの問題はアプリが自分のクラスのフィールドに状態を持ってしまうことで、Instant Runがそれを検知できなくてうまく動作しなかった
    • Live EditはComposeにだけ特化している
    • メソッド内の変更にスコープを狭めて、compose compiler pluginとcompose runtimeの力を借りることで何が起こっているのかを検知しやすくなった
    • まだまだプレビュー段階なのでフィードバックがほしい
  • XMLでも同様のことはできたはず、という指摘もある
    • Live Editはプレビューだけでなく、動作中のアプリに対しても変更が効く
    • アプリのロジックに手を入れることができるという利点がある

Q: Androidはx86など歴史的に様々なCPUアーキテクチャに対応していたが、なぜかMIPSアーキテクチャにも対応した。なぜ…？

  • x86
    • x86はエミュレーターもあったし、内部的にもプラットフォームやアプリの開発に使っていた
    • PC版のGoogle Play Gamesもある
  • MIPS
    • MIPSももちろんSuperHとかにも対応していたね
      • ちゃんとGoogle PlayもPlay Servicesも対応してた
  • サポートコスト
    • 初期の頃はかなりオープンで特定のハードウェアに対してロックインはしたくなかった
    • ただ特定のCPUをサポートすることは自分たちとアプリ開発者にとってかなりの労力がかかることに途中で気づいた
    • ARMがモバイルのCPUとして台頭するようになって、ほかのCPUへのサポートをやめるようになった
    • Intelでさえ対応しているアプリをみているとテストが不足していたりあまりいい状態ではない
    • 新しいアーキテクチャは全員にとって導入コストが高いので、初期に比べて方針を変更している
  • RISC-VといったアーキテクチャなどもTwitterとかで盛り上がっているのは認識している
    • やはり対応コストが高いので今は静観している

Q: Androidアプリ開発を教えてます。Jetpack Composeから教えるべき？それともViewシステムから教えるべき？

Q: UIだけでない、全体的なWear OS開発に関するガイドなどはある？

Q: Composeを使う場合、Fragmentはもう使わないほうがいい？

  • ComposeはFragmentがあってもなくても動作する
  • Githubのサンプルは単一Activityのものとそうでないものが両方ある
  • Jetsurveyは複数Fragmentを使っているので参考になると思う
  • ほかにもたくさんのガイドを用意しているが、ケースバイケースであることを忘れずに

Q: 開発者にもっと使ってほしいAndroid APIは？

  • Window size classesは使ってほしい
  • AppSearch APIは使ってもらうことでプラットフォームでできることが多くなるのでぜひつかってほしい
  • プラットフォームチームとしては、直接APIを呼んでもらうより、後方互換性を考えてJetpackライブラリが使えないかを考えてほしい
  • というかJetpackと名がつくものすべてを使ってほしい
  • Jetpack ComposeではPreview API
    • ひとつの大きな画面のプレビューよりもパーツ単位の小さなプレビューをたくさん表示できるので使ってほしい
  • ほかのアノテーションも使ってほしい
  • Graphics APIs
    • CanvasはCompose以降使いやすくなってコミュニティによってつかってもらえた
    • （Android 1.0からあるので15年前でも同じものは作れたが…）
    • 既存のコンポーネントでは表現できないことがたくさんできるので使ってみてほしい

Q: Androidが公開されて10年、名前をつけることは難しいことだとみんなわかったが、クラスやAPIの中で一番ネーミングがひどいものは？

  • Spinner
    • 「Spinner」という名前には理由がある（！）
  • ColorMatrixColorFilter
  • 〜X、〜2はやめたいよね
  • 大文字をどこで使うかが曖昧なやつ: HttpURLConnection
    • "misshapen camel case"
  • ListView（？）
  • EditTextはTextFieldのほうがよかった

Discussion