ラクマのアプリで「出品時間の削減」を行った実装の裏側

ラクマのiOSエンジニアをしている鶴田です。

ラクマでは、常に新規開発のプロジェクトが走っており、毎月のように新しい機能が導入されています。
ただ、開発と並行して技術的な負債とも向き合ってきました。

ラクマiOSアプリのフルSwift化を約4年かけてやり遂げた話 | 楽天グループ株式会社ラクマ事業部

こんにちは。楽天ラクマモバイルアプリケーション開発グループのdarquroです。今回はラクマiOSアプリのフルSwift化を、約4年かけてやり遂げた話を書きたいと思います。私は2018年10月1日に楽天グループに入社しました。当時採用面接で驚いたのは、アプリエンジニアのチーム体制を聞いたところ、iOS1名、Android1名という状態だったことでした。 ...

https://www.wantedly.com/companies/rakutenrakuma/post_articles/427902

最近では、そんな負債も減ってきたため、新規機能の開発へ大きく時間を割くことができています。
その中でも、最近リリースした機能とその裏側について、今回はご紹介したいと思います。

出品時間の削減

「出品時間の削減」は元々ラクマは4枚のみ出品画像を追加できる仕様となっており、1枚ずつアップロードすることが前提のAPI設計となっていて、その仕様がDBのレコードの順番にも依存していました。

そのため、並列アップロードを実現するには、サーバーサイドのAPIとDBの設計まで大きく書き直す必要がありました。なぜなら、サーバー、フロントエンド、アプリと多くのチームを巻き込んで同時に実装を修正する必要があったからです。

ここ数ヶ月は、その重い腰をようやく上げて、チーム一丸となって取り組んできました。

- どうやって削減するのか？

出品時間で一番のネックとなるものは、画像のアップロードでした。

商品が持つ他の情報（タイトル、説明、状態など）はデータとして軽量なため、そこまで問題にならなかったのですが、画像の場合はデータの容量もあり一度の出品で最大10枚までアップロードできるため、画像が多ければ多いほど出品時間が増加するからです。

そこで、現状は画像を１つずつアップロードしていたものを、並列化してアップロードすることで、高速化を実現しようと考えました。

As Is

To Be

- 技術選定に関して

今回は、主にiOSアプリ面からみた並列化実装の話をします。

並列化の実装を行う上で、技術の選択肢は２つありました。

Combine による並列化
Concurrency による並列化

今回は Combine の実装方法を取りました。

【理由１】

先ほども述べた通り、並列化実装は兼ねてより（2020年から）想定していましたが、まだ Objective-C が残っており、画像の API Client もその中の１つでした。当時は Concurrency がネイティブでは用意されておらず、Combine がネイティブでサポートされた直後だったこともあり、それを念頭に Combine でリファクタリングを行いました。

そのため、画像の API Client は現在 Combine で実装されており、Concurrency にする場合は書き換える必要があります。

【理由２】

簡易な Concurrency による書き換えをトライしてみましたが、１つ問題がありました。それは、並列実行の進捗状況をどのようにハンドリングするかです。

並列実行中の Concurrency で進捗状況を取る場合、呼び出し元に進捗状況を伝える方法を別途作成する必要があります。クロージャーを渡すことでそれは可能ですが、処理が汚くなってしまい Concurrency のメリットが薄れてしまうため、Concurrency で実装することは適切ではないという結論になりました。