DroidKaigi2025の参加したセッション等のメモ(当日編)
今年もDroidKaigiに参加してきました。見られなかったものも録画で見てもう一度書くつもりですが、スピード重視で当日見たセッションのメモを書き留めておきます。
ちなみに自分はAIエージェントについて興味があり、KoogやAIなどのセッションについて多めです。
雑にまとめてる部分もあるので、わからんという方は気軽にコメントください！
目次
- Building cross-platform apps in Kotlin with Compose Multiplatform
- DroidKaigi2025 セッション1日目
- DroidKaigi2025 セッション2日目
- 全体的に
Building cross-platform apps in Kotlin with Compose Multiplatform
初日のCMPのワークショップ。
セバスチャンさんとマートンさんの講義。
去年はFleetという新しいIDEを使ってのCMP講義でしたね
CMPは馴染みがあるのではじめて知ったことを中心に。
expect/actualのクイズがあった。jvmのみターゲットなら、commonMainからJVM呼べるということを知った(が必要なケースは多分少ない)。
(expect/actualの作り方ですが、こちらは関数やクラスそれぞれに推奨があり公式に詳細なガイドがあるのでおすすめです。)
JetbrainsのtoolboxやkotlinconfのアプリもCMPで作られている。(Junieもだけどそれは知ってた。確かgemini code assistもそう)
bilibiliもCMPで作られているらしい。
CMPはvoice overもサポートされているらしい。
Hot reloadははじめて触りましたがかなり良かったです。デバッグ用のビューもあり、JVMデスクトップのみですがこれは使っていきたい。
これを使うためにJVMのターゲットを入れるのも場合によってはありかも？
去年と比べてCMPのエコシステムも充実し、力の入れ具合が伝わりました。製品レベルでも採用が増えてきそうな予感がします。
講義後には質問の時間があり、講師さんの前に行列ができていました。私も思い切ってKoogについて質問し、日本語での発音はなにか聞きました。クーグで良いとのことでした。
DroidKaigi2025 セッション1日目
KotlinでのAI活用による開発
セバスチャンさんとマートンさんによるAIコーディングとKoogに関する紹介。
AIコーディングですが、最近IDEではVSCode触ることも多いのですが、同じようなことがJunieや補完などでだいたいできると知りました。
Koogですがopen routerのproviderを使うのがおすすめとのこと(プリペイド払いいける)
Agent.asToolsでエージェントをツールとして使える。
Agentはジェネリクスで型指定できるのは知っていましたが、inputType = TypeOf<String>()みたいに引数で型を渡すこともできる。
Ask the speakerで質問に行きました。
KoogはLangChainとLangGraphの領域にまたがって、両方を一つのライブラリで達成するものと捉えてよいか -> Yes
実例はある？ -> YouTrackはKoogを使っている。JunieはもともとKoogを使っていなかったが、今移行中とのこと。
Koogはマルチーエージェントの領域をカバーしているといえる？ -> たぶんYes
ユーザーのpromptに追加の文字列を加えるなど、単純な処理をStrategyGraphの中に置くべきか、外に置くべきか -> 場合による
UIだけじゃないComposeの可能性 ━ 宣言的に奏でるメロディ
Compose Runtimeがとても分かりやすく理解できるセッション。
各コンポーネントの連携と役割が整理されました。
Koruriというプロジェクトをもとに、音を奏でるアプリをCompose Runtimeで作る。
SineWaveやVolumeなどをChainやMixなどのComposable関数で合成。(UIで言うとRawとかに近い？)
KoruriのコンポジションツリーはUIツリーに統合可能。
他のセッションにもありましたが、MapのSDKの内部を見ているとCompose Runtimeの登場人物が出てきたりして、ここでの知識があると理解の助けになります。
またComposeの中を理解するのはやはり重要なので、初学者の方から万人におすすめのセッションです。
参考文献としてありましたがmosaicは自分も見たことが有り、おすすめです。compose internalはまだ読んでないので読もう。
あと個人的にこちらの記事もおすすめです(Slot Tableの話は２日目のセッションでも出てきます)->Inside Jetpack Compose #Android - Qiita
Android開発者のためのGen AI
Gemini NanoやAIのしくみ、プロンプトエンジニアリングの話。
AICoreというシステムサービスはGeminiNanoを動かすランタイム。
GenAi Apiとprompt Apiが使える。GenAi APIは翻訳やSpeech to Textなど事前に定義されたタスクを実行する。
量子化を使ってモデルを軽量にする。
クラウドを使うなら、Firebase AI Logicを使う。
ベクトルやトランスフォーマー、temperatureの話もある。AIの基礎を知りたい人にもおすすめ。
LLMの評価に、サンプルとしては200個あると良い。100個くらいでもいいがデータの質は良いことが前提。
metricsとしてAccuracy, Precision(適合率), Recall(再現率), F1 Scoreを使う。
Precisionは偽陽性をはかる。
Recallは正解の見落としがどれくらいあるかをはかる。
F1 ScoreはPrecisionとRecallのバランスを取る式で評価
他にいろいろメトリクスがあるので、検索してみると出てくる(翻訳や要約にはそれ用のメトリクスがありました)
temperatureに関してどの値から始めましょうという話
感情的な刺激をLLMに与えると良い
プロンプトは英語でとか、LLMが苦手なスコアリングは避けて分類に置き換えるとか
いろいろなプロンプトのテクニックがまとまっていました。
Ask the speakerではビルドにGeminiNanoを含めてダウンロードが不要にならないか質問しました。
システムサービスを使っているので他のアプリがダウンロードしては不要になるそうです。
現状初回はダウンロード必要になるそうです。技術が進めばいずれダウンロード不要になるかも？という話も出てましたがこれは推測。
またローカルLLM使うメリットとして、コストだけでなくセキュリティの観点があり、これは法規的にローカルLLMでないとクリアできない場合があるとのことです。
Androidライブラリアンの手引き：堅牢なライブラリとSDKの構築
ライブラリではpublicにするAPIを最小化する必要がある
内部が見えてしまうといろいろとデメリットがありよくない。
interanal/publicなど可視性の修飾子を適切に使う
javaコードからのKotlinコードの可視性のための@JvmSynthetic(internalだけだとアクセスできてしまうらしい)
explicitAPIはpublicをつけないコードにアクセスするとエラーを発生させる。たくさんのコードの可視性を管理するのに便利。
@Deprecatedアノテーションのレベルや、削除するまでの運用方法
binary compatibilityは、バイナリを再コンパイルせずに、より新しいバージョンのライブラリや環境で動作させる能力
MatravaはAPIのbinary compatibilityをチェックするツール。
リソースの可視性、resourcePrefixとか、non-transitive Rclassの話など
ライブラリの可視性の管理の話が網羅されていて、ライブラリを作ったり、ライブラリを使っていてトラブルが起きたときに、振り返りたい。
Androidエンジニアとしてのキャリア
自分に刺さる内容でした。
キャリアプランとか漠然としか考えていなかったのですが、やりたいことから逆算してある程度見通しを立てて計画を立てることが重要。
そういうことをあまりできていなかったので、ちゃんと考えようと思いました。
コミュニティに属するということもメリットとか、パーソナルブランディングとか、メンターの存在とか
mhidaka氏についても知らなかったことが知れて、面白かったです。
自分のミスですが、Ask the speakerにたどり着けなかったのが痛い。
DroidKaigi2025 セッション2日目
Compose Multiplatform × AI で作る、次世代アプリ開発支援ツールの設計と実装
ComposeFlowはドラッグアンドドロップでCompose Multiplatformのアプリが作れるツール。
ComposeFlowのUIビルダー自体もCompose Multiplatformのアプリで、Node treeを管理していて、
ドラッグアンドドロップでUIに変更があったときに再構成される。
modifierの順番は重要ですが、ComposeFlowを使うとドラッグアンドドロップで即座に影響を確認できるので、これは便利。
各ノードはコードの生成方法を知っていて、generateCodeでコード生成する。KotlinPoetを使っている。
ComposeNodeは@Serializableクラスでyamlで出力される。
プロンプトはキャッシュできるらしい。コンテキストを節約できるらしい。
YAMLからjsonにパースする方法が紹介されていて、Koogの話も出ていました。
AIコーディングエージェントのフローは難しそうだけどワークフローとしてはシンプル。
ノウハウとして、LLMに詳細なフィードバックを返すことが重要とのこと。
デフォルト値を与えることも重要。
Ask the speakerでは、AIエージェントの評価について聞きました。
Pythonのフレームワークではビルドインの仕組みがあるらしいです。
Androidは裏でどのようにデータ構造を活用しているのか
データ構造を理解するのは大事。意思決定や正確なデータ構造を選択するうえで重要。
LRUキャッシュはLinkedHashMapで実装されている。
(LRUキャッシュはあまり使われていないデータから削除するもの)
DaggerのDagはDirected Acyclic Graph(有効非巡回グラフ)
これはグラフが循環せず、ある頂点から同じ頂点に戻ってこないということ。
このデータ構造を利用して、Daggerは循環参照をエラーとして検出する。
DaggerはBFS(幅優先検索)で2つのノード間の最短のパスを検出して、有用なエラーログを出す
続いてUIの話で、findViewByIDよりViewBindingが良い。
ビューは木構造で、DFトラバーサル(Depth-First Search)で探索する。
これが前者なら毎回探索することになるが、後者はキャッシュされ、毎回検索しなくて良い。
Composeは裏でSlotTableというデータ構造を使っている。
GapBufferはテキストエディタで使われる構造。これで再構成を効率的に処理できる。
この辺疎いですが知りたくなるときはあるので、必要になったときにまた見返したい。
Metro で学ぶ依存性注入のナビゲーション
今注目のDIフレームワークであるMetro、そのオーナーさんであるZac氏のセッション。
DIの基礎からMetroのコンセプトまで学べるようになっています。
DroidKaigiのカンファレンスアプリでMetroをちょっと触って、良さそうだと思っていました。
導入も簡単だし、またセッションの中にありますがビルドのパフォーマンスが良い。
Kaptを使っている場合ビルド時にいくつもの処理が必要だが、
MetroはKotlinの中間表現を使っているため、そこが大幅に短縮される。
debugのオプションが用意されている
相互運用性やマイグレーションも対応している
IDEサポートは現状一応できるが難易度が高め、将来機能として専用のIDEプラグインがサポートされる予定
Be a Business-Driven Android Engineer
モバイルエンジニアが売上をKPIに持った話。
KPIを作るところから苦労したとのこと。ビジネスチームとのコミュニケーションが重要。
RemoteConfigで簡易バックエンドを作っているとのこと。
全体的に
世間の流れ的に、Google I/Oとか聞くとAIの話ばかりだったりするのですが、
DroidKaigiのセッションはバランスが良く、またAIに聞けば分かるような話ではなく、
深く切り込んだ話やいろいろな知見がまとまったものが多く、非常に有意義でした。
またリアルイベントでいろいろな人の話を聞いたり、話たりすると、いい刺激となります。
自分の知識や仕事、キャリアについて見つめ直す良い契機となりました。
あと個人的に英会話も学びたいなと思いました。