はじめに
こんにちは。asken Androidエンジニアの永井です。
大規模なAndroidアプリ開発において、複数のActivityを管理するのは複雑でパフォーマンスの低下を招く可能性があります。そこで注目したいのがSingleActivityとNavigationという強力な組み合わせです。今日はこの組み合わせがもたらすメリットについて話したいと思います。
この記事は、株式会社asken (あすけん) Advent Calendar 2024 の5日目の記事です。
SingleActivityとNavigationとは
Googleが提案する遷移アーキテクチャで、従来のActivity間での遷移における課題を解決することができる画面遷移の方法です。
従来のActivityの課題
Activity間での遷移管理の複雑さ： Activity間のIntentによるデータの受け渡しやFragmentの管理など、画面遷移に伴う処理が煩雑になることで、特に深い階層となるとコードが複雑化しバグを生みやすくなります。
バックスタック管理の難しさ： AndroidのバックスタックはActivity単位で管理されるため、複雑な画面遷移ではバックスタックの状態を正確に把握し、管理することが難しくなります。
Activityが有するリソースの無駄： 画面遷移によりActivityの生成および破棄が頻繁に発生するため、これによるメモリ消費量が増加しパフォーマンス低下につながります。
SingleActivityとNavigationComposeのメリット
SingleActivityはその名の通り、一つのActivity上でアプリのすべての画面遷移をおこないます。 そもそものActivity間の遷移がなくなるため、画面遷移での複雑さによる課題が解消されます。 そしてバックスタックの管理もNavigationComposeによって効率的におこなうことができるようになります。
NavigationComposeとは直感的なDSLで記述することができる画面遷移方法で、JetpackCompose前提で設計されているため画面描画との親和性が非常に高いです。 さらにDeepLinkやバックスタック管理がしやすい上に、タブやドロワーといったNavigationコンポーネントとも相性がよく効率的に実装することができます。
導入における懸念点
大規模なリファクタリングに伴うコスト： 現存する画面をすべてComposeへ変換しデータおよび画面の流れを整理していくため、画面数によっては膨大な工数が必要になります。
学習コスト： チームメンバー全員がSingleActivityやCompose、NavigationCompose、そして場合によってはJetpack Navigationの知識を習得する必要があります。
データの整合性： Composeへ移行するにあたり、既存のコードとの間で、状態管理やデータのやり取りなど、整合性を維持しながらどのように変更していくか考える必要があります。
まとめ
この遷移アーキテクチャを採用することで、アプリ全体の構造がシンプルになり可読性を高めることができ、そしてActivity遷移時に必要だったIntentの発行などボイラーコードが不要になることから、生産性を高めることができます。 またActivity生成破棄に必要だったメモリが削減されることで、遷移パフォーマンスが向上し、よりよいUXにつながります。
そしてこれらComposeを中心としたGoogleのメインストリームに寄せていくことが、Viewからの脱却然りネイティブの恩恵を受けることに繋がり、ひいては開発効率の底上げだけでなくAndroidアプリとしての生き残りへと大きく寄与していくと思います。
まだActivityの遷移が残っているプロダクトは一度導入検討してみてはいかかでしょうか？
積極採用中です
askenではエンジニアを絶賛募集中です。
まずはカジュアルにお話しできればと思いますので、ぜひお気軽にご連絡ください！
