Androidアプリの取り組み2019.04.25 morizooo突撃隣のアーキテクチャ© 2019 Mirrativ, Inc.
View Slide
●Profile●morizooo(@morizo_999)●ミラティブAndroid担当(2018/2〜)●マイブーム:b-monster
Mirrativについて2.タイトル等設定 3.配信開始1.起動Mirrativスマホ1台だけでゲーム実況/ライブ配信を可能にするコミュニケーションサービス
サービスコンセプト=友達の家でドラクエやってる感じゲームを中心に置いた「コミュニケーション空間」
99● 5年目アプリの現状● 課題● 取り組んでいること今日話すこと
目次99アプリの現状
99Android Gradle Plugin 3.4.0targetSdkVersion 28minSdkVersion 16(5月に21に上げる)support library version 28.0.3 (AndroidX)言語: Java 8, Kotlin 1.3.30主要ライブラリ: Koin, Glide, Retrofit, Gson開発環境
99アーキテクチャActivity/FragmentAPI ClientResponse(POJO)CustomView(一部だけ)● いわゆるM-VC
99ACTIVITY/FRAGMENTActivity/FragmentAPI ClientResponse(POJO)CustomView(一部だけ)● ApiClientを呼び出し結果をViewに表示● プレゼンテーションロジックを持つ● View,Controllerの責務を持つ(境目が曖昧)
99CUSTOMVIEWActivity/FragmentAPI ClientResponse(POJO)CustomView(一部だけ)● Viewのコンポーネントとして切り出された物● Viewとしての描画の責務を持つ
99API CLIENTActivity/FragmentAPI ClientResponse(POJO)CustomView(一部だけ)● サーバーに対して問い合わせ行いResponseを取得● Viewに特化したPOJOを返す
99feature配下に機能単位にパッケージを切ってUIを配置→ 多数の責務を持ったり、複数のパッケージに依存していたりカオス化...パッケージ構造
目次99課題
99● どこに処理を書くか悩む○ パッケージ構造が不明瞭○ ViewとControllerがの境目が曖昧● 厳密なルールがないのでActivityに処理が集中○ 6000行のActivityが存在 責務破綻
99● マッチョActivityを超える危険なやつら☠☠☠ ○ 最凶のBaseクラス ■ 汎用的に作ろうとしてるせいでたらい回しにされる ■ 1000行のクラスを継承する ○ ロジックを持ったView ○ HelperがViewを持ってる ○ checkHogeというメソッドだが副作用がある 責務破綻
99● 例:オーブ/ダイヤ問題○ 開発当初はダイヤ、リリース前にオーブに変更○ クライアント内ではオーブという名前○ サーバー/分析ログではダイヤという名前のまま○ 初見殺し爆誕→ アンチパターンとして認識ユビキタス言語がぶれる
目次99取り組み
99O 開発に夢中KR 2019/4〜に洗い出した辛みを解消し、全platformで理想の状態を確立する全社的に開発体験を見直すときが来た● 週に1日は開発体験向上活動を行う● 各Platformでそれぞれ行われている
99● 最凶のActivityを倒す● Android Architecture Componentsの導入● 各層の責務の意識合わせ● パッケージ構造の整理● 不要なライブラリの撲滅● Kotlin化するANDROIDの取り組み内容
99● 一番でかいやつを倒せられればなんとかなるだろう理論● 不要な機能の削除(複雑な仕様を減らす)○ ユーザー利用状況踏まえて機能を削除● Viewに分離○ CustomViewで小さなコンポーネントにしていく● Android Architecture Components の ViewModelの利用○ 状態管理を改善する最凶のACTIVITYを倒す
99● 公式の設計に役立つライブラリ ● 推奨アーキテクチャとしてMVVMが紹介されている ANDROID ARCHITECTURE COMPONENTSの導入https://developer.android.com/jetpack/docs/guide
99● ViewModel, LiveDataを利用 ○ Activity<->View間の状態管理が楽になる ○ View用のプロパティ置き場として活用(M-VCのまま) ANDROID ARCHITECTURE COMPONENTS
99ANDROID ARCHITECTURE COMPONENTS利用例
99● Model○ クライアントに特化したAPIをサーバーで返しているので、Responseは基本的にそのまま描画するだけ○ iOS/Android/Webでビジネスロジックが各プラットフォームに書かれないようにする○ クライアント上にしか存在しないモデルも勿論あるので、そちらはビジネスロジックを持つ各層の責務
99● View○ Viewは情報を表示するだけ○ プレゼンテーション/ビジネスロジックを持たない○ Modelを直接参照してはだめ各層の責務
99● Controller○ Modelを取得(APIリクエスト実行)○ Viewに描画するデータを設定する○ Viewのコールバックのハンドリング○ 一旦Fatにして整理できたら分解する各層の責務
99天下一パッケージ武道会の結果、機能単位からレイヤー単位にフラットに変える方針にパッケージ構造機能単位 レイヤー単位 機能+レイヤー?将来的には機能毎にmultimodule化する想定
99● Android Annotations○ 昔は便利だったが今ではフレームワークの進化で不要○ 学習コストを掛ける時間がもったいない○ 既存コードの意図がわからず解読する時間がかかる○ Staticになってテストし辛い部分もあるので消し去る→ コードネーム:チョベリバ(死語)不要なライブラリの撲滅
99● Java<->Kotlin間の脳内コンテキストスイッチをなくす● 親まで辿ってnullチェックするのがしんどい● 仕様を理解する上で良いタスクになる○ 副業で依頼しやすい● Authorが自分になるので圧倒的当事者意識KOTLIN化
99● 現状は苦しいアーキテクチャになっている● GUI/システムアーキテクチャを変更出来る段階ではない○ 既存のコードを責務を意識して改善する● 過去のコードに感謝し、スケールできるように改良を続けていく● 一緒に改善していく仲間を探しています!!!まとめ
積極採用中!© 2019 Mirrativ, Inc. ◆体験入社/副業制度あります! 改善が好きな方!!!一緒にやりませんか!!!