Tweet
Tweet

Slide 1

Slide 1 text

Mobileアプリの アーキテクチャ設計法 〜KMMを例に〜 Keita Kagurazaka

Slide 2

Slide 2 text

課題と制約

Slide 3

Slide 3 text

課題と制約 ● 現状と理想のギャップが課題 ● 選択肢を制限するものが制約 ○ 技術的なもの ○ チーム由来のもの ○ 歴史的経緯によるもの ● 制約を守りつつ、課題を解決しなければならない ● アーキテクチャは課題の解決方法の1つ

Slide 4

Slide 4 text

Kyashでの課題

Slide 5

Slide 5 text

Kyashでの課題 ● [課題1] 両OSで同じロジックを2度実装することによる問題 ○ リソースの無駄遣い ○ 同メンバーが対応することによる虚無感 (特にテスト) ● [課題2] OSでロジックが異なったことによるインシデント ○ 画面遷移可能かの判断で非常に複雑な場所があった ○ その判定ロジックがOS間で異なり、片方のOSでだけインシデントが発 生

Slide 6

Slide 6 text

制約条件 ● [制約1] 各OSごとにUIを最適化し、UXを最大化する方針 ● [制約2] フルリニューアルを実施することができない ○ 事業の状態を考えたときのリソースに起因 ○ すなわち、部分的な導入がしやすく、それによって既存部分に与える 影響を最小化したい

Slide 7

Slide 7 text

制約条件 ● [制約1] 各OSごとにUIを最適化し、UXを最大化する方針 ● [制約2] フルリニューアルを実施することができない ○ 事業の状態を考えたときのリソースに起因 ○ すなわち、部分的な導入がしやすく、それによって既存部分に与える 影響を最小化したい [選択1] Kotlin Multiplatform Mobile

Slide 8

Slide 8 text

共通化するレイヤー ● KMMは部分導入の自由度が高い ○ APIクライアントだけ ○ UseCaseまで ○ etc.

Slide 9

Slide 9 text

共通化するレイヤー ● KMMは部分導入の自由度が高い ○ APIクライアントだけ ○ UseCaseまで ○ etc. ● [課題1] 両OSで同じロジックを2度実装することによる問題 の解決のため には [選択2] UI以外は原則すべて共通化する

Slide 10

Slide 10 text

選択による課題と制約

Slide 11

Slide 11 text

KMM採用の課題と制約 ● [制約3] iOSメンバーはKotlinの経験がなく、これから学ぶ必要あり ● [制約4] 過去のPRにしかないストック情報がある ○ [選択3] KMMのリポジトリを分ける ○ アプリ側のリポジトリとのインテグレーションが必要 ○ [課題3] インテグレーションのオーバーヘッド ● [課題4] Kotlin Nativeにおけるmulti-thread問題 ○ 以下native-mt問題

Slide 12

Slide 12 text

native-mt問題 ● Kotlin Nativeでは原則としてオブジェクトがスレッドを跨げない ● 例外はfreezeしたfrozen object ○ frozen objectを変更するとランタイムでクラッシュ ● 基本的な対応策 ○ スレッドを跨ぐオブジェクトはImmutableにする ○ mutable stateを持つクラスがfreezeされないようにする

Slide 13

Slide 13 text

native-mt問題 ● [制約3] iOSメンバーはKotlinの経験がなく、これから学ぶ必要あり ○ 注意して開発しよう、は選択できない ● 課題を制約に変換して解消 ○ [制約5] frozenをアーキテクチャ基盤に隠蔽し、ロジックやUIの実装時 に意識させない

Slide 14

Slide 14 text

アーキテクチャの選定 ● [選択4] MVIベースのアーキテクチャを採用する ● ImmutableなIntentをUI側から入力し、ImmutableなUI state / eventを 出力してもらう ● 各レイヤーで受け渡されるデータがすべてImmutableであれば、基盤側 でfreezeしちゃえばnative-mt問題は発生しない

Slide 15

Slide 15 text

UI層の技術選定 ● [選択5] UI toolkitには宣言的UIを採用 ● [制約1] 各OSごとにUIを最適化し、UXを最大化する方針 ○ OS標準のUI toolkitを選択したい ● [選択4] MVIベースのアーキテクチャを採用する ○ ImmutableなUI stateが差分ではなく全体として更新通知される

Slide 16

Slide 16 text

アーキテクチャ概観 UI StateHolder UseCase Repository ApiClient state Intent event

Slide 17

Slide 17 text

アーキテクチャ概観 UI StateHolder UseCase Repository ApiClient state Intent event Intent → UI state or event

Slide 18

Slide 18 text

アーキテクチャ概観 UI StateHolder UseCase Repository ApiClient state Intent event

Slide 19

Slide 19 text

アーキテクチャ概観 UI StateHolder UseCase Repository ApiClient state Intent event [課題5] IntentがAndroidの既 存概念とコンフリクトする

Slide 20

Slide 20 text

アーキテクチャ概観 UI StateHolder UseCase Repository ApiClient state Action event [選択6] UI層からの入力は Actionと命名

Slide 21

Slide 21 text

自動テスト戦略 ● [課題2] OSでロジックが異なったことによるインシデント

Slide 22

Slide 22 text

自動テスト戦略 ● [課題2] OSでロジックが異なったことによるインシデント ● [選択7] 自動結合テスト ○ HttpClientにおけるレスポンスのみをmockする ■ KMMではKtor clientのMockEngineを活用 ○ 全Actionに対し、期待となるUI state / eventを検証 ○ expect / actualを活用し、JVM / iOS両方の環境でのテストをワン ソースで実施

Slide 23

Slide 23 text

テストコードのイメージ @Test fun executeAction_loadInitially_success() = reactorSuspendTest( reactorFactory = ::CouponListReactorFactory, responses = { every { "/v1/coupons/list?limit=10" } returns SUCCESS_RESPONSE_1_3 } ) { reactor -> reactor.test { reactor.execute(Action.LoadInitially) assertTrue(awaitState() is LoadState.Loading) /* 省略 */ } }

Slide 24

Slide 24 text

テストコードのイメージ @Test fun executeAction_loadInitially_success() = reactorSuspendTest( reactorFactory = ::CouponListReactorFactory, responses = { every { "/v1/coupons/list?limit=10" } returns SUCCESS_RESPONSE_1_3 } ) { reactor -> reactor.test { reactor.execute(Action.LoadInitially) assertTrue(awaitState() is LoadState.Loading) /* 省略 */ } }

Slide 25

Slide 25 text

テストコードのイメージ @Test fun executeAction_loadInitially_success() = reactorSuspendTest( reactorFactory = ::CouponListReactorFactory, responses = { every { "/v1/coupons/list?limit=10" } returns SUCCESS_RESPONSE_1_3 } ) { reactor -> reactor.test { reactor.execute(Action.LoadInitially) assertTrue(awaitState() is LoadState.Loading) /* 省略 */ } }

Slide 26

Slide 26 text

テストコードのイメージ @Test fun executeAction_loadInitially_success() = reactorSuspendTest( reactorFactory = ::CouponListReactorFactory, responses = { every { "/v1/coupons/list?limit=10" } returns SUCCESS_RESPONSE_1_3 } ) { reactor -> reactor.test { reactor.execute(Action.LoadInitially) assertTrue(awaitState() is LoadState.Loading) /* 省略 */ } }

Slide 27

Slide 27 text

CIによるインテグレーション省力化 ● [課題3] インテグレーションのオーバーヘッド ● [選択8] 徹底的なインテグレーションの自動化 ○ maven repository / XCFrameworkを置く成果物リポジトリ ○ KMM側のPRに対応して成果物リポジトリにbranchが生える ○ SNAPSHOT運用されるので、そのbranchをrefする ○ KMM側のPRが閉じたら成果物リポジトリのbranchも消える ○ その他tagを切って過去バージョンをアーカイブしたり、QA期間用のフ ローも自動化

Slide 28

Slide 28 text

PoC実装

Slide 29

Slide 29 text

Cache strategy ● [課題6] Cache DBの変更通知をUI stateに反映するフローを自然に表現 できない Model User Action state fun update( prev: State a: Action ): State Server

Slide 30

Slide 30 text

Cache strategy ● [課題6] Cache DBの変更通知をUI stateに反映するフローを自然に表現 できない Server DB ? Model User Action state fun update( prev: State a: Action ): State

Slide 31

Slide 31 text

Cache strategy ● [課題6] Cache DBの変更通知をUI stateに反映するフローを自然に表現 できない Server DB Model User Action state fun update( prev: State a: Action ): State

Slide 32

Slide 32 text

Cache strategy ● [課題6] Cache DBの変更通知をUI stateに反映するフローを自然に表現 できない Server DB Model ? state fun update( prev: State a: Action ): State User Action

Slide 33

Slide 33 text

調査 ● KMM + MVIで調査したところ、Wantedlyさんの記事を発見 ● https://www.wantedly.com/companies/wantedly/post_articles/300999 ○ 2020年のKotlin Advent Calendar最終日の記事

Slide 34

Slide 34 text

ReactorKitから借用する ● [選択9] Action -> UI stateの変換を2 stepsに分ける Model User Action state fun mutate( a: Action ): Mutation fun reduce( prev: State, m: Mutation ): State Mutation Server DB

Slide 35

Slide 35 text

結果 ● スタートポイントの課題は解決 ○ これまでより品質が担保できる状態 ● iOSメンバーの感想 ○ Kotlinの書き方は学ぶ必要があったが、アーキテクチャやiOSだから という理由で困ったことはなかった ● 単純にコード量が減ったというだけでなく、書ける人・レビューできる人がこ れまでより増えた面も

Slide 36

Slide 36 text

Why not ● 既存のアーキテクチャフレームワークを使わず、自前で基盤を実装 ● 解くべき課題と制約は事業・チームが異なれば変わる ● 何なら時間でも変化する

Slide 37

Slide 37 text

native-mt問題の完全解決 ● Kotlin NativeにおけるNew Memory Manager ○ インスタンスがスレッドを跨げないという制約がなくなる ○ まだexperimentalでnot production ready ● これからKMMにtryしたい人は、これがreadyになるのを待ちましょう ● 非常に大きな制約が消えるので、必然的にアーキテクチャ設計に影響する でしょう

Slide 38

Slide 38 text

まとめ ● 世のアーキテクチャがシンプル or オーバーエンジニアリングに見えるの は、解くべき課題や制約がそれぞれで異なるから ● 課題を解決するアイデアとしてのアーキテクチャの知識は必要 ● 事業やチームの課題と制約を明確に意識して設計しましょう

Slide 39

Slide 39 text

アーキテクチャは 選定するのではなく 設計せよ

Slide 40

Slide 40 text

Thanks!