📝
Google I/O 2021: AMA Jetpack メモ
Google I/O 2021初日に行われた AMA: Jetpackセッションについて、抜粋してメモ的に書き起こしてみました。
（開始は9:40付近〜）
（Jetpack Compose用のAMAがあるのでCompose以外の質問を中心に答える、とのこと）
Q: AndroidXライブラリの多くは開発の進捗が遅いように見える。今のペースに満足していますか？それとも開発リソースが分散していると感じていますか？
Jetpackのペースには満足している。
- 確かに多くのライブラリがある。
- すでにあるライブラリへのサポートの最適化はいつも考えている。Alphaのものもあるので、Stableにしていかなくてはならないし、新しいコンセプトの実装もフィードバックを受けながら進めたい。そこにはどうしてもトレードオフがある。
- 質問に直接的に答えると、Jetpackのペースには満足している。Google Playのトップアプリ1,000個の内、実に88%に何らかのJetpackライブラリが導入されているし、この調子で今後も継続的にコミュニティをサポートしていきたい。
Q: LiveDataは非推奨になるの？
tl;dr: No.
- Javaにとっては唯一のソリューションなので、LiveDataはなくならない。とはいえ、Flow含めKotlin Coroutineの割合を徐々に増やしているのは皆さんもお気づきかと思う。JetBrainsと密に連携してAndroidへの対応がしっかり入るようにしている。現に新しいライブラリをCoroutinesベースにしはじめている。
- ライブラリがCoroutinesを使っているという理由でデベロッパーもCoroutinesを使うメリットはあるが、だからといってJavaへのサポートが無くなるわけではない。むしろLiveDataはJavaユーザーへの後方互換となるだろう。
- LiveDataはとてもシンプルでいい。RxJavaやCoroutinesのほうが複雑。Coroutinesを簡単にするように努力はしているが、シンプルなケースではLiveDataもアリ。
- LiveDataとFlowを比較と移行に関するブログ記事を公開したので、そちらも参照してほしい。
Q: Mutiple backstacksってなにがどうなってるの？
Multiple backstacks…複数の画面を状態を保存して復元できるという概念。
- BottomNavigationとか。
- ちょうど今日、Multiple backstacksに対応したNavigation ComponentsとFragmentsのライブラリを公開した。Navigation UIを使っている場合はデフォルトでオンになっているので、導入は簡単。BottomNavigationやNavigationViewを使ってる場合は自動的にそれっぽい画面遷移になる。Navigationを使っていない場合でも、Fragmentsに対応するAPIがある。
- さらに、Navigation Composeも対応した！こちらも2行の修正で済む。併せてドキュメントなども全部更新しました。
Q: Coroutinesの代わりにWorkManagerを使ったほうがいい場面は？
どれくらいタスクがクリティカルかによる
- アプリがフォアグラウンドにいるときだけ必要な場合は、Coroutinesでいい。
- CoroutinesはScopeと紐付いてるので、FragmentやActivityに紐付いたものだといなくなったときにキャンセルされてしまう。
- アプリのライフサイクルを超えてタスクを実行する必要がある場合は、WorkManagerを使うべき。
- 先送りにできるかどうかがポイントで、アップロードやダウンロードなどの重要なタスクはUIがいなくなってもやる必要がある。WorkManagerはまさにそういうタスクに向いてる。
- WorkManagerがカバーできる範囲を広げてフォアグラウンドサービスもできちゃうからわかりにくくなったよね。
- WorkManagerのほうが裏側がかなり複雑なことは意識しておいたほうがいい。アプリを起動したり、ネットワークを探したりはすべてコストがかかる。Coroutinesで動くなら、Coroutinesを使ってしまったほうがいい。
- ただまぁ、WorkManagerでCoroutinesを使ったりもできるから完全に独立はしてないよね…笑
Q: Githubを介してコントリビューションできるようにしてるの最高。コミュニティ側でコントリュートできるライブラリを増やすつもりはある？
増やしたいけど、そこまで単純な話じゃない。
- やってみた人はわかると思うけど、Githubはただのミラーで、投稿されたものはAOSPインフラに取り込まれて内容が検証される。この取り込むプロセス含め、メンテナーがPRを読む時間などがオーバーヘッドとなってしまう。
- コミュニティからのコントリビューションが増えてきている中、ワークフローの問題も見えてきててそちらを直している。これからコントリュートしてもらえるライブラリは増える予定ではあるが、今はワークフローの改善に注力している。
- 本当に皆さんのコントリビューションに助けられている。今回入ったFragmentsライブラリのStrict modeなんかは完全にコミュニティからのコントリビューションのみで実装された。すごいことだしすごく嬉しい。
- コントリュートできることを探してるひとはBugBountyリストもみてね。
Q: KMMの人気が出てきているが、JetpackライブラリをKMMに対応させる予定はある？
Yes…?
- もちろんKMMの動向は注意深く追っていて、どう使われてるか、ライブラリを対応させるとはどういうことかを考えている。対応の検討はしているが、今のところはAndroidの対応を優先する。
- 決して他のプラットフォームに対応しないということではないが、もしやるとしたらJetpackの使いやすさも上手く移植したい。KMMは出たばかりの技術なので、限られた用法では使いやすくできるかもしれないが、たくさんの人が使うようなライブラリに仕上げることは難しい。なので、対応しないわけではないが、具体的な見通しはない。
- KMMに対応するには、まずKotlinに対応する必要がある。ここ数年ライブラリをKotlinに寄せていくことをやってきてはいるが、まだまだ対応が必要。Jetpack側もJetBrains側も両方協力して進めてる。
- Kotlinを使いはじめて5−6年になるが、公式に扱うことが決まったあともJetpackライブラリをKotlinに移行しはじめるのに時間がかかった。Javaから離れたくないクライアントがいたり、コード量の問題があったり、R8の改善をおこなったり。ようやくKotlinで書き始めた段階。
- さんざんKotlinに移行しろとは言ってきてるが、我々もKotlinに移行するのはかなり苦戦している笑
Q: MVIのようなリアクティブパターンに対しては、どんなサポートが提供されていますか？
特にMVIのような個別のパターンは意識していない。
- MVIのような個別のパターンは特に意識していなくて、単一データフロー全般に対するドキュメントを公開してきた。データがアプリ内でどう流れるかのベストプラクティスのほうが、どんなパターンを使うかより重要。
- 例えばComposeではUIレイヤーでデータを取り込むAPIを用意している。また、ViewModelレイヤーからのFlowsやObservableデータホルダーを読み込む方法などのガイダンスを用意している
Q: DataStore、古いOS向けの互換性は追加される？
質問の意図がちょっとよくわからない。。14までの後方互換性はすでにある。
- 確かに考えてみたら面白くて、Jetpackのほとんどのライブラリはもう何年も互換性がある状態で、Androidのアップデートを待たなくても利用できる。Jetpack Composeだってパフォーマンスを担保するためにArtとかの条件が厳しいにもかかわらず、21までの互換性がある。
- AppCompatなどのコアなライブラリも後方互換性をもっているので、開発しているときは一つのターゲットに対してアプリを作っておけば全部に対応しているようになってる。
- もしかしたら「他のOS」とかを指してるかも？RaspberryPiのサーバーがあるけど、そこでDataStoreを使ってる。Androidですらないけど、構造化したデータを保存する必要があってDataStoreが一番簡単じゃん、ってなったので使ってみた。
Q: Security-Cryptoのようなライブラリを使えば、RoomやDataStoreをセキュアにすることができるが、そういう対応は考えているか
（Roomは）すでに安定してる方法はあるのでそちらを使ってほしい。
- 具体的にSecurity-Cryptoがどのようなライブラリかはわからないが、AndroidXの一部としてセキュリティ系のライブラリはあって、それを使ってEncrypted SharedPreferencesを実現している。DataStoreも暗号化版を用意する。
- DataStoreにはシリアライズAPIがあるので、今の時点で自前で実装することも可能だが、SharedPreferencesと同様に暗号化の機能を内蔵させる予定。
- Roomも同様にSQLCypherを使って暗号化を実現できる。暗号化版のRoomを提供するかどうかは検討はしているが、正直まだ決めていない。すでに存在するものを提供することに価値があるかどうかがわからない。
- ただすでに安定してる方法はあるのでそちらを使ってほしい。
Q: LiveDataからFlowへの移行ガイドのように、CameraX、WorkManager、Paging3といった新しいAPIへの移行ガイドは提供される？
移行する方法がほしければ、実現に向けて働きかけるので言ってほしい。
- LiveDataからFlowへの移行ガイドは先ほどあがったやつですね。いい記事なのでぜひ読んでほしい。
- 他のAPIは、もしかしたら提供するかも。こういうガイドは皆さんのリクエストによるものもある。移行する方法がほしければ、実現に向けて働きかけるので言ってほしい。理想的には全てにガイドがあるといいが複雑なので、言ってくれれば多分出せるようにリソースを調整する。
- 補足すると、実はすでにdeveloper.android.comにはPaging2からPaging3への移行ガイドはある。ViewPagerもある。Navigationも複数ActivityからFragmentを使ったNavigationへの移行ガイドがある。結構書いてるし、もちろんこれからも増やしていく方針。
- IssueTracker（issuetracker.google.com）にもドキュメントに特化したコンポーネントがある。こちらはドキュメントで、ブログ記事は例を使ったガイド、どちらもぜひ増やしたい。（どんなのがほしいか）教えてほしい。
Q: Jetpack update videoに関して：Jetpack系ライブラリは以後alpha/betaリリース「だけ」になるのか、RCを含めたリリースサイクルを継続するのか。後者の場合はRCとbetaの違いは？
RCリリースはこれからもあると思う。
- alphaは初期リリース。Stableに入る前にbetaを経由して変更を加えられるようにして、バグを拾ったりフィードバックを貰えるようにしている。
- RCリリースはこれからもあると思う。昔を思い出してほしいけど、みんなSupportLibrary26.0.5くらいまで待ってから実装してたよね？そういうのはもうやめたい。
- チームのルールとしてStableはRCの最終盤と同じである必要がある、というのがあって、RCに対してバグ修正をいれたら新たなRCをリリースするようにしている。Stableに入る前にPlay Storeの導入件数をみて安定度合いを見る。そうすることでStableの安定性に自身がもてるようになっている。
Q: Flowはこの先どうなる？Alpha/Betaを抜けるのはいつ？
すでにFlowはAlpha/Betaステージではない
- FlowはAlpha/Betaステージにはすでにない。ほとんどのAPIはすでにStable。最新の1.5ではよく使われていたCallbackFlowやChannelFlowもStableになっている。The future is now!
- これからドキュメントを増やしたり、ガイドを用意してたりする。LiveDataのドキュメントとかも更新していて、「LiveDataはこの用法だけに使ってね」みたいなコメントを追加している。
- Android API surfaceにどんどんFlowが浸透していってる。たとえばComposeのAPIにもFlowかなり使われている。
- Paging3では内部的にかなり書き換わってるが、すごくきれいになった。みんなのアプリがすっきりするだけじゃなく、ライブラリそのもののメンテナンスが楽になったり、理解しやすくなってる。加えてDataStoreもCoroutinesを使ってるし、WindowManagerもそうだし。中核をなすライブラリの多くをCoroutinesベースで書いている。
- これからはFlow。もちろんデベロッパーに寄り添った開発がしたいのでRxJavaとかも対応していく。
Q: KSPへ徐々に移行していく予定はある？
KSPがStableになればRoomのKSP対応もStableになる。Dagger、HiltやGoogleのライブラリも移行を検討している。
- KSPはKotlin Symbol Processing。Javaのアノテーションプロセッサーにちょっと近い。RoomやDatabindingなどにアノテーションプロセッサーがいくつか入っているが、Kotlinでアノテーションプロセッサーを使おうとすると、そのためだけにKotlinがJavaのスタブを生成する手順がはいる。KSPを使うと、直接Kotlinのコードを解析できる。
- ここ7-8ヶ月ほどRoomのKSPを作っていて、対応することができた。KSP自体がまだStableではないので、まだ実験的なサポートではある。KSPがStableになればRoomのKSP対応もStableになる。KSPに対応したからといってRoomがKotlinを吐き出すわけではなく、まだJavaベースではある。Kotlinコードの生成も予定はしている。
- Roomには対応しているが、Jetpackのすべてのアノテーションに対して対応を行うわけではない。重要なものから対応していてRoomが先、Dagger、HiltやGoogleのライブラリも検討している。時間はかかるが、実施はする。Roomのケースではごく簡単なテストでさえ2xの速度がでている。
- Dagger、Hiltで一番言われるのは、ビルド速度に関すること。ほんとKSP対応が待ちきれない。
Q: Wear Tiles APIは、BuilderパターンとかあってあんまりKotlinっぽくない。改善する予定はある？改善を待ったほうがいい？
Stableリリースまで待たないで、Alphaな内にIssueを立てて教えてほしい。
- Wearチームの動き見てるとすごい。いろんなAPI面をKotlin化してる。WatchFace APIとか完全に書き換わっていて、Kotlinのよさを取り込んでいる。ほかのAPIも同様になるはず。
- Wear関連、とくにWear Tiles APIはまだまだAlphaの段階。コアな部分は同じかもしれないし、BuilderパターンはJava向けに残ったりするかもしれないけど、だからといってそれ以外にAPIがあってはいけない訳ではない。
- IssueTrackerにもWearコンポーネントがあるので、Stableリリースまで待たないで、Alphaな内にIssueを立てて教えてほしい。
- ひとつのコミュニティとしてライブラリを作り上げてるので、これ以外にも「こうすれば簡単になるんじゃない？」みたいな意見はどんどん知らせてほしい。一緒に最高のライブラリをつくろう。
Discussion