こんにちは、マルチデバイスチームの小林(@bakobox)とデジスマチームの荒谷(@_a_akira)です。
エムスリーは、iOSDC Japan 2023はゴールドスポンサー、DroidKaigi 2023ではサポーターとして協賛させていただきました。 小林はiOSDC・DroidKaigi両方、荒谷はDroidKaigiにオフライン参加しましたので、それぞれのレポートをしていきたいと思います。
iOSDC
iOSDCは小林が担当します。
私はDAY1・DAY2はオンライン、DAY3はオフラインで参加させていただきました。 コロナ禍に新卒で入社したこともあり、オフラインでエンジニア同士で交流する機会はなかなか無く、とても良い経験になりました！
また、LT大会にて初めてペンライトを振りました笑
面白かったセッション
私が聞いたセッションの中からいくつかピックアップし、感想とともに紹介させていただきます。 ニコニコ動画に課金したので、見られなかったセッションも後で見ます！
Swift Packageを使った巨大な依存グラフのキャッシュ戦略
- コードが200万行以上
- Xcodeプロジェクト数が300個以上
- ビルド済みフレームワーク数が150個以上
といった超巨大なLINEアプリのビルド環境についての発表でした。
巨大なプロジェクトではビルド時間が問題になります。 bazelというビルドツールを利用することでビルド時間の短縮に成功しましたが、 次第にbazelのメンテナンスコストが膨れ上がり、新たなビルドツールScipioの開発を決断したとのことです。
XcodeとSwiftPMの仕組みに乗っかったツールであるため、
- それらがメンテされてる限りは壊れにくい
- Scipioの使用を辞めやすい
といった点が素晴らしいと感じました。
弊社ではSwiftPMへの移行を進めております。詳しくはこちらをご覧ください。
こういうのは標準APIでいいよね
やりたいことに対して大きすぎるライブラリ・利用箇所が少ないライブラリの使用をやめたり、用途が重複しているライブラリを１つにまとめたり、そもそも使われていないライブラリを削除していった結果、依存ライブラリの数が44 -> 15に減ったというお話でした。 標準APIで置き換えられる箇所が多くあったようです。
また副次的な効果としてクラッシュ率・ビルド時間・起動時間・アプリサイズが改善したそうです。
ライブラリを導入する前に、
- ちゃんとメンテナンスされているか
- 将来置き換えるとなったときに剥がしやすいかどうか
- 標準APIで代用できないか
などを考えるのは重要だと改めて感じました。
メルカリ10年間のiOS開発の歩み
メルカリアプリの初期開発から現在に至るまでの歴史をGitのコミットログとともに紹介されていました。
2018年から2019年にかけて行われたリアーキテクチャが終わってすぐに、アプリをゼロから書き換えるプロジェクトが始動したという興味深いお話も聞くことができました。
弊社でも大規模なリファクタリングが行われていました。詳しくはこちらをご覧ください。 www.m3tech.blog
Xcode Previewを気軽に利用するためのDI戦略
SwiftUIでDIをする場合、Initializer Injectionと@Environmentを使った手法が考えられますが、
Initializer Injectionでは、
- 子Viewの依存をルートのViewからバケツリレーのような感じで渡していく必要があり、数が増えると大変
- どのViewにどの依存が必要なのかの把握が難しくなる
@Environmentでは、
- 必要な依存を渡していなくてもコンパイルエラーにならず、実行時エラーが起きる
- initでアクセスできない
という問題がそれぞれあります。この発表では、それらの問題を解決する良いとこ取りの手法が提案されています。
そして、この発表スライドがSwiftUIで作られていることに驚きです。
おまけ
弊社のノベルティグッズは医療系IT企業ということでマスクでした。諸事情により一部の方にのみ配られていたらしいです。入っていた方はラッキーです！
DroidKaigi
DroidKaigiは荒谷が担当します。
DroidKaigiは第1回から全部参加しているのですが、コロナ禍でオンラインが主流になってからはその他のオフラインイベントにも参加していなかったので、実に4年ぶりのオフラインカンファレンス参加でした。
物理的な制約がないオンラインの方が良いなと思っていたのですが、久しぶりにオフラインカンファレンスに参加して、現地でしか味わえない臨場感だったり熱気を感じることができ、オフラインも悪くないな、参加して良かったなと思えるイベントでした。
特にDroidKaigiは運営の方の努力が凄まじく、参加者にとにかく楽しんでもらおうという気持ちが凄く伝わってくるイベントだなーと毎回感じています。
スタッフの皆様いつもありがとうございます！
面白かったセッション
2日間私が聞いたセッションの中で面白かったのをいくつかピックアップしました。 同時に4セッション行われていたので、同時刻で見れなかった残りの3つのセッションも後日動画で見たいと思います。
作って学ぶadbプロトコル (Day1 13:20)
Android開発をしていれば必ず利用するadbですが、仕組みを意識したことはなかったのでとても勉強になりました。 プロトコルを実装しながら解説してくれているので、adb初心者にもわかりやすく、仕組みを学びたい方におすすめです。
Kotlinハイパフォーマンスプログラミング (Day2 11:00)
map等のCollectionクラスにある拡張関数が中でリストを再生成しているのは知っていたのですが、高速化を厳密にやったことがなかったので、 SequenceやforEachで具体的にどのくらい速度が違うのかわかって面白かったです。
中規模アプリにおけるレイヤードアーキテクチャでの例外との向き合い方 (Day2 16:00)
異常系のハンドリング方法が丁寧にまとめられていて、Androidに限らず参考になる内容だと思いました。
Flutterですが、私が担当している デジスマ診療アプリでもほぼ似たような構成になっていて、
インフラ層で発生したエラーや、ドメイン層でのビジネスロジックのエラーを同層で独自のエラーにマッピングしてUI層で任意の形で表示する仕組みを作っています。
セッションでは述べられていませんでしたが、こうすることでUI層で表示方法を切り替えるだけなので多言語化も楽に対応できると思います。
Material 3 やめました (Day2 17:00)
Material Design 3を省略してM3(エムスリー)と呼ぶのですが、yanzmさんがセッション中に何回もエムスリー辞めましたって言っていたので、ドキドキしながら聞いていましたｗ
弊社名はエムスリーなので当然？M3対応をしたのですが(一部アプリのみ)、たしかにM3は色の使い分けが難しく、色に関してはほぼ上書きして使っています......
テキストのスタイルはSubTitle1, SubTitle2, Body1, Body2よりはTitleLarge, TitleMedium, TitleSmallのように使う場所とサイズの指定になってわかりやすくなったので、個人的にはM3の方が好きです。
これからM3対応しようとしている人にはとても参考になる内容だと思います。
まとめ
スタッフ・スピーカーの皆様、本当にありがとうございました。勉強になったことはもちろん、とても良い刺激になりました！ 残念ながら弊社からスピーカーとして参加したメンバーはいませんでしたが、来年は狙っていきたいと思います！
We are hiring!
エムスリーでは、技術イベント好きなエンジニアを募集しております！ 興味を持った方、ご応募お待ちしています！
