Android 領域における2024年の変化と挑戦

TUANGのプロダクト開発チームでAndroidアプリを開発しているカーキです。 最近は、ダンダダン のアニメ放送に毎週歓喜しています。

2024年の末に投稿しようと思っていたものの、気付いたら年を越して2025年になっていました。

スタメンのAndroidエンジニアは3-4人と、決して大きい組織ではありませんが、機能開発をしつつプラットフォームの改善にも並列で取り組んでいます。 今回のブログでは、2024年の1年間でのAndroidチームでの技術的な変化・挑戦をまとめて紹介します。

Compose のコード規約を作成

TUNAG の Android プロジェクトでは、2021年ごろから Jetpack Compose をUI作成のフレームワークとして導入していました。 これまでは Jetpack Compose について知見にあるメンバーが知見の浅いメンバーに対して教えたり、レビューを通じて知見を共有することで、Jetpack Compose の共通認識を作っていました。

ただ実際にComposeのコードを書くメンバーが増えたときに、複数の書き方があるときにどちらを選択したら良いかが分からないなどの問題が表出してきました。 そこで、これまで暗黙的に共有されていた記述方法を言語化したり、まだチームの中で方針が決まっていなかった部分を GitHub Issues などで議論を深めていきました。

また自社での Compose のコード規約を考える上で、API Guidelines for Jetpack Compose を参考に作成をしました。

コード規約の一部

コード規約は GitHub の wiki にまとめています。

コード規約が策定されたことによって、実装者が安心してJetpack Composeを利用することができるようになりました。 また成果物としてのコード規約の影響だけでなく、チームのメンバーでコード規約を作る過程にも価値があったと感じています。 コード規約では、いくか記述法として方法がある中で「なぜその選択をしたのか」の背景が必要になります。GitHub Issues などで議論を深める中で、「一般的にそう書かれているから」ではなく、「なぜその書き方が良いのか」について話し合うことができました。

様々な方法がある中で、TUNAGというプロダクトでなぜその選択をするのかについて、話し合うことができたのが良かったと感じています。

lintを導入

コード規約の作成に加えて、Compose の記述方法に関する lint をプロジェクトに追加しました。 今まで TUNAG 全体でも linter は未導入だったのですが、プレビュー用のComposable関数のprivate 修飾子のつけ忘れなど、どうしても抜け漏れが発生していました。 Compose のコード規約をチームで守っていくために linter の導入を決めました。

linter としては、detekt を採用しました。 外部から Compose の lint のルールセットを追加できる点であったり、潜在的なバグの検出などのルールが標準で用意されている点で detekt を選択しました。 採用したルールに関しては、自分たちで作成したコード規約をもとに、必要なものを取り入れる形で決めています。

また linter による指摘を GitHub Actions の reviewdogを使って、PRでコメントされるようにもしています。

reviewdogによるlintのワーニング通知

これによってレビュワーによるレビューの前から、問題を検知することができるようになりました。

マルチモジュールのアップデート

TUNAGでは、2020年ごろからマルチモジュールの導入を行っていました。 しかし、この当時のマルチモジュール化は細かい責務分けができていなかったため、むしろ負債になっている状態でした。 そこで2023年ごろから、責務分けなどを考慮した上でモジュールを再編していました。2024年はそれをさらに進化させ、モジュールを介した画面遷移を行うためのNavigationモジュールの作成を行いました。

マルチモジュールのアプリ構成では、モジュールを横断した画面遷移は依存関係が循環してしまうため、機能ごとでモジュールを切ることができませんでした。 モジュールが膨大になってくるとそのままビルドの速度にも影響します。機能をモジュールで分割できずappで実装することになり、ビルドの速度やJetpack Composeのプレビューに時間がかかる状態になっていました。

Navigationという画面遷移の抽象のみを持つモジュールを用意し、遷移実装をappで持たせることで、モジュールの依存関係が循環しないような形で実装をすることができました。

この実装が用意されたことで、2024年からは機能ごとにモジュールを分けることが可能になり、新機能に関しては新しい機能モジュールとしてスムーズに開発を進めています。

アプリの起動のフローの整理

アプリ起動処理のフローの整理を行いました。 元々はタイムラインの機能を提供するMainActivityにすべての実装がありました。そのためMainActivityの実装が非常にファットになっており、本来のタイムラインのために実装したい処理との区別がつかないような状態になっていました。また新たに起動時に処理させたいことがあっても、現在の処理を理解することが障壁になっており、機能追加時の障害にもなっていました。

それらを解消するために、起動の処理を整理し、MainActivityからの引き剥がしを行いました。 これにより、起動時にはどのような順番で処理が行われて、処理に応じたユーザーへの表示が明確になりました。

アプリの起動フロー再構成時に利用したメモ

Android15対応

2024年秋に安定版がリリースされ、提供されている Android15 の対応を実施しました。 TUNAGプロジェクトとしては、そこまで大きな対応はありませんでしたが、edge-to-edge の対応が全画面に対して必要となりました。

edge-to-edge 対応とはAndroidのシステム領域である「ステータスバー」や「ナビゲーションバー」まで画面の描画領域を広げることができる機能です。 edge-to-edge の提供自体は過去から提供されていましたが、Android15 以降を targetSDK に設定しているアプリでは、強制的に適用されるようになりました。 TUNAGのAndroidプロジェクトはほとんどの画面でActivityベースで開発が行われているため、すべての画面において edge-to-edge の対応を行う必要がありました。

今回の対応としては、edge-to-edge で利用できるようになった領域に関しては従来通り透過をしないという暫定的な対応をしました。 今後よりネイティブアプリとして真価を発揮できるよう、画面に応じてナビゲーションバーの領域を一部透過するなど適宜対応していく方針となっています。

Kotlin 2.0への更新

Kotlin2.0へとメジャーバージョンの更新を実施しました。 TUNAGでは通常Kotlinのリリースの1ヶ月以内でのプロジェクトへの導入・リリースを目指しています。ただ今回はメジャーバージョンの更新であったため、慎重に検証を行いました。

結果としては、TUNAGにはそこまでKotlinのバージョンに依存しているライブラリが少なかったため、大きな問題もなく上げることができました。

Kotlin 2.0 へのアップデートでの大きな目玉としては、K2コンパイラへ移行があります。 ただK2コンパイラが Android Studio で利用可能になった当時はアルファ版であり開発に支障をきたすレベルのバグが存在していました。年末時点でK2コンパイラーを普段の開発で利用しているメンバーはおらずその早さはまだ実感できていません。 今回チームで2024年を振り返ったタイミングで、改めてK2コンパイラを使ってみようとなり、K2コンパイラの性能についてはこれからチームで検証していくこととなります。

PicassoからCoilへの移行

2024年11月にPicassoが非推奨となり、Coil への移行が推奨されることがアナウンスされました。 TUNAGアプリは2018年当時からPicassoを利用しており、かなりの部分でPicassoに依存していました。

2023年からは Jetpack Compose で実装している部分に関しては一部 Coil の利用していましたが、過去に AndroidView で実装された部分に関してはすべてPicassoが利用されていました。ただ現在は Jetpack Compose での実装がメインとなり、TUNAG においては Coil がデファクトスタンダードになりつつあることを踏まえて、AndroidView で実装された箇所に関してもこの機会に Coil に移行する措置を行いました。

元々 Jetpack Compose のために Coil を導入したときにシングルトンの ImageLoader インスタンスの実装を行っていたため、両ライブラリで多少の違いはあったものの単純な置き換え作業となりました。

Markdown の検証

TUNAGの投稿では、マークダウンを利用することができます。 今まではWebViewのHTML表示などを利用して騙し騙しにマークダウンを提供していましたが、アプリケーションとしてよりWebViewに依存しないような構成にするために、TextViewベースのマークダウン表示の技術検証を行いました。

こちらはMarkwonというライブラリをカスタマイズして、TUNAGでのマークダウンの書式が適用されるようにしました。 現在は技術検証が終わった段階で未リリースですが、これから順次アプリ内のマークダウンの表示を、こちらのネイティブベースのものに置き換えていく方針です。

最後に2025年に向けて

今回は2024年にTUNAG Androidアプリにて行った技術的な変化と挑戦を紹介しました。 こうして並べてみると、結構様々なチャレンジを行ってきたんだなと感じます。 機能開発だけでなく、アプリ開発におけるプラットフォームの改善にもより一層力を入れて、機能開発のベースラインを向上し、生産性の向上を目指しています。

株式会社スタメンでは、2025年より一層開発部門のギアを上げていくために全方向で開発メンバーを募集しています。

herp.careers