1 iOSクライアント Re-Architectureのその後 Masaki Haga

2 About Me - 2018年4月にメルカリへ入社。 - UK版メルカリやJP版メルカリのUX関連プロジェクト（画像検索、ホーム画面な ど）を担当。 - 現在はPersonalizationチームのiOS Tech Lead。主にHomeやSearch画 面関連のプロジェクトを担当。 Masaki Haga

3 iOSクライアント Re-Architectureの概要 ● 2018年からスタート ● 現在までに主要な画面(出品, 商品詳細, 検索, ホーム)はすべて Re-Architecture済み ● Micro View Controllerという概念に基づく

4 Micro View Controller とは？

5 2018年時点での問題 ● 主要な画面でのロジックの増大、複雑化

6 Item Detail VC ● Show Product Images ● Show Product Name ● Show Brand Name if available ● Show Price ● Show Merpay Balance if available ● Call Like API ● Navigate to comment screen ● Call purchase API …. And more

7 Micro View Controllerとは？ ● どのようなアーキテクチャでも、ビジネスロジックが増えれば各レイヤーは肥大 化する。 ● 一つのVCを複数のVCに分けることができれば、一つのVCに入るロジックを減 らすことができるのではないか。

8

9 Product Image VC ● Show Product Images Product Name VC ● Show Product Name ● Show Brand Name if available Product Price VC ● Show Price ● Show Merpay Balance if available Like Button VC ● Call Like API Comment Button VC ● Navigate to comment screen Purchase Button VC ● Call purchase API

10 Micro View Controllerとは？ ● 一つの画面を複数のView Controllerに分ける。 ● それらのVCのViewをUIStackViewでつなげ、UIScrollViewにのせる。 ○ 各VCが自分のViewのサイズを決定 ○ 親VCが最終的なContent Sizeを決定 ● UIStackViewでUIViewControllerをつなげる部分(ContainerView)や Input, Output, Dependency Injectionに関するProtocol等を共有 Frameworkとして提供する。

11 Mercariの組織 出品 商品詳細 ホーム マイページ カテゴリ 特化 etc...

12

13 並行開発やABテスト ● ABテストの結果、機能を採用しない場合は、関連するロジックはすべてView Controller内にカプセル化されているので、View Controllerごと消すことが できる。

14 効果 ● 各View Controllerのコード量の減少 ○ 共有できるレイアウトのロジックはDesign Systemとして提供する。 ○ 共有できないログ、API、遷移などのロジックはVC内に記述し分散させる。 ● 表示速度の改善

15 Item Thumbnail ● Log, Navigation, UIContextMenuのロジックがカプ セル化されている。

16 めでたしめでたし？

17 １．Stateの管理

18 Stateの管理 ● View ControllerそれぞれがStateの型を持っていた。 ● Stateを同期するため、シンプルなVCでもコード量が多かった。 ○ 例：いいねボタンのState

19

20

21 FLUXライクなArchitecture ● Store, Action, Reducerから構成される。 ● 大きな単位のVCがStoreのインスタンスを保持する。

22

23 効果 ● Stateを同期させることが簡単になる。 ● 複雑なReactive Frameworkのコードの減少。 ● Stateの変化が理解しやすくなる。

24 ２．ViewControllerとViewの区別

25 ViewControllerの深いネスト ● 細かくView Controllerを作りすぎると、単純なViewでもコードのオーバーヘッ ドが多くなったり、View Controllerがネストしてコードの見通しが悪い。 ● Viewにすべきか、View Controllerにすべきか。ロジックの量で各チームが判 断。

26 ３．組織とArchitecture

27 背景 ● 2018年、Re-Architectureと同時期に組織が大きくなった。 ● メンバーの価値観が多様化。 ● Design SystemやDeclarative UIがチーム内でも注目され始める。

28 sections.append(contentsOf: [ .group([ .detailPush(title: "My profile".localizedString, selectionBlock:pushToMyProfile), .detailPush(title: "Saved and viewed items".localizedString, selectionBlock:pushToMyLikesAndViews), .detailPush(title: "Listings".localizedString, selectionBlock:pushToMyListings), .detailPush(title: "Purchases".localizedString, selectionBlock:pushToMyPurchases), .detailPush(title: "Instant offers".localizedString, selectionBlock:pushToInstantSales) ]), .gap(), .group([ .detailPush(title: "Settings".localizedString, selectionBlock:pushToSettings), .detailPush(title: "Support messages".localizedString, selectionBlock:pushToMercariNews), .detailPush(title: "Help centre".localizedString, selectionBlock:pushToHelpCenter) ]), .gap() ])

29 論点 ● 組織の開発スタイルや規模にどれだけマッチしているか ● On-Boardingのしやすさ ● 実装のスピード ● データフローのつかみやすさ ● Testability ● PlatformのAPI（UIKit）は直接使いやすいか ...etc

30 結論 ● アーキテクチャに正解はない。 ● 各View ControllerのInput, Output, Dependency Injectionに関する Protocolは統一されているが、内部のArchitectureはある程度各チームの裁 量に任せる。

31 Micro View Controllerの応用 (Home)

32

33

34 新しいHome ● 様々なコンポーネントが柔軟に追加できる。 ● コンポーネントの出し分けがbackendから操作できる。 ● Stateが変更された際、差分がなめらかにUIに反映される。

35 UIStackView vs UICollectionView ● UIStackViewはsub viewが自分でviewの大きさを決めるのに対して UICollectionViewは親がsub viewの大きさを決める（self-sizingを使わな ければ）。 ● UICollectionViewはDifference UpdateにUIKitがアニメーションをつけて くれる。 ● UICollectionViewの場合、sub viewのインスタンスは見た目よりも多く作ら れる。

36 まとめ ● Mercari iOSのアーキテクチャ ○ Micro View Controllerによるロジックの分散、カプセル化 ○ 各View ControllerのInput, Output, Dependency Injectionに関す るProtocolの統一 ○ StoreによるStateの同期 ○ UIStackViewやUICollectionViewによるContainerViewの仕組み

37 Thank you!