こんにちは。Androidエンジニアの半揚@cffYoHaです。2023年9月14日(木)〜16日(土)の3日間開催されたDroidKaigi 2023に参加してきました。本記事では、新卒Androidエンジニアの木川@E_oxypetalum_7と、DroidKaigiの様子や印象に残ったセッションを紹介していきます。
DroidKaigiの様子
半揚は、昨年のDroidKaigiに引き続き2回目のオフライン参加でした。スポンサーズディナーやネイル体験会など、新たな経験ができて非常に楽しいカンファレンスでした。昨年よりも知っているエンジニアの方が増え、理解しているライブラリやAPIが増えるとともに、わかっていないワードも増えた気がしています...
フェンリルは今年もゴールドスポンサーとしてブースを出展し、多くのエンジニアの方と交流することができました。今年用意したノベルティの「ソース」は、もちろん「ソースコード」と「ソース」をかけたギャグです（笑）。
DroidKaigi 2023 では、新たな取り組みとして「フェンリルソースチャレンジ」を実施しました。
「ノベルティのソースについているラベルを正しく表示できる Composable 関数は4つのうちどれか」を当ててもらうチャレンジとなっています。Modifierの順序を問うものとフォントが異なるものがあり、ソースコードは木川が実装しました。「おもしろかった、勉強になった」など多数の嬉しいコメントを頂きました！
セッション紹介（半揚）
まずは、半揚が気になったセッションの紹介です。
Deep dive into size configuration changes
サイズに関する“configuration changes”についてのセッションでした。landscapeとマルチウィンドウモードの利用割合が高いことが、Large screenの特徴のようです。加えて、landscapeでのマルチウィンドウで画面分割をした際に、比率によってはウィンドウがportraitに変わってしまうという状況も発生します。これらの操作によって、configuration changesが頻繁に発生するとのことでした。
configuration changesが発生するとActivityが再作成されますが、その発生はユーザーの操作により発生するため、予測はできません。そのため、実装側がconfiguration changesに対して講じてきた手段の変遷について、紹介されていました。
API 23までは、Activityの再起動が行われる挙動であったため、Activityを監視すればよかったのですが、24以上からは、大規模なconfiguration changesの場合にActivityの再作成が発生します。反対に、小規模なconfiguration changesの場合は、Activity.onConfigurationChanged()とView.onConfigurationChanged()が呼び出されます。しかし、API 30〜33 ではActivity.onConfigurationChanged()は呼び出されないようです。
developer.android.com
これらの複雑な仕様は、API 34で呼び出されるように修正されているようです。オフライン会場では、スピーカーの方が「修正してもらうよう頑張りました！」と言っていて、笑いが起きていました。現状のおすすめとして、View.onConfigurationChanged()もしくは、LocalConfiguration.currentをモニターするとよいとのことでした。
私はまだLarge screen対応の経験がありませんが、着実にLarge screen対応の時代が来ていることをひしひしと感じるセッションでした。
Jetpack Compose の Side-effect を使いこなす
Jetpack Composeで用意されている、各Side-effect APIについて、具体的なコードを交えながら紹介するセッションでした。LauchedEffectとDiposableEffectの違いや、rememberUpdateStateが必要かどうかといったAPIの紹介以外の比較やユースケースについても触れていました。
私は、Jetpack ComposeをCodeLab等で一通りかじったものの、8つもAPIがあると使い分けが難しく度々混乱することがありました。Side-effect API初学者にとっても易しい構成で、大変参考になりました。
パフォーマンスの低下につながる事例の紹介として、LazyListのstateをLog出力するものがありました。状態を参照してLogを出力するような場合、SideEffectで囲うことでRecompositionの発生を防ぐことができるようです。
セッション中に紹介されていたLogを出力するコードは、基本的にはデバッグや原因調査等で一時的に書くだけにとどまります。しかし、最終的なコードに残っているとパフォーマンス低下につながってしまうため、注意が必要とのことでした。
セッション紹介（木川）
ここからは木川が執筆します。気になったセッションを紹介します。
Kotlin ハイパフォーマンスプログラミング
スピーカーの大前さんが、Yahoo! 天気アプリの「風レーダー」という、風の様子を粒子アニメーションで表示する機能の実装を通して得たKotlinパフォーマンスチューニングに関する知見の紹介でした。
モバイルKotlinのパフォーマンスにはメモリが重要であり、Kotlinの醍醐味であるスマートな記述も時にはボトルネックになっている、ということをJavaでデコンパイルされたコードを交えながら説明頂きました。詳細はスライドの方を参照して頂きたいのですが、分解宣言のセクションでは、ゲッターメソッドの戻り値ではなく引数に書き込み先を渡すタイプの関数設計について納得することができて、勉強になりました。
また、計算量でお馴染みのランダウの記号について「あくまでもランダウの記号による計算量は計算回数が十分に大きい時の性質を表します。ですが、今実装している処理は実際どれだけの回数処理されますか？」というメッセージにハッとさせられました。数学的な検証はプログラミングにおいて重要ですが、プロダクトに対して実際に求められている動作要件は何か？という問いを意識してプロダクトを作っていきたいと思いました。
Jetpack Compose で Android/iOS アプリを作る
今年5月末にCompose for iOSがアルファ版となったCompose MultiplatformとKoltin Multi Platform（KMP）を組み合わせて、Android／iOSどちらでもビルド可能なアプリを実際に制作した際のレポート的なセッションでした。
モバイルでのクロスプラットフォームにおいてポピュラーとなりつつあるFlutterでは、Dartによる記述が求められる上に、AndroidまたはiOSの機能を要求するような部分ではKotlinとSwiftでの書き分けが求められます。一方で、Compose Multiplatform + KMPでは両OSのほぼ全ての実装が馴染み深いKotlinで完結できるという点において非常に魅力的に感じました。UI部分についてはComposeで書かれた共通コードが利用されていて、各OSで書き分ける必要があるロジックなどは、expect funとactual funという一対になる関数宣言を用い、actual funにて各OSでのロジックを実装し、expect funにてOSごとに適切なactual funを呼び出すことでマルチOSな実装を実現できるそうです。
まだ発展途上なシステムということもあり、KMPで実装する部分には両OSで利用できるライブラリを利用する必要があったり、デモンストレーション上ではiOS側にもMaterial UIが適応されていたため各OSに適したUIにするには一工夫必要そうな印象を受けました。ですが、DroidKaigi 2023の公式アプリにもCompose Multiplatform + KMPが利用されており、こちらのUIは両OSに調和するデザインだったため工夫の余地はありそうでした。今後に期待したいトピックだと思います。
おわりに
DroidKaigiに参加するのはオンライン・オフライン共に初めてでした。ブースにてさまざまな方とコミュニケーションを取ったり、セッションでホットなAndroidの話題を聴くことができて非常に楽しかったです！
また、3日目のCodeLabにも参加しました。会場で出会った人と楽しく会話しながらDroidKaigiの公式アプリへのコントリビュートに挑戦し、非常によい体験ができました！
今回のカンファレンスで得た知見や経験を今後のプロダクトに生かしてまいります！
