ABEMAのKotlin Multiplatform

1. ABEMAのKotlin Multiplatform / / Flutter × Kotlin Multiplatform by CyberAgent # Takahiro Menju / takahirom
2. About me Takahiro Menju takahirom(@new_runnable) ABEMA Android DroidKaigi Conference App Leader Google Developers Expert for Android DroidKaigi/conference-app- まだまだ活発に開発しているので お待ちしてます🙏
3. .ABEMAのマルチデバイス対応 .Kotlin Multiplatformとは .Kotlin Multiplatformを始めるには .各チームでのアプローチ .どのように作るか .今後 .まとめ
4. ABEMAの マルチデバイス対応
5. ABEMAのマルチデバイス対応 https://abema.tv/supported-device
6. ABEMAのマルチデバイス対応 • Android https://abema.tv/supported-device
7. ABEMAのマルチデバイス対応 • Android • iOS https://abema.tv/supported-device
8. ABEMAのマルチデバイス対応 • Android • iOS • Android TV https://abema.tv/supported-device
9. ABEMAのマルチデバイス対応 • Android • iOS • Android TV • Apple TV https://abema.tv/supported-device
10. ABEMAのマルチデバイス対応 • Android • iOS • Android TV • Apple TV • Amazon Echo https://abema.tv/supported-device
11. ABEMAのマルチデバイス対応 • Android • iOS • Android TV • Apple TV • Amazon Echo • などなど https://abema.tv/supported-device
12. UIも、OSも違う
13. UIも、OSも違う • それぞれのデバイスで、 仕様の実装がバラバラになるので ⼯数が膨らむ
14. UIも、OSも違う • それぞれのデバイスで、 仕様の実装がバラバラになるので ⼯数が膨らむ • それぞれのデバイスで、 バグが出たときに対応
15. UIも、OSも違う • それぞれのデバイスで、 仕様の実装がバラバラになるので ⼯数が膨らむ • それぞれのデバイスで、 バグが出たときに対応 • しかし、それぞれのデバイスで、 同じロジックはたくさんある
16. Kotlin Multiplatformとは
17. Kotlin Multiplatform Multiplatform programming https://kotlinlang.org/docs/multiplatform.html
18. Kotlin Multiplatform • Kotlinで書かれたコードを、複数の プラットフォームで動作させる仕組み Multiplatform programming https://kotlinlang.org/docs/multiplatform.html
19. Kotlin Multiplatform • Kotlinで書かれたコードを、複数の プラットフォームで動作させる仕組み • 例えばSwiftのコードからKotlinで書かれた コードの実装を呼び出すことができる Multiplatform programming https://kotlinlang.org/docs/multiplatform.html
20. Kotlin Multiplatformを始 めるには
21. ⽅向性を提案する
22. ⽅向性を提案する • ⽬的と課題を設定
23. ⽅向性を提案する • ⽬的と課題を設定 • “クライアント全体としての開発の⾼速化と継続的な機能提供”
24. ⽅向性を提案する • ⽬的と課題を設定 • “クライアント全体としての開発の⾼速化と継続的な機能提供” • アプローチを⽐較する
25. ⽅向性を提案する • ⽬的と課題を設定 • “クライアント全体としての開発の⾼速化と継続的な機能提供” • アプローチを⽐較する • Flutter、React Native、Kotlin Multiplatformなどを⽐較
26. ⽅向性を提案する • ⽬的と課題を設定 • “クライアント全体としての開発の⾼速化と継続的な機能提供” • アプローチを⽐較する • Flutter、React Native、Kotlin Multiplatformなどを⽐較 • ⽅向性を⽰す
27. ⽅向性を提案する • ⽬的と課題を設定 • “クライアント全体としての開発の⾼速化と継続的な機能提供” • アプローチを⽐較する • Flutter、React Native、Kotlin Multiplatformなどを⽐較 • ⽅向性を⽰す • ロジックを共有できるUI / UX観点と開発やコミュニティ状況、 DXと将来性を鑑みて、現時点の⽅向としてKotlin Multiplatformを採⽤する提案を⾏った(by Yuji Hato @dekatotoro)
28. 参考になるもの 公式のケーススタディ https://kotlinlang.org/lp/mobile/case-studies/ ビジネス的な視点がもっと必要があるなら以下が参考になる。 Building a Business Case for Kotlin Multiplatform & Mobile Code Sharing https://dev.to/touchlab/building-a-business-case-for-kotlin-multiplatform-mobile-code- sharing- m
29. 各チームでのアプローチ
30. Kotlin Multiplatformを試しているチーム
31. Kotlin Multiplatformを試しているチーム • さまざまなデバイスの対応を⾏うConsumer Electronics (CE)チーム
32. Kotlin Multiplatformを試しているチーム • さまざまなデバイスの対応を⾏うConsumer Electronics (CE)チーム • Webチーム
33. Kotlin Multiplatformを試しているチーム • さまざまなデバイスの対応を⾏うConsumer Electronics (CE)チーム • Webチーム • iOSとAndroidのエンジニアによる、Native チーム → 今⽇話すメインはこちら
34. CE(Consumer Electronics)チーム • Kotlin Multiplatformを使って設計を強制するというものを検 討中 • Kotlin MultiplatformでUseCase、Entityなどを実装 • Data層やUI層は各プラットフォームで実装する → これから導⼊して経過を⾒ていく UI UseCase / Entity Data Kotlin Multiplatform Platfrom Platfrom 簡略図
35. WEBチーム • Kotlin Multiplatformの検証中 • Playgroundのリポジトリを作って検証 • いくつかの技術的な問題があり未導⼊ • TypeScriptの定義で、enumが使えない • https://youtrack.jetbrains.com/issue/KT- • https://youtrack.jetbrains.com/issue/KT- • Ktorのサイズ⼤きい • https://youtrack.jetbrains.com/issue/KTOR- • など • 少しずつ改善されていこうとしている。
36. Nativeチームでの アプローチ
37. ロジックを共通化できない か？
38. Nativeチームの⾛り始め
39. Nativeチームの⾛り始め • Domain Objectを共通化できないか？
40. Nativeチームの⾛り始め • Domain Objectを共通化できないか？ • そもそも設計の段階で結構話し合いが⼤変になっていた😂
41. Nativeチームの⾛り始め • Domain Objectを共通化できないか？ • そもそも設計の段階で結構話し合いが⼤変になっていた😂 • iOS、Androidの既存のアーキテクチャの違い、 Repositoryの範囲は？どこまでUseCase？Entityを interfaceとdefault functionを使って分ける？Entity化 はどこからするか？
42. Nativeチームの⾛り始め • Domain Objectを共通化できないか？ • そもそも設計の段階で結構話し合いが⼤変になっていた😂 • iOS、Androidの既存のアーキテクチャの違い、 Repositoryの範囲は？どこまでUseCase？Entityを interfaceとdefault functionを使って分ける？Entity化 はどこからするか？ → どうしようか。。
43. Nativeチームの⾛り始め
44. Nativeチームの⾛り始め • APIクライアントの実装からKotlin Multiplatformを導⼊していく
45. Nativeチームの⾛り始め • APIクライアントの実装からKotlin Multiplatformを導⼊していく • 最初はAndroidエンジニアがガッ て作る
46. なぜAPIクライアントから導⼊し たか
47. なぜAPIクライアントから導⼊したか
48. なぜAPIクライアントから導⼊したか • 同じサーバーを使っているので、iOSとAndroidの実装差異が少ないた め、議論が発⽣しにくい。そのため、スムーズに実装できる
49. なぜAPIクライアントから導⼊したか • 同じサーバーを使っているので、iOSとAndroidの実装差異が少ないた め、議論が発⽣しにくい。そのため、スムーズに実装できる • 実績ができるので他の部分への導⼊も進みやすくなる
50. なぜAPIクライアントから導⼊したか • 同じサーバーを使っているので、iOSとAndroidの実装差異が少ないた め、議論が発⽣しにくい。そのため、スムーズに実装できる • 実績ができるので他の部分への導⼊も進みやすくなる • 共通化できる部分が多く、今後も活かせる
51. なぜAPIクライアントから導⼊したか • 同じサーバーを使っているので、iOSとAndroidの実装差異が少ないた め、議論が発⽣しにくい。そのため、スムーズに実装できる • 実績ができるので他の部分への導⼊も進みやすくなる • 共通化できる部分が多く、今後も活かせる • APIの定義 リクエストやレスポンスのオブジェクト
52. なぜAPIクライアントから導⼊したか • 同じサーバーを使っているので、iOSとAndroidの実装差異が少ないた め、議論が発⽣しにくい。そのため、スムーズに実装できる • 実績ができるので他の部分への導⼊も進みやすくなる • 共通化できる部分が多く、今後も活かせる • APIの定義 リクエストやレスポンスのオブジェクト • APIのヘッダーなどの設定、エラーなどの処理
53. なぜAPIクライアントから導⼊したか • 同じサーバーを使っているので、iOSとAndroidの実装差異が少ないた め、議論が発⽣しにくい。そのため、スムーズに実装できる • 実績ができるので他の部分への導⼊も進みやすくなる • 共通化できる部分が多く、今後も活かせる • APIの定義 リクエストやレスポンスのオブジェクト • APIのヘッダーなどの設定、エラーなどの処理 • FakeのAPI実装、テストや、まだAPI実装がないときに共通の Fakeを使ってクライアントで開発することができる。
54. なぜAPIクライアントから導⼊したか • 同じサーバーを使っているので、iOSとAndroidの実装差異が少ないた め、議論が発⽣しにくい。そのため、スムーズに実装できる • 実績ができるので他の部分への導⼊も進みやすくなる • 共通化できる部分が多く、今後も活かせる • APIの定義 リクエストやレスポンスのオブジェクト • APIのヘッダーなどの設定、エラーなどの処理 • FakeのAPI実装、テストや、まだAPI実装がないときに共通の Fakeを使ってクライアントで開発することができる。 • 将来的にAPIのレスポンスのEntityからドメインオブジェクトへの変 換もできる。
55. なぜAndroidエンジニアから ガッと作る形になったか
56. チームで⾏う3つのアプローチ Approaches to organizing teamwork for Multiplatform projects https://kotlinlang.org/docs/mobile/organize-process-around-kmm.html#approaches-to- organizing-teamwork-for-multiplatform-projects
57. チームで⾏う3つのアプローチ • . AndroidチームがMultiplatformのモ ジュールを開発する。iOSの開発者はブ ラックボックスとして扱う Approaches to organizing teamwork for Multiplatform projects https://kotlinlang.org/docs/mobile/organize-process-around-kmm.html#approaches-to- organizing-teamwork-for-multiplatform-projects
58. チームで⾏う3つのアプローチ • . AndroidチームがMultiplatformのモ ジュールを開発する。iOSの開発者はブ ラックボックスとして扱う • . AndroidとiOS両⽅がマルチプラット フォームライブラリで同時に作業する Approaches to organizing teamwork for Multiplatform projects https://kotlinlang.org/docs/mobile/organize-process-around-kmm.html#approaches-to- organizing-teamwork-for-multiplatform-projects
59. チームで⾏う3つのアプローチ • . AndroidチームがMultiplatformのモ ジュールを開発する。iOSの開発者はブ ラックボックスとして扱う • . AndroidとiOS両⽅がマルチプラット フォームライブラリで同時に作業する • 3. マルチプラットフォームライブラリの作 業は専⽤チームが⾏う Approaches to organizing teamwork for Multiplatform projects https://kotlinlang.org/docs/mobile/organize-process-around-kmm.html#approaches-to- organizing-teamwork-for-multiplatform-projects
60. . AndroidチームがMultiplatformのモジュールを開発する戦略 • 新しいモジュールでは問題なくスムーズに導⼊ していくことができる。✅ • Kotlin Multipaltformの適応範囲を広げていく 場合、Androidのエンジニアが⼤部分を⾒るこ とになるので、継続的には現実的ではなさそ う。🚫
61. . AndroidとiOS両⽅がマルチプラットフォームライブラリで同時 に作業する • 今のNativeチームにマッチしている。✅ • 問題となるのは学習コスト。 • Android iOSエンジニアがお互いの技術を学ぶ Bootcampを⾏っており、ある程度のKotlinの知識が 浸透していた。✅ • 引き続き学習していく仕組みを整える必要がありそう
62. 3. マルチプラットフォームライブラリの作業は専⽤チームが⾏う • 検討は⾏ったが、⼈の採⽤が難 しい🚫
63. ABEMAでの現在のアプローチ • ” .AndroidチームがMultiplatformのモジュールを開発する戦 略”を⾏い、 • ” . AndroidとiOS両⽅がマルチプラットフォームライブラリで 同時に作業する”に移⾏していく形 • AndroidのエンジニアのほうがKotlinやGradleに慣れている • iOSエンジニアが意外とKotlin Multiplatformに興味があって 良かった(良いチーム)
64. どのように作るか
65. プロジェクト構成をどうするか
66. Kotlin/kmm-sampleではどうしているか 同じGitHubのリポジトリで、 AndroidアプリとiOSアプリを管 理 1つsharedというモジュールを 作ってそれを使う
67. Kotlin Multiplatform Project 現在の構成 proto Android project apiclient apiclient-fake iOS project ios-abema-mpp
68. Kotlin Multiplatform Project proto Android project apiclient apiclient-fake iOS project ios-abema-mpp Android, iOS, Kotlin Multiplatformで リポジトリを分けて管理 (これは現在の状態からの移⾏のしやすさからこうなっている) Androidプロジェクト GitHub リポジトリ iOSプロジェクト GitHub リポジトリ Kotlin Multiplatform Project GitHub リポジトリ
69. Kotlin Multiplatform Project proto Android project apiclient apiclient-fake iOS project ios-abema-mpp 細かくモジュールを分けている
70. Kotlin Multiplatform Project proto Android project apiclient apiclient-fake iOS project ios-abema-mpp Wire を利⽤し、Protocol Buffersの定義ファイルから ⽣成されたコードを置いている Ktor Clientを使ったAPI Client テストダブルやプロトタイプ実装 で使うfake iOS⽤のライブラリ 技術的詳細
71. なぜモジュールを分けるか
72. Kotlin Multiplatform Project proto Android project apiclient apiclient-fake iOS project ios-mpp Web Ktorのサイズが⼤きくて⼊れられない さまざまなプラットフォームでの導⼊を想定したときに⼊れたい部分だけ ⼊れられた⽅が良い
73. Kotlin Multiplatform Project proto Android project apiclient apiclient-fake iOS project ios-mpp マルチモジュールのさまざまな 利点を受けられる これらはスケールしたときに 影響が出てくる ‧並列でのビルド ‧必要がない依存関係が⼊らない
74. Kotlin Multiplatform Project proto Android project apiclient apiclient-fake iOS project ios-mpp また構成するモジュールが 300を超える Android Jetpackの構成を 参考にしているため、 以下のような仕組みを参考にでき る ‧必要なモジュールだけテストや ビルド : AffectedMoudleDetector ‧必要なモジュールだけIDEに インポート : Android Jetpackの Playgroundについて https:// qiita.com/takahirom/items/ b e c e https://github.com/androidx/androidx/blob/ e d b bf fee b fec fc /buildSrc/src/main/kotlin/androidx/ build/dependencyTracker/AffectedModuleDetector.kt https://github.com/androidx/androidx/blob/ ce d fbed e fbc f /playground-common/README.md
75. Kotlin Multiplatform Project proto . . -abd a Android project apiclient . . apiclient-fake . . iOS project ios-mpp . . Maven implementation(“tv.abema: ”) Maven implementation(“tv.abema:apiclient: . . ”) Maven implementation(“tv.abema:proto: . . -abd a”) 基本的にMavenで管理し(GitHub Packagesを利⽤する)、 バージョンがモジュール毎に存在する 依存モジュールが別のプロジェクトに勝⼿に変更されて、 勝⼿に壊れることがないようにしている。
76. Kotlin Multiplatform Project proto Android project apiclient apiclient-fake iOS project ios-mpp iOSͰ͸CocoapodsͰϞδϡʔϧΛ·ͱΊͯࢀর͢Δ ৄ͘͠͸ҎԼʮiOSʹKMMΛಋೖ͢Δtipsʯby 𝚖𝚊𝚛𝚝𝚢-𝚜𝚞𝚣𝚞𝚔𝚒 (@marty_suzuki) https://speakerdeck.com/martysuzuki/iosnikmmwodao-ru-surutips Cocoapods
77. 実装上のテクニック
78. プラットフォームで拡張可能に
79. OkHttpのインスタンスはAndroidでは⼀つに する必要がある！ プラットフォームで拡張可能でない場合は共有 されなくなってしまう。
80. プラットフォームで拡張可能にする それぞれのプラットフォームのソースセットでDIする。 ここでは単純にConstractor Injectionしている androidMain/kotlin内 public fun ApiClient( // τοϓϨϕϧؔ਺ config: ApiClientAndroidConfig, ): ApiClient { return ApiClient(ApiClientAndroidImpl(config), config) } public class ApiClientAndroidConfig( public val okHttpClient: OkHttpClient, loggerEnabled: Boolean, ) : ApiClient.Config( loggerEnabled = loggerEnabled, )
81. 1コードで各プラットフォームで テストを実⾏
82. commonTestで1コードで各プラットフォームで テストを実⾏できる commonTestフォルダにテストコードを置いて、 以下で実⾏するだけ。 ./gradlew allTests :iosX Test :jvmTest :allTests
83. expect/actualとinterfaceの使い 分け
84. expect/actualだとテストが難しい場合がある actualを実装できるのは⼀つだけなので、 テストで置き換えするには以下のように全部openにする必要がある commonMain/ expect open class PlatformExpectActual() { open fun platform(): String } jvmMain/ actual open class PlatformExpectActual { actual open fun platform(): String = "jvm" } commonTestͷςετ val platform = object : PlatformExpectActual() { override fun platform(): String { return "test platform" } } Client(platform).doIt()
85. expect/actualを使ったクラスで共通処理をするには ڞ௨ॲཧΛ͜ͷexpectΫϥεͰॻ͜͏ͱ͢ΔͱҎԼͷΑ͏ʹΤϥʔʹͳͬͯ͠·͏ɻ ҰԠextension functionΛ࢖͑͹͔͚ͳ͘΋ͳ͍ɻ
86. interfaceとexpect/actualの使い分け 公式ドキュメントには以下のような記述 がある。 “expect actualを使いすぎないように。いくつかのケースではinterfaceが拡 張性が⾼く、テストがしやすい。” https://kotlinlang.org/docs/mpp-connect-to-apis.html#rules-for- expected-and-actual-declarations
87. interfaceとexpect/actualを⽐較する UPQ
    MFWFM
    ؔ਺ɺ ม਺ DPNNPO.BJO͔ Βͷݺͼग़͠Ͱ࣮ ૷Ϋϥεͷίϯε τϥΫλΛݺͼग़ ͤΔ͔ ςετͰͷஔ͖׵ ͑ ڞ௨ॲཧΛॻ͘ FYQFDUBDUVBM ✅ ✅ 🚫 🚫 JOUFSGBDF 🚫 🚫 ✅ ✅
88. interfaceとexpect/actualの使い分け 現状は以下のような形で使っている expect/actualを使う ‧プリミティブな関数やUtility ‧interfaceの実装クラスがプラットフォーム側にあるときにインスタンス化 するなどの設定を⾏うとき interfaceを使う ‧上記以外のとき
89. CIビルド速度の改善
90. buildに1時間10分😇
91. Affected Module Detectorを有効化する https://github.com/dropbox/AffectedModuleDetector デフォルトのプラグインではAndroidのタスク⽤に作られていて、 Kotlin Multiplatformで使えるようにできていないため、⾃分でプラグインの実装を追加する サンプルリポジトリ https://github.com/takahirom/kotlin-multiplatform-affected-module-detector-sample 少し実装中にハマったので概念的なところを紹介。
92. Affected Module Detectorを有効化する Affected Module Detectorの仕組み A B C implementation(project(“:B”)) implementation(project(“:C”))
93. Affected Module Detectorを有効化する Affected Module Detectorの仕組み A B C 変更
94. Affected Module Detectorを有効化する Affected Module Detectorの仕組み B C isProjectAffected = true A isProjectAffected = true isProjectAffected = false
95. Affected Module Detectorを有効化する これでビルドを制御するとどうなるか？？ B C ビルドする A ビルドする ビルドしない
96. Affected Module Detectorを有効化する これでビルドを制御するとどうなるか？？ Cがビルドされていないので、Bがビルド失敗して、困る😇 B C Cがビルドされていないので モジュールBのビルドに失敗する A
97. Affected Module Detectorを有効化する どうするか？ Kotlin Multiplatformのビルドで⻑いのはlinkDebugIosなどタスクだが、こ れはModuleBのビルドに不要なので、そのタスクだけ無効化する。 B linkDebugIosなどだけ無効化 A C ビルドする ビルドする
98. Affected Module Detectorを有効化する だいたいの変更で半分の時間でビルドできるようになった
99. 公式にKotlin/Nativeのビルド時間改善の記事がある Tips for improving Kotlin/Native compilation time https://kotlinlang.org/docs/native-improving-compilation- time.html#gradle-configuration ‧~/.konanのキャッシュ ‧“build”などのタスクを避けて、必要なビルドだけ⾏う。 ‧メモリの設定 など
100. 今後
101. やっていること、やりたいこと • 実際に⼯数を減らす • Kotlin Multiplatformの利⽤範囲の拡⼤ • ICONIXプロセスを⽤いたドメインオブジェ クトやUseCaseの作成、共通化 • 他のデバイスへの展開 • Kotlinの学習⽅法を考える
102. まとめ
103. まとめ • 複数のチームでKotlin Multiplatformに対するアプ ローチを⾏っている • Nativeチームではマルチモジュールによるアプローチ を⾏っている • まだ新しい技術で、いろいろ試⾏錯誤している。 今後もさまざまなアプローチを⾏う予定になっている
104. Thank you