Google I/O'19: Build a Modular Android App Architectureのまとめ・感想

Created at Sun, Jun 9, 2019

以下の動画のまとめです。

Build a Modular Android App Architecture (Google I/O'19)

なぜモジュール化をするか?

スケール

モジュール化することで、開発者が独立して開発出来るようになる

• 人数が増えてきた時、アプリが大きくなってきた時にモジュール化は有効

保守性

例えば、モノリシックアプリだとレイアウトファイルを1つのディレクトリに持つことになる

• 何をしているのか、何をしたいのかが理解しにくい
• 長いレイアウトファイル名になりがち

ビルド時間の短縮

変更があったモジュール + その依存関係にあるモジュールが再ビルドされるため、ビルド時間が短くなる

CIの高速化

再ビルドが必要なモジュールのみテストをすれば良いので、テスト時間が短くなる

• androidx/dependencyTrackerを使うといい感じにテストが出来る（らしい）

APKサイズの縮小

App Bundle、Dynamic Deliveryの恩恵を受けられる

モジュール

どのようにモジュール分けをするか?

1. Feature（機能）ごとに分ける

ライブラリモジュールとDynamic Featureモジュールの2種類がある。

• ライブラリモジュール
  • com.android.libraryを指定する
• Dynamic Featureモジュール
  • onDemand trueとfalseがある
    • Paidのような一部のユーザが使う機能の場合はtrueが良い
    • Onboardingのように、後でいらなくなる機能の場合はfalseが良い

Plaidでは以下のようなモジュール構成にした。

dribbleと、designernewsがDynamic Featureモジュールになっている。

2. Layer（層、階層）ごとに分ける

Plaidでは以下のように分けた。

• Web Servicesの知識はUIはいらないので、implementationを指定する
  • そうすることで、UIがDTOやRetrofitの知識を知らないですむ
• Entitiesの知識はUIが必要なので、apiを指定する
  • ただし、この場合、DAOsの知識までUIが知ってしまうので微妙
    • そこでCommon Value Objectsの導入

こうすることで、UIがDAOの知識を知らずに済む

Fakes for tests

• モックよりも優れた方法
  • fakeはRepository（対象のクラス）がどのように振る舞うかを理解した上で作られる
    • （モックはその場、その場で作られがちという意味？）

Featureモジュールの利点

• カプセル化
• Dynamic Delivery

Layerごとに分ける利点

• サードパーティライブラリの依存を独立
• 構造をもたらす

Dynamic Deliveryの課題

Featureモジュール間のNavigationをどうするか?

• appから、Dynamic Featureモジュールへの依存を持てない
  • （これはDynamic Deliveryの制約のため）
  • 文字列、リフレクションでstartActivityするしかない
  • Fragmentも同様

今後、Navigationライブラリで自然に書けるようになるらしい😃

データベース

1つのデータベースのみ持つ

• pros
  • コネクションの管理が楽
  • テーブルのシェアが簡単
• cons
  • モジュール間に依存が生まれる

モジュールごとに1つのデータベースを持つ

• pros
  • モジュール間の依存が疎になる
• cons
  • データベースのコネクション管理がめんどい
  • 繰り返しのコードが生まれやすい

hybridアプローチ

特にルールを決めずに、データベースモジュールを作っていく

• pros
  • Flexible
• cons
  • Fiexible
    • どこに、どのDAO、Entityを置けば良いのかの判断を常に迫られる

マルチモジュール対応Room絶賛開発中らしい😃

Android free modules

multi platformにする場合

• Kotlin nativeとか
  • ちゃんとユースケースを持っているなら、multi platformは良い選択

テストの高速化

• 確かにテストは早くなるが、テストのためだけにAndroid freeにするのは冗長
  • Robolectricで十分
  • Android Frameworkの再開発は無駄e

最後に

• 最小限の依存関係でモジュールを構成する
• 関心事の分離
  • ビジネスロジックがUIに依存しない
• 抽象化
  • 抽象化は非常に便利だが、複雑になりがちなので、抽象化により得れる利点を常に考える
• これらのモジュール化のやりかたは、あくまでオプション
  • ユーザはマルチモジュールなコードだからって5つ星はくれない
  • あくまでユーザが一番大事

まとめ・感想

• Dynamic DeliveryはNavigationに対応が入ってきたあたりで導入検討したいなって思った
  • まだノウハウが少ない印象なので
• Fakeのためのモジュールはいいアイデアだなって思った
  • テストで、モックはあまり使わない流れなのかもしれない
    • 確かにモックをカジュアルに使いすぎると何をテストしているか分からなくなるときがある
• やっぱ関心ごとの分離って大事なんやなって
  • 層、モジュールでうまく強制、表現したい
  • サードパーティライブラリへの依存が、特定のモジュールに押し込めるのは良さ

• android
• architecture
• io19
• android-architecture