サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

<h2 id="はじめに">はじめに</h2>

<p>この記事は&nbsp;<a href="https://qiita.com/advent-calendar/2022/dmm" target="_blank">DMMグループ Advent Calendar 2022</a>&nbsp;の21日目の記事です。</p>

<p>こんにちはAndroid版 DMM TVアプリ ブックフロアの開発を担当した森です。<br />
本日はDMM TVアプリ開発で使用した<a href="https://kotlinlang.org/lp/mobile/" target="_blank">Kotlin Multiplatform Mobile(KMM)</a>についてご紹介できればと思います。</p>

<h2 id="DMM-TVアプリ-アーキテクチャ">DMM TVアプリ アーキテクチャ</h2>

<p>DMM TVアプリの開発では<a href="https://kotlinlang.org/lp/mobile/" target="_blank">Kotlin Multiplatform Mobile(KMM)</a>を使用してiOS・Android共に共通のドメイン層を利用しています。</p>

<figure title="DMM TVアプリ アーキテクチャ図"><img alt="" height="1193" itemprop="image" loading="lazy" src="https://image.dmm-corp.com/hu6ogij4ysmfdyz629jou52a8kak" title="" width="1200" />
<figcaption>DMM TVアプリ アーキテクチャ図</figcaption>
</figure>

<p>UI層はiOS・Androidで別々に用意してNativeClientとし、ViewModel/Presenterから利用するUseCaseやRepository、また取得してきたDomainModel(ドメインモデル)を共通化することで、ドメイン層の開発コストを削減しています。&nbsp;</p>

<h2 id="KMM利用時のメリット">KMM利用時のメリット</h2>

<h3 id="開発コストの削減">開発コストの削減</h3>

<p>ドメイン層をOS間で共通化することで単純に開発コストが下がりました。</p>

<p>特に初期段階の開発だけでなく、その後のドメイン部分の変更やパフォーマンス改善を実施する際にも開発コストが下がるのでiOS・Android共にUI層の作り込みに時間をかけれた印象があります。</p>

<h3 id="OS間の仕様差分の低減">OS間の仕様差分の低減</h3>

<p>ドメインロジックをOS間で共通化することでOS間の仕様差分を減らすことができました。</p>

<p>例えばiOS・Androidで共通のロジックで表示されるキャンペーン表示文言などをドメインモデルからプロパティとして公開することで、共通の表示仕様にすることができました。</p>

<p><strong>共通ロジックによるプロパティ公開</strong></p>

<pre>
<code>val campaignText = when {
    // 割引キャンペーンと還元キャンペーン両方あり
    hasDiscount &amp;&amp; hasPointRefund -&gt; {
      when (maxDiscountRate) {
        100 -&gt; discountCampaignText // 100％割引の場合は還元キャンペーンは表示しない
        else -&gt; "$discountCampaignText &amp; $pointCampaignText"
      }
    }
    // 割引キャンペーンのみ
    hasDiscount -&gt; {
      discountCampaignText
    }
    // 還元キャンペーンのみ
    hasPointRefund -&gt; {
      pointCampaignText
    }
    else -&gt; {
      null
    }
  }</code></pre>

<p><strong>共通ロジックで表示されるキャンペーン</strong></p>

<figure title="共通ロジックで表示されるキャンペーン"><img alt="" height="1049" itemprop="image" loading="lazy" src="https://image.dmm-corp.com/972ba7zhpvxq96a6j238oxomvh54" title="" width="1000" />
<figcaption>共通ロジックで表示されるキャンペーン</figcaption>
</figure>

<h2 id="KMM利用時のデメリット">KMM利用時のデメリット</h2>

<h3 id="iOSエンジニアのKotlin学習コスト">iOSエンジニアのKotlin学習コスト</h3>

<p>開発初期段階では特にiOSエンジニアの方がKotlinになれておらず、書き方に迷うことがある印象を受けました。</p>

<h3 id="ドメイン部分修正時に各OSでUI層の修正が必要になる">ドメイン部分修正時に各OSでUI層の修正が必要になる</h3>

<p>各OSで共通のプロパティに依存しているため、ドメイン層に変更があった時に両OSでUI層の対応をしないと片方のビルドが通らなくなり、開発ブランチから最新の差分を取得してくるとビルドできないという問題が頻発しました。</p>

<figure title="ドメイン部分修正時に各OSでUI層の修正が必要になる"><img alt="" height="809" itemprop="image" loading="lazy" src="https://image.dmm-corp.com/c9szdbs8yky64o7xqvicjsmkh9wy" title="" width="1200" />
<figcaption>ドメイン部分修正時に各OSでUI層の修正が必要になる</figcaption>
</figure>

<h2 id="片方のOSでビルドが通らない課題の解決策">片方のOSでビルドが通らない課題の解決策</h2>

<h3 id="PR自動ラベリングとDanger自動指摘の導入">PR自動ラベリングとDanger自動指摘の導入</h3>

<p>本来であればCIでビルドできるか自動でチェックできるのが好ましいのですが、現状のプロジェクト構成だと全OSでのビルド完了に1時間以上かかってしまうため、変更のあったパッケージ毎にGithub Actionsの<a href="https://github.com/actions/labeler" target="_blank">labeler</a>&nbsp;を使用して自動ラベリングすると共に<a href="https://github.com/danger/danger" target="_blank">Danger</a>による自動指摘を導入しました。</p>

<p><strong>自動ラベリング 設定例</strong></p>

<pre>
<code>Android:
- android/**/*

iOS:
- ios/**/*

KMP:
- native-shared/**/*</code></pre>

<p><strong>Dangerfile 設定例</strong></p>

<pre>
<code>added = git.added_files.include? "native-shared/**"
deleted = git.deleted_files.include? "native-shared/**"
modified = git.modified_files.include? "native-shared/**"
renamed = git.renamed_files.include? "native-shared/**"

warn("各OS共通部分に変更が入っています。Android,iOSでビルドが問題ないか確認してください。") if added || deleted || modified || renamed</code></pre>

<p><strong>Dangerによる自動指摘の様子</strong></p>

<figure title="Dangerによる自動指摘の様子"><img alt="" height="246" itemprop="image" loading="lazy" src="https://image.dmm-corp.com/0onhfeg8cauj2uw19dwelxui7tuj" title="" width="1200" />
<figcaption>Dangerによる自動指摘の様子</figcaption>
</figure>

<h3 id="PR運用フローによる改善">PR運用フローによる改善</h3>

<p>さらに私達のチームでは PullRequest(PR)運用フローを工夫して開発ブランチへのマージ前に両OSでビルドが通る状態になるようにしました。</p>

<ol>
	<li>Androidエンジニアがドメイン層に変更を入れた場合、ドメイン層の修正とAndroid側のUI層の修正が完了したら、その時点でのPRを作成しiOSエンジニアに共有します。</li>
	<li>iOSエンジニアはドメイン層のレビューを行うと共にiOSのUI層の修正を追加コミットを行いiOS側もビルドできるようにします。</li>
	<li>上記PRをiOSエンジニア、Androidエンジニアそれぞれからレビューを頂き、共にApproveをもらったらマージをする。</li>
</ol>

<p><strong>Androidエンジニアがドメイン層に変更を入れた場合のPR運用フロー</strong></p>

<figure title="Androidエンジニアがドメイン層に変更を入れた場合のPR運用フロー"><img alt="" height="1201" itemprop="image" loading="lazy" src="https://image.dmm-corp.com/azg8iplagyst1628gccenyqy11d0" title="" width="937" />
<figcaption>Androidエンジニアがドメイン層に変更を入れた場合のPR運用フロー</figcaption>
</figure>

<h2 id="結果">結果</h2>

<p>ビルドが通らない問題が起こる頻度は劇的に下がりました。</p>

<p>またiOSエンジニアとAndroidエンジニアが仕様変更があった際に互いにキャッチアップができるというメリットも生まれました。</p>

<h3 id="おわりに">おわりに</h3>

<p>今回はじめて実務でKMMを利用しましたが、iOS・Androidでほとんど共通の仕様でプロダクトを開発するモバイルアプリ開発では非常に強力なソリューションであると改めて実感しました。</p>

<p>自身はAndroidエンジニアだったため、Kotlinに慣れているというのもありますが、非常に開発はしやすかったイメージです。</p>

<p>特に複雑なロジックが必要になるドメインロジックの実装や、パフォーマンスを改善するための修正をした際に、Android側だけでなくiOS側にも貢献できるというのがとても開発者体験を向上させると思いました。</p>

<p>今後も新規プロダクト開発では積極的に利用していきたいと思いました。</p>

<h3 id="宣伝">宣伝</h3>

<p>マンガも買える、読める DMM TVをよろしくお願いたします。<br />
<a href="https://tv.dmm.com/vod/" target="_blank">DMM TV｜アニメ・エンタメ見放題、コスパ最強月額550円</a></p>

<h2 id="あとがき">あとがき</h2>

<p>今回導入を先導してくださった&nbsp;<a href="https://twitter.com/kgmyshin" target="_blank">@kgmyshin</a>さん&nbsp;<a href="https://twitter.com/cantabile_hisa" target="_blank">@cantabile_hisa</a>さん ありがとうございました。<br />
また様々な改善を提案、導入してくださった&nbsp;<a href="https://twitter.com/cantabile_hisa" target="_blank">@cantabile_hisa</a>さん&nbsp;<a href="https://twitter.com/roana0229" target="_blank">@roana0229</a>さん 本当にありがとうございました。</p>


DMM TV

Android

アドベントカレンダー2022

DMM TVアプリ開発で使用したKotlin Multiplatform Mobile(KMM) について

DMM TVアプリ開発で使用したKotlin Multiplatform Mobile(KMM) について

シェア

関連する求人

関連する記事

関連するサービス